Hacker News Reader

Hacker News

Comment by WalterBright | Hacker News Reader

Parent Full thread

WalterBright

We don't have a marketing budget, although we have many hard core users!

View on HN

Is that really it? Why cannot you get a marketing budget, sponsored perhaps?

BTW:

I am not fond of stuff like:

  // Sort lines
  import std.stdio;
  import std.array;
  import std.algorithm;

  void main()
  {
      stdin
          .byLine(KeepTerminator.yes)
          .uniq
          .map!(a => a.idup)
          .array
          .sort
          .copy(stdout.lockingTextWriter());

Are there any ways to do this that do not involve a bunch of "."s? I do not understand "map!" and "a.idup" either, FWIW.

I really want to like D, but it tries to do too many things all at once, in my opinion.

Perhaps I will give C3 a fair try.

That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

`map` is an operation on a data structure that replaces one element with another, in this case `a` gets replaces with `idup(a)`. The `idup` makes a copy of its argument in memory, and marks the data is immutable.

> That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

How would it look like with this particular code? Just for comparison.

> The `idup` makes a copy of its argument in memory, and marks the data is immutable.

How is one supposed to know this? Reading the documentation? I really want to look at the code and be able to know straight away what it does, or have a rough idea.

See https://en.m.wikipedia.org/wiki/Uniform_function_call_syntax - the examples section has two side by side. The Nim language version is also pretty readable even if you're not familiar with it.

As for idup... The first several search results for "dlang idup" are all useful.

> I really want to look at the code and be able to know straight away what it does, or have a rough idea.

I presume you really don't like perl, ML based (ocaml, f sharp, rust) Haskell or K.

I love Perl[1] and OCaml. I dislike the rest. It depends on the task.

[1] https://news.ycombinator.com/item?id=44359539

> As for idup... The first several search results for "dlang idup" are all useful.

Yes, I am sure it was, I am sure an LLM would have helped too, but I think that is besides the point here.

Is it beside the point? Looking at that perl example:

$string =~ s/\d+/NUM/g;

I don't have a clue what is going on. Sure, I see the regex, but what is =~ doing?

There's only so far you can stretch most languages before you need to actually put in effort to learn them.

"=~" is the operator testing a regular expression match. It should be obvious, because on the right side you see regex, and you ought to know what "=" or "==" does.

FWIW, I knew this as a kid, too, despite knowing absolutely nothing about the language at the time.

Anyways, you should read https://news.ycombinator.com/item?id=44463391 if you care about why I dislike the way D does it.

> > That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

> How would it look like with this particular code? Just for comparison.

I do not know how to write D, so the following might not compile, but it's not hard to give it a go:

    copy(sort(array(map!(uniq(byLine(stdin, KeepTerminator.yes)), a => idup(a)))), stdout.lockingTextWriter())

> > The `idup` makes a copy of its argument in memory, and marks the data is immutable.

> How is one supposed to know this? Reading the documentation? I really want to look at the code and be able to know straight away what it does, or have a rough idea.

Are you serious? You are offended by the idea of reading documentation?This is not helping the credibility of your argument. Again, I'm not a D user, but this is just silly.

> Are you serious? You are offended by the idea of reading documentation?This is not helping the credibility of your argument. Again, I'm not a D user, but this is just silly.

If you knew me, and you read my comment history, you would have NEVER said that. It is not even a matter of reading the documentation or not. "idup" seems arbitrary, sorry, I meant the whole line sounds arbitrary. Why "a"? Why "a.idup"? Why "map!"? I was asking genuine questions. You do not have to bash me and see ghosts. I was curious as to why it was implemented the way it was.

I am an active speaker against people who hate reading the documentation.

And FYI, I love Perl[1] and OCaml[2].

[1] https://news.ycombinator.com/item?id=44359539

[2] You would have to check the comment history.

I think perhaps you are not realising the negative tone of your comments. There is no way to read "How is one supposed to know this? Reading the documentation?" except sarcasm. No amount of good faith in unrelated comment threads changes this. I believe that's why you're getting downvoted - not because people are easily offended about D, as you seem to believe.

Well, I did not intend my statement to be sarcastic. It was a genuine question. Blame my lack of social skills, or the fact that I am on the spectrum. I was curious about the implementation details, i.e. why "!" (in map), why "a", why "idup", etc. That is not to say I am reluctant to read the documentation, I am more than willing, but I wanted to know the story behind it. I have ideas, but they might be wrong. I do not want to guess when I can have a direct answer from Walter.

a!arg is used because I hated the look of a<arg> used in C++. (Using < > to bracket things when < means less than and > means greater than is always trying to short-circuit my brain.)

What makes the choice of < > for template parameter bad appears when someone tries to nest templates.

     a<b<arg>>

and now a means greater becomes a shift right. That's one of the reason that it you had a genious ideo to find domething else in D

a(template params)(runtime params) at declaration a!(template params)(runtime params) at invocation with the type deduction and parenthesis omission making often even disappear completely the template syntax.

thank you

> Why "a"

`a` is a parameter in the lambda function `a => a.idup`.

> Why "map!"

This is definitely something that can trip up new users or casual users. D does not use <> for template/generic instantiation, we use !. So `map!(a => a.idup)` means, instantiate the map template with this lambda.

What map is doing is transforming each element of a range into something else using a transformation function (this should be familiar I think?)

FWIW, I've been using D for nearly 20 years, and the template instantiation syntax is one of those things that is so much better, but you have to experience it to understand.

> "idup" seems arbitrary

Yes, but a lot of things are arbitrary in any language.

This name is a product of legacy. The original D incarnation (called D1) did not have immutable data as a language feature. To duplicate an array, you used the property `dup`, which I think is pretty well understood.

So when D2 came along, and you might want to duplicate an array into an immutable array, we got `idup`.

Yes, you have to read some documentation, not everything can be immediately obvious. There are a lot of obvious parts of D, and I think the learning curve is low.

Thanks for the reply.

> Yes, but a lot of things are arbitrary in any language.

I disagree, but to each their own.

> Yes, you have to read some documentation, not everything can be immediately obvious.

I do not disagree, but I wanted to know the rationale behind it ("map!(a => a.idup)")!

> I am an active speaker against people who hate reading the documentation.

How is one supposed to know this?

I dunno, check my comment history if you are so curious. Been down-voted for daring to say that people should be less reluctant to read documentation.

I refer you to the context of this discussion—how it is we got to be here:

> How is one supposed to know this? Reading[…]?

Are you asking me to find the comment where I stated that I "dislike" people who are reluctant to read documentation?

No.

> Reading the documentation?

Yes?

> I really want to look at the code and be able to know straight away what it does, or have a rough idea.

You said elsewhere that you love Perl. Would you say your sentence above applies to Perl?

It does not, but Perl is a much older language, and I have familiarized myself with it through actual discourses regarding its syntax, implementation details, and so forth. But in this thread? All I got was wrongful accusations and down-votes. I am done replying to this thread. Should have just let Walter reply, but that was not enough for you people, was it?

Funny though, because most of the things these people accuse me of are dead wrong, and my comment history is proof of that. In fact, I have been down-voted to oblivion for telling people to read the documentation. I guess we may have come full circle.

Glad we had this utterly pointless chat.

I'm not a D user and I don't have a ball in this game. I just found your critique of D's syntax rather odd because it can be applied to basically any language one is not already familiar with. Maybe I'm wrong, but I don't think my response was particularly rude...

I mean, to me it just looks ugly. Perhaps written in a different way, it would have been better. I have seen Haskell and Elixir code, but they were much less ugly.

Then again, it is entirely subjective, and we should not argue about taste.

To each their own.

I don't think you're wrong, I have used D for 19 years and don't really use the UFCS dot style, it requires too much context. Just loops are more readable. In D you don't have much decisions forced on you tbh.

I appreciate it.

I just wrote a somewhat bigger program in D and I mostly used UFCS chains for the toString() overrides to have better debug outputs. There are also some idiomatic forms that are frequent like conversion bar = foo.to!int is much more readable than bar = to!int(foo)

So it's basically a pipe or like the pipe operator in some languages? Looks interesting.

It has a fairly direct analogy in some languages. A C♯ programmer reading the above will immediately recognize the analogy to .Select(), .ToArray(), and so forth from LiNQ.

* https://learn.microsoft.com/en-gb/dotnet/api/system.linq.enu...

Yup, it looks and behaves very much like Unix piping.

You don’t like instance functions?

I do not like this in particular:

  stdin
        .byLine(KeepTerminator.yes)
        .uniq
        .map!(a => a.idup)
        .array
        .sort
        .copy(stdout.lockingTextWriter());

I would like to emphasize that this is a personal preference. No need to continue to bash me over it.

I prefer Elixir's |> operator, if you want an example of something I prefer.

And yet... Perl is good with its chained operators acting on lists?

    print join '',
        sort { $a cmp $b }
        grep { !$seen{$_}++ } # = uniq
        <STDIN>;

I do not write such Perl code, but I have in the past.

Oh and by the way, it does not look that different from that of Rust. :) I have came across a lot of Rust projects.

What’s the difference?

    stdin
      |> byLine(yes)
      |> uniq
      |> map(a => aidup)
      |> array
      |> sort
      |> copy(stdout)

I’m sorry if you took it as bashing. It’s mere curiosity as I’ve never seen that preference before.

Is it a fair comparison? Would it work in Elixir? I have not seen it in Elixir projects as such.

Adjusting for the actual Elixir functions, yes that would work. That's how Elixir's |> works, it takes the value from the left and passes it as the first argument to function on the right. Which is what the chain of calls in D is doing.

Thanks. I don’t know elixir.

I have not yet seen such long chains in Elixir. Could you show me a project where it is used?

"map(a => aidup)" caught me by surprise, too. Would Elixir do such a thing?

For what it's worth, in Elixir you might write something along the lines of the following (this is a rough translation, I haven't tested it):

  IO.stream(:stdio, :line)
  |> Stream.map(&String.trim_trailing/1)
  |> Enum.uniq()
  |> Enum.map(&String.duplicate(&1, 1))
  |> Enum.sort()
  |> Enum.each(&IO.puts/1)

This is not equivalent in style or presentation to:

  stdin
      .byLine(KeepTerminator.yes)
      .uniq
      .map!(a => a.idup)
      .array
      .sort
      .copy(stdout.lockingTextWriter());

Personally, I find the D version visually unappealing (and confusing), especially the way "stdin" sits alone on its own line, followed by a sequence of indented method calls. The excessive use of dots combined with the indentation structure makes it look, to me, rather awkward.

That is just my own opinion.

You can format it whatever way you like. D does not use formatting to impose semantic meaning.

Look, I will not comment on D any further because it seems like it gets down-voted for no reason. Take your positive comments if you so wish, no need to down-vote the ones that express different opinions. You won. I will not be commenting on it any further. I shall NEVER be expressing my opinions on this language, nor will I ever raise any questions regarding the motivation for its implementation details.

People are too quick to use the "down-vote" button, and are too quick to judge. I love documentation, I write them. I am an active speaker against people who hate reading the documentation. This was not a case against reading documentation, yet people - wrongfully - believed so. People always glance past things like: "not fond of", and "in my opinion". It is tiresome.

This thread could have been educational, but instead it was a thread meant to bash me. It is my fault.

I wish you did have the marketing. I first read about D 10+ years ago and I continue to be disappointed that it never really took off. Having those hardcore users is great, but a language really is best with a thriving community and ecosystem. Languages like Go and Rust had the benefit of being able to kickstart those by having the backings of Google and Mozilla.

Reply on news.ycombinator.com