www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Reasons to use D

reply "Chris" <wendlec tcd.ie> writes:
Out of curiosity I searched for "reasons to use D" and I found 
this:

http://blog.pluralsight.com/d-programming-language-explained

This paragraph called my attention:

"At the same time, D doesn’t get all New Age on you: It doesn’t 
try to be multi-paradigm, it doesn’t claim “five percent better 
than C” performance, nor does it provide any language features 
that dramatically alter the existing object-oriented programming 
status quo."

Sorry, but D _is_ multi-paradigm and it does challenge (not 
actively though) the OOP "status quo". I haven't written a class 
for a long time now, and I don't really miss it. D does not go 
against OOP in an ideological kind of way, but it clearly shows 
other ways of doing things.

I like this one:

"Users of D host an annual D language conference, but they mainly 
communicate online."

If you are lucky, you can watch them in their natural habitat. 
Their mating habits are still a mystery to scientists.

The article is not that old, you know (May 2014).
Sep 11 2015
next sibling parent reply "Jack Stouffer" <jack jackstouffer.com> writes:
On Friday, 11 September 2015 at 11:52:20 UTC, Chris wrote:

 Out of curiosity I searched for "reasons to use D" and I found 
 this:

 http://blog.pluralsight.com/d-programming-language-explained

 This paragraph called my attention:

 "At the same time, D doesn’t get all New Age on you: It doesn’t 
 try to be multi-paradigm, it doesn’t claim “five percent better 
 than C” performance, nor does it provide any language features 
 that dramatically alter the existing object-oriented 
 programming status quo."

 Sorry, but D _is_ multi-paradigm and it does challenge (not 
 actively though) the OOP "status quo".


It's ironic, BECAUSE D is multi-paradigm it allows the author to 
believe it's not. When you have a C like syntax and a language 
that allows you to write your Java like code, and if you don't 
know about ranges, then I can easily see how this could be the 
author's opinion.
Sep 11 2015
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 11 September 2015 at 12:07:47 UTC, Jack Stouffer wrote:


 It's ironic, BECAUSE D is multi-paradigm it allows the author 
 to believe it's not. When you have a C like syntax and a 
 language that allows you to write your Java like code, and if 
 you don't know about ranges, then I can easily see how this 
 could be the author's opinion.


You have a point there. But then again, if you don't know about 
ranges and all the other nice things in D, you shouldn't stick 
out your head like this.
Sep 11 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 11 September 2015 at 11:52:20 UTC, Chris wrote:

 Out of curiosity I searched for "reasons to use D" and I found 
 this:

 http://blog.pluralsight.com/d-programming-language-explained

 This paragraph called my attention:

 "At the same time, D doesn’t get all New Age on you: It doesn’t 
 try to be multi-paradigm, it doesn’t claim “five percent better 
 than C” performance, nor does it provide any language features 
 that dramatically alter the existing object-oriented 
 programming status quo."

 Sorry, but D _is_ multi-paradigm and it does challenge (not 
 actively though) the OOP "status quo". I haven't written a 
 class for a long time now, and I don't really miss it. D does 
 not go against OOP in an ideological kind of way, but it 
 clearly shows other ways of doing things.


Then again, there are a lot of multi-paradigm platforms. I think 
C++ apologizers  say  "C++ is multi-paradigm" where others say 
"C++ is a messy hack". It sounds better.

Multi paradigm: JVM, .NET, Common Lisp... even JavaScript could 
be framed as multi paradigm. Single paradigm: Forth, Scheme... 
And... eh?

Here is another source for external D evaluations I missed, 
January 2015:

http://developers.slashdot.org/story/15/01/20/2026221/is-d-an-underrated-programming-language

I find the viewpoints of the student who wrote 18000 lines of D 
code interesting.
Sep 11 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 11 September 2015 at 12:30:42 UTC, Ola Fosheim Grøstad 
wrote:

 I find the viewpoints of the student who wrote 18000 lines of D 
 code interesting.


"3. The documentation poor."

I agree.... but so is the documentation for virtually everything 
else I've ever used too. I'd take D's over Ruby's for example.
Sep 11 2015
next sibling parent reply "Namespace" <rswhite4 gmail.com> writes:
On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe wrote:

 On Friday, 11 September 2015 at 12:30:42 UTC, Ola Fosheim 
 Grøstad wrote:

 I find the viewpoints of the student who wrote 18000 lines of 
 D code interesting.


 "3. The documentation poor."

 I agree.... but so is the documentation for virtually 
 everything else I've ever used too. I'd take D's over Ruby's 
 for example.


JQuery, PHP, C++? That the nicest docs I've ever seen.
Sep 11 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 11 September 2015 at 13:35:07 UTC, Namespace wrote:

 JQuery, PHP, C++? That the nicest docs I've ever seen.


C++ tends to be nice, yes. PHP isn't really any better than D, at 
least not when I was using it a few years ago.

jQuery has burned me in the past. Take this page for example: 
http://api.jquery.com/html/

Tell me what it doesn't tell you... well, unless you know, you'll 
fail. And waste hours debugging some code that works perfectly 
fine with the browser's innerHTML property yet fails with 
jQuery's .html().


No docs are better than subtly wrong docs.
Sep 11 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 11 September 2015 at 13:51:55 UTC, Adam D. Ruppe wrote:

 jQuery has burned me in the past.


BTW this is the lesson I've learned: have a couple examples for 
the most common case, ready to be copy/pasted AND explicitly call 
out the weird edge cases with examples learned from debugging 
experience.

For example, D docs should demonstrate patterns of compiler 
errors produced by common misuse. Make it so when someone 
searches the vomit dmd spews, it shows them the official doc 
saying "this is why it happened, what it means, and how to fix 
it".

Tutorials should immediately accustom people to seeing compiler 
errors by guiding them into, then back out of, various error 
situations.


If only I have three months wherein I didn't have to do anything 
else.... I'd actually really like to write a lot of D 
documentation.
Sep 11 2015
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 11 September 2015 at 13:51:55 UTC, Adam D. Ruppe wrote:

 On Friday, 11 September 2015 at 13:35:07 UTC, Namespace wrote:

 JQuery, PHP, C++? That the nicest docs I've ever seen.


 C++ tends to be nice, yes. PHP isn't really any better than D, 
 at least not when I was using it a few years ago.

 jQuery has burned me in the past. Take this page for example: 
 http://api.jquery.com/html/

 Tell me what it doesn't tell you... well, unless you know, 
 you'll fail. And waste hours debugging some code that works 
 perfectly fine with the browser's innerHTML property yet fails 
 with jQuery's .html().


 No docs are better than subtly wrong docs.


I don't know. I liked the PHP documentation for having user 
entries, not always correct, but often pointing out very real 
pitfalls. Of course, it is better to not have the pitfalls in the 
first place...

C++ is really bad on StackOverflow. But cppreference.com is good 
and accurate, but that's because it actually is based on a formal 
reference. So for C++ I don't need Google as much as I do when 
writing programs in Python or Javascript.

MDN and caniuseit.com are good too, I think.
Sep 11 2015
prev sibling next sibling parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Friday, 11 September 2015 at 13:51:55 UTC, Adam D. Ruppe wrote:

 jQuery has burned me in the past. Take this page for example: 
 http://api.jquery.com/html/

 Tell me what it doesn't tell you... well, unless you know, 
 you'll fail.


Does it have to do with char encodings?
Sep 11 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 11 September 2015 at 15:30:05 UTC, Sebastiaan Koppe 
wrote:

 Does it have to do with char encodings?


Not the issue I hit: it has to do with the script tags being 
ripped out. It says "To set the content of a <script> element, 
which does not contain HTML, use the .text() method and not 
.html().", but it doesn't say all script in the middle of the 
html will be ripped out too.

The way I read that was $("script").html() is wrong and you 
should use $("script").text(). OK, script tags are implicitly 
cdata so indeed it might be different.. but if you do 
"div".innerHTML = "<script>sdasd</script>" in the browser, it all 
works!

So when it said "This method uses the browser's innerHTML 
property", I wasn't expecting it to behave significantly 
differently!
Sep 11 2015
parent reply "skoppe" <mail skoppe.eu> writes:
On Friday, 11 September 2015 at 19:54:55 UTC, Adam D. Ruppe wrote:

 On Friday, 11 September 2015 at 15:30:05 UTC, Sebastiaan Koppe 
 wrote:

 Does it have to do with char encodings?


 Not the issue I hit.


Ah, forget about my suggestion, I misread something on the link 
you send.


 So when it said "This method uses the browser's innerHTML 
 property", I wasn't expecting it to behave significantly 
 differently!


That is not the only way it behaves differently. jQuery's html() 
will actually execute inline script, whereas innerHTML won't.

Coming back to the thread's title, jQuery is a perfectly valid 
reason to use D. Sad that there is no proper way to do modern web 
development in D.
Sep 11 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 12 September 2015 at 03:52:11 UTC, skoppe wrote:

 That is not the only way it behaves differently. jQuery's 
 html() will actually execute inline script, whereas innerHTML 
 won't.


I'm pretty sure it is the other way around...
Sep 11 2015
parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Saturday, 12 September 2015 at 04:05:44 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 12 September 2015 at 03:52:11 UTC, skoppe wrote:

 That is not the only way it behaves differently. jQuery's 
 html() will actually execute inline script, whereas innerHTML 
 won't.


 I'm pretty sure it is the other way around...


I suppose you mean changing the contents of an existing script 
element. I was talking about inserting a new inline-script via 
html().

Run this in the console on this page:

$("#copyright").html("<script>alert(42);</script>");    // shows 
42
document.querySelector("#copyright").innerHTML = 
"<script>alert(42);</script>";    // nothing
Sep 12 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 12 September 2015 at 11:36:47 UTC, Sebastiaan Koppe 
wrote:

 I suppose you mean changing the contents of an existing script 
 element. I was talking about inserting a new inline-script via 
 html().


oh yeah, you are right. That's one thing I do like about D 
though: I find it so much easier to remember (perhaps because I 
wrote most the libs I use myself). I forget the difference 
between stuff like substr and substring in Javascript or chop and 
chomp in Ruby and so on. I have to refer to the docs to remember 
this stuff, even when I write it all the time.

I find D's ways to be much easier to store in the brain, despite 
D arguably being a bigger, more complex language.
Sep 12 2015
parent reply "Meta" <jared771 gmail.com> writes:
On Saturday, 12 September 2015 at 16:32:52 UTC, Adam D. Ruppe 
wrote:

 oh yeah, you are right. That's one thing I do like about D 
 though: I find it so much easier to remember (perhaps because I 
 wrote most the libs I use myself). I forget the difference 
 between stuff like substr and substring in Javascript or chop 
 and chomp in Ruby and so on. I have to refer to the docs to 
 remember this stuff, even when I write it all the time.

 I find D's ways to be much easier to store in the brain, 
 despite D arguably being a bigger, more complex language.


Maybe because the static type system allows for overloading and 
so all of these utility functions don't have to do a million 
different things depending on what you pass to them.
Sep 12 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 12 September 2015 at 16:34:42 UTC, Meta wrote:

 Maybe because the static type system allows for overloading and 
 so all of these utility functions don't have to do a million 
 different things depending on what you pass to them.


Yea. Another huge thing to me is the slice operator. I use it for 
a lot of stuff and it is consistent for strings and other arrays. 
(well, utf issues aside, but D's rule there is simple enough to 
remember too)
Sep 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 12 September 2015 at 18:23:55 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 12 September 2015 at 16:34:42 UTC, Meta wrote:

 Maybe because the static type system allows for overloading 
 and so all of these utility functions don't have to do a 
 million different things depending on what you pass to them.


 Yea. Another huge thing to me is the slice operator. I use it 
 for a lot of stuff and it is consistent for strings and other 
 arrays. (well, utf issues aside, but D's rule there is simple 
 enough to remember too)


Arrayviews ("slices") are available as a type so you can do it 
like this:

a = new Uint32Array([7,2,3,6]) // a is [7, 2, 3, 6]
b = a.subarray(1,3) // b reference [2, 3]
b[0] = 8 // now a is [7, 8, 3, 6]
a.set([5,9], 2) // now a is [7,8,5,9]

Destructuring is coming too. So you can destructure arrays as if 
they are tuples. E.g.:

var a,b;
[a,b] = [2,4]
[a,b] = [b,a]

I think it might work in TypeScript or some of the other 
compilers already.
Sep 12 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 12 September 2015 at 18:44:44 UTC, Ola Fosheim 
Grøstad wrote:

 Arrayviews ("slices") are available as a type so you can do it 
 like this:


Yeah, there's also the Array.slice and String.substring that work 
kinda similarly in old standard javascript. But there's still a 
lot of type-specific verbiage in there, whereas with D, it is 
always the same [a .. $] for almost anything so it is one thing 
to remember instead of three or more.
Sep 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 12 September 2015 at 18:48:52 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 12 September 2015 at 18:44:44 UTC, Ola Fosheim 
 Grøstad wrote:

 Arrayviews ("slices") are available as a type so you can do it 
 like this:


 Yeah, there's also the Array.slice and String.substring that 
 work kinda similarly in old standard javascript.


Array.slice create value copies, not reference views. I don't 
think there is a "slice" for Array. :-/


 But there's still a lot of type-specific verbiage in there, 
 whereas with D, it is always the same [a .. $] for almost 
 anything so it is one thing to remember instead of three or 
 more.


Yes. So, let's create a TypeScript like subset of:D.

Compile GC-based D-JS -> JavaScript + TypeScript definitions.

The problem is that you might need a little bit of Dependent 
Typing in order to provide types for the browser API. I.e. return 
type depending on parameter values? Not sure.
Sep 12 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 12 September 2015 at 18:59:11 UTC, Ola Fosheim 
Grøstad wrote:

 Array.slice create value copies, not reference views. I don't 
 think there is a "slice" for Array. :-/


Right, that's why I said "kinda similarly"... the copy is really 
important if you want to mutate it, but it is good enough for 
viewing (tho poorly performing by comparsion).


 Compile GC-based D-JS -> JavaScript + TypeScript definitions.


That's basically what my D->JS thing did back in 2011.


 The problem is that you might need a little bit of Dependent 
 Typing in order to provide types for the browser API. I.e. 
 return type depending on parameter values? Not sure.


That doesn't actually happen very often, and when it does, you 
can do a function overload like string foo(string s) { return s;} 
vs int foo(int i) { return i; } and it works in D land pretty 
well. Then use a pragma(mangle) to make both refer to the same 
browser function.

That actually worked somewhat well in my dtojs but it was a mild 
hassle too once function callbacks got more involved. You can 
template them in D but then it bloats the generated JS for no 
real reason since they all have identical dynamically typed code! 
I suppose that is solvable too but i never got around to it and 
just went back to writing normal javascript. (I write small JS 
files anyway, it is an ok language for small scripts.)
Sep 12 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 12 September 2015 at 20:03:09 UTC, Adam D. Ruppe 
wrote:

 That's basically what my D->JS thing did back in 2011.


Nice, so now you will do it again in 2016 ? ;)


 That actually worked somewhat well in my dtojs but it was a 
 mild hassle too once function callbacks got more involved. You 
 can template them in D but then it bloats the generated JS for 
 no real reason since they all have identical dynamically typed 
 code!


Yes, you need to convert the D into a JS-specific IR and then fix 
it in an optimization step before code gen.

But function overloading isn't enough, unless you accept casting, 
since javascript can return anything. I guess you can use 
template parameters when you request literal strings like 
«document.createElement("div")», but in other situations it might 
be more tricky. I don't think function overloading is enough if 
you want to avoid casting.

But the TypeScript definition files might make it somewhat 
easier, and might be a good starting point as they expose typing 
issues. I don't think they are too hard to parse partially:

https://github.com/Microsoft/TypeScript/blob/master/lib/lib.core.es6.d.ts
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es6.d.ts
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.dom.d.ts
etc

Although I think one  should only include what browsers have in 
common. So it is a tedious job that probably involves writing a 
test program that test what different browsers support and upload 
results to a web server...


 I suppose that is solvable too but i never got around to it and 
 just went back to writing normal javascript. (I write small JS 
 files anyway, it is an ok language for small scripts.)


It's ok if you only write a few hundred lines of javascript, but 
the IDE code completion you get with typing really makes a 
difference.
Sep 12 2015
prev sibling parent "bachmeier" <no spam.com> writes:
On Friday, 11 September 2015 at 13:51:55 UTC, Adam D. Ruppe wrote:

 C++ tends to be nice, yes. PHP isn't really any better than D, 
 at least not when I was using it a few years ago.


I recently decided to learn PHP just to learn PHP. I can confirm 
that the official docs are definitely worse than those for D. The 
Hacker News-type comments at the bottom make me question the 
quality of the whole PHP ecosystem.
Sep 11 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe wrote:

 On Friday, 11 September 2015 at 12:30:42 UTC, Ola Fosheim 
 Grøstad wrote:

 I find the viewpoints of the student who wrote 18000 lines of 
 D code interesting.


 "3. The documentation poor."

 I agree.... but so is the documentation for virtually 
 everything else I've ever used too. I'd take D's over Ruby's 
 for example.


Ruby and Python have their documentation on Slashdot...

I wish Ali's book was available on dlang.org and cross-linked 
with documentation. I think documentation is the smaller issue 
(full language spec is a much more important priority IMHO).

But it is interesting to read these current raw viewpoints from 
people who obviously chose D as the best starting point for their 
projects, used it for a while, but somehow lost interest and feel 
a need to express their views.

If D had an asm.js backend it might be possible to create a 
"editor/compiler in your browser" tutorial. I like those. Combine 
that with shared view and live chat in the same window and you 
have a kick ass entry level solution.
Sep 11 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 11 September 2015 at 13:41:23 UTC, Ola Fosheim Grøstad 
wrote:

 Ruby and Python have their documentation on Slashdot...


StackOverflow... Duh...
Sep 11 2015
prev sibling next sibling parent "David DeWitt" <dkdewitt gmail.com> writes:
On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe wrote:

 On Friday, 11 September 2015 at 12:30:42 UTC, Ola Fosheim 
 Grøstad wrote:

 I find the viewpoints of the student who wrote 18000 lines of 
 D code interesting.


 "3. The documentation poor."

 I agree.... but so is the documentation for virtually 
 everything else I've ever used too. I'd take D's over Ruby's 
 for example.


I think the D docs are actually pretty good so I dont get why ppl 
say otherwise.  I do much prefer the "New library reference 
preview" to the standard layout for the std.  The only thing D 
needs is more examples of stuff online and easily searchable.  I 
can Google something in Python and find a number of examples 
which is nice for work.
Sep 11 2015
prev sibling parent reply "Bahman Movaqar" <b.movaqar gmail.com> writes:
On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe wrote:

 "3. The documentation poor."

 I agree.... but so is the documentation for virtually 
 everything else I've ever used too. I'd take D's over Ruby's 
 for example.


Couldn't help but to drop in and count two exceptions: Racket's 
docs[1] and Java API docs[2].

[1] http://docs.racket-lang.org/
[2] http://docs.oracle.com/javase/7/docs/api/
Sep 11 2015
parent reply "bachmeier" <no spam.com> writes:
On Friday, 11 September 2015 at 14:17:03 UTC, Bahman Movaqar 
wrote:

 On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe 
 wrote:

 "3. The documentation poor."

 I agree.... but so is the documentation for virtually 
 everything else I've ever used too. I'd take D's over Ruby's 
 for example.


 Couldn't help but to drop in and count two exceptions: Racket's 
 docs[1] and Java API docs[2].

 [1] http://docs.racket-lang.org/
 [2] http://docs.oracle.com/javase/7/docs/api/


I'd add Guile. It's fun to read the manual.
Sep 11 2015
parent "Bahman Movaqar" <b.movaqar gmail.com> writes:
On Friday, 11 September 2015 at 17:58:49 UTC, bachmeier wrote:

 On Friday, 11 September 2015 at 14:17:03 UTC, Bahman Movaqar 
 wrote:

 On Friday, 11 September 2015 at 13:15:03 UTC, Adam D. Ruppe 
 wrote:

 "3. The documentation poor."

 I agree.... but so is the documentation for virtually 
 everything else I've ever used too. I'd take D's over Ruby's 
 for example.


 Couldn't help but to drop in and count two exceptions: 
 Racket's docs[1] and Java API docs[2].

 [1] http://docs.racket-lang.org/
 [2] http://docs.oracle.com/javase/7/docs/api/


 I'd add Guile. It's fun to read the manual.


/me nods
Another fun manual is Gforth's.
Sep 12 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 11 September 2015 at 12:30:42 UTC, Ola Fosheim Grøstad 
wrote:


 Here is another source for external D evaluations I missed, 
 January 2015:

 http://developers.slashdot.org/story/15/01/20/2026221/is-d-an-underrated-programming-language

 I find the viewpoints of the student who wrote 18000 lines of D 
 code interesting.


It is interesting. However, criticism of D often revolves around 
issues that every language has (or will have sooner or later - 
see you later Rust!;)). Yet people are willing to put up with the 
deficiencies of other languages, because they are told to by a 
committee, because it's "official", because it's 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? Not to 
mention the fact that every few years there's a new C++ 
programming style that renders old code obsolete (in other words 
"What you've written so far is all crap!").

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.

A lot of it has to do with expectations. The user is 
disappointed, but what did s/he expect in the first place? A good 
example are book reviews on amazon. Some people say a book is 
crap, because there were words they didn't understand, some 
people hate a book, because they expected something like Tolkien, 
but the language was not "noble" enough for their liking. Does 
that mean the book is actually bad?

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.
Sep 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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/
Sep 11 2015
parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Friday, 11 September 2015 at 15:37:45 UTC, Ola Fosheim Grøstad 
wrote:

 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).


I never understood those TypeScript people. They would learn a 
*new* language, just to compile it into JavaScript?


 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/


Maybe there are so many tools for JavaScript, because it is so 
simple?

And if you are in the JavaScript-is-evil camp, it is already 
obvious that there are so many tools.

In either case, they are not doing better. It is their natural 
course of action.
Sep 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 11 September 2015 at 16:07:09 UTC, Sebastiaan Koppe 
wrote:

 I never understood those TypeScript people. They would learn a 
 *new* language, just to compile it into JavaScript?


It isn't a new language. It is where ECMAScript is going + 
structural typing and generics. The typing helps with catching 
errors at compile time and gives you much better IDE support 
(completion).

It would be nice to have a stricter version of it, but what is 
good about TS is that you can put static typing over existing 
code bases that are pure Javascript (and browser APIs). So it is 
very interoperable, but not strict.


 Maybe there are so many tools for JavaScript, because it is so 
 simple?

 And if you are in the JavaScript-is-evil camp, it is already 
 obvious that there are so many tools.

 In either case, they are not doing better. It is their natural 
 course of action.


Not sure what you meant by "natural course". The JavaScript/HTTP 
platform is doing better because the tool developers are forced 
to be interoperable with what is there (browsers/http).

That means it is more obvious that inventing an isolated universe 
is a bad idea, and that you need 100% interoperability to do 
well, not 50%.

If D had 100% interop with C++ then it would do much better, 
selling a 50% solution is difficult. But that would take radical 
changes...
Sep 11 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Here's another recent D mention:

http://cppcast.com/2015/09/scott-meyers/

at 16:35.
Sep 11 2015
prev sibling parent "Bahman Movaqar" <b.movaqar gmail.com> writes:
On Friday, 11 September 2015 at 11:52:20 UTC, Chris wrote:

 Out of curiosity I searched for "reasons to use D" and I found 
 this:
 [...]
 The article is not that old, you know (May 2014).


I recall when Scala came out, somebody published[1] a 
"intro/review" on Scala where he said "Scala is Haskell on JVM"; 
poor feller didn't know none of Scala, Haskell and OCaml.

The cost of publishing something online is almost 0.  This 
invites people with little to no knowledge and experience to pour 
out superficially done "reviews" in large quantities into 
Google's brain.
There are people (easy to find on Twitter) who brag about writing 
one technical review/introduction each day; this is almost 
impossible if done correctly.

I wouldn't take any of the online reviews seriously unless with a 
huge pile of rough grained salts :-)

[1] I can't find the link.  I should be thankful I suppose.
Sep 11 2015