Live data from Hacker News

D for the Win

tomerfiliba.com

81–90 of 105 posts

Re: D for the Win

#81
post #56
post #53

Earlier quoted context omitted.

Can you give a code example in Go?

Quick example on the playground, if this is what you were asking about: http://play.golang.org/p/zShJKp0t3n

So subtyping automatically happens for all members of a struct? I'm not sure I like that but I guess I'd have to see how well it works in practice.

Re: D for the Win

#82
post #74
post #68

Earlier quoted context omitted.

http://play.golang.org/p/Vl9XzK3hOS

Interesting but this is not the same feature. Go implements what seems like multiple inheritance, D simply dispatch calls to a member, which can be a pointer to T instead of T. So you can implement custom pointer types.

I have provided a better example: http://play.golang.org/p/yYg8okmN6a

Yes, it's a different feature, but is not multiple inheritance either (although I understand why, at a first glance, you'd think it would seems like that). It's just composition. In this new example, look how you can do b.myInt, even though b is now a bar, not a foo. In fact this happened in the old example too, but it was invisible. This is how the Lock function accessed the mutex.

Re: D for the Win

#83
post #81
post #56

Earlier quoted context omitted.

Quick example on the playground, if this is what you were asking about: http://play.golang.org/p/zShJKp0t3n

So subtyping automatically happens for all members of a struct? I'm not sure I like that but I guess I'd have to see how well it works in practice.

No, it only happens if you embed the type, a.i. the member is anonymous.

http://golang.org/doc/effective_go.html#embedding

http://golang.org/ref/spec#Struct_types

Note that there's also interface embedding which is a different thing.

Re: D for the Win

#85

Why did Walter choose to not open source the compiler from the beginning? I would be willing to bet that it would hold the position that Ruby/Python currently hold if he had made that choice. The ability to apt-get/yum to install a language on a cheap linux server would have done wonders for its adoption, especially in the middle of the rise of linux and the web.

The D front end is not only open sourced now, it is Boost licensed, which is the most open of the open source licenses.

Over in the D community we're very proud of our use of the Boost license.

Re: D for the Win

#86
post #73

Earlier quoted context omitted.

> syntax is really easy to most programmers who is willing to learn This is exactly how this sentence should look like, no need for any language at the beginning. While syntax does matter (and I only recently arrived at this conclusion) its "intuitiveness" or "similarity" is utterly unimportant. You either are a "real programmer" and have no problem picking up different syntaxes and semantics, or you're not. That's a…

It is important - we're not just robots doing work to eat and have where to live, we need to enjoy what we do and having pleasant syntax is what made many fall in love with Ruby. Let's not pretend syntax doesn't matter - it does, indeed, otherwise there wouldn't be Scala today either!

I agree, syntax does matter. A program should look good on the page. It's much more satisfying to write code in a language that you can craft in an eye-pleasing manner.

Re: D for the Win

#87

"The strange alias _curr this is a lovely feature of D known as subtyping. It basically means that any property that doesn't exist at the struct's scope will we forwarded to _curr, e.g., when I write myCtx.foo and myCtx has no member named foo, the code is rewritten as myCtx._curr.foo." That's a great feature. I don't see many languages investing enough focus into this kind of "delegation wiring."

Yes. It makes it easy to do things like, for example, create your own "int" type without having to duplicate all the behaviors of int. Just override the behaviors you'd like to change, then forward the rest to the wrapped int field.

Re: D for the Win

#88
post #66
post #38

Python a D have totally different use cases. Just because you can do something with Python doesn't mean you should.

Tell that to all those guys writing desktop utilities in Python slow as molasses. Every time I get some GNU/Linux GUI utility running very very slow and check the code, it is Python under the hood.

Please, it's really unfair to single out Linux GUI tools. Basic system utilities are also written in python, like yum, which masks its slowness by doing network access on each invocation and makes you think that's why it's so slow.

Re: D for the Win

#89
I have a lot of respect for Walter and for D. But having not enough time to try everything, I'm leaning towards doing a project in Nimrod[0] when I have the time.

D people who have some knowledge of Nimrod (or Nimrod people who have good knowledge of D) - where do you think D outdoes Nimrod? D is more mature, with a larger community, and a recognized brand - granted, and these are NOT trivial things -- in practice, they usually matter more than any specific feature. Yet, my question in this case IS about language/environment features.

As far as I can tell, all the examples in the article can be done at least as easily/tersely/nicely, if not more so, in Nimrod.

[0] http://nimrod-lang.org/

Re: D for the Win

#90
post #88
post #66

Earlier quoted context omitted.

Tell that to all those guys writing desktop utilities in Python slow as molasses. Every time I get some GNU/Linux GUI utility running very very slow and check the code, it is Python under the hood.

Please, it's really unfair to single out Linux GUI tools. Basic system utilities are also written in python, like yum, which masks its slowness by doing network access on each invocation and makes you think that's why it's so slow.

I singled out GUIs, because it seems to be so pervasive nowadays, as if the coders couldn't do better.
Post reply on HN