Hacker News Reader

Comment by throwaway_pdp09 | Hacker News Reader

I'll read through the article but is D really like python in any way? functionals, closures, comprehensions, decorators etc.?

View on HN

Anonymous lambdas instead of comprehensions, delegates instead of closures. D does not have decorators in the sense Python does, well function attributes might come close. What I do enjoy in D syntax-wise is UFCS: https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

Array slicing, ranges, compile-time execution. Probably the most succinct and easy-to-read syntax out of many compiled languages. It's an investment (as with any other language) but the learning curve is not steep if you get scared away by C++ or Rust for that matter. Julia comes to mind too in terms of syntax but no UFCS and its interoperability with C++/C looks like a lot of work compared to D.

UFCS is awesome, I had no idea it existed! Implicit classes are my favorite feature of scala[1], I agree .chain syntax is infinitely more readable.

[1] https://riptutorial.com/scala/example/7538/implicit-classes

Unlike in Scala, you can chain your custom methods in D.

For example, seqOfChars.map!(a => a.toLower).filterIfNotDigitChar.sort.uniq; is simply not possible in Scala.

Here is a great presentation about fp in D: http://beza1e1.tuxen.de/stuff/FunctionalD.pdf

It is possible in Scala: https://scastie.scala-lang.org/k7bHR6EWS7qXvaC8gIj3VA

(Unless you mean something different).

True. I forgot about implicits (because I try not to use them :).

Unfortunately it looks more like a kludge tbo. Sort and uniq get also hidden in a class which can be tucked away from your eyes and this is never good.

Thanks for calling my presentation "great". I don't design my slides to work without me talking though.

The official tour has a short page about FP as well: https://tour.dlang.org/tour/en/gems/functional-programming

Anyways, since Walter is probably reading this: Any new insights around this quote five years later?

> I know a lot of the programming community is sold on exclusive constraints (C++ concepts, Rust traits) rather than inclusive ones (D constraints). What I don't see is a lot of experience actually using them long term. They may not turn out so well. –Walter Bright

It would seem that D and Nim have many similar goals and features.

Yes, they are frequently compared. If you like style-insensitive (case insensitivity, underscore ignored) languages with hacker mentality, Nim is for you. This is simply a no-go for me. I briefly tried Nim before even knowing about D and it never stuck with me due to awkward syntax (subjective). Later I learnt that Nim (being a younger language) frequently breaks backward compatibility. Maybe it changed now but all the above was enough to pass it and move on.

What I dislike is the {. .} annotations, Active Oberon also followed that path and I don't find it that great.

Some context would be nice - can you say a little more on that annotation please.

That is how Nim does pragmas,

https://nim-lang.org/docs/manual.html#pragmas

And Active Oberon as well (here called flags),

http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang...

The way to interpret that statement IMO is that D is a good alternative to using a scripting language. I use it that way all the time - it's almost completely replaced Ruby, which was my previous scripting language of choice.

Reply on news.ycombinator.com