On Friday, 11 September 2015 at 15:14:55 UTC, Chris wrote:
the way it is. If not implementing breaking changes is an issue in D, why do people put up with C++'s backward compatibility then?
Because of the lack of alternatives... But it is possible to do both. It is possible to bring current D to a complete state and maintain it, and also create a subset of it.
In the JavaScript world you have various versions of JavaScript, TypeScript, TypeScript+React, TypeScript+Angular, they coexists. So, as long as you can easily interface between languages it is ok.
I think language designers should focus more on creating languages for writing libraries to use with other languages than creating host languages. I am very unlikely to use Rust and D as host languages (Swift, Objective-C, Python etc are more likely).
If D implemented breaking changes on a regular basis, the criticism would go along the lines of "One cannot use it, because the code breaks all the time, stay away from it until it's stable!". I've heard it all before.
Yes, sure. Getting what you have specced out and polished is important, because as we can see with Rust the number of contributors increase quite a lot when people sense that you are "close to being done, this is it". I guess because it is easier to defend investing "work time" then.
Then again it takes a looong time from you freeze to being totally production ready in most people's eyes. Go has been polished for 3 years and still need another year... But Go's commercial uptake is impressive for a relatively simple language. Rust needs a few more years, yep, I think so.
At least this particular reviewer of D actually used it and he or she does have points to take home and work on. However, I can't help but think that it's only from D that people expect miracles.
All languages suck at one level or another, which is why it is perhaps better to create smaller languages that interoperate with other languages really well, but I guess that vision is not so interesting, because adding a feature is easier and more fun than polishing what you have.
Often the runtime become more of an issue than the language. You don't want 4 big runtimes in the same executable.
There are good things about Perl 6 for instance, but it is just TOO big to keep in your head if you don't use it frequently. Which is a petty, because a focused string processing language would be a nice "sublanguage" to integrate with other languages.
Same thing with Haskell. I'd love to use Haskell for some very specific tasks, but not as main programming language for a project.
I think the JavaScript world is doing much better at the integration part than other platforms. There are now more and more browser-compilers where you can write code for various languages and have it compiled to JavaScript on the fly. Even OCaml:
http://zhanghongbo.me/js-demo/
