www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++17

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
Just a thought:

1. D needs capable compiler programmers.

2. Converting C++ programmers is a good recruitment strategy.

3. C++ programmers are very concerned about memory management 
features.

4. When C++17 is released, current C++ programmers will go "I was 
ready to leave C++, but I will give it a second chance now that 
it has all these new interesting features". So 2017-2018 is a bad 
period for converting C++ programmers.

It seems to me that a competitive production-ready solution that 
satisfies the current crop of C++ programmers has to be 
implemented within 6 months. When C++17 is perceived as being 
near release the psychology will be "I will wait for C++17 before 
looking at other languages".

Would it be possible to make a fully compatible 
unique_ptr/shared_ptr solution that acts as the default memory 
management scheme in D within 6 months?

If not, what is the strategy behind focusing on interfacing with 
C++? (Evaluated in relation to the C++17 release.)
Jan 26 2016
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad 
wrote:

 Would it be possible to make a fully compatible 
 unique_ptr/shared_ptr solution that acts as the default memory 
 management scheme in D within 6 months?


No that would be stupid to make that the default as it is unsafe.

Now if one want to use that, D is very capable of doing it 
already. Just won't make it the default (like it is not the 
default in C++ either).

People that don't switch because of this aren't going to swicth 
if it is added as it's already in.
Jan 26 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:

 No that would be stupid to make that the default as it is 
 unsafe.


When would you estimate that D could have a production ready 
default memory managment solution (without GC)?

When people look at a language they don't ask themselves what is 
possible, but what the main features are and how convenient it 
looks.

So from a (C/C++) marketing point of view it is better to send 
the message "excellent memory management with optional GC" than 
"GC backed memory with optional..."
Jan 26 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:

 No that would be stupid to make that the default as it is 
 unsafe.


 When would you estimate that D could have a production ready 
 default memory managment solution (without GC)?


Now, D can do the exact same as C++ .


 When people look at a language they don't ask themselves what 
 is possible, but what the main features are and how convenient 
 it looks.


It is in the standard lib, as it is for C++.


 So from a (C/C++) marketing point of view it is better to send 
 the message "excellent memory management with optional GC" than 
 "GC backed memory with optional..."


That's dumb from an engineering point of view.
Jan 26 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:

 On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:

 No that would be stupid to make that the default as it is 
 unsafe.


 When would you estimate that D could have a production ready 
 default memory managment solution (without GC)?


 Now, D can do the exact same as C++ .


Not really, but that was not the question. So let me repeat:

When would you estimate that D will have a production ready 
default memory management solution (without GC).
Jan 26 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 15:59:37 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:

 On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:

 No that would be stupid to make that the default as it is 
 unsafe.


 When would you estimate that D could have a production ready 
 default memory managment solution (without GC)?


 Now, D can do the exact same as C++ .


 Not really, but that was not the question. So let me repeat:

 When would you estimate that D will have a production ready 
 default memory management solution (without GC).


I don't think it is desirable. I do think we should focus on 
having GC.malloc/GC.free have the same level of perfs than 
malloc/free, which is very doable.

Now as to when, well, I'm waiting for your PR.
Jan 26 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote:

 I don't think it is desirable. I do think we should focus on 
 having GC.malloc/GC.free have the same level of perfs than 
 malloc/free, which is very doable.


Does this mean that you have given up on D getting an ownership 
mechanism?



 Now as to when, well, I'm waiting for your PR.


Not sure what you mean?
Jan 26 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 19:02:54 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote:

 I don't think it is desirable. I do think we should focus on 
 having GC.malloc/GC.free have the same level of perfs than 
 malloc/free, which is very doable.


 Does this mean that you have given up on D getting an ownership 
 mechanism?


There doesn't seem to be much work towards this and it doesn't 
appear to be a high priority issue. Things like catching C++ 
exceptions seem to be far higher up on the priority list than a 
defined memory model or ownership mechanics.
I see C++17 and think of why I should keep using D when C++ is 
aping a lot of its best features.
Jan 26 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:

 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.


Yes... and Rust is also maturing... So.
Jan 26 2016
prev sibling next sibling parent reply bachmeier <no spam.com> writes:
On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:


 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.


You and 99.9% of other C++ programmers. D is not going to gain 
anything from efforts to recruit C++ programmers because they 
are, in spite of claims to the contrary, very happy with the 
language. The productive path is to provide a good alternative 
that keeps them from touching C++ in the first place.
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 19:33:04 UTC, bachmeier wrote:

 You and 99.9% of other C++ programmers. D is not going to gain 
 anything from efforts to recruit C++ programmers because they 
 are, in spite of claims to the contrary, very happy with the 
 language.


That's not actually true. Many C++ programmer express a dislike 
for how the the syntax has developed over time, all the weird 
corner-cases, the obfuscated meta programming mechanisms and 
unpredictable implicitness when trying to do more advanced 
typing. Just getting the right constructor to fire can be a 
challenge.

The general C++ semantics are good enough, but the language has 
to many weird aspects to it that is "beyond repair" and that 
makes C++ programming time consuming.
Jan 26 2016
parent reply bachmeier <no spam.com> writes:
On Tuesday, 26 January 2016 at 20:25:34 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 19:33:04 UTC, bachmeier wrote:



 That's not actually true. Many C++ programmer express a dislike 
 for how the the syntax has developed over time, all the weird 
 corner-cases, the obfuscated meta programming mechanisms and 
 unpredictable implicitness when trying to do more advanced 
 typing. Just getting the right constructor to fire can be a 
 challenge.

 The general C++ semantics are good enough, but the language has 
 to many weird aspects to it that is "beyond repair" and that 
 makes C++ programming time consuming.


The problem is that "C++ programmers" is not a random sample. 
It's a group that was willing to push through the pain of old C++ 
and read books by Scott Meyers and learn template 
metaprogramming. The willingness to endure that torture weeded 
out all but the very best matches. Now there are improvements 
with C++11, C++14, and C++17, so *that group* getting a *much 
improved language* has no incentive to switch. Everyone else is 
already using another language.

"With C++xx, there's little benefit to switching" is a very 
common sentiment among current C++ programmers. And it's probably 
true. On the other hand, with a few exceptions, it's hard to see 
someone choosing to learn C++ rather than D. Making a push for 
those developers will be more productive.
Jan 26 2016
next sibling parent bachmeier <no spam.com> writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:


 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true. On the other hand, with a few exceptions, it's 
 hard to see someone choosing to learn C++ rather than D. Making 
 a push for those developers will be more productive.


Also, I see the competition for new programmers on a daily basis. 
Rcpp, which allows one to embed C++ code inside an R program, is 
the most popular dependency of R packages. D is unable to compete 
in that space because of the lack of proper DLL support for 
Windows and no such support for Mac. I will never be convinced 
that D wouldn't be preferred by data scientists. But that's not 
happening because of D's current limitations.
Jan 26 2016
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:

 out all but the very best matches. Now there are improvements 
 with C++11, C++14, and C++17, so *that group* getting a *much 
 improved language* has no incentive to switch. Everyone else is 
 already using another language.


Even if that was true, it still means that there are THOUSANDS of 
ex-C++ programmers that would use a C++ like language if it 
provided comparable semantics.

In my experience C++14 is mostly ok if you avoid advanced 
programming mechanisms, but if you want to achieve a specific set 
of abstractions you end up wasting a lot time on getting around 
the corner cases, like avoiding situations where the compiler 
cannot deduce what to do (instantiation conflicts).
Jan 26 2016
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:

 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true.


It's not true.

After failing to convince my coworkers to use D, I wondered about 
this. I actually thought, myself, that C++14 is good enough and 
nearly like writing D. I was wrong.

I've recently spent about 2 or 3 months writing C++14 at work. I 
ended up complaining a lot. Most of the time because I'd written 
a bug that wouldn't have happened in D. The rest was usually due 
to something supposedly simple taking an inordinate amount of 
work.

And the compile times... I never used to think they were _that_ 
important. I do now. I actually think slower when writing C++, 
which means I work slower. It sounds obvious, but I only really 
felt it recently.

The penny really dropped when I wrote D again for the 1st time 
after weeks and weeks of C++14. It was night and day. Suddenly my 
thoughts started getting to converted to code all that faster, 
with fewer bugs to distract and annoy me.

Don't get me wrong: I vastly prefer C++14 to C++98 or plain C. 
But even modern C++ needs this:

https://en.wikipedia.org/wiki/Erase%E2%80%93remove_idiom

Which is, quite frankly, ridiculous. Do you know how you split a 
string in C++? You install boost, that's how.

Atila
Jan 26 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jan 27, 2016 at 12:16:58AM +0000, Atila Neves via Digitalmars-d wrote:

 On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:

"With C++xx, there's little benefit to switching" is a very common
sentiment among current C++ programmers. And it's probably true.


 
 It's not true.
 
 After failing to convince my coworkers to use D, I wondered about
 this. I actually thought, myself, that C++14 is good enough and nearly
 like writing D. I was wrong.
 
 I've recently spent about 2 or 3 months writing C++14 at work. I ended
 up complaining a lot. Most of the time because I'd written a bug that
 wouldn't have happened in D. The rest was usually due to something
 supposedly simple taking an inordinate amount of work.


This reminds me of the time when I wanted to make a "trivial" change to
an old C++ project of mine. This was after I had become acquianted with
D, and gotten used to built-in AA's. I noticed that C++14 finally
officially had hashtables in the standard library (which is worth a rant
in itself -- who has ever heard of a modern programming language that
has no standard hashtable implementation until how many decades
after?!), and was eager to finally try it out in my code.  It would be a
simple task, I thought; simply plop in the new standard hashtable at a
strategic point in the code to serve as a cache, and performance should
improve. Right? Right??

Many hours later, I was tearing my hair out trying to resolve stupid
issues like:

1) You cannot instantitate a hashtable template without also specifying
   a hash function. WAT?! No built-in hash function??! Well, yes there
   is, except...

2) The standard hashtables have no standard hash function for structs.
   You have to write your own.  WAT??!

3) After you have a hash function, you have to create the hashtable with
   an explicitly-attached hash function -- it's not a template
   parameter, it has to be a function object passed to the hashtable's
   ctor. Which means passing around the hash function everywhere all
   over the code, wherever there's the need to create a hashtable.
   Arghh...

I'm pretty sure with a "little" more effort I could have made it work...
but seriously, that was several *hours* compared to the 2 seconds it
takes in D to add an AA to your code.

You people who think there's still enough reasons to stick to C++ crack
me up.  Do you have any idea what on earth you're talking about?!


[...]

 The penny really dropped when I wrote D again for the 1st time after
 weeks and weeks of C++14. It was night and day. Suddenly my thoughts
 started getting to converted to code all that faster, with fewer bugs
 to distract and annoy me.


Exactly!!!! If that project of mine had been in D, it would have taken
me at the most 5-10 mins to code, test, and debug the new code change.
With C++, it took several hours and it still hasn't gotten off the
ground yet.  This isn't some isolated incident or unfortunate
coincidence either.  C++ is full of convoluted idioms and needlessly
complex paraphrases to shoehorn modern programming techniques onto a
decrepit and dying ancient core. Make one mistake and you're faced with
either a memory leak, an untraceable pointer bug, an off-by-1 bug, or
some other kind of nasty, hard-to-debug problem. Oh, right, we're not
supposed to touch malloc/free or new/delete anymore, we're supposed to
wrap those in "safe" library abstractions. And we're not supposed to
used naked pointers anymore, it should be one of those fancy black magic
pointer wrappers that do ref-counting or some such. Ergo, convoluted
idioms and needlessly complex paraphrasis for what, conceptually, ought
to have been a straightforward 5 lines of code, that comes out in C++ as
50+ lines or more.



 Don't get me wrong: I vastly prefer C++14 to C++98 or plain C. But
 even modern C++ needs this:
 
 https://en.wikipedia.org/wiki/Erase%E2%80%93remove_idiom
 
 Which is, quite frankly, ridiculous. Do you know how you split a
 string in C++? You install boost, that's how.


[...]

The fact that boost is required to write anything non-trivial in C++
without reinventing the square wheel or pulling all your hair out, is a
sign that something has deeply gone wrong with the language. Yet its
proponents continue to stab themselves with knives and revel in the
pain, since C++ is, after all, still superior, especially over that
pathetic failure called D. "I can't write D code in the same painful,
bug-prone, productivity-killing way as I write C++ code, so D sux!"

I suppose it's too much of a sacrifice for C++ coders to write code in
less painful, more bug-free, and more productive ways. After all, what
about the job security??!

(And lest you think I'm just a rambling lunatic, here's another ex-C++
coder who sees it the same way:
http://bartoszmilewski.com/2013/09/19/edward-chands/ )


T

-- 
If you compete with slaves, you become a slave. -- Norbert Wiener
Jan 26 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2016 4:45 PM, H. S. Teoh via Digitalmars-d wrote:

 http://bartoszmilewski.com/2013/09/19/edward-chands/ )




   "And you know a new feature is badly designed if Scott Meyers has a talk 
about it."
Jan 26 2016
prev sibling next sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 This reminds me of the time when I wanted to make a "trivial" change to
 an old C++ project of mine. This was after I had become acquianted with
 D, and gotten used to built-in AA's. I noticed that C++14 finally
 officially had hashtables in the standard library (which is worth a rant
 in itself -- who has ever heard of a modern programming language that
 has no standard hashtable implementation until how many decades
 after?!), and was eager to finally try it out in my code.  It would be a
 simple task, I thought; simply plop in the new standard hashtable at a
 strategic point in the code to serve as a cache, and performance should
 improve. Right? Right??
 
 Many hours later, I was tearing my hair out trying to resolve stupid
 issues like:
 
 1) You cannot instantitate a hashtable template without also specifying
    a hash function. WAT?! No built-in hash function??! Well, yes there
    is, except...


Wrong.
There's std::hash<T>. It's a struct, not a function though.


 2) The standard hashtables have no standard hash function for structs.
    You have to write your own.  WAT??!


Usually, you just specialize std::hash<T> for your type.

How often do you write custom structs/classes (it's the same in C++) to be
used _by value_ as key in a hash table anyway?


 3) After you have a hash function, you have to create the hashtable with
    an explicitly-attached hash function


Wrong.


 -- it's not a template parameter,


Wrong again. It is a template parameter and it defaults to std::hash<T>.


    it has to be a function object passed to the hashtable's
    ctor.


With default argument std::hash<T>().


    Which means passing around the hash function everywhere all
    over the code, wherever there's the need to create a hashtable.


Wrong.
You just specialize std::hash<T> and be done.


    Arghh...


Yes.


 I'm pretty sure with a "little" more effort I could have made it work...
 but seriously, that was several *hours* compared to the 2 seconds it
 takes in D to add an AA to your code.
 
 You people who think there's still enough reasons to stick to C++ crack
 me up.  Do you have any idea what on earth you're talking about?!


Well apparently you don't.

Tobi
Jan 26 2016
prev sibling parent reply =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 [long rant]


If you want to attract new programmers you should stop constantly bashing
other programming languages on the public forums.

This is one thing that Rust got right.

Tobi
Jan 27 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
wrote:

 H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 [long rant]


 If you want to attract new programmers you should stop 
 constantly bashing other programming languages on the public 
 forums.

 This is one thing that Rust got right.


Well, C++ hash tables are ok. It is the result of a C++ library 
philosophy, which one may or may not agree with.

The point of this thread was to argue that D needs to attract 
C/C++ programmers and might be better off selecting semantics 
that attract them. There is something to be said about timeliness 
for doing so.

Autumn 2016 seems to be the perfect time to market D to C++ 
programmers, but the first thing they will ask for is no-GC 
memory handling, and "malloc" + DIY will just result in a big big 
yawn.

If 8 weekend programmers can replace 1 full time programmer and D 
needs 5 more full time programmers to compete (with C++, Rust and 
Swift), then D needs 40 weekend programmers to compete.

It takes a focused _strategy_ to get into the hearts of C/C++ 
programmers. It's not going to happen on it's own.
Jan 27 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 08:56:09 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
 wrote:

 H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 [long rant]


 If you want to attract new programmers you should stop 
 constantly bashing other programming languages on the public 
 forums.

 This is one thing that Rust got right.


 Well, C++ hash tables are ok. It is the result of a C++ library 
 philosophy, which one may or may not agree with.

 The point of this thread was to argue that D needs to attract 
 C/C++ programmers and might be better off selecting semantics 
 that attract them. There is something to be said about 
 timeliness for doing so.

 Autumn 2016 seems to be the perfect time to market D to C++ 
 programmers, but the first thing they will ask for is no-GC 
 memory handling, and "malloc" + DIY will just result in a big 
 big yawn.

 If 8 weekend programmers can replace 1 full time programmer and 
 D needs 5 more full time programmers to compete (with C++, Rust 
 and Swift), then D needs 40 weekend programmers to compete.

 It takes a focused _strategy_ to get into the hearts of C/C++ 
 programmers. It's not going to happen on it's own.


The response from the D community seems to be an overwhelming 
"It's fine as is" when it's obviously not. Which is making me 
question sinking more time into D if there actually is no 
cohesive plan to make D an actual C++ competitor rather than a 
toy language as it currently stands.
Jan 27 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than a 
 toy language as it currently stands.


I found it very interesting that Bjarne Stroustrup basically 
admitted in his presentation of GSL that the progress of Rust has 
forced C++ to change faster. And there is no doubt that Apple is 
putting its money behind Swift, planning for a major upgrade 
(Swift 3)...

As far as I can tell there is a horse race between C++, Rust and 
perhaps also Swift that will affect what programmers expect from 
system level programming languages in the coming years.

So "It's fine as is" isn't really an option.
Jan 27 2016
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 toy language


What is with everyone using inane hyperbole in this thread? Is 
everyone trying to one up each other?

D is a toy language? Really? Tell that to Sociomantic and AdRoll, 
I'm sure they use D right next to brainfuck, right?
Jan 27 2016
next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 15:37:39 UTC, Jack Stouffer 
wrote:

 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 toy language


 What is with everyone using inane hyperbole in this thread? Is 
 everyone trying to one up each other?

 D is a toy language? Really? Tell that to Sociomantic and 
 AdRoll, I'm sure they use D right next to brainfuck, right?


PureScript is used by SlamData, a multi-million dollar company.
I still consider PureScript a toy language.
Jan 27 2016
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 27 January 2016 at 16:12:49 UTC, rsw0x wrote:

 PureScript is used by SlamData, a multi-million dollar company.
 I still consider PureScript a toy language.


Purescript, Typescript, etc. are not languages, they're glorified 
preprocessors.
Jan 27 2016
prev sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 16:12:49 UTC, rsw0x wrote:

 On Wednesday, 27 January 2016 at 15:37:39 UTC, Jack Stouffer 
 wrote:

 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 toy language


 What is with everyone using inane hyperbole in this thread? Is 
 everyone trying to one up each other?

 D is a toy language? Really? Tell that to Sociomantic and 
 AdRoll, I'm sure they use D right next to brainfuck, right?


 PureScript is used by SlamData, a multi-million dollar company.
 I still consider PureScript a toy language.


Do you have a better definition than that of wiki ?

It seems to me one can create reliable, maintainable computer 
programs in a production environment in D, that it is hardly 
limited in terms of not having a full range of programming 
constructs, and that library support is not a serious problem for 
a bigger project because the cost of writing bindings or wrapping 
things is one-off.


https://en.wikipedia.org/wiki/Toy_programming_language

A toy language is a computer programming language that lacks the 
requirements to create reliable, maintainable computer programs 
in a production environment.[citation needed] Which programs to 
categorize as toy languages is difficult, however.[citation 
needed] Languages such as Brainfuck and Whitespace are both 
considered esoteric programming languages.[citation needed] They 
are Turing complete,[citation needed] which means they are able 
to compute any computable function.[citation needed] Logo is an 
example of a toy language.[citation needed] Its goal was 
originally to create a math land where children could play with 
words and sentences.[citation needed] For a long time, the GNU 
Compiler Collection was shipped with a toy programming language 
called Treelang[citation needed] which was essentially C without 
the advanced features such as pointers, arrays, and 
records.[citation needed]
Limitations

Though a toy language may be mathematically complete, it is 
usually limited in one or several ways. It may not support a full 
range of programming constructs or concepts. It may lack a full 
set of support libraries considered to be required for creating 
production-quality programs.
Uses

The main use of a toy language is in computer languages research. 
Some uses are as frameworks for researching new programming 
constructs or as a prototype for new language concepts or 
paradigms. Other notable uses are as a learning or demonstration 
tool, e.g. in universities, for programming constructs and 
techniques not available in mainstream languages and as an 
exercise in building a language from scratch.
Jan 27 2016
prev sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 15:37:39 UTC, Jack Stouffer 
wrote:

 D is a toy language? Really? Tell that to Sociomantic and 
 AdRoll, I'm sure they use D right next to brainfuck, right?


  brainfuck...

  Recently as an experiment I was going through to decide on the 
minimum instructions needed for a chip; Perhaps processor design 
would have them listed, but I came around 6-7 different 
instructions. With these instructions in combination you can 
do/build everything else.

  I'm also reminded of playing the TIS-100 game not too long ago, 
which was a 'chip' designed with 10 instructions and you had to 
program the chips in parallel to get stuff done. This includes 
everything from multiplication and division, to sorting and array 
access.

  It's amazing what you can do with so very little if you approach 
it right.
Jan 27 2016
prev sibling next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 On Wednesday, 27 January 2016 at 08:56:09 UTC, Ola Fosheim 
 Grøstad wrote:

 On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
 wrote:

 H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 [long rant]


 If you want to attract new programmers you should stop 
 constantly bashing other programming languages on the public 
 forums.

 This is one thing that Rust got right.


 Well, C++ hash tables are ok. It is the result of a C++ 
 library philosophy, which one may or may not agree with.

 The point of this thread was to argue that D needs to attract 
 C/C++ programmers and might be better off selecting semantics 
 that attract them. There is something to be said about 
 timeliness for doing so.

 Autumn 2016 seems to be the perfect time to market D to C++ 
 programmers, but the first thing they will ask for is no-GC 
 memory handling, and "malloc" + DIY will just result in a big 
 big yawn.

 If 8 weekend programmers can replace 1 full time programmer 
 and D needs 5 more full time programmers to compete (with C++, 
 Rust and Swift), then D needs 40 weekend programmers to 
 compete.

 It takes a focused _strategy_ to get into the hearts of C/C++ 
 programmers. It's not going to happen on it's own.


 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than a 
 toy language as it currently stands.


Grumbling is great, up to a point.  Talented and discerning 
people who don't see a way to fix problems are going to grumble.

Change takes time, and one tends to overestimate what can be 
accomplished in shorter periods of time, and underestimate what's 
possible over longer periods.  Since I've been here (one or two 
years) we've seen some very substantial improvements - the web 
site, the documentation, C++ integration, D being usable on 
ARM/Android, just to name a few.

But the power is in your hands too.  Perhaps the D Foundation and 
corporate sponsorship will change the resource question in time.  
But it's a different situation from being in a vast corporation 
where one has no control and nobody will listen to you.  Ilya saw 
that D needed better numerical primitives and he wrote ndslice.  
John Colvin saw that D needed a focal point for numerical and 
scientific computing and he took charge of that - nobody 
appointed him.

There isn't so much benefit to having a coherent top-down plan 
when you can neither force people to work on things, nor pay them 
to do so.  That's not how open-source works, and it's more 
governed by the principle of catallaxy discussed by Hayek than it 
is some kind of corporate project.  The advantage of not having a 
top down plan is that decisions can be shaped by local knowledge 
from peoples' practical experience of the kinds of problems they 
need to solve.

If you want to change the GC etc, telling other people they ought 
to look at that will be much less effective than picking some 
aspect of the problem to work on.  For example, the sociomantic 
GC was released - I wonder what the blockers are for this to be 
ported in part or whole to D.

If one doesn't have time to work on the whole thing, one can at 
least start creating a focal point for a white paper and then let 
others add to it and refine it.
Jan 27 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 27 January 2016 at 16:40:11 UTC, Laeeth Isharc 
wrote:

 and it's more governed by the principle of catallaxy discussed 
 by Hayek


Principle of spontaneous order might be appropriate.
Jan 27 2016
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 17:11:18 UTC, jmh530 wrote:

 On Wednesday, 27 January 2016 at 16:40:11 UTC, Laeeth Isharc 
 wrote:

 and it's more governed by the principle of catallaxy discussed 
 by Hayek


 Principle of spontaneous order might be appropriate.


One and the same.
https://en.wikipedia.org/wiki/Catallactics

Note this bit especially - Hayek's suggested Greek construction 
would be rendered καταλλαξία) from the Greek verb katallasso 
(καταλλάσσω) which meant not only "to exchange" but also "to 
admit in the community" and "to change from enemy into friend."

https://en.wikipedia.org/wiki/Catallactics

Catallactics is a theory of the way the free market system 
reaches exchange ratios and prices. It aims to analyse all 
actions based on monetary calculation and trace the formation of 
prices back to the point where an agent makes his or her choices. 
It explains prices as they are, rather than as they "should" be. 
The laws of catallactics are not value judgments, but aim to be 
exact, objective and of universal validity. It was first used 
extensively by the Austrian School economist Ludwig von 
Mises.[citation needed]

Catallactics is a praxeological theory, the term catallaxy being 
used by Friedrich Hayek to describe "the order brought about by 
the mutual adjustment of many individual economies in a 
market."[1] Hayek was dissatisfied with the usage of the word 
"economy" because its Greek root, which translates as "household 
management", implies that economic agents in a market economy 
possess shared goals. He derived the word "Catallaxy" (Hayek's 
suggested Greek construction would be rendered καταλλαξία) from 
the Greek verb katallasso (καταλλάσσω) which meant not only "to 
exchange" but also "to admit in the community" and "to change 
from enemy into friend."[2]

According to Mises (Human Action, page 3) and Hayek[3] it was 
Richard Whately who coined the term "catallactics". Whately's 
Introductory Lectures on Political Economy (1831) reads:[4]

     It is with a view to put you on your guard against prejudices 
thus created, (and you will meet probably with many instances of 
persons influenced by them,) that I have stated my objections to 
the name of Political-Economy. It is now, I conceive, too late to 
think of changing it. A. Smith, indeed, has designated his work a 
treatise on the "Wealth of Nations;" but this supplies a name 
only for the subject-matter, not for the science itself. The name 
I should have preferred as the most descriptive, and on the whole 
least objectionable, is that of CATALLACTICS, or the "Science of 
Exchanges."
Jan 27 2016
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 27 January 2016 at 21:58:06 UTC, Laeeth Isharc 
wrote:

 One and the same.

 [snip]


I disagree. Your point was that open source is bottom-up and not 
top-down. That's more like spontaneous order
https://en.wikipedia.org/wiki/Spontaneous_order
It's a specific idea within the broader set of ideas in economics.

Praxeology is Mises' term for the science of human action. In his 
view, the science of human action is broad, encompassing many 
fields. He refers to one of those fields Catallactics, which is 
the theory of exchange. For all intents and purposes, when you 
hear Catallactics, you could replace it with Economics and you'd 
be fine (price theory might be even more accurate). Perhaps the 
main difference is that Catallactics theoretically covers all 
exchange, but even Economics these days covers many types of 
non-monetary exchange.

To me, it makes as much sense to say that open source is governed 
by the principles of catallaxy as it does to say that it's 
governed by the principles of economics. What specific meaning is 
conveyed by saying that? Too broad.
Jan 27 2016
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than a 
 toy language as it currently stands.


I can't take any of this seriously as long as ConcernedDev1950 do 
not provide any PR.
Jan 27 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:

 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than a 
 toy language as it currently stands.


 I can't take any of this seriously as long as ConcernedDev1950 
 do not provide any PR.


ConcernedDev1950 will go use a language that doesn't require them 
to write the standard library.
Jan 27 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 27 January 2016 at 20:51:43 UTC, rsw0x wrote:

 On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:

 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 The response from the D community seems to be an overwhelming 
 "It's fine as is" when it's obviously not. Which is making me 
 question sinking more time into D if there actually is no 
 cohesive plan to make D an actual C++ competitor rather than 
 a toy language as it currently stands.


 I can't take any of this seriously as long as ConcernedDev1950 
 do not provide any PR.


 ConcernedDev1950 will go use a language that doesn't require 
 them to write the standard library.


Apparently no, they come here and cry and get nothing done.
Jan 27 2016
next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 22:18:49 +0000, deadalnix wrote:


 On Wednesday, 27 January 2016 at 20:51:43 UTC, rsw0x wrote:

 On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:

 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 The response from the D community seems to be an overwhelming "It's
 fine as is" when it's obviously not. Which is making me question
 sinking more time into D if there actually is no cohesive plan to
 make D an actual C++ competitor rather than a toy language as it
 currently stands.


 I can't take any of this seriously as long as ConcernedDev1950 do not
 provide any PR.


 ConcernedDev1950 will go use a language that doesn't require them to
 write the standard library.


 
 Apparently no, they come here and cry and get nothing done.


I just want to do my own thing. When I try doing it in D, I often have to 
work on three or four dependencies as well. Sometimes it's a good tradeoff 
-- D occasionally has something no other language I'm willing to use has. 
Most of the time it's not.

That's not crying; it's practicality.
Jan 27 2016
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 22:18:49 UTC, deadalnix wrote:

 On Wednesday, 27 January 2016 at 20:51:43 UTC, rsw0x wrote:

 On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote:

 On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote:

 The response from the D community seems to be an 
 overwhelming "It's fine as is" when it's obviously not. 
 Which is making me question sinking more time into D if 
 there actually is no cohesive plan to make D an actual C++ 
 competitor rather than a toy language as it currently stands.


 I can't take any of this seriously as long as 
 ConcernedDev1950 do not provide any PR.


 ConcernedDev1950 will go use a language that doesn't require 
 them to write the standard library.


 Apparently no, they come here and cry and get nothing done.


Yes, how dare people see D marketed as a non-alpha language then 
realize the language is actually still in an alpha-state.
Jan 27 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 28 January 2016 at 00:46:00 UTC, rsw0x wrote:


 Yes, how dare people see D marketed as a non-alpha language 
 then realize the language is actually still in an alpha-state.


It's not in an alpha state. It's a grassroots language. There's 
no other way to describe it. Being community driven, it moves in 
the direction and at the pace that the community drives it. 
There's no large team, no governing body, no committee to drive 
development. Everyone using it needs to accept that any 
particular personal peeve they have with the language are only 
going to get changed in one of two ways: there's enough momentum 
behind it to cause it to percolate up to the top of the priority 
list for the core developers, or if you do it yourself. That's 
what it boils down to.

It's unreasonable to lambast the core developers as wanting to do 
nothing to improve the language. There are only so many hours in 
the day. Walter and Andrei care very much about this language. So 
do many others who are working to make it better, focusing on the 
areas that fit within their needs and their abilities. That's why 
it has come along as far as it has.

Debate about which issues should take priority are certainly 
needed, but these threads that degenerate into bashing the core 
developers, or calling D a "toy" language, serve no purpose other 
than to waste bandwidth and make it difficult to discuss what 
really matters.
Jan 27 2016
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 28, 2016 at 02:59:38AM +0000, Mike Parker via Digitalmars-d wrote:

 On Thursday, 28 January 2016 at 00:46:00 UTC, rsw0x wrote:
 

Yes, how dare people see D marketed as a non-alpha language then
realize the language is actually still in an alpha-state.


 
 It's not in an alpha state. It's a grassroots language. There's no
 other way to describe it. Being community driven, it moves in the
 direction and at the pace that the community drives it. There's no
 large team, no governing body, no committee to drive development.
 Everyone using it needs to accept that any particular personal peeve
 they have with the language are only going to get changed in one of
 two ways: there's enough momentum behind it to cause it to percolate
 up to the top of the priority list for the core developers, or if you
 do it yourself. That's what it boils down to.
 
 It's unreasonable to lambast the core developers as wanting to do
 nothing to improve the language. There are only so many hours in the
 day. Walter and Andrei care very much about this language. So do many
 others who are working to make it better, focusing on the areas that
 fit within their needs and their abilities. That's why it has come
 along as far as it has.
 
 Debate about which issues should take priority are certainly needed,
 but these threads that degenerate into bashing the core developers, or
 calling D a "toy" language, serve no purpose other than to waste
 bandwidth and make it difficult to discuss what really matters.


+1, the voice of reason.


T

-- 
Debian GNU/Linux: Cray on your desktop.
Jan 27 2016
prev sibling next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 28 January 2016 at 02:59:38 UTC, Mike Parker wrote:

 There's no large team, no governing body, no committee to drive 
 development. Everyone using it needs to accept that any 
 particular personal peeve they have with the language are only 
 going to get changed in one of two ways: there's enough 
 momentum behind it to cause it to percolate up to the top of 
 the priority list for the core developers, or if you do it 
 yourself. That's what it boils down to.


  You know, this reminds me when i worked in a software company 
for a short while. I found it utterly aggravating. There was code 
i could work on and fix and do, but the whole structure of it 
required a number of things, including getting permission to work 
on it. You couldn't just work on it and get it working, you had 
to go through a series of steps to get approval to work on it. QA 
were a separate set of testers (who in my experience weren't 
coders so couldn't even get their tests to work), a database list 
of bugs and requests, and you didn't necessarily get any option 
of working on at all. Often i felt like i was sitting on my hands 
when it could have taken me 15 minutes to just fix the damn thing.

  I'm not saying a committee or governing body is bad, but when 
it's too large (or tries to be) then it becomes it's own 
bottleneck taking 100x longer than needed. My own preference for 
coding is 1) Get it to work, 2) Optimize, 3) Beautify it.
Jan 27 2016
prev sibling parent Ola Foaheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 02:59:38 UTC, Mike Parker wrote:

 On Thursday, 28 January 2016 at 00:46:00 UTC, rsw0x wrote:


 Yes, how dare people see D marketed as a non-alpha language 
 then realize the language is actually still in an alpha-state.


 It's not in an alpha state. It's a grassroots language. There's 
 no other way to describe it. Being community driven, it moves 
 in the direction and at the pace that the community drives it.


That's not actually true, Walter ultimately decides everything. 
Lisp might have been grassroot, but only because it is 100% 
library driven. Leading to Common Lisp, Common Music etc...


 There's no large team, no governing body, no committee to drive 
 development. Everyone using it needs to accept that any 
 particular personal peeve they have with the language are only 
 going to get changed in one of two ways: there's enough 
 momentum behind it to cause it to percolate up to the top of 
 the priority list for the core developers, or if you do it 
 yourself. That's what it boils down to.


The point of this thread is that D would benefit from cutting the 
scope of no-gc management to deliver on time and gain momentum 
and build a larger team.

It is about strategy. Telling people "DIY" or "submit PR" is off 
topic. That is not a viable strategy that can make D converge 
towards completion in a timely manner.


 Debate about which issues should take priority are certainly 
 needed, but these threads that degenerate into bashing the core 
 developers, or calling D a "toy" language, serve no purpose 
 other than to waste bandwidth and make it difficult to discuss 
 what really matters.


People read too much into "toy language". Many toy languages are 
better and more advanced than non-toy languages. They are just 
not designed and developed in a manner that lead to completion 
and often lack a formal specification.

Some might argue that without a specfication you don't even have 
a language, you have an experimental prototype that could lead to 
a specified language. If it is impossible to implement a fully 
compatible D compiler without studying DMD it basically means 
that nobody knows what the D language is.
Jan 27 2016
prev sibling parent reply bachmeier <no spam.com> writes:
On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller 
wrote:


 If you want to attract new programmers you should stop 
 constantly bashing other programming languages on the public 
 forums.

 This is one thing that Rust got right.

 Tobi


I know I should just let this go, because time is valuable, but 
anyway...

All language comparisons involve "bashing" other languages. 
Otherwise there is no answer when someone asks "Why language X 
rather than language Y?"

Forget about random posters on a forum. Let's go to the Rust 
homepage, click the link https://github.com/ctjhoa/rust-learning 
and then click on Why Rust? 
http://www.oreilly.com/programming/free/files/why-rust.pdf

That's not a random forum post. It's a document promoting Rust, 
linked on the Rust homepage, and produced by O'Reilly. Here are a 
few quotes:

"It’s difficult to write secure code. It’s common for security 
exploits to leverage bugs in the way C and C++ programs handle 
memory, and it has been so at least since the Morris virus, the 
first Internet virus to be carefully analyzed, took advantage of 
a buffer overflow bug to propagate itself from one machine to
the next in 1988."

"It’s very difficult to write multithreaded code, which is the 
only way to exploit the abilities of modern machines. Each new 
generation of hardware brings us, instead of faster processors, 
more of them; now even midrange mobile devices have multiple 
cores. Taking advantage of this entails writing multithreaded
code, but even experienced programmers approach that task with 
caution: concurrency introduces broad new classes of bugs, and 
can make ordinary bugs much harder to reproduce."

"In allowing an array reference to affect the behavior of a 
subsequent return statement, my C compiler is fully 
standards-compliant. An “undefined” operation doesn’t just 
produce an unspecified result: it is allowed to cause the program 
to do anything at all."

And ironically, in this very thread, a C++ programmer has called 
D a toy language.
Jan 27 2016
next sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:

 All language comparisons involve "bashing" other languages. 
 Otherwise there is no answer when someone asks "Why language X 
 rather than language Y?"


  Sometimes it's just one language feature (or lack of it) that 
makes (or breaks) the decision to use it. If you step back and 
consider a starting point from which all discussions must 
eventually flow, that starting point is most likely C (I doubt 
assembly language is considered since it's too low level). So 
invariably there MUST be comparison and bashing between 
languages. Truthfully I'll happily bash C, it has a horrible 
memory management model that requires way too careful of 
management. But that doesn't mean it's a bad language, in many 
cases it's still a very very fine language, especially for 
writing code for PIC chips and the like.


 http://www.oreilly.com/programming/free/files/why-rust.pdf

 That's not a random forum post. It's a document promoting Rust, 
 linked on the Rust homepage, and produced by O'Reilly. Here are 
 a few quotes:

 <snip>


  All of the quotes seem well thought out, and truthful. If Rust 
provides a good way to deal with and take advantage of the 
features, then they will probably get a wider audience.


 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.


  Toy language? I recall BASIC was considered a beginners language 
back in the day, and yet so much code is written with it. True 
since the language was more fully implemented on DOS with Qbasic 
and later Visual Basic; But as long as you can get the work done 
then I wouldn't see a problem
Jan 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 16:48:24 UTC, Era Scarecrow 
wrote:

  Toy language? I recall BASIC was considered a beginners 
 language back in the day, and yet so much code is written with 
 it. True since the language was more fully implemented on DOS 
 with Qbasic and later Visual Basic; But as long as you can get 
 the work done then I wouldn't see a problem


BASIC was polished and shipped with literally every single home 
computer in the 80s. Primitive yes, but widely used. Much more so 
than D. It did exactly what it was supposed to do and didn't have 
any incomplete features.
Jan 27 2016
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 17:50:09 UTC, Ola Fosheim 
Grøstad wrote:

 BASIC was polished and shipped with literally every single home 
 computer in the 80s. Primitive yes, but widely used. Much more 
 so than D. It did exactly what it was supposed to do and didn't 
 have any incomplete features.


  Well i'd say it had incomplete features, having goto/gosub and 
global variables; Although it worked it bred spaghetti code like 
crazy.

  I'm sure BASIC would have had more features if they could have 
fit them into the ROM; But like the TCC (Tiny C Compiler) they 
first added what was most important and added additional features 
afterwards until they couldn't fit anything else while shaving 
every byte they could along the way.

  Curiously i wrote a de-tokenizer a year or something ago and 
some of the features bled through a bit quite obviously; All math 
and number storage being done with a 6 byte BCD packed format 
(that I'm told is also used in calculators) while the line 
numbers were unsigned shorts (probably for sorting reasons). It 
had the interesting effect of having to convert the 16bit line 
number using division while printing the program out, and then 
just outputting the numbers for everything else with a quick 
conversion from BCD to string.

  But BASIC shined most when there was so little memory. It wasn't 
uncommon to have only 4k for available RAM; And you could write 
short yet useful programs in 4k.
Jan 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 19:42:46 UTC, Era Scarecrow 
wrote:

  Well i'd say it had incomplete features, having goto/gosub and 
 global variables; Although it worked it bred spaghetti code 
 like crazy.


Not incomplete features, just a very very very bad feature set. 
:-)

I added my own BASIC instructions on the C64 when I was in my 
late teens. You had a section at address $C000 where you could 
put 4K of machine language without interfering with BASIC. I 
believe I added some commands for sound.

Of course, there were also expansion cartridges that would give 
you extra commands and so on.

BASIC was also the CLI, so it took the role as a primitive 
version of Bash on Unix.


  I'm sure BASIC would have had more features if they could have 
 fit them into the ROM;


I believe Microsoft made adaptions for each machine. The BASIC 
dialect could be quite different. Didn't matter too much, the 
hardware was different too ;-).

Computer magazines had an enormous amount of listings of BASIC 
programs you could punch in. "Continued in next issue". :-D


 But BASIC shined most when there was so little memory. It 
 wasn't uncommon to have only 4k for available RAM; And you 
 could write short yet useful programs in 4k.


Yes, VIC20 had 3.5K left for BASIC.
Jan 28 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/

Mentions D.
Jan 29 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 29 January 2016 at 10:43:08 UTC, Ola Fosheim Grøstad 
wrote:

 https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/

 Mentions D.


Since it is in danish, let me quickly translate the informative 
sections:

Bjarne Stroustrup (translated from danish): The safety rules is 
part of the more extensive guidelines 
(https://github.com/isocpp/CppCoreGuidelines ) and supported by a 
small library (https://github.com/microsoft/gsl ) .  We have 
"annotations" which can be used to neutralize the rules (as an 
"unsafe" annotation). We minimize their usage. Our goal is 100% 
safety and I assume that we will get as close to that goals as 
any language that can work directly with hardware. We already 
have 100% resource safety, and that is better than languages like 

areas.»


On garbage collection:

Bjarne Stroustrup (translated from danish): Yes, programming 
language creators and researchers have always been fascinated by 
garbage collection. I think that is a mistake: GC is not general 
- it cannot deal with non-memory resources - and is not ideal - 
it introduces a central facility in (otherwise) distributed 
systems. The good solution is to not produce garbage: 
http://www.stroustrup.com/resource-model.pdf . RAII is central in 
my ideas about programming.


He also acknowledges scandinavian contributions to programming 
languages, the OO languages Simula and Beta.
Jan 29 2016
parent bitwise <bitwise.pvt gmail.com> writes:
On Friday, 29 January 2016 at 11:08:41 UTC, Ola Fosheim Grøstad 
wrote:

 On garbage collection:

 Bjarne Stroustrup (translated from danish): Yes, programming 
 language creators and researchers have always been fascinated 
 by garbage collection. I think that is a mistake: GC is not 
 general - it cannot deal with non-memory resources - and is not 
 ideal - it introduces a central facility in (otherwise) 
 distributed systems. The good solution is to not produce 
 garbage: http://www.stroustrup.com/resource-model.pdf . RAII is 
 central in my ideas about programming.


+ucent.max

Non-memory resource management.

I really hope something gets figured out with lifetimes this year.

     Bit
Jan 29 2016
prev sibling next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:

 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.



C++ programmer


No.
I've been using D since 2012 and have ported two large personal 
academic codebases to it.
Ignoring the issues D has or pretending they don't exist isn't 
helping D.

Rust had explosive adoption despite targeting the same exact 
niche as D, there is **not** a lack of developers that want an 
alternative to C++.

The entire point of this thread is what is D doing to keep up 
with Rust and C++17, the answer seems to be... not much.
Maybe the developers around here haven't bothered to check C++17 
features recently I guess.
Jan 27 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 17:20:37 UTC, rsw0x wrote:

 Rust had explosive adoption despite targeting the same exact 
 niche as D, there is **not** a lack of developers that want an 
 alternative to C++.


Indeed, and why do Rust have so many contributors to the 
essential infrastructure? Because they attract C/C++/academic 
developers that are capable and inclined to contribute to the 
essential infrastructure.

I don't really see how attracting "scripty" programmers will 
significantly affect the number of contributors to compiler + 
tooling. I also don't think the current contributors contributing 
more will make a significant change.
Jan 27 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:

 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.


D is incomplete, unfinished, unspecified and unstable. C++14 is 
an ISO standard and has several independent implementations that 
are polished and stable compiler releases.

That makes D a toy language and C++ an industry standard.

Not very difficult to grok, I would think.
Jan 27 2016
next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:

 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.


 D is incomplete, unfinished, unspecified and unstable. C++14 is 
 an ISO standard and has several independent implementations 
 that are polished and stable compiler releases.

 That makes D a toy language and C++ an industry standard.

 Not very difficult to grok, I would think.


It make its immature but come on, it's not a toy.
Jan 27 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 19:21:11 UTC, Abdulhaq wrote:

 On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim 
 Grøstad wrote:

 On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:

 And ironically, in this very thread, a C++ programmer has 
 called D a toy language.


 D is incomplete, unfinished, unspecified and unstable. C++14 
 is an ISO standard and has several independent implementations 
 that are polished and stable compiler releases.

 That makes D a toy language and C++ an industry standard.

 Not very difficult to grok, I would think.


 It make its immature but come on, it's not a toy.


Fits fairly well under Eric S. Raymond's toy language definition, 
actually.
Jan 27 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 19:25:49 +0000, rsw0x wrote:


 On Wednesday, 27 January 2016 at 19:21:11 UTC, Abdulhaq wrote:

 On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim Grøstad
 wrote:

 On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote:

 And ironically, in this very thread, a C++ programmer has called D a
 toy language.


 D is incomplete, unfinished, unspecified and unstable. C++14 is an ISO
 standard and has several independent implementations that are polished
 and stable compiler releases.

 That makes D a toy language and C++ an industry standard.

 Not very difficult to grok, I would think.


 It make its immature but come on, it's not a toy.


 
 Fits fairly well under Eric S. Raymond's toy language definition,
 actually.


I've seen almost nothing produced by Eric S Raymond besides a hypertext 
version of the INTERCAL spec and _The Cathedral and the Bazaar_. Oh, and 
some random conspiracy theorist on IRC making outrageous claims and ESR 
accepting them as absolute truth without a second thought. So I'm not 
sure why I should prioritize his definitions.

More to the point, people here are using different definitions, which 
results in a profound lack of communication that looks like an argument 
with content but isn't.

D is quite unlike languages intended and marketed as toys, such as 
GolfScript, Befunge, and Whitespace; or personal projects intended mostly 
as an exercise for the designer. Compared to them, D is a much better 
choice for use in production code. D is also somewhat unlike languages 
such as C++ and Java, which have reliable implementations, are well 
specified, and change at a pace that a Fortune 500 company can keep up 
with.

Of the two, D's heart is in the C++/Java camp: it's intended for serious 
use, has features to make that feasible, and has a reliable core of 
features that work. However, it's not close enough -- not well versioned 
enough, doesn't have sufficiently stable tools -- for it to be generally 
wise to bet your company on it.

D as a programming language is unlikely to stabilize any time soon. The 
release structure doesn't support it. The language spec is a living 
document rather than being versioned. This is useful for keeping everyone 
compatible with the newest features (you do it or nobody can use your 
library) but is bad for keeping your company's code working over the 
course of years without people having to update it to the latest language 
features. Companies typically stick to one version for quite some time, 
but in D's case, this means cutting off a number of third-party libraries.

The tooling has improved over time. Five years ago, dsss was newfangled; 
now dub has consumed all. dfix and dfmt have only come up recently, and 
there's talk of including them in the standard distribution.

And this is related, but it's not about the language as such: the library 
situation is improving, but slowly. In 2008 dsource.org hosted probably 
fifty projects. Eight years later, code.dlang.org indexes 650 packages. 
There are database adapters for a scant handful of databases. There are 
no Google or Amazon API clients. There are many missing things. *That* 
makes it hard to use D in production, even if the tooling and stability 
were there.
Jan 27 2016
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim 
Grøstad wrote:

 That makes D a toy language and C++ an industry standard.

 Not very difficult to grok, I would think.


Sure, but...
https://www.youtube.com/watch?v=7FYTc55nGEI
Jan 27 2016
prev sibling next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Wednesday, 27 January 2016 at 00:16:58 UTC, Atila Neves wrote:

 I've recently spent about 2 or 3 months writing C++14 at work. 
 I ended up complaining a lot. Most of the time because I'd 
 written a bug that wouldn't have happened in D. The rest was 
 usually due to something supposedly simple taking an inordinate 
 amount of work.


The deepest I've personally gone into C++ was when writing a 
quicksort and other sort functions. The whole thing fell 
spectacularly apart for something that was tiny and obscure and 
looked correct. It was quite a pain.


 The penny really dropped when I wrote D again for the 1st time 
 after weeks and weeks of C++14. It was night and day. Suddenly 
 my thoughts started getting to converted to code all that 
 faster, with fewer bugs to distract and annoy me.



 Do you know how you split a string in C++? You install boost, 
 that's how.


  Heh, considering strings are still based on C's implementation 
which null terminated, mostly due to memory constraints that the 
original computers had (64k, OR LESS of memory), EVERY byte was 
precious. I'm not sure how Boost would deal with splitting a 
string, but I can think of a way that would do the job (well two 
ways if you want one that doesn't mutate the original data).

  I personally think C++ should probably be abandoned for a better 
language since it's insistence on backwards compatibility chains 
it to some very bad design decisions; And it's horrid syntax 
*Yuck!* which has kept me from using it for over two decades; Not 
to mention the STL looks confusing and only makes some sense 
after a good video tutorial where the basics of the principles 
were explained.

  Good code and API's shouldn't need a lot of explaining to get 
them to work. Good design shouldn't need a lot of fiddling to get 
it to work in a way that logically makes sense.
Jan 26 2016
prev sibling parent bachmeier <no spam.net> writes:
On Wednesday, 27 January 2016 at 00:16:58 UTC, Atila Neves wrote:

 On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:

 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true.


 It's not true.

 After failing to convince my coworkers to use D, I wondered 
 about this. I actually thought, myself, that C++14 is good 
 enough and nearly like writing D. I was wrong.


I definitely agree with you that D is the better choice for us. 
And I haven't talked to a random sample of thousands of C++ 
programmers, so I may be wrong. But my impression is that the C++ 
programmers of today are the modern version of the early 
programmers that refused to touch FORTRAN because they weren't 
about to use a compiler. They won't give up on a language in 
which they are so heavily invested, one which most of the world 
avoids, to use a language designed to be used by humans. For 
those of us that just want to get work done, D is a great choice, 
but we moved on from or never even started with C++.
Jan 26 2016
prev sibling parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote:

 "With C++xx, there's little benefit to switching" is a very 
 common sentiment among current C++ programmers. And it's 
 probably true. On the other hand, with a few exceptions, it's 
 hard to see someone choosing to learn C++ rather than D. Making 
 a push for those developers will be more productive.


If this was true, then Rust wouldn't have seen explosive 
popularity, as it targets the same niche as C++ does(except with 
a safety-oriented aspect.)
crates.io has 21 million package downloads recorded, does dub has 
similar statistics we can compare it to?
Jan 26 2016
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:

 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.


The real victory isn't, "Everyone carries our flag," it's 
"Everyone adopts our good ideas."
Jan 26 2016
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 19:51:22 UTC, Joseph Rushton 
Wakeling wrote:

 On Tuesday, 26 January 2016 at 19:07:03 UTC, rsw0x wrote:

 I see C++17 and think of why I should keep using D when C++ is 
 aping a lot of its best features.


 The real victory isn't, "Everyone carries our flag," it's 
 "Everyone adopts our good ideas."


They invented it all as well.
Jan 26 2016
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote:

 On Tuesday, 26 January 2016 at 15:59:37 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:

 On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 26 January 2016 at 09:33:22 UTC, deadalnix wrote:

 No that would be stupid to make that the default as it is 
 unsafe.


 When would you estimate that D could have a production ready 
 default memory managment solution (without GC)?


 Now, D can do the exact same as C++ .


 Not really, but that was not the question. So let me repeat:

 When would you estimate that D will have a production ready 
 default memory management solution (without GC).


 I don't think it is desirable. I do think we should focus on 
 having GC.malloc/GC.free have the same level of perfs than 
 malloc/free, which is very doable.

 Now as to when, well, I'm waiting for your PR.


They will never have the performance of e.g, jemalloc.

re: GC in D,
GC in D is a pipedream, if it wasn't, why is it still so horrible?
Everyone keeps dancing around the fact that if the GC wasn't 
horrible, nobody would work around it.
The fact that the GC has to be worked around is proof enough that 
the GC has failed.
Jan 26 2016
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 19:04:33 UTC, rsw0x wrote:

 Now as to when, well, I'm waiting for your PR.


 They will never have the performance of e.g, jemalloc.


In fact I will. The design of SDC's GC is based on jemalloc after 
extensive discussion with Jason Evan. He is considering 
backporting part of the work in jemalloc.

Namely, the only major additional work that need to be done is to 
write one uint per page on "large" allocations (namely 16kb - 
192kb) in order to be able to detect internal pointers. 
Considering these aren't that common to boot, this is not 
expected to impact perfs significantly.

On the other hand, D's type system can be leveraged to reduce 
lock contention on the GC (and not lock at all on thread local 
allocs).

Really, there is a lot to be done here and I'm reluctant to push 
for more language things while what we have is far from top notch.
Jan 26 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:

 On the other hand, D's type system can be leveraged to reduce 
 lock contention on the GC (and not lock at all on thread local 
 allocs).


There's no such thing in D.

shared int* i = new int(5);
int* l = new int(5);

these call the same exact functions with the same exact typeid.
Jan 26 2016
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 20:22:19 UTC, rsw0x wrote:

 On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:

 On the other hand, D's type system can be leveraged to reduce 
 lock contention on the GC (and not lock at all on thread local 
 allocs).


 There's no such thing in D.

 shared int* i = new int(5);
 int* l = new int(5);

 these call the same exact functions with the same exact typeid.


It doesn't have to. This is no secret that the current 
implementation is shit.
Jan 26 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 26 Jan 2016 20:22:19 +0000, rsw0x wrote:


 On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:

 On the other hand, D's type system can be leveraged to reduce lock
 contention on the GC (and not lock at all on thread local allocs).


 
 There's no such thing in D.
 
 shared int* i = new int(5);
 int* l = new int(5);
 
 these call the same exact functions with the same exact typeid.


Which means that the checks regarding shared are performed at compile 
time and not at runtime. That's perfectly valid.

The type system is also mostly expressed at compile time -- there's no 
runtime check inserted at the start of each method ensuring that each of 
its class-based parameters is in fact of the required type. That's not a 
problem.
Jan 26 2016
parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 20:43:06 UTC, Chris Wright wrote:

 On Tue, 26 Jan 2016 20:22:19 +0000, rsw0x wrote:


 On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote:

 On the other hand, D's type system can be leveraged to reduce 
 lock contention on the GC (and not lock at all on thread 
 local allocs).


 
 There's no such thing in D.
 
 shared int* i = new int(5);
 int* l = new int(5);
 
 these call the same exact functions with the same exact typeid.


 Which means that the checks regarding shared are performed at 
 compile time and not at runtime. That's perfectly valid.

 The type system is also mostly expressed at compile time -- 
 there's no runtime check inserted at the start of each method 
 ensuring that each of its class-based parameters is in fact of 
 the required type. That's not a problem.


Yes, and what he said is not currently possible in D because 
there's no way to know if an allocation is shared or not implying 
that the language *does* need changes.
Jan 26 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:

 GC in D is a pipedream, if it wasn't, why is it still so horrible?
 Everyone keeps dancing around the fact that if the GC wasn't horrible,
 nobody would work around it.


Rather, if everyone believed the GC was awesome in all circumstances, 
nobody would work around it. It could be awesome in all circumstances, 
but if people believe otherwise, they'll try working around it. It could 
be generally awesome but bad for a certain use case, in which case people 
who need to support that use case will need to work around it.

In this case, I think it's a marketing issue, not a technical one. D's 
being marketed as an alternative to C++, and existing C++ users tend to 
believe that any garbage collector is too slow to be usable.
Jan 26 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:

 In this case, I think it's a marketing issue, not a technical 
 one. D's being marketed as an alternative to C++, and existing 
 C++ users tend to believe that any garbage collector is too 
 slow to be usable.


Yes, I've noticed how some C++ programmers on reddit and other 
places say things like "I looked at the website for language X, 
but when I saw they mentioned using a GC I lost all interest".
Jan 26 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 26 January 2016 at 20:49:33 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:

 In this case, I think it's a marketing issue, not a technical 
 one. D's being marketed as an alternative to C++, and existing 
 C++ users tend to believe that any garbage collector is too 
 slow to be usable.


 Yes, I've noticed how some C++ programmers on reddit and other 
 places say things like "I looked at the website for language X, 
 but when I saw they mentioned using a GC I lost all interest".


These are looking for a reason not to use X. They were never 
potential users.
Jan 26 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 22:36:34 UTC, deadalnix wrote:

 On Tuesday, 26 January 2016 at 20:49:33 UTC, Ola Fosheim 
 Grøstad wrote:



 Yes, I've noticed how some C++ programmers on reddit and other 
 places say things like "I looked at the website for language 
 X, but when I saw they mentioned using a GC I lost all 
 interest".


 These are looking for a reason not to use X. They were never 
 potential users.


Actually, I don't think so. They have just been disappointed by 
other languages with a GC and have dismissed GC as a viable 
solution for their type of programming (like DSP).

I think being a non-GC programmer is a part of an _identity_ they 
take pride in.

You might say that is akin to audiophiles, sometimes it makes 
sense, sometimes not?
Jan 26 2016
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:

 On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:

 GC in D is a pipedream, if it wasn't, why is it still so 
 horrible? Everyone keeps dancing around the fact that if the 
 GC wasn't horrible, nobody would work around it.


 Rather, if everyone believed the GC was awesome in all 
 circumstances, nobody would work around it. It could be awesome 
 in all circumstances, but if people believe otherwise, they'll 
 try working around it. It could be generally awesome but bad 
 for a certain use case, in which case people who need to 
 support that use case will need to work around it.

 In this case, I think it's a marketing issue, not a technical 
 one. D's being marketed as an alternative to C++, and existing 
 C++ users tend to believe that any garbage collector is too 
 slow to be usable.


In any case where you attempt to write code in D that is equal in 
performance to C++, you must avoid the GC.
Either stop advertising D as an alternative to C++ or do 
something about this, because as it stands it's dishonest to say 
that D achieves the same performance as C++ when hiding the 
asterisk that is "when you abandon 90% of the standard library 
and much of the core language itself while jumping through hoops"
Jan 26 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:15:07 UTC, rsw0x wrote:

 In any case where you attempt to write code in D that is equal 
 in performance to C++, you must avoid the GC.


Yes, I don't see why anyone should have to link in the GC if they 
don't want to use it.
Jan 26 2016
parent reply Igor <Vladamir.I google.com> writes:
On Tuesday, 26 January 2016 at 21:21:53 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 21:15:07 UTC, rsw0x wrote:

 In any case where you attempt to write code in D that is equal 
 in performance to C++, you must avoid the GC.


 Yes, I don't see why anyone should have to link in the GC if 
 they don't want to use it.


I think the leaders are in over their heads. They have no real 
vision or plan to make D the language it can be. They are 
satisfied with their niche in the programming world.  They need a 
Steve Jobs type of person to make this stuff happen. Someone that 
understands what has to be done, in what order, and how to make 
it happen.

What D lacks is organizational structure! It's akin to a bunch of 
kids programming in their bedrooms cobbling together stuff and 
being ecstatic that it works(for them at least). D is basically 
stagnate(bug fixes and piddly stuff don't count), which is pretty 
sad considering it looks to be a one of the best languages on the 
planet.

If I said this stuff in North Korea I'd be hung!
Jan 26 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:

 I think the leaders are in over their heads. They have no real 
 vision or plan to make D the language it can be. They are 
 satisfied with their niche in the programming world.


The vision statement says this:

«Safety is a primary concern of all work, especially work 
involving early memory reclamation (below). Our main challenge 
for H1 2016 is to create a combination of language and library 
support for  safe reference counting. We would also hopefully 
support ownership patterns such as uniqueness with borrowing.»

And this:

«"No GC" is a primary concern going forward for the standard 
library and client code.
We need good language+library support and robust idioms to follow 
for good no-GC code.»

These are very weak statements, and there are no estimates. So 
what does it mean? Planning in H1, design in H2, implementation 
after that and production ready in 2-10 years? If so, why put it 
in H1? What is the ETA?

:-/



 If I said this stuff in North Korea I'd be hung!


There is quite a bit of whipping and screaming around here, but I 
have yet to see a hanging.
Jan 26 2016
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:

 D is basically stagnate(bug fixes and piddly stuff don't
 count), which is pretty sad considering it looks to be a
 one of the best languages on the planet.


 From this statement, I'm guessing that you started using D *very* 
recently. While there are certainly some major problems with D 
that need to be addressed, the idea that it is "stagnant" is 
ridiculous.

Go download a version of DMD from a few years ago, and see how 
far you get with compiling any major, modern D project:
     http://downloads.dlang.org/releases/2012/

D has made *massive* strides forward in the last few years, and 
from what I see the pace of development has not slowed 
significantly. The real problem is simply that D2 is an extremely 
ambitious project, and it will take a further huge investment of 
developer resources to bring it to something resembling 
completion.
Jan 26 2016
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:

 What D lacks is organizational structure! It's akin to a bunch 
 of kids programming in their bedrooms cobbling together stuff 
 and being ecstatic that it works(for them at least).


I'm going to chalk this up to lack of experience in volunteer 
based software projects.


 D is  basically stagnate(bug fixes and piddly stuff don't 
 count), which is pretty sad considering it looks to be a one of 
 the best languages on the planet.


This is absolutely ridiculous, I'm sorry, there's no other way to 
describe this.

The sheer number of new language features, removals of bad ideas, 
and new library features makes C++ growth look glacial in 
comparison. I literally know of no other language than Python 
that has as quick a turnaround on new ideas than D has.
Jan 26 2016
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 05:28:56 +0000, Jack Stouffer wrote:


 The sheer number of new language features, removals of bad ideas,
 and new library features makes C++ growth look glacial in comparison. I
 literally know of no other language than Python that has as quick a
 turnaround on new ideas than D has.


I think the general trend is to create a new language rather than evolve 
an existing one. It's easier to market.
Jan 26 2016
parent Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 27 January 2016 at 05:41:18 UTC, Chris Wright wrote:

 I think the general trend is to create a new language rather 
 than evolve an existing one. It's easier to market.


I have to disagree with you there. The number of new languages 
per year that hit more than, let's say, 10,000 continuous users 
is quite small; in most years it's zero.
Jan 26 2016
prev sibling parent reply Igor <Vladamir.I google.com> writes:
On Wednesday, 27 January 2016 at 05:28:56 UTC, Jack Stouffer 
wrote:

 On Tuesday, 26 January 2016 at 21:50:58 UTC, Igor wrote:

 What D lacks is organizational structure! It's akin to a bunch 
 of kids programming in their bedrooms cobbling together stuff 
 and being ecstatic that it works(for them at least).


 I'm going to chalk this up to lack of experience in volunteer 
 based software projects.


 D is  basically stagnate(bug fixes and piddly stuff don't 
 count), which is pretty sad considering it looks to be a one 
 of the best languages on the planet.


 This is absolutely ridiculous, I'm sorry, there's no other way 
 to describe this.

 The sheer number of new language features, removals of bad 
 ideas, and new library features makes C++ growth look glacial 
 in comparison. I literally know of no other language than 
 Python that has as quick a turnaround on new ideas than D has.


Um,

1. I'm not comparing it to C++.

2. Compared to the explosion that D1 had several years ago and 
all the libraries that were create and all the work, D is 
relatively stagnate. Just because stuff is still happening 
doesn't mean anything.

D has lost a lot of momentum in the Phobos\Tango mess and many of 
the eager programmers in D seemed to have moved on to greener 
pastures. It's been over 15 years since D's incarnation and one 
would expect it to be much much further along?

"C was originally developed by Dennis Ritchie between 1969 and 
1973". Within 10 years C as pretty much the defacto standard.

Maybe D needs to create it's own OS built on an OOP foundation 
without all the pitfalls of modern windows, OSX and Linux? Maybe 
that will put it on the map.
Jan 27 2016
next sibling parent Wilson <sdfdsfsdfsd sdasd.com> writes:
On Wednesday, 27 January 2016 at 22:32:33 UTC, Igor wrote:

 Maybe D needs to create it's own OS built on an OOP foundation 
 without all the pitfalls of modern windows, OSX and Linux? 
 Maybe that will put it on the map.


...I can't tell if you're being sarcastic or not...
Jan 27 2016
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 27 January 2016 at 22:32:33 UTC, Igor wrote:

 Um,

 1. I'm not comparing it to C++.

 2. Compared to the explosion that D1 had several years ago and 
 all the libraries that were create and all the work, D is 
 relatively stagnate. Just because stuff is still happening 
 doesn't mean anything.


Then you're discussing a different topic than most everyone else 
in this thread.

This thread began as a discussion of the language itself, not the 
D ecosystem as a whole. The explicit point of comparison is C++ 
(check the title and the O.P.).

Of course, this forum goes off topic all the time, so I'm not 
saying there's necessarily anything wrong with changing the 
subject - I'm just pointing out why people were confused about 
your point.
Jan 27 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 27 January 2016 at 22:32:33 UTC, Igor wrote:


 2. Compared to the explosion that D1 had several years ago and 
 all the libraries that were create and all the work, D is 
 relatively stagnate. Just because stuff is still happening 
 doesn't mean anything.

 D has lost a lot of momentum in the Phobos\Tango mess and many 
 of the eager programmers in D seemed to have moved on to 
 greener pastures. It's been over 15 years since D's incarnation 
 and one would expect it to be much much further along?


Not even close. I've been following and using D since 2003 and 
maintaining Derelict since 2004. I was there through the 
Phobos/Tango divide and the transition to D2. I can tell you 
anecdotally that things are running on quite a larger scale now 
than at any other point during that time. More libraries to 
choose from, more newsgroup traffic, more new people asking 
questions, more downloads of the compiler (as per the charts 
Andrei periodically posts), and more across the board. D is much 
further along than it used to be.
Jan 27 2016
parent Ola Foaheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 02:46:05 UTC, Mike Parker wrote:

 Phobos/Tango divide and the transition to D2. I can tell you 
 anecdotally that things are running on quite a larger scale now 
 than at any other point during that time. More libraries to 
 choose from, more newsgroup traffic, more new people asking 
 questions, more downloads of the compiler (as per the charts 
 Andrei periodically posts), and more across the board. D is 
 much further along than it used to be.


A fair section of the hardcore C/C++ developers have been lost to 
C++ and Rust. An influx of non hardcore developers does not lead 
to increased momentum regarding compiler and tooling, but will 
most likely lead to a increased resistance to breaking changes.

The measures of growth from search engines shows a loss of 
interest and stagnation.

As far as I can tell the hardcore developers who once viewed D as 
an upcoming star they dabbled with in anticipation if what will 
come increasingly view as a something of the past.

I believe these trends can turn around with the right strategy. 
With no clear strategy I predict that D will:

1. Loose attention of hardcore developers because of 
incompleteness.

2. Loose non hardcore developers to high level languages with 
better tooling and improving compilers/infrastructure.

So clearly, delivering on time matters.
Jan 27 2016
prev sibling next sibling parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-01-26 22:15 GMT+01:00 rsw0x via Digitalmars-d <
digitalmars-d puremagic.com>:


 In any case where you attempt to write code in D that is equal in
 performance to C++, you must avoid the GC.


No.
There are many places when performances could be optimized. The GC surely
can be improved, but avoid it is no silver bullet, and I even doubt it has
the most time spend / speedup ratio.

And that's only taking speed into account. There are many more factor to
take into account. Consistency / reliability should be the prime focus.
Because I keep getting compiler bugs, almost on a weekly basis.
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:49:16 UTC, Mathias Lang wrote:

 2016-01-26 22:15 GMT+01:00 rsw0x via Digitalmars-d < 
 digitalmars-d puremagic.com>:


 In any case where you attempt to write code in D that is equal 
 in performance to C++, you must avoid the GC.


 No.
 There are many places when performances could be optimized. The 
 GC surely
 can be improved, but avoid it is no silver bullet, and I even 
 doubt it has
 the most time spend / speedup ratio.


It is a silver bullet if you have:

1. latency requirements
2. memory consumption requirements
3. interfacing FFI requirements
...
Jan 26 2016
parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 26 January 2016 at 21:52:32 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 21:49:16 UTC, Mathias Lang wrote:

 2016-01-26 22:15 GMT+01:00 rsw0x via Digitalmars-d < 
 digitalmars-d puremagic.com>:


 In any case where you attempt to write code in D that is 
 equal in performance to C++, you must avoid the GC.


 No.
 There are many places when performances could be optimized. 
 The GC surely
 can be improved, but avoid it is no silver bullet, and I even 
 doubt it has
 the most time spend / speedup ratio.


 It is a silver bullet if you have:

 1. latency requirements
 2. memory consumption requirements
 3. interfacing FFI requirements
 ...


4. multithreaded allocations because the entire thing is wrapped 
in a mutex
Jan 26 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 26 Jan 2016 21:15:07 +0000, rsw0x wrote:


 On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote:

 On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:

 GC in D is a pipedream, if it wasn't, why is it still so horrible?
 Everyone keeps dancing around the fact that if the GC wasn't horrible,
 nobody would work around it.


 Rather, if everyone believed the GC was awesome in all circumstances,
 nobody would work around it. It could be awesome in all circumstances,
 but if people believe otherwise, they'll try working around it. It
 could be generally awesome but bad for a certain use case, in which
 case people who need to support that use case will need to work around
 it.

 In this case, I think it's a marketing issue, not a technical one. D's
 being marketed as an alternative to C++, and existing C++ users tend to
 believe that any garbage collector is too slow to be usable.


 
 In any case where you attempt to write code in D that is equal in
 performance to C++, you must avoid the GC.


Over on d.learn there was a post by H.S. Teoh today about how a struct 
deserializer she wrote used techniques that absolutely require a GC in 
order to work without leaking memory everywhere. The version of the code 
without this technique was an order of magnitude slower.

You could probably implement something in C++ that had similar 
performance, but you'd be writing a custom string type with reference 
counting, and it would be terribly annoying to use.

But the huge reason that it's a marketing problem rather than a technical 
one is that I doubt most people care enough about performance most of the 
time to need to avoid garbage collection. The success of Unity3D shows 
that you can write games in garbage collected languages, and those have 
at least moderate latency requirements.

If you're doing real-time programming, you do need to be very careful 
about the GC. If your entire application is real-time, then you can't use 
a GC at all. If portions of it have lower latency requirements, which, 
I'm told, is common, you can use  nogc in strategic places, call 
GC.disable and GC.enable where appropriate, and enjoy the best of both 
worlds.

A bit of digging suggests that real-time programs have troubles with 
malloc being too slow or having unpredictable latency, and there are a 
few specialized allocators for real-time systems. So this isn't so much a 
problem with GC in particular; it's more of a problem with general-
purpose allocators.
Jan 26 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 05:32:04 UTC, Chris Wright wrote:

 On Tue, 26 Jan 2016 21:15:07 +0000, rsw0x wrote:


 On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright 
 wrote:

 On Tue, 26 Jan 2016 19:04:33 +0000, rsw0x wrote:

 GC in D is a pipedream, if it wasn't, why is it still so 
 horrible? Everyone keeps dancing around the fact that if the 
 GC wasn't horrible, nobody would work around it.


 Rather, if everyone believed the GC was awesome in all 
 circumstances, nobody would work around it. It could be 
 awesome in all circumstances, but if people believe 
 otherwise, they'll try working around it. It could be 
 generally awesome but bad for a certain use case, in which 
 case people who need to support that use case will need to 
 work around it.

 In this case, I think it's a marketing issue, not a technical 
 one. D's being marketed as an alternative to C++, and 
 existing C++ users tend to believe that any garbage collector 
 is too slow to be usable.


 
 In any case where you attempt to write code in D that is equal 
 in performance to C++, you must avoid the GC.


 Over on d.learn there was a post by H.S. Teoh today about how a 
 struct deserializer she wrote used techniques that absolutely 
 require a GC in order to work without leaking memory 
 everywhere. The version of the code without this technique was 
 an order of magnitude slower.

 You could probably implement something in C++ that had similar 
 performance, but you'd be writing a custom string type with 
 reference counting, and it would be terribly annoying to use.


As I haven't reviewed the code, I'll leave no comment.


 But the huge reason that it's a marketing problem rather than a 
 technical one is that I doubt most people care enough about 
 performance most of the time to need to avoid garbage 
 collection. The success of Unity3D shows that you can write 
 games in garbage collected languages, and those have at least 
 moderate latency requirements.


Unity3D engine is written in C++, moot point. It's also well 
known in gaming communities for being incredibly underperforming. 
There's no "AAA" games written in Unity, just indie games and 
phone games.

Hilariously enough, if you google "What major games have been 
made with Unity?" The first result(for me, anyways) was a reddit 
thread
https://www.reddit.com/r/gamedev/comments/2qigo0/why_arent_more_aaa_games_developed_with_unity/

Top response
"It's super easy to get from 0% to 90% in Unity but really hard 
to get from 90% to 100%.* The garbage collector is a major 
culprit in this."


 If you're doing real-time programming, you do need to be very 
 careful about the GC. If your entire application is real-time, 
 then you can't use a GC at all. If portions of it have lower 
 latency requirements, which, I'm told, is common, you can use 
  nogc in strategic places, call GC.disable and GC.enable where 
 appropriate, and enjoy the best of both worlds.


Except the GC has leaked into the entire language.
Here's a fun idea, let's play "things that definitely should be 
usable in  nogc but are unusable in  nogc"
all core.thread.* functions are unusable in  nogc
for some dumb reason mutexes, semaphores, condition variables et 
cetera are classes; I have an in-house library that essentially 
wraps pthread primitives in structs.
I have no way to use exceptions in  nogc outside of massive 
hacks, I have to resort to C error handling.
I have to manually create my own functors to be able to capture 
variables by value in lambdas so that they're usable in  nogc. 
How C++98.
Alias template parameters are again massive hidden abusers of the 
GC.
Data structures? Haha. Nothing.
Logging? Time to create your own fprintf wrapper and wonder why 
you're not just using C directly.
This is just a tiny sample of my experience using  nogc.


 A bit of digging suggests that real-time programs have troubles 
 with malloc being too slow or having unpredictable latency, and 
 there are a few specialized allocators for real-time systems.


This is almost entirely applicable only to hard real-time. Note 
that hard real-time is a tiny minority of most real-time 
problems; it's almost always a variant of soft real-time.


 So this isn't so much a problem with GC in particular; it's 
 more of a problem with general- purpose allocators.


Yes, you allocate outside of the real-time parts and reuse memory 
in pools/buffers. This is completely against the grain of having 
a standard library that relies on a GC, the massive majority of 
Phobos(and hell, a lot of the runtime and language itself) is 
completely unusable in  nogc code.
The major problem with having a GC that it lulls developers into 
thinking it's okay to allocate *everywhere* because the cost of 
an allocation is now out of sight, and therefore, out of mind. 
This is doubly true for D's hidden allocations.

As a quick example, a lot of the code Walter rewrote to use 
ranges in Phobos over last year(? I think?) runs magnitudes 
faster while not allocating at all.

Yes, there are real-time garbage collectors. Yes, the London 

a low-latency C++ system despite this.
NASDAQ's OMX system, to the best of my knowledge, uses Java. With 
the garbage collector disabled and replaced with a C++-like 
allocator(JavaOne 2007, NASDAQ's CIO discussed this, and it is 
also talked about by Irene Aldridge in her 2012 publication)
Jan 26 2016
parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-01-27 8:10 GMT+01:00 rsw0x via Digitalmars-d <
digitalmars-d puremagic.com>:


 I have to manually create my own functors to be able to capture variables
 by value in lambdas so that they're usable in  nogc. How C++98.
 Alias template parameters are again massive hidden abusers of the GC.



For delegate you can use `scope delegate`, which is stack-allocated.
Using a sink-based approach like `toString` that specific point is quite
easily solved.
`scope` safety being unimplemented, it's also quite easy to abuse if you
don't have control over the function decl:

```
import core.stdc.stdio;
void main ()  nogc
{
    string foobar = "Value";
    scope sink = (int u) { printf("%s: %d\n", foobar.ptr, u); };
    foo(sink);
}

void foo (void delegate (int)  nogc sink)  nogc
{
    sink(42);
}
```
Alternatively, you can make foo's parameter `scope` and use the literal
inline, it's recognized by  nogc.
Jan 27 2016
parent reply rsw0x <anonymous anonymous.com> writes:
On Wednesday, 27 January 2016 at 08:48:20 UTC, Mathias Lang wrote:

 2016-01-27 8:10 GMT+01:00 rsw0x via Digitalmars-d < 
 digitalmars-d puremagic.com>:


 [...]



 For delegate you can use `scope delegate`, which is 
 stack-allocated.
 Using a sink-based approach like `toString` that specific point 
 is quite
 easily solved.
 `scope` safety being unimplemented, it's also quite easy to 
 abuse if you
 don't have control over the function decl:

 ```
 import core.stdc.stdio;
 void main ()  nogc
 {
     string foobar = "Value";
     scope sink = (int u) { printf("%s: %d\n", foobar.ptr, u); };
     foo(sink);
 }

 void foo (void delegate (int)  nogc sink)  nogc
 {
     sink(42);
 }
 ```
 Alternatively, you can make foo's parameter `scope` and use the 
 literal
 inline, it's recognized by  nogc.


This is not applicable in a scenario where I want to actually 
copy the parameters by value.
It still captures the context, it just allows it to move down the 
stack.
Jan 27 2016
parent Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-01-27 9:56 GMT+01:00 rsw0x via Digitalmars-d <
digitalmars-d puremagic.com>:


 This is not applicable in a scenario where I want to actually copy the
 parameters by value.
 It still captures the context, it just allows it to move down the stack.


Then a library solution to do so is trivial.
Jan 27 2016
prev sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:

 Now, D can do the exact same as C++ .


That is a lie. Large parts of druntime still allocate GC memory 
and thus will cause the GC to run. For example core.thread. We 
need a solution where druntime can be used without druntime ever 
doing a single allocation through the gc.
Jan 26 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 26/01/16 11:33, deadalnix wrote:

 On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad wrote:

 Would it be possible to make a fully compatible unique_ptr/shared_ptr
 solution that acts as the default memory management scheme in D within
 6 months?


 Now if one want to use that, D is very capable of doing it already. Just
 won't make it the default (like it is not the default in C++ either).


I bring it up every time the subject comes up, in the hopes that at some 
point it will sink in.

No, D is not capable of doing it already. Without 100% reliable 
destructors, RAII is simply not implementable.

D's destructors are not guaranteed to run on 100% of fully initialized 
structs, which means that a RAII container has no way to make sure its 
resource is actually freed. It is up to the implementer. This eradicates 
almost all of the utility RAII was meant to provide.

Shachar
Jan 27 2016
next sibling parent reply Minas Mina <minas_0 hotmail.co.uk> writes:
On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh 
wrote:

 On 26/01/16 11:33, deadalnix wrote:

 On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim 
 Grøstad wrote:

[...]


 Now if one want to use that, D is very capable of doing it 
 already. Just
 won't make it the default (like it is not the default in C++ 
 either).


 I bring it up every time the subject comes up, in the hopes 
 that at some point it will sink in.

 No, D is not capable of doing it already. Without 100% reliable 
 destructors, RAII is simply not implementable.

 D's destructors are not guaranteed to run on 100% of fully 
 initialized structs, which means that a RAII container has no 
 way to make sure its resource is actually freed. It is up to 
 the implementer. This eradicates almost all of the utility RAII 
 was meant to provide.

 Shachar


Can you show a case where this happens?
Jan 27 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 27/01/16 16:24, Minas Mina wrote:

 On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh wrote:

 On 26/01/16 11:33, deadalnix wrote:

 On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad wrote:

 [...]


 Now if one want to use that, D is very capable of doing it already. Just
 won't make it the default (like it is not the default in C++ either).


 I bring it up every time the subject comes up, in the hopes that at
 some point it will sink in.

 No, D is not capable of doing it already. Without 100% reliable
 destructors, RAII is simply not implementable.

 D's destructors are not guaranteed to run on 100% of fully initialized
 structs, which means that a RAII container has no way to make sure its
 resource is actually freed. It is up to the implementer. This
 eradicates almost all of the utility RAII was meant to provide.

 Shachar


 Can you show a case where this happens?


Sure. Here it is, again:

import std.stdio;

struct RAII {
     int num;

     ~this() {
         writefln("Destructed %s", num);
     }
}

struct Container {
     int num;
     RAII raii;

     this(int num) {
         writefln("Constructing %s", num);
         this.num = num;
         raii = RAII(num);

         if( num==0 )
             throw new Exception("Ooops");
     }
}

void test(int num) {
     try {
         auto c = Container(num);
         writefln("Point %s", num);
     } catch(Exception ex) {
         writefln("Caught %s", ex.msg);
     }
}

void main()
{
     test(1);
     test(0);
}
Jan 27 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/27/2016 09:51 AM, Shachar Shemesh wrote:

 import std.stdio;

 struct RAII {
      int num;

      ~this() {
          writefln("Destructed %s", num);
      }
 }

 struct Container {
      int num;
      RAII raii;

      this(int num) {
          writefln("Constructing %s", num);
          this.num = num;
          raii = RAII(num);

          if( num==0 )
              throw new Exception("Ooops");
      }
 }

 void test(int num) {
      try {
          auto c = Container(num);
          writefln("Point %s", num);
      } catch(Exception ex) {
          writefln("Caught %s", ex.msg);
      }
 }

 void main()
 {
      test(1);
      test(0);
 }


Interesting. It may be worked around, but is arguably a mistake in the 
language definition. Have you submitted an issue for this? -- Andrei
Jan 27 2016
next sibling parent reply ZombineDev <valid_email he.re> writes:
On Wednesday, 27 January 2016 at 17:08:09 UTC, Andrei 
Alexandrescu wrote:

 On 01/27/2016 09:51 AM, Shachar Shemesh wrote:

 import std.stdio;

 struct RAII {
      int num;

      ~this() {
          writefln("Destructed %s", num);
      }
 }

 struct Container {
      int num;
      RAII raii;

      this(int num) {
          writefln("Constructing %s", num);
          this.num = num;
          raii = RAII(num);

          if( num==0 )
              throw new Exception("Ooops");
      }
 }

 void test(int num) {
      try {
          auto c = Container(num);
          writefln("Point %s", num);
      } catch(Exception ex) {
          writefln("Caught %s", ex.msg);
      }
 }

 void main()
 {
      test(1);
      test(0);
 }


 Interesting. It may be worked around, but is arguably a mistake 
 in the language definition. Have you submitted an issue for 
 this? -- Andrei


https://github.com/D-Programming-Language/dmd/pull/5151 has been 
on the table since Aug 14, 2015.
Jan 27 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/27/2016 03:09 PM, ZombineDev wrote:

 https://github.com/D-Programming-Language/dmd/pull/5151 has been on the
 table since Aug 14, 2015.


Thanks! I've initiated a follow up with Walter and Martin. -- Andrei
Jan 27 2016
prev sibling parent Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Wednesday, 27 January 2016 at 17:08:09 UTC, Andrei 
Alexandrescu wrote:

 Interesting. It may be worked around, but is arguably a mistake 
 in the language definition. Have you submitted an issue for 
 this? -- Andrei


1) https://issues.dlang.org/show_bug.cgi?id=14246

Includes suggestion on how the compiler could handle it.

2) https://issues.dlang.org/show_bug.cgi?id=9704

Related issue with postblits.

3) https://issues.dlang.org/show_bug.cgi?id=2590

Here, Don suggests that it's not a bug because destructors should 
only run on fully constructed objects, referencing C++. However, 
IMO this is not a valid argument for D, as we have .init, which 
is always a valid state. It can still be debated whether the 
destructor of the failed object itself should run, but it should 
always be safe to run the destructors of members.
Jan 28 2016
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh 
wrote:

 I bring it up every time the subject comes up, in the hopes 
 that at some point it will sink in.

 No, D is not capable of doing it already. Without 100% reliable 
 destructors, RAII is simply not implementable.

 D's destructors are not guaranteed to run on 100% of fully 
 initialized structs, which means that a RAII container has no 
 way to make sure its resource is actually freed. It is up to 
 the implementer. This eradicates almost all of the utility RAII 
 was meant to provide.

 Shachar


The only time it may not run, it is when these are collected by 
the GC. Which is not a problem if you want to use RAII, as in 
C++, to not use a GC.

What need to sink in is that, when it come to RAII, you have all 
the same tool as in C++ and can do all the same shit (modulo 
internal pointers), as unasfely as in C++.
Jan 27 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 20:28:42 +0000, deadalnix wrote:


 On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh wrote:

 I bring it up every time the subject comes up, in the hopes that at
 some point it will sink in.

 No, D is not capable of doing it already. Without 100% reliable
 destructors, RAII is simply not implementable.

 D's destructors are not guaranteed to run on 100% of fully initialized
 structs, which means that a RAII container has no way to make sure its
 resource is actually freed. It is up to the implementer. This
 eradicates almost all of the utility RAII was meant to provide.

 Shachar


 
 The only time it may not run, it is when these are collected by the GC.
 Which is not a problem if you want to use RAII, as in C++, to not use a
 GC.


Shachar Shemesh showed us that a struct's fields do not have their 
destructors called when the struct's constructor throws an exception.

This doesn't make RAII impossible. It's an unexpected annoyance, though, 
and it complicates the use of RAII. On the plus side, there's a pull 
request to change this.
Jan 27 2016
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
I humbly believe D should not care about C++ any more. It should 
take own path, and attract developers not just from the C++ camp.

No matter from which camp someone comes, that person will 
complain about something. Obviously, C/C++ programmers complain 
about GC because they are used to manage the memory manually. 
People from JVM (this is where I belong even though I use D for 
over 10 years) and .NET worlds can rightfully complain about many 
things especially in the area of business applications and 
systems, distributed systems (90% of big-data solutions run on 
Spark, Hadoop or Storm).

People from functional worlds will complain about OOP approach in 
the standard library. People from OOP world will complain about 
modules in the standard library that are done in more functional 
way...

Finding a balance is hard, and I humbly believe having all the 
features C++ has in D will help...
Jan 26 2016
parent Dejan Lekic <dejan.lekic gmail.com> writes:
 Finding a balance is hard, and I humbly believe having all the 
 features C++ has in D will help...


Correction: ...WILL NOT help...
Jan 26 2016
prev sibling next sibling parent reply Sergei Degtiarev <sdegtiarev yahoo.com> writes:
On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad 
wrote:

 Just a thought:
 2. Converting C++ programmers is a good recruitment strategy.
 4. When C++17 is released, current C++ programmers will go "I 
 was ready to leave C++
 If not, what is the strategy behind focusing on interfacing 
 with C++? (Evaluated in relation to the C++17 release.)


I think, you see it at wrong angle. Yes, I am C++ programmer, and 
I love it, and I anticipate C++17 coming. And I also like D, and 
hope it eventually be another language I will be as fluent as I'm 
in C++ now, but I'm no way going to be "converted". If you are 
going to recruit those who about to abandon C++, you will have 
the worst part.
Memory management review in D is a bright idea, and challenging 
project, it might be a dream project for some, so wouldn't it be 
better spoken as "attracting" C++ people instead of "converting" 
them? Sure, you will get much more enthusiasm talking about it 
this way.
I believe, D and C++ are sibling languages and opposing them is 
kind of counterproductive.
Jan 26 2016
next sibling parent reply Bubbasaur <bubba gmail.com> writes:
Really I don't get this talk about convert someone from a 
language x to y. It will be very hard, some are programming since 
a long time and many don't want to change no matter what, and 
there are other issues like jobs and so on.

I think we need to gather attention from new people that are 
entering in the field. So they don't mind to risk or try new 
languages.

If a guy wants a language that compiles to a native code, and 
it's "easier" than C++, has GC and so on, then he will be 
fascinated by D and finally you won a new user.
Jan 26 2016
parent Sergei Degtiarev <sdegtiarev yahoo.com> writes:
On Wednesday, 27 January 2016 at 06:16:47 UTC, Bubbasaur wrote:

 Really I don't get this talk about convert someone from a 
 language x to y. It will be very hard, some are programming 
 since a long time and many don't want to change no matter what, 
 and there are other issues like jobs and so on.

 I think we need to gather attention from new people that are 
 entering in the field. So they don't mind to risk or try new 
 languages.

 If a guy wants a language that compiles to a native code, and 
 it's "easier" than C++, has GC and so on, then he will be 
 fascinated by D and finally you won a new user.


Absolutely, totally agree, and I am indeed one of these C++ 
programmers. I'm actually fascinated by different set of D 
features, but nevertheless.
Jan 27 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 03:06:35 UTC, Sergei Degtiarev 
wrote:

 I think, you see it at wrong angle. Yes, I am C++ programmer, 
 and I love it, and I anticipate C++17 coming. And I also like 
 D, and hope it eventually be another language I will be as 
 fluent as I'm in C++ now, but I'm no way going to be 
 "converted".


Please note that I am talking about getting C++ programmers to 
pick D for their weekend programming, not their work-related 
programming.

C++ is a good recruitment platform because compiler programmers 
should:

1. like low level programming
2. understand the hardware
3. like to make code fast
4. be able to drop down to C/C++ for interfacing with backends

But you also want them to have a good theoretical background. 
That makes for a much smaller population to recruit from.


 If you are going to recruit those who about to abandon C++, you 
 will have the worst part.


I don't think so. Most people with a comp. sci. background has 
known that C++ is a flawed language from it's inception. Those 
people are better qualified to do improve the language. What 
keeps C++ rolling is that no other language provides the full 
feature set in the right packaging. + frameworks.


 Memory management review in D is a bright idea, and challenging 
 project, it might be a dream project for some, so wouldn't it 
 be better spoken as "attracting" C++ people instead of 
 "converting" them? Sure, you will get much more enthusiasm 
 talking about it this way.


Ok, but if they don't favour D over C++, will they then have 
enough interest in D to work on the compiler + tooling?

C++ and Rust have many more people working on compilers and 
tooling, so over time D either needs to expand the number of core 
"weekend" contributors or reduce the scope of the project.
Jan 26 2016
prev sibling parent Wilson <sdfdsfsdfsd sdasd.com> writes:
I wouldn't be using D if there wasn't a way around the GC. I 
don't have a grudge against Garbage Collection, I just can't have 
all my threads paused in a real-time application for practical 
reasons. If a user is running my program on a slow machine and I 
need to run a lot of code per frame then I don't have time for a 
collection to run, not ever. I do have to jump through a few 
hoops but with each update of the language and standard library 
I've definitely noticed improvements in getting around the GC.

If you want C++ programmers then you need to make messing around 
with D be near _zero_ commitment. By that I mean that if you 
write some code in D you should be able to make it compatible 
with a C++ project with very little effort. I don't know how D 
handles this as I haven't needed to make my D code work in a 
project that's mostly written in C++, but I haven't seen a 
feature like this heavily marketed, which is what you'd want to 
do when appealing to C++ programmers.

The reverse sweetens the deal. If you can easily use your 
favorite C++ library when writing D code then there are no 
worries about having to roll your own. Having alternatives, 
ports, and bindings for major libraries is great, and D does have 
these for many libraries a C++ developer might want... but I'm 
not sure how someone would go about binding their own C++ code... 
I don't know if it's easy or a huge pain?

D looks better and feels better to write than C++ so retaining 
C++ developers isn't going to be an issue, just getting them to 
try it and providing them with access to the libraries they need 
is all you need to really do... and yeah, making coding without 
the GC more viable would help a lot. I mean, jumping through all 
the hoops to get around the GC is still better than working with 
C++, template semantics alone make up for that, but my life could 
be make a lot easier with less hoops.

The other thing that would really help is better IDE support... 
It might just be because I'm using Linux but I've really had to 
hack together something that supports my needs. Most C++ 
programmers are going to want an easy plugin solution into their 
IDE of choice, which might be VS, or it might be whatever fringe 
IDE that doesn't bug out on their system.
Jan 27 2016