Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

A friend of mine needed to complete a small project and thought of using 
a language he didn't know for it. He already knew I work on D so he 
considered it alongside Go. He ended up choosing the latter, and 
documented his decision making process in a few notes that he 
subsequently shared with me. I'll paste below a sort of transcript of 
his handwritten notes.

I think this is valuable information from a relatively unbiased 
potential user, and good ideas and action items on how we can improve 
our curb appeal. Even mistaken perceptions are good signal - it means 
our materials weren't explicit enough to dispel them.

====================

* Golang: simple!

+ very small language, very concise & simple
+ playground/tutorial
+ easy to start using it, no-nonsense
+ vast libraries
+ no inheritance
+ one binary to distribute
+ good for servers
+ feels like a better C (mostly)
- can't write generic code involving arrays/slices
- no good IDE
+ Google!
+ clear feeling it's here to stay
+ visible, many projects
+ enforced style (indentation, exports)

* Dlang: big!










sign but sits emtpy; by comparison Go -> condo in hip, trendy area

* Ideas for D

















programming language design challenge there is, but less focused on 
purpose (Andrei's note: I assume D more at fault than C++ on this)

General feeling: "I don't feel smart enough for D and am looking for a 
quick way to accomplish a goal. I've read the Wikipedia article on D and 
didn't understand a few things. The examples seem to show off the 
language but that made them confusing. I wanted to get more into it, but 
by that time Go had already won - I looked at the tutorials, changed the 
sample code a bit right in the browser to see how it'd work for me, it 
was easy, I was in already. Some of my comments therefore illustrate my 
shortcomings than the language's, but that's true one way or another for 
all programmers (that's why technical superiority of a language doesn't 
guarantee its success)."

===============

I'd love us to derive a few action items from this and other feedback.


Andrei

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 I'd love us to derive a few action items from this and other 
 feedback.

I think the front page focuses too much on the language itself at 
the moment. Perhaps we should continue with the direction with 
forum integration, and devote a good piece of real estate for the 
ecosystem (e.g. latest code.dlang.org updates) and maybe an IDE 
screenshot carousel, OSLT. Making it up-front that we have three 
compilers, a built-in profiler, and tight GDB integration might 
also be worthwhile.

"Mengu" <mengukagan gmail.com> writes:

On Friday, 13 March 2015 at 02:00:08 UTC, Vladimir Panteleev 
wrote:
 On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
 wrote:
 I'd love us to derive a few action items from this and other 
 feedback.

 I think the front page focuses too much on the language itself 
 at the moment. Perhaps we should continue with the direction 
 with forum integration, and devote a good piece of real estate 
 for the ecosystem (e.g. latest code.dlang.org updates) and 
 maybe an IDE screenshot carousel, OSLT. Making it up-front that 
 we have three compilers, a built-in profiler, and tight GDB 
 integration might also be worthwhile.

this and reading the rest of the comments here, i have another 
suggestion:

let's have four tabbed examples in the front page.

1) simple example
2) vibe.d example
3) advanced example
4) concurrency example

"disme" <noreply hotmail.com> writes:

do you people really want to see this language be more popular? 
do you? doesnt look like it at all to me, the only few people in 
those 18+ pages that are actually telling you the real problems 
are mostly being ignored for futile python, go and rust talk, 
seriously?

let me go ahead and say that no i dont use D, ive found it awhile 
ago and came back to look at it from time to time which puts me 
in a perfect spot to tell you that the fundamental problems for 
new comers are right here, in those posts:

page 7 - Leandro Motta Barros' post
page 10 - Almighty Bob's first post
page 11 - Almighty Bob's post (again)
page 14 - rumbu's first post
page 17 - Xavier Bigand's post
page XX - many of Chris' posts
(may have missed a few but those are the ones that jumped out at 
me where i really went "THIS MAN GETS IT!")

yes, those are fundamental problems FOR A NEW COMER! 90% of the 
posts i see in this thread are a bunch of... i dont even know? 
advanced "problems" that new comers would have no clue what they 
are about, only those few posts i mentioned are seeing the real 
problems.

this community seems to be filled with really intelligent, 
dedicated people capable of solving some of the hardest 
challenges but you fail to see the tiny little bitty small things 
that are stopping the new comers and instead you worry about 
things that are far beyond their scope people...

i guess ill find out in a few months when i visit the language 
again if those posts have been paid attention to, with that said 
i wonder how many people will reply to this because they havent 
read until the end (tiny little bitty detail slipping by again?)

"Chris" <wendlec tcd.ie> writes:

On Sunday, 15 March 2015 at 14:15:18 UTC, disme wrote:
 do you people really want to see this language be more popular? 
 do you? doesnt look like it at all to me, the only few people 
 in those 18+ pages that are actually telling you the real 
 problems are mostly being ignored for futile python, go and 
 rust talk, seriously?

 let me go ahead and say that no i dont use D, ive found it 
 awhile ago and came back to look at it from time to time which 
 puts me in a perfect spot to tell you that the fundamental 
 problems for new comers are right here, in those posts:

 page 7 - Leandro Motta Barros' post
 page 10 - Almighty Bob's first post
 page 11 - Almighty Bob's post (again)
 page 14 - rumbu's first post
 page 17 - Xavier Bigand's post
 page XX - many of Chris' posts
 (may have missed a few but those are the ones that jumped out 
 at me where i really went "THIS MAN GETS IT!")

 yes, those are fundamental problems FOR A NEW COMER! 90% of the 
 posts i see in this thread are a bunch of... i dont even know? 
 advanced "problems" that new comers would have no clue what 
 they are about, only those few posts i mentioned are seeing the 
 real problems.

 this community seems to be filled with really intelligent, 
 dedicated people capable of solving some of the hardest 
 challenges but you fail to see the tiny little bitty small 
 things that are stopping the new comers and instead you worry 
 about things that are far beyond their scope people...

 i guess ill find out in a few months when i visit the language 
 again if those posts have been paid attention to, with that 
 said i wonder how many people will reply to this because they 
 havent read until the end (tiny little bitty detail slipping by 
 again?)

We invariably end up talking about language features and syntax, 
as if D lost out against Go, because of feature X being (or not 
being) there. We lose, because we fail to give people that warm 
glow in their chests. The feeling of "now I have something", 
which is basically what makes people go for something. I felt 
like this about D when I first got to know it, after a long 
period of being frustrated with every other language. Although 
irrational, my intuition was that D would offer me a lot, and it 
hasn't failed to do so. But this is, because I was willing to 
make an effort. Many potential users are either not willing to 
make an effort or they don't have enough time. So we should make 
it as easy as possible for them. As was said in a post earlier, 
the decision to go for language X is often not 100% rational, but 
also based on subjective positive feelings. To ignore this basic 
human fact, doesn't help us. Having a great language with 
advanced features and doing some "feel good" marketing are not 
mutually exclusive.

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Sunday, 15 March 2015 at 14:56:23 UTC, Chris wrote:
 We invariably end up talking about language features and 
 syntax, as if D lost out against Go, because of feature X being 
 (or not being) there. We lose, because we fail to give people 
 that warm glow in their chests. The feeling of "now I have 
 something", which is basically what makes people go for 
 something. I felt like this about D when I first got to know 
 it, after a long period of being frustrated with every other 
 language. Although irrational, my intuition was that D would 
 offer me a lot, and it hasn't failed to do so. But this is, 
 because I was willing to make an effort. Many potential users 
 are either not willing to make an effort or they don't have 
 enough time. So we should make it as easy as possible for them.

Makes a lot of sense. But…

 As was said in a post earlier, the decision to go for language 
 X is often not 100% rational, but also based on subjective 
 positive feelings. To ignore this basic human fact, doesn't 
 help us. Having a great language with advanced features and 
 doing some "feel good" marketing are not mutually exclusive.

This is true, but D's main problem isn't that people haven't come 
to D with high expectations of getting a better alternative to 
C++. The problem is that they came for emotional reasons and left 
for rational reasons.

They key is in understanding why people leave. Retention of the 
_target audience_ is more important than adoption rate.

It seems that many of those that stays with D either picked it 
for a hobby, or are not primarily programmers (I am not really 
sure why they pick D? Does not seem like a rational choice.), 
then a very small (and vocal) group use it for business.

In my opinion you need to pick a target audience, and with the 
CTFE focus targeting professional system level programmers is the 
only thing that makes sense. D needs to deliver on all aspects 
that C++ is good at before it is marketable, or else it will stay 
a hobby language for professionals and others. That means 
matching C++ on stability too.

If it is more work to implement smart pointers in D than in C++, 
then there are some fundamentally unacceptable limits in the core 
language. So it is not only marketing... D is not complete.

D needs a redesign to get away from lock-the-world GC without 
scars... A  language redesign that cannot be done with "last 
minute patches of special casing hell".

Over focusing on growing the user base by making tutorials, will 
only make changes harder, and it will attract the wrong kind of 
people that will ask for the non-system-level features making it 
even harder to improve the core language.

Why grow the user base before the language is done? You end up 
with no target audience, a very fragmented user base and equally 
fragmented eco system. Fragmentation makes it harder to produce 
professional level things.

It is also completely misguided to push D as a web dev platform. 
D is up against: Ruby, Python, Dart, node.js+angular, Java, Go 
etc in an environment where performance is mostly about 
networking, database/ORM integration and infrastructure 
AWS/Azure/Google... D is nowhere near being a plausible solution 
in this space, CTFE is essentially pointless in this domain.

"Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:

On Monday, 16 March 2015 at 09:31:17 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 15 March 2015 at 14:56:23 UTC, Chris wrote:
 We invariably end up talking about language features and 
 syntax, as if D lost out against Go, because of feature X 
 being (or not being) there. We lose, because we fail to give 
 people that warm glow in their chests. The feeling of "now I 
 have something", which is basically what makes people go for 
 something. I felt like this about D when I first got to know 
 it, after a long period of being frustrated with every other 
 language. Although irrational, my intuition was that D would 
 offer me a lot, and it hasn't failed to do so. But this is, 
 because I was willing to make an effort. Many potential users 
 are either not willing to make an effort or they don't have 
 enough time. So we should make it as easy as possible for them.

 Makes a lot of sense. But…

 As was said in a post earlier, the decision to go for language 
 X is often not 100% rational, but also based on subjective 
 positive feelings. To ignore this basic human fact, doesn't 
 help us. Having a great language with advanced features and 
 doing some "feel good" marketing are not mutually exclusive.

 This is true, but D's main problem isn't that people haven't 
 come to D with high expectations of getting a better 
 alternative to C++. The problem is that they came for emotional 
 reasons and left for rational reasons.

This is an interesting assertion, and you have been around here 
much longer than me.  Of course the above must be generally true 
of any language (since one develops a better sense for what it is 
like by using it for a while), and I suppose it is also true that 
people who stick with D stick for more informed reasons.  Are 
there reasons to be concerned that the right kind of people don't 
stick with D, given that it is still maturing as a language, that 
not everyone can use it at work, and that there are many options 
available now, so a degree of churn is normal.  A language will 
be successful by starting with a very high appeal to a certain 
group, rather than a modest appeal to everyone.

 They key is in understanding why people leave. Retention of the 
 _target audience_ is more important than adoption rate.

Okay, but target audience is an emergent more than a centrally 
planned property, although one can remove the obvious roadblocks 
for certain important groups.

 It seems that many of those that stays with D either picked it 
 for a hobby, or are not primarily programmers (I am not really 
 sure why they pick D? Does not seem like a rational choice.), 
 then a very small (and vocal) group use it for business.

I don't know if true without the data (is it worth trying a 
questionnaire on the download page) but supposing it is true is 
this surprising given it is not yet standard in the enterprise, 
and most firms are conservative?  Surely most languages get their 
start in this way.  It is a rational choice for people in this 
camp because native code, and who wants to deal with C++.   (And 
I love C, but...)
 In my opinion you need to pick a target audience, and with the 
 CTFE focus targeting professional system level programmers is 
 the only thing that makes sense. D needs to deliver on all 
 aspects that C++ is good at before it is marketable, or else it 
 will stay a hobby language for professionals and others. That 
 means matching C++ on stability too.

See Innovator's Dilemma and Peter Thiel's work.  It needs to have 
a monopoly of appeal to certain groups, and as it develops spread 
out from there.  I don't see the link between CTFE and systems 
level programming.

 If it is more work to implement smart pointers in D than in 
 C++, then there are some fundamentally unacceptable limits in 
 the core language. So it is not only marketing... D is not 
 complete.

 D needs a redesign to get away from lock-the-world GC without 
 scars... A  language redesign that cannot be done with "last 
 minute patches of special casing hell".

I don't claim to understand the topic well enough, but it looks 
to me like a relative resource question combined with a desire to 
do things elegantly (which takes longer even though it is the 
right way) not a fundamental design question.

 Over focusing on growing the user base by making tutorials, 
 will only make changes harder, and it will attract the wrong 
 kind of people that will ask for the non-system-level features 
 making it even harder to improve the core language.

 Why grow the user base before the language is done? You end up 
 with no target audience, a very fragmented user base and 
 equally fragmented eco system. Fragmentation makes it harder to 
 produce professional level things.

That's one reason saying "D hasn't gone anywhere, so it won't" 
seems a misdiagnosis.  It wouldn't have been possible/ the cost 
would have been higher to move to D2 with a much larger installed 
base (look at Python), and the language previously perhaps wasn't 
ready for prime time.  There is a lot of FUD from this talk of D 
not being finished - it seems like it's more than finished enough 
to do good work in many domains.  I appreciate for realtime the 
GC is a problem, but that surely isn't a majority of use cases 
and can be worked around (viz Sociomantic).  I almost was put off 
by the complaining (which goes back a decade and is to be 
expected where people really do care), but am glad I pressed 
ahead.

I am not sure what more non-system level users would ask for as 
_language_ features, nor what would lead to fragmentation rather 
than diversity in the user base.  The forums will suffer in 
signal:noise at some point, which is a natural cost of growth, 
and this would need to be dealt with thoughtfully, but that is a 
good kind of problem to have.  I really don't see how tutorials 
will hurt the language, because it will bring in more users with 
resources, and that will also help in the longer run.

D cannot be centrally planned, so one must be careful in speaking 
of target audience - especially when one cannot know in advance 
about who will stumble across it and find it useful.

 It is also completely misguided to push D as a web dev 
 platform. D is up against: Ruby, Python, Dart, node.js+angular, 
 Java, Go etc in an environment where performance is mostly 
 about networking, database/ORM integration and infrastructure 
 AWS/Azure/Google... D is nowhere near being a plausible 
 solution in this space, CTFE is essentially pointless in this 
 domain.

That covers a multitude of use cases, and I am not sure that 
every one of these requires more of those things you mention than 
are currently available.  Ruppe uses it for web development, I 
think.  It seems rather defeatist to suggest that because one 
lacks features in certain domains one should just not even try to 
develop them, although I can understand the frustration.

"Sativa" <Sativa Indica.org> writes:

On Sunday, 15 March 2015 at 14:15:18 UTC, disme wrote:
 do you people really want to see this language be more popular? 
 do you? doesnt look like it at all to me, the only few people 
 in those 18+ pages that are actually telling you the real 
 problems are mostly being ignored for futile python, go and 
 rust talk, seriously?

 let me go ahead and say that no i dont use D, ive found it 
 awhile ago and came back to look at it from time to time which 
 puts me in a perfect spot to tell you that the fundamental 
 problems for new comers are right here, in those posts:

 page 7 - Leandro Motta Barros' post
 page 10 - Almighty Bob's first post
 page 11 - Almighty Bob's post (again)
 page 14 - rumbu's first post
 page 17 - Xavier Bigand's post
 page XX - many of Chris' posts
 (may have missed a few but those are the ones that jumped out 
 at me where i really went "THIS MAN GETS IT!")

 yes, those are fundamental problems FOR A NEW COMER! 90% of the 
 posts i see in this thread are a bunch of... i dont even know? 
 advanced "problems" that new comers would have no clue what 
 they are about, only those few posts i mentioned are seeing the 
 real problems.

 this community seems to be filled with really intelligent, 
 dedicated people capable of solving some of the hardest 
 challenges but you fail to see the tiny little bitty small 
 things that are stopping the new comers and instead you worry 
 about things that are far beyond their scope people...

 i guess ill find out in a few months when i visit the language 
 again if those posts have been paid attention to, with that 
 said i wonder how many people will reply to this because they 
 havent read until the end (tiny little bitty detail slipping by 
 again?)

Why do you believe that something has to be dumbed down for your 
sake instead of stepping up and learning learning something that 
will prove to be more powerful in the end?

I don't think D or anything should kowtow to "KISS". Of course 
the lazy ignorant masses want this but humanity ultimate 
suffers... and there is enough simple programming languages for 
simple people. Do we really want another Python, Go, Java, perl, 
php, asp, JS, lua, Ruby, Rust... Oh, wait, instead of listing 
hundreds of languages, just look here:

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

Most of those damn languages are essentially just syntactically 
different. Python vs Perl vs php? Who cares, it's all the same 
crap. If all the energy went in to creating a better languages 
with more power(power != complex) instead of just duplicating the 
stone wheel then maybe we can get somewhere?

I really find it odd when someone complains about a "feature" but 
never uses it. e.g., "I don't like /++/", How often do you use 
it? "Never, I don't like it!"... then whats the problem, if you 
don't use it then how is it getting in the way of your progress? 
"Well, because other people use it and I get confused when I see 
it in their code!". So, instead of allowing them to program the 
way they want, you want to control them so you don't have to 
think as hard?

Wouldn't you agree: "The best language is the one that gets out 
of the way and lets you do exactly what you need to do in the 
most efficient way(which isn't just about time).

"deadalnix" <deadalnix gmail.com> writes:

On Sunday, 15 March 2015 at 14:59:22 UTC, Sativa wrote:
 On Sunday, 15 March 2015 at 14:15:18 UTC, disme wrote:
 do you people really want to see this language be more 
 popular? do you? doesnt look like it at all to me, the only 
 few people in those 18+ pages that are actually telling you 
 the real problems are mostly being ignored for futile python, 
 go and rust talk, seriously?

 let me go ahead and say that no i dont use D, ive found it 
 awhile ago and came back to look at it from time to time which 
 puts me in a perfect spot to tell you that the fundamental 
 problems for new comers are right here, in those posts:

 page 7 - Leandro Motta Barros' post
 page 10 - Almighty Bob's first post
 page 11 - Almighty Bob's post (again)
 page 14 - rumbu's first post
 page 17 - Xavier Bigand's post
 page XX - many of Chris' posts
 (may have missed a few but those are the ones that jumped out 
 at me where i really went "THIS MAN GETS IT!")

 yes, those are fundamental problems FOR A NEW COMER! 90% of 
 the posts i see in this thread are a bunch of... i dont even 
 know? advanced "problems" that new comers would have no clue 
 what they are about, only those few posts i mentioned are 
 seeing the real problems.

 this community seems to be filled with really intelligent, 
 dedicated people capable of solving some of the hardest 
 challenges but you fail to see the tiny little bitty small 
 things that are stopping the new comers and instead you worry 
 about things that are far beyond their scope people...

 i guess ill find out in a few months when i visit the language 
 again if those posts have been paid attention to, with that 
 said i wonder how many people will reply to this because they 
 havent read until the end (tiny little bitty detail slipping 
 by again?)

 Why do you believe that something has to be dumbed down for 
 your sake instead of stepping up and learning learning 
 something that will prove to be more powerful in the end?

 I don't think D or anything should kowtow to "KISS". Of course 
 the lazy ignorant masses want this but humanity ultimate 
 suffers... and there is enough simple programming languages for 
 simple people. Do we really want another Python, Go, Java, 
 perl, php, asp, JS, lua, Ruby, Rust... Oh, wait, instead of 
 listing hundreds of languages, just look here:

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

 Most of those damn languages are essentially just syntactically 
 different. Python vs Perl vs php? Who cares, it's all the same 
 crap. If all the energy went in to creating a better languages 
 with more power(power != complex) instead of just duplicating 
 the stone wheel then maybe we can get somewhere?

 I really find it odd when someone complains about a "feature" 
 but never uses it. e.g., "I don't like /++/", How often do you 
 use it? "Never, I don't like it!"... then whats the problem, if 
 you don't use it then how is it getting in the way of your 
 progress? "Well, because other people use it and I get confused 
 when I see it in their code!". So, instead of allowing them to 
 program the way they want, you want to control them so you 
 don't have to think as hard?

 Wouldn't you agree: "The best language is the one that gets out 
 of the way and lets you do exactly what you need to do in the 
 most efficient way(which isn't just about time).

Thank you for this excellent demonstration of what a good 
strawman is.

"weaselcat" <weaselcat gmail.com> writes:

On Sunday, 15 March 2015 at 14:15:18 UTC, disme wrote:
 do you people really want to see this language be more popular? 
 do you? doesnt look like it at all to me, the only few people 
 in those 18+ pages that are actually telling you the real 
 problems are mostly being ignored for futile python, go and 
 rust talk, seriously?

 let me go ahead and say that no i dont use D, ive found it 
 awhile ago and came back to look at it from time to time which 
 puts me in a perfect spot to tell you that the fundamental 
 problems for new comers are right here, in those posts:

 page 7 - Leandro Motta Barros' post
 page 10 - Almighty Bob's first post
 page 11 - Almighty Bob's post (again)
 page 14 - rumbu's first post
 page 17 - Xavier Bigand's post
 page XX - many of Chris' posts
 (may have missed a few but those are the ones that jumped out 
 at me where i really went "THIS MAN GETS IT!")

 yes, those are fundamental problems FOR A NEW COMER! 90% of the 
 posts i see in this thread are a bunch of... i dont even know? 
 advanced "problems" that new comers would have no clue what 
 they are about, only those few posts i mentioned are seeing the 
 real problems.

 this community seems to be filled with really intelligent, 
 dedicated people capable of solving some of the hardest 
 challenges but you fail to see the tiny little bitty small 
 things that are stopping the new comers and instead you worry 
 about things that are far beyond their scope people...

 i guess ill find out in a few months when i visit the language 
 again if those posts have been paid attention to, with that 
 said i wonder how many people will reply to this because they 
 havent read until the end (tiny little bitty detail slipping by 
 again?)

most of the posts you linked just said there's documentation 
issues. I don't think anyone disagrees with that.

"bearophile" <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:



+1
I have a ER on  safe by default and Walter seems to agree. But 
I'd like more. A "strict D" mode? :-)




 once






D can't be a single-purpose language. And it has more moving 
parts compared to Go.

Bye,
bearophile

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote:
 D can't be a single-purpose language.

Yeah. The other side of the coin is that, from a D user's 
perspective, Go and Rust are one-trick ponies.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 02:19 +0000, Vladimir Panteleev via Digitalmars-d
wrote:
 On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote:
 D can't be a single-purpose language.

 
 Yeah. The other side of the coin is that, from a D user's 
 perspective, Go and Rust are one-trick ponies.

On the other hand Go is gaining massive traction in the market, and
there is much anticipation regarding Rust.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Wyatt" <wyatt.epp gmail.com> writes:

On Friday, 13 March 2015 at 07:00:12 UTC, Russel Winder wrote:
 On the other hand Go is gaining massive traction in the market

The power of marketing is truly frightening.

-Wyatt

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 13:28 +0000, Wyatt via Digitalmars-d wrote:
 On Friday, 13 March 2015 at 07:00:12 UTC, Russel Winder wrote:
 On the other hand Go is gaining massive traction in the market

 
 The power of marketing is truly frightening.

There is certainly an element of "Google invented and use this, I must
as well" so nil effort marketing has caught many. On the other hand
there are many, cf. CloudFlare, for example, that have created a real
sane use of Go as fundamentally a strongly typed checked simplified C
with a form of CSP.

The removal of shared memory multi-threading in favour of using
processes and channels should never be underestimated as a Really Good
Thing™ that other native code languages (*) have failed to do anything
about. Thus Go wins, others lose.

(*) JVM languages have GPars.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a Really Good
 Thing™ that other native code languages (*) have failed to do anything
 about. Thus Go wins, others lose.

That's a marketing success as well. Go didn't "remove" shared memory 
multi-threading, it just unrecommends it. That's quite unremarkable from 
a programming language design standpoint, but as discussed that's not 
always crucial for success. -- Andrei

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a Really Good
 Thing=E2=84=A2 that other native code languages (*) have failed to do a=


nything
 about. Thus Go wins, others lose.

=20
 That's a marketing success as well. Go didn't "remove" shared memory=20
 multi-threading, it just unrecommends it. That's quite unremarkable from=

=20
 a programming language design standpoint, but as discussed that's not=20
 always crucial for success. -- Andrei

I think you need to show a bit of Go code that uses threads to be able
to back up that claim.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 14 March 2015 at 09:03:11 UTC, Russel Winder wrote:
 On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via 
 Digitalmars-d
 wrote:
 On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
 The removal of shared memory multi-threading in favour of 
 using
 processes and channels should never be underestimated as a 
 Really Good
 Thing™ that other native code languages (*) have failed to 
 do anything
 about. Thus Go wins, others lose.

 
 That's a marketing success as well. Go didn't "remove" shared 
 memory multi-threading, it just unrecommends it. That's quite 
 unremarkable from a programming language design standpoint, 
 but as discussed that's not always crucial for success. -- 
 Andrei

 I think you need to show a bit of Go code that uses threads to 
 be able
 to back up that claim.

No, that is the classical "prove that god do not exist" trick. 
This is up to Go to prove it is safe. Hint: it isn't.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 09:44 +0000, deadalnix via Digitalmars-d wrote:
[=E2=80=A6]
 No, that is the classical "prove that god do not exist" trick.=20
 This is up to Go to prove it is safe. Hint: it isn't.

This could go on ad nauseam. It is up to C, C++, D, Rust, Fortran, Java,
Python, Ruby, etc., etc. to prove they are safe. Hint: they aren't. The
closest there is is Spark Ada, and that has problems.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 14 March 2015 at 11:51:54 UTC, Russel Winder wrote:
 On Sat, 2015-03-14 at 09:44 +0000, deadalnix via Digitalmars-d 
 wrote:
 […]
 No, that is the classical "prove that god do not exist" trick. 
 This is up to Go to prove it is safe. Hint: it isn't.

 This could go on ad nauseam. It is up to C, C++, D, Rust, 
 Fortran, Java,
 Python, Ruby, etc., etc. to prove they are safe. Hint: they 
 aren't. The
 closest there is is Spark Ada, and that has problems.

When it come to concurrency, Rust is. None of the other are.

Now you can double down on trying to make me prove a negative, 
but that only makes you sound like a religious zealot.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 22:12 +0000, deadalnix via Digitalmars-d wrote:
[=E2=80=A6]
=20
 When it come to concurrency, Rust is. None of the other are.

That would imply Rust has the possibility of replacing Spark Ada then?

 Now you can double down on trying to make me prove a negative,=20
 but that only makes you sound like a religious zealot.

I am an atheist, religiously so.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/14/15 2:02 AM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-d
 wrote:
 On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a Really Good
 Thing™ that other native code languages (*) have failed to do anything
 about. Thus Go wins, others lose.

 That's a marketing success as well. Go didn't "remove" shared memory
 multi-threading, it just unrecommends it. That's quite unremarkable from
 a programming language design standpoint, but as discussed that's not
 always crucial for success. -- Andrei

 I think you need to show a bit of Go code that uses threads to be able
 to back up that claim.

package main

type Data struct {
     i int
}

func func1(c chan *Data ) {
     var t *Data;
     t = <-c
     println(t)
}

func func2(c chan *Data ) {
     var t *Data;
     t = <-c
     println(t)
}

func main() {
     c := make(chan *Data)
     t := Data{10}
     go func1(c)
     c <- &t
     go func2(c)
     c <- &t
     println(&t)
}

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 10:11 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/14/15 2:02 AM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 07:55 -0700, Andrei Alexandrescu via Digitalmars-=


d
 wrote:
 On 3/13/15 6:45 AM, Russel Winder via Digitalmars-d wrote:
 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a Really Goo=




d
 Thing=E2=84=A2 that other native code languages (*) have failed to do=




 anything
 about. Thus Go wins, others lose.

 That's a marketing success as well. Go didn't "remove" shared memory
 multi-threading, it just unrecommends it. That's quite unremarkable fr=



om
 a programming language design standpoint, but as discussed that's not
 always crucial for success. -- Andrei

 I think you need to show a bit of Go code that uses threads to be able
 to back up that claim.

=20
 package main
=20
 type Data struct {
      i int
 }
=20
 func func1(c chan *Data ) {
      var t *Data;
      t =3D <-c
      println(t)
 }
=20
 func func2(c chan *Data ) {
      var t *Data;
      t =3D <-c
      println(t)
 }
=20
 func main() {
      c :=3D make(chan *Data)
      t :=3D Data{10}
      go func1(c)
      c <- &t
      go func2(c)
      c <- &t
      println(&t)
 }
=20

I see no threads in this code! :-)

But yes, it certainly shows you can create shared-memory
"multi-threading" this way, but anyone actually doing it would be being
very silly. Sending addresses down multiple channels is obvious here and
definitely not the right thing to do unless the datum contains an
embedded lock which is then used. cf.
https://talks.golang.org/2012/10things.slide#3

It would be better if channels could only accept value types, and not
reference types.

Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to
mention JCSP and GPars.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/14/15 11:24 AM, Russel Winder via Digitalmars-d wrote:
 But yes, it certainly shows you can create shared-memory
 "multi-threading" this way,

So your affirmation has been refuted.

 but anyone actually doing it would be being
 very silly.

That's "design by prayer". Aren't most bugs created by people doing very 
silly things?

 Sending addresses down multiple channels

One is enough.

 is obvious here and
 definitely not the right thing to do unless the datum contains an
 embedded lock which is then used. cf.
 https://talks.golang.org/2012/10things.slide#3

Yes, of course it's not the right thing to do. Your point being...?

 It would be better if channels could only accept value types, and not
 reference types.

Probably not as that would further hamstrung the language.


Andrei

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 12:54 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/14/15 11:24 AM, Russel Winder via Digitalmars-d wrote:
 But yes, it certainly shows you can create shared-memory
 "multi-threading" this way,

=20
 So your affirmation has been refuted.

It appears so, I grovel at the feet of logic and proof.

The core issue here is the ability to ship memory addresses around
instead of having to ship values. I still believe dataflow to be the
superior architecture for concurrent and parallel systems. Actian
Datarush and GPars are on the JVM and avoid Unsafe, and whilst you can
set up sharing of mutable data structures, it is a lot harder than as in
Go. Likewise with Python-CSP and PyCSP sending values that are not
references to shared mutable state is the norm. It is quite hard to do
otherwise with Python as a consequence of the GIL and the necessity to
use multiprocessing (i.e. each process is a separate PVM and hence
separate OS process, and hence different address space).

 but anyone actually doing it would be being
 very silly.

=20
 That's "design by prayer". Aren't most bugs created by people doing very=

=20
 silly things?

And prayer achieves nothing.

I think you can probably remove the "very" there and it still be right.

 Sending addresses down multiple channels

=20
 One is enough.

Actually no, you need two. I believe you are thinking that the sender
retains the reference and sends the reference so one send is enough.
True per se. But what Rust is trying to enforce, which C++ (and D?) do
not, is ownership of the reference, so that you can send a reference the
originator cannot then use.  Clearly std::unique_ptr is trying to
provide this for C++ but it isn't enforced as has to be to avoid the
situation you coded up in Go.
=20
 is obvious here and
 definitely not the right thing to do unless the datum contains an
 embedded lock which is then used. cf.
 https://talks.golang.org/2012/10things.slide#3

=20
 Yes, of course it's not the right thing to do. Your point being...?

A language has to enforce not manipulating shared mutable memory or the
programs will likely be broken. Functional programming's obsession with
copying rather than sharing, helps with this.

 It would be better if channels could only accept value types, and not
 reference types.

=20
 Probably not as that would further hamstrung the language.

I am not sure that is true. I find it somewhat strange that Go allows
sharing of references to mutable state in this way, it certainly doesn't
fit with the way I was brought up to use dataflow.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 14 March 2015 at 18:24:51 UTC, Russel Winder wrote:
 I see no threads in this code! :-)

 But yes, it certainly shows you can create shared-memory
 "multi-threading" this way, but anyone actually doing it would 
 be being
 very silly. Sending addresses down multiple channels is obvious 
 here and
 definitely not the right thing to do unless the datum contains 
 an
 embedded lock which is then used. cf.
 https://talks.golang.org/2012/10things.slide#3

So now we are going from Go is safe, to well, it is obviously not 
safe (then, why were you so eager to have a proof ?) but nobody 
in their right mind would do something like this.

But this is only a short snippet. This can happen the same way in 
a million line codebase, and good luck finding it.

Also, the "no good programmer would do this" is an immediate red 
flag. Not only programmer will do this, but the one that claim 
they won't will do it even sooner as they evidently lack self 
awareness.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 22:18 +0000, deadalnix via Digitalmars-d wrote:
[=E2=80=A6]
 So now we are going from Go is safe, to well, it is obviously not=20
 safe (then, why were you so eager to have a proof ?) but nobody=20
 in their right mind would do something like this.

It is usually Andrei that catches me out overstating the case in
general=E2=80=A6

My model of dataflow is of processes (separate address spaces) passing
messages which are values not address. This is the way I use GPars,
Python-CSP and Go. As Andrei proved with an existence proof, Go makes it
easy to break this model by sending address around because goroutines
are not processes: goroutines are tasks on a thread pool in a single
address space.
=20
 But this is only a short snippet. This can happen the same way in=20
 a million line codebase, and good luck finding it.
=20
 Also, the "no good programmer would do this" is an immediate red=20
 flag. Not only programmer will do this, but the one that claim=20
 they won't will do it even sooner as they evidently lack self=20
 awareness.

Indeed. Which is why goroutines really should be enforced processes,
i.e. no access to state outside the goroutine code should be allowed. As
far as I am aware Erlang is the premier example of doing this right. We
try hard with GPars, but there are still ways of circumventing.
Python-CSP has the "problem" that every process is a separate PVM so
they really are processes, no mutable state sharing is possible unless
you actively construct it. You can, but it is quite hard to do by
accident.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Bienlein" <jeti789 web.de> writes:

 Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, 
 not to
 mention JCSP and GPars.

I'm not really sure whether this can be put exactly that way. On 
a machine with 4 GB RAM you can spawn about 80.000 goroutines 
(aka green threads). Let's say each threads calculates a large 
fibonacci number. If the fibonacci calculation yields the 
processor frequently all 80.000 run seamingly in parallel and 
return their result almost "at the same time".

With GPars this would not work. You can only start some 2.000 
Java threads on a machine with the same amount of memory. If also 
the fibonacci calculation in Groovy/GPars yields the processor, 
using GPars the first 2.000 fibonacci calculations will 
nevertheless crowd out the following 2.000 threads of all those 
80.000 fibonacci calculations and so on. I once tried this out 
with both Go and Groovy/GPars.

-- Bienlein

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/17/15 1:50 PM, Bienlein wrote:
 Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to
 mention JCSP and GPars.

 I'm not really sure whether this can be put exactly that way. On a
 machine with 4 GB RAM you can spawn about 80.000 goroutines (aka green
 threads). Let's say each threads calculates a large fibonacci number. If
 the fibonacci calculation yields the processor frequently all 80.000 run
 seamingly in parallel and return their result almost "at the same time".

How many physical threads would the 80K goroutines create? -- Andrei

"deadalnix" <deadalnix gmail.com> writes:

On Tuesday, 17 March 2015 at 22:30:37 UTC, Andrei Alexandrescu 
wrote:
 On 3/17/15 1:50 PM, Bienlein wrote:
 Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, 
 not to
 mention JCSP and GPars.

 I'm not really sure whether this can be put exactly that way. 
 On a
 machine with 4 GB RAM you can spawn about 80.000 goroutines 
 (aka green
 threads). Let's say each threads calculates a large fibonacci 
 number. If
 the fibonacci calculation yields the processor frequently all 
 80.000 run
 seamingly in parallel and return their result almost "at the 
 same time".

 How many physical threads would the 80K goroutines create? -- 
 Andrei

The Go runtime manages this. About as many as there are CPU.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Tue, 2015-03-17 at 22:49 +0000, deadalnix via Digitalmars-d wrote:
 On Tuesday, 17 March 2015 at 22:30:37 UTC, Andrei Alexandrescu=20
 wrote:
 On 3/17/15 1:50 PM, Bienlein wrote:
 Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP,=20
 not to
 mention JCSP and GPars.

 I'm not really sure whether this can be put exactly that way.=20
 On a
 machine with 4 GB RAM you can spawn about 80.000 goroutines=20
 (aka green
 threads). Let's say each threads calculates a large fibonacci=20
 number. If
 the fibonacci calculation yields the processor frequently all=20
 80.000 run
 seamingly in parallel and return their result almost "at the=20
 same time".

 How many physical threads would the 80K goroutines create? --=20
 Andrei

=20
 The Go runtime manages this. About as many as there are CPU.

The Go runtime manages the threadpool and scheduling of kernel threads,
but the number of them remains a number specified manually unless you
want the default of 1.

Benchmarking generally reveals that optimal number of kernel threads in
a pool is number of CPUs =C2=B11, it depends on the work and things like
cacheline misses, hyperthreads, etc., etc.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Tue, 2015-03-17 at 15:30 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/17/15 1:50 PM, Bienlein wrote:
 Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to
 mention JCSP and GPars.

 I'm not really sure whether this can be put exactly that way. On a
 machine with 4 GB RAM you can spawn about 80.000 goroutines (aka green
 threads). Let's say each threads calculates a large fibonacci number. I=


f
 the fibonacci calculation yields the processor frequently all 80.000 ru=


n
 seamingly in parallel and return their result almost "at the same time"=


.
=20
 How many physical threads would the 80K goroutines create? -- Andrei
=20

It doesn't, you specify the number of kernel threads in the thread pool
manually. The default is 1.
=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Paulo Pinto" <pjmlp progtools.org> writes:

On Tuesday, 17 March 2015 at 20:50:51 UTC, Bienlein wrote:
 Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, 
 not to
 mention JCSP and GPars.

 I'm not really sure whether this can be put exactly that way. 
 On a machine with 4 GB RAM you can spawn about 80.000 
 goroutines (aka green threads). Let's say each threads 
 calculates a large fibonacci number. If the fibonacci 
 calculation yields the processor frequently all 80.000 run 
 seamingly in parallel and return their result almost "at the 
 same time".

 With GPars this would not work. You can only start some 2.000 
 Java threads on a machine with the same amount of memory. If 
 also the fibonacci calculation in Groovy/GPars yields the 
 processor, using GPars the first 2.000 fibonacci calculations 
 will nevertheless crowd out the following 2.000 threads of all 
 those 80.000 fibonacci calculations and so on. I once tried 
 this out with both Go and Groovy/GPars.

 -- Bienlein

What about using a JVM with green threads support or Quasar, 
wouldn't it be more comparable?

--
Paulo

"Bienlein" <jeti789 web.de> writes:

 What about using a JVM with green threads support or Quasar, 
 wouldn't it be more comparable?

 --
 Paulo

Long text, contents of common interest in the last section :-)

Thanks for the hints, Paulo. Quasar looks interesting. The 
current number one actor implementation for the JVM is Akka 
(akka.io). It was earlier built on Hawtdispatch 
(https://github.com/fusesource/hawtdispatch), which is similar to 
Quasar but much simpler. Now they have plugged in their own 
scheduler. Those libraries follow the same approach that a small 
number of threads (small to make the overhead of context switches 
small) serve a large number of consumers (e.g., channels, actors, 
or whatever consumer abstraction). This works well as long as all 
tasks are short-runners. It becomes a problem once you have many 
long-runners. Me talking about large fibonacci numbers in my 
previous post was to indicate that it is all about the problem 
with long-runners. In Vert.x they have a separate scheduler for 
long-runners that can serve a certain number of tasks and rejects 
tasks once the max is exceeded. I will check out have they have 
implemented channel select in Quasar. In Go they can do this 
efficiently, because it is done by the built-in scheduler and not 
in the library.

As what D is concerned it has vibe.d, which follows on principle 
the same approach as described above from what I understand about 
it. There is an old discussion about integrating vibe.d in the D 
distribution. This way multi-threading in D comes with batteries 
included as in Go. I still think this is a good idea :-).

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Wed, 2015-03-18 at 08:58 +0000, Bienlein via Digitalmars-d wrote:
[=E2=80=A6]
 Thanks for the hints, Paulo. Quasar looks interesting. The=20
 current number one actor implementation for the JVM is Akka=20
 (akka.io). It was earlier built on Hawtdispatch=20

Possibly, but there are others that get a lot of use, GPars for
example :-)

[=E2=80=A6]

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Ziad Hatahet via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Wed, Mar 18, 2015 at 1:09 AM, Paulo Pinto via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Tuesday, 17 March 2015 at 20:50:51 UTC, Bienlein wrote:

  Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to
 mention JCSP and GPars.

 I'm not really sure whether this can be put exactly that way. On a
 machine with 4 GB RAM you can spawn about 80.000 goroutines...

 What about using a JVM with green threads support or Quasar, wouldn't it
 be more comparable?

 --
 Paulo

It seems it is the same issue. From the Quasar user manual (
http://docs.paralleluniverse.co/quasar/):

Fibers are not meant to replace threads in all circumstances. A fiber
should be used when its body (the code it executes) blocks very often
waiting on other fibers (e.g. waiting for messages sent by other fibers on
a channel, or waiting for the value of a dataflow-variable). For
long-running computations that rarely block, traditional threads are
preferable. Fortunately, as we shall see, fibers and threads interoperate
very well.

--
Ziad

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Tue, 2015-03-17 at 20:50 +0000, Bienlein via Digitalmars-d wrote:
 Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP,=20
 not to
 mention JCSP and GPars.

=20
 I'm not really sure whether this can be put exactly that way. On=20
 a machine with 4 GB RAM you can spawn about 80.000 goroutines=20
 (aka green threads). Let's say each threads calculates a large=20
 fibonacci number. If the fibonacci calculation yields the=20
 processor frequently all 80.000 run seamingly in parallel and=20
 return their result almost "at the same time".
=20
 With GPars this would not work. You can only start some 2.000=20
 Java threads on a machine with the same amount of memory. If also=20
 the fibonacci calculation in Groovy/GPars yields the processor,=20
 using GPars the first 2.000 fibonacci calculations will=20
 nevertheless crowd out the following 2.000 threads of all those=20
 80.000 fibonacci calculations and so on. I once tried this out=20
 with both Go and Groovy/GPars.

<This needs to go to the GPars mailing lists list so I have cross
posted.>

A priori I do not believe the claim made here: a GPars task is submitted
to a thread pool, which is exactly what the goroutines are. Thus the
number of Java threads is not a bound on the number of GPars tasks. Any
bounds will be provided by the Fork/Join pool.

If you have code you can send me, I will run it and do the benchmarking.
If not I guess I will have to write some. Until we have the results of
executing code, the above must be treated as pure conjecture, which I
believe will be refuted. If the claim however turns out to be true, then
it highlights a bug in GPars.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Bienlein" <jeti789 web.de> writes:

 A priori I do not believe the claim made here: a GPars task is 
 submitted
 to a thread pool, which is exactly what the goroutines are. 
 Thus the
 number of Java threads is not a bound on the number of GPars 
 tasks. Any
 bounds will be provided by the Fork/Join pool.

Here is a GPars sample from 
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html

final class Copy implements Callable {
     private final DataflowChannel inChannel
     private final DataflowChannel outChannel1
     private final DataflowChannel outChannel2

public def call() {
	final PGroup group = Dataflow.retrieveCurrentDFPGroup()
	while (true) {
		def i = inChannel.val
		group.task {
			outChannel1 << i
			outChannel2 << i
		}.join()
	}
}

If inChannel.val blocks, the thread serving the Copy instance is 
blocked and lost for serving other channels. If this happens 
several times the JVM has run out of threads and the application 
is in limbo.

This is not the case in Go. When a goroutine is blocked by a 
blocking take on an empty channel, the Go scheduler withdraws the 
thread serving this goroutine and assigns it to some other 
goroutine.

Ziad Hatahet via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, Mar 13, 2015 at 6:45 AM, Russel Winder via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a Really Good
 Thing=E2=84=A2 that other native code languages (*) have failed to do any=

thing
 about. Thus Go wins, others lose.

Except that Go does not really remove shared memory multithreading; it is
still possible to get data races (which is why they have a race detector).
They provide channels, but nothing is preventing races other than
convention. On the other hand, Rust (a native code language) offers a much
superior solution, with compile-time enforcement of data sharing.

--
Ziad

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 14 March 2015 at 00:34:35 UTC, Ziad Hatahet wrote:
 On Fri, Mar 13, 2015 at 6:45 AM, Russel Winder via 
 Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a 
 Really Good
 Thing™ that other native code languages (*) have failed to do 
 anything
 about. Thus Go wins, others lose.

 Except that Go does not really remove shared memory 
 multithreading; it is
 still possible to get data races (which is why they have a race 
 detector).
 They provide channels, but nothing is preventing races other 
 than
 convention. On the other hand, Rust (a native code language) 
 offers a much
 superior solution, with compile-time enforcement of data 
 sharing.

 --
 Ziad

How very true, but, by the time you run into data races, you are 
pretty much commited to go.

Sad.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 5:54 PM, deadalnix wrote:
 On Saturday, 14 March 2015 at 00:34:35 UTC, Ziad Hatahet wrote:
 On Fri, Mar 13, 2015 at 6:45 AM, Russel Winder via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a Really Good
 Thing™ that other native code languages (*) have failed to do anything
 about. Thus Go wins, others lose.

 Except that Go does not really remove shared memory multithreading; it is
 still possible to get data races (which is why they have a race
 detector).
 They provide channels, but nothing is preventing races other than
 convention. On the other hand, Rust (a native code language) offers a
 much
 superior solution, with compile-time enforcement of data sharing.

 --
 Ziad

 How very true, but, by the time you run into data races, you are pretty
 much commited to go.

 Sad.

I'm surprised Russel fell for it. -- Andrei

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 14 March 2015 at 03:12:39 UTC, Andrei Alexandrescu 
wrote:
 On 3/13/15 5:54 PM, deadalnix wrote:
 On Saturday, 14 March 2015 at 00:34:35 UTC, Ziad Hatahet wrote:
 On Fri, Mar 13, 2015 at 6:45 AM, Russel Winder via 
 Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 The removal of shared memory multi-threading in favour of 
 using
 processes and channels should never be underestimated as a 
 Really Good
 Thing™ that other native code languages (*) have failed to 
 do anything
 about. Thus Go wins, others lose.

 Except that Go does not really remove shared memory 
 multithreading; it is
 still possible to get data races (which is why they have a 
 race
 detector).
 They provide channels, but nothing is preventing races other 
 than
 convention. On the other hand, Rust (a native code language) 
 offers a
 much
 superior solution, with compile-time enforcement of data 
 sharing.

 --
 Ziad

 How very true, but, by the time you run into data races, you 
 are pretty
 much commited to go.

 Sad.

 I'm surprised Russel fell for it. -- Andrei

Don't be surprised, because, by the time you run into data races, 
you are pretty much committed to go.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 20:12 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/13/15 5:54 PM, deadalnix wrote:
 On Saturday, 14 March 2015 at 00:34:35 UTC, Ziad Hatahet wrote:
 On Fri, Mar 13, 2015 at 6:45 AM, Russel Winder via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 The removal of shared memory multi-threading in favour of using
 processes and channels should never be underestimated as a Really Goo=




d
 Thing=E2=84=A2 that other native code languages (*) have failed to do=




 anything
 about. Thus Go wins, others lose.

 Except that Go does not really remove shared memory multithreading; it=



 is
 still possible to get data races (which is why they have a race
 detector).
 They provide channels, but nothing is preventing races other than
 convention. On the other hand, Rust (a native code language) offers a
 much
 superior solution, with compile-time enforcement of data sharing.



Rust may indeed be superior to Go on this. It will be interesting to see
if Rust, once formally released to world, makes an impression on the
rise of Go. I certainly hope so, since writing Rust code is nicer than
writing Go code.

I suspect not. Go marketed itself as a "better C" (as C++ did
originally), and got some Python folk and a lot of PHP folk to switch:
Go's main traction is in the Internet, networking, Web applications
arena despite claiming to be a systems programming language. Rust is
pitching against C++ as D does. C++ folk appear to be locked-in in a way
that means Rust and D need to rethink the pitch.

 How very true, but, by the time you run into data races, you are pretty
 much commited to go.

 Sad.


Why? In any CSP-like system, it is possible to get deadlock, livelock
and races. However "debugging" them is nigh on trivial compared to the
effort required with shared-memory multi threading.

PyCSP and Python-CSP as well as Go show this.

 I'm surprised Russel fell for it. -- Andrei

Fell for what?=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Saturday, 14 March 2015 at 09:12:31 UTC, Russel Winder wrote:
 Why? In any CSP-like system, it is possible to get deadlock, 
 livelock
 and races. However "debugging" them is nigh on trivial compared 
 to the
 effort required with shared-memory multi threading.

 PyCSP and Python-CSP as well as Go show this.

I am not sure if CSP alone is the main reason for why people use 
Go for micro services. I guess it is the combined focus on high 
concurrency, simplicity and stability that makes it suitable for 
the kind of things you would use a new language for: smaller 
projects with specific demands.

 I'm surprised Russel fell for it. -- Andrei

 Fell for what?

Andrei doesn't grok that Go has an overall better infrastructure 
for writing high concurrency applications that are bottle necked 
by network traffic.

D lacks:
1. stack protection for fibers
2. non-hogging GC
3. a simple language that makes it easy to read external library 
code
4. channels

And that' only to get started competing, add infrastructure 
adoption and eco system and the competition is already lost.

D+vibe.d is a nice offering, but not a winning horse if comes 
down to a race. Competing on Go's terms will not lead anywhere.

D would be better off going for a "free" niche, like game 
servers, non-C++ game programming etc.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/14/2015 2:12 AM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 20:12 -0700, Andrei Alexandrescu via Digitalmars-d
 wrote:
 I'm surprised Russel fell for it. -- Andrei

 Fell for what?

The mark of a successful long con! :-)

"Freddy" <Hexagonalstar64 gmail.com> writes:

On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote:
 A "strict D" mode?

That sounds like an amazing idea.

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote:
 Andrei Alexandrescu:



 +1
 I have a ER on  safe by default and Walter seems to agree. But 
 I'd like more. A "strict D" mode? :-)

Yes, but what is a "strict mode". I agree with most of what is 
said about D and Go in the top post, but is there a market for 
yet another high level language that isn't high level enough?

I've spent some time hashing out a "D-minus" that could be 
compiled with D2 (or at least with a simple transform), and it is 
more attractive to move towards lower level programming and 
optimization when creating a subset...

So what is a a reduced D that is largely compatible with D2? I 
would remove features that people love, like modular arithmetics. 
You can do that since it is undefined when you move out of the 
range. You can also introduce new hints as  uda.

The overall better approach is to generalize and simplify the 
core semantics of the language then have D2/D3/simpleD in the 
same compiler and allow them to mostly work together (separate 
files, but D2 code importable into D3)

 D can't be a single-purpose language. And it has more moving 
 parts compared to Go.

That's true, what one could consider is better separation between 
library-features and common-code features. Like Python where you 
generally can leave all the __XXX__, yield etc to library code 
and keep a simple surface (largely thanks to tuples/lists btw).

"bearophile" <bearophileHUGS lycos.com> writes:

Ola Fosheim Grøstad:

 Yes, but what is a "strict mode". I agree with most of what is 
 said about D and Go in the top post, but is there a market for 
 yet another high level language that isn't high level enough?

"Strict mode" is a D2 with immutable+ safe+pure by default, 
something like a "var" keyword to denote mutable values, no comma 
operator, static full tracking of memory ownership, less implicit 
casts (because now we have the safe int(x) sytnax), and few other 
small changes that make the language less bug prone and more 
strict.

And I'd still like built-in tuple syntax in D.

Bye,
bearophile

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 10:34:32 UTC, bearophile wrote:
 Ola Fosheim Grøstad:

 Yes, but what is a "strict mode". I agree with most of what is 
 said about D and Go in the top post, but is there a market for 
 yet another high level language that isn't high level enough?

 "Strict mode" is a D2 with immutable+ safe+pure by default, 
 something like a "var" keyword to denote mutable values, no 
 comma operator, static full tracking of memory ownership, less 
 implicit casts (because now we have the safe int(x) sytnax), 
 and few other small changes that make the language less bug 
 prone and more strict.

 And I'd still like built-in tuple syntax in D.

 Bye,
 bearophile

That actually sounds quite nice, but I wonder if this is just 
hopeful wishing or something D would actively move towards.

"Zoadian" <no no.no> writes:

On Friday, 13 March 2015 at 10:34:32 UTC, bearophile wrote:
 Ola Fosheim Grøstad:

 Yes, but what is a "strict mode". I agree with most of what is 
 said about D and Go in the top post, but is there a market for 
 yet another high level language that isn't high level enough?

 "Strict mode" is a D2 with immutable+ safe+pure by default, 
 something like a "var" keyword to denote mutable values, no 
 comma operator, static full tracking of memory ownership, less 
 implicit casts (because now we have the safe int(x) sytnax), 
 and few other small changes that make the language less bug 
 prone and more strict.

 And I'd still like built-in tuple syntax in D.

 Bye,
 bearophile

+1

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 3:34 AM, bearophile wrote:
 Ola Fosheim Grøstad:

 Yes, but what is a "strict mode". I agree with most of what is said
 about D and Go in the top post, but is there a market for yet another
 high level language that isn't high level enough?

 "Strict mode" is a D2 with immutable+ safe+pure by default, something
 like a "var" keyword to denote mutable values, no comma operator, static
 full tracking of memory ownership, less implicit casts (because now we
 have the safe int(x) sytnax), and few other small changes that make the
 language less bug prone and more strict.

 And I'd still like built-in tuple syntax in D.

That's a rather random collection - "strict" seems to be "D without the 
stuff bearophile dislikes". -- Andrei

"bearophile" <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

 That's a rather random collection - "strict" seems to be "D 
 without the stuff bearophile dislikes". -- Andrei

I am OK with that definition. Is that your best critique to those 
suggestions? :-)

Bye,
bearophile

"Rory" <rjmcguire gmail.com> writes:

On Friday, 13 March 2015 at 15:03:37 UTC, bearophile wrote:
 Andrei Alexandrescu:

 That's a rather random collection - "strict" seems to be "D 
 without the stuff bearophile dislikes". -- Andrei

 I am OK with that definition. Is that your best critique to 
 those suggestions? :-)

 Bye,
 bearophile

:) I'd use that.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

Note that you can get this largely by starting a module with the following:

    immutable  safe pure:

 something like a "var" keyword to denote mutable values,

Transitive const may make this problematic.

 no comma operator,

Some good arguments for this.

 static full tracking of memory ownership,

Makes the language significantly more complex.

 less implicit casts (because now we have the safe int(x) sytnax),

I think D does very well with implicit casts.

 and few other small changes that make the language less bug prone and
 more strict.

 And I'd still like built-in tuple syntax in D.

[... Just one more feature ...] is the road to hell.

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with 
 the following:

    immutable  safe pure:

As far as I'm aware, there's no way to mark functions impure this 
way other than lexical location. Am I incorrect?

"Namespace" <rswhite4 gmail.com> writes:

On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with 
 the following:

   immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure 
 this way other than lexical location. Am I incorrect?

There is no way to mark functions impure, mutable or virtual. ;)

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
 On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with 
 the following:

  immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure 
 this way other than lexical location. Am I incorrect?

 There is no way to mark functions impure, mutable or virtual. ;)

Is there a reason for this?
I currently put  safe: at the top of all of my D files, and use 
 trusted/ system as needed(i.e, barely ever except for IO.) I'm 
not sure if it's good practice but I prefer it.

"Namespace" <rswhite4 gmail.com> writes:

On Friday, 13 March 2015 at 19:11:59 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
 On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with 
 the following:

 immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure 
 this way other than lexical location. Am I incorrect?

 There is no way to mark functions impure, mutable or virtual. 
 ;)

 Is there a reason for this?
 I currently put  safe: at the top of all of my D files, and use 
  trusted/ system as needed(i.e, barely ever except for IO.) I'm 
 not sure if it's good practice but I prefer it.

As always: there was many discussions and nothing was 
decided/done.
The nearest thing we had (and I'm so proud that the suggestion 
comes from me :P) was: final(false), pure(false) etc.

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 19:18:11 UTC, Namespace wrote:
 On Friday, 13 March 2015 at 19:11:59 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
 On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright 
 wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module 
 with the following:

 immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure 
 this way other than lexical location. Am I incorrect?

 There is no way to mark functions impure, mutable or virtual. 
 ;)

 Is there a reason for this?
 I currently put  safe: at the top of all of my D files, and 
 use  trusted/ system as needed(i.e, barely ever except for 
 IO.) I'm not sure if it's good practice but I prefer it.

 As always: there was many discussions and nothing was 
 decided/done.
 The nearest thing we had (and I'm so proud that the suggestion 
 comes from me :P) was: final(false), pure(false) etc.

This is really something that should be brought up again, it 
seems like a small change with a big payoff.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 1:24 PM, weaselcat wrote:
 On Friday, 13 March 2015 at 19:18:11 UTC, Namespace wrote:
 On Friday, 13 March 2015 at 19:11:59 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 19:03:29 UTC, Namespace wrote:
 On Friday, 13 March 2015 at 19:01:08 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with the
 following:

 immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure this
 way other than lexical location. Am I incorrect?

 There is no way to mark functions impure, mutable or virtual. ;)

 Is there a reason for this?
 I currently put  safe: at the top of all of my D files, and use
  trusted/ system as needed(i.e, barely ever except for IO.) I'm not
 sure if it's good practice but I prefer it.

 As always: there was many discussions and nothing was decided/done.
 The nearest thing we had (and I'm so proud that the suggestion comes
 from me :P) was: final(false), pure(false) etc.

 This is really something that should be brought up again, it seems like
 a small change with a big payoff.

Yah, we sorely need a way to undo an attribute. BTW " undo" is short and 
sweet. -- Andrei

"Namespace" <rswhite4 gmail.com> writes:

 Yah, we sorely need a way to undo an attribute. BTW " undo" is 
 short and sweet. -- Andrei

I thought reusing keywords is what you like:


----
pure:
nothrow:

// ... some stuff

default: // not pure/nothrow
----


----
class Foo {
final:
     // ...
default: // virtual
     // ...
}
----

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 12:01 PM, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with the following:

    immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure this way other
than
 lexical location. Am I incorrect?

You are correct, which is why D also supports:

    immutable  safe pure {
       ... nice declarations ...
    }

    ... naughty declarations ...

"Namespace" <rswhite4 gmail.com> writes:

On Friday, 13 March 2015 at 22:14:45 UTC, Walter Bright wrote:
 On 3/13/2015 12:01 PM, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with 
 the following:

   immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure 
 this way other than
 lexical location. Am I incorrect?

 You are correct, which is why D also supports:

    immutable  safe pure {
       ... nice declarations ...
    }

    ... naughty declarations ...

But most prefer labels. Did you dislike things like 'pure(false)' 
or' default:'? Just out of interest, since it is a bit offtopic.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 3:14 PM, Walter Bright wrote:
 On 3/13/2015 12:01 PM, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with the
 following:

    immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure this way
 other than
 lexical location. Am I incorrect?

 You are correct, which is why D also supports:

     immutable  safe pure {
        ... nice declarations ...
     }

     ... naughty declarations ...

The bottom line is we need a way to undo attributes. -- Andrei

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

On Fri, Mar 13, 2015 at 04:14:30PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/13/15 3:14 PM, Walter Bright wrote:
On 3/13/2015 12:01 PM, weaselcat wrote:
On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
On 3/13/2015 3:34 AM, bearophile wrote:
"Strict mode" is a D2 with immutable+ safe+pure by default,

Note that you can get this largely by starting a module with the
following:

   immutable  safe pure:

As far as I'm aware, there's no way to mark functions impure this
way other than lexical location. Am I incorrect?

You are correct, which is why D also supports:

    immutable  safe pure {
       ... nice declarations ...
    }

    ... naughty declarations ...

 
 The bottom line is we need a way to undo attributes. -- Andrei

Which people have been clamoring for, for a long time now.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it.
-- Donald Knuth

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 6:32 PM, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Mar 13, 2015 at 04:14:30PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 3/13/15 3:14 PM, Walter Bright wrote:
 On 3/13/2015 12:01 PM, weaselcat wrote:
 On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with the
 following:

    immutable  safe pure:

 As far as I'm aware, there's no way to mark functions impure this
 way other than lexical location. Am I incorrect?

 You are correct, which is why D also supports:

     immutable  safe pure {
        ... nice declarations ...
     }

     ... naughty declarations ...

 The bottom line is we need a way to undo attributes. -- Andrei

 Which people have been clamoring for, for a long time now.

That's why we need it! :o) -- Andrei

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

On Fri, Mar 13, 2015 at 08:12:15PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/13/15 6:32 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Mar 13, 2015 at 04:14:30PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 3/13/15 3:14 PM, Walter Bright wrote:
On 3/13/2015 12:01 PM, weaselcat wrote:
On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
On 3/13/2015 3:34 AM, bearophile wrote:
"Strict mode" is a D2 with immutable+ safe+pure by default,

Note that you can get this largely by starting a module with the
following:

   immutable  safe pure:

As far as I'm aware, there's no way to mark functions impure this
way other than lexical location. Am I incorrect?

You are correct, which is why D also supports:

    immutable  safe pure {
       ... nice declarations ...
    }

    ... naughty declarations ...

The bottom line is we need a way to undo attributes. -- Andrei

Which people have been clamoring for, for a long time now.

 
 That's why we need it! :o) -- Andrei

Yes, and it's about time it finally got acknowledged! :-P


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully
expressed at length against my verbal capabilities, I am afraid that I must
unfortunately bring it to your attention that I am, in fact, NOT verbose.

"Alaksiej =?UTF-8?B?U3RhbmtpZXZpxI0i?= <harald_zealot tut.by> writes:

 You are correct, which is why D also supports:

    immutable  safe pure {
       ... nice declarations ...
    }

    ... naughty declarations ...

 The bottom line is we need a way to undo attributes. -- Andrei

+100

Good language has to attract write good things simple and dirty
things in more complex way. The current state of atribution is
contrary :(

"Dude" <dude onwheet.net> writes:

On Friday, 13 March 2015 at 18:55:18 UTC, Walter Bright wrote:
 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,

 Note that you can get this largely by starting a module with 
 the following:

    immutable  safe pure:

no you can't until there will be something like disable(pure) or 
default immutable  safe

 something like a "var" keyword to denote mutable values,

 Transitive const may make this problematic.

Yes, I agree


 static full tracking of memory ownership,

 Makes the language significantly more complex.

Yes, but maybe it's worth it

 less implicit casts (because now we have the safe int(x) 
 sytnax),

 I think D does very well with implicit casts.

Me too

 And I'd still like built-in tuple syntax in D.

 [... Just one more feature ...] is the road to hell.

No if it would be my own just one more feature :P

"bearophile" <bearophileHUGS lycos.com> writes:

Walter Bright:

 On 3/13/2015 3:34 AM, bearophile wrote:
 "Strict mode" is a D2 with immutable+ safe+pure by default,


Thank you Walter for giving me an actual answer :-)


 Note that you can get this largely by starting a module with 
 the following:

    immutable  safe pure:

"immutable" in my post was mostly referring to local variables, 
foreach variables and so on.


 something like a "var" keyword to denote mutable values,

 Transitive const may make this problematic.

I don't understand, but perhaps you misunderstood me. I am 
talking about variables. In strict mode they are constant by 
default. This means in this code both x and y are immutable:

auto x = 10;
foreach (y; 0 .. 10) {}

So in strict mode if you want them mutable you need a new keyword 
like "var":

var x = 10;
foreach (var y; 0 .. 10) {}



 static full tracking of memory ownership,

 Makes the language significantly more complex.

You are probably right. But it also gives good things back to a 
system language.
In the last years I've seen that taking twice the time to write 
my code is a good deal if later I can avoid wasting stressful 
hours searching and fixing bugs. So now I am willing to pay a 
high price up front when I code to avoid some bugs later. I have 
friends that have taken a look at Rust and have dismissed it for 
being too much fussy and hard to get code to compile (despite 
probably with practice the Rust rules should become quite simpler 
to follow), but Rust looks like the right language for me and I'd 
like the same qualities in the language that I like more (D). So 
in the end I don't know what's the best solution for D.


 less implicit casts (because now we have the safe int(x) 
 sytnax),

 I think D does very well with implicit casts.

I am not sure of that. Implicit casts cause some troubles, you 
can see this if you program for a while in a language with no or 

In D we have some implicit casts also because the "cast(int)x" 
syntax is dangerous. But now we can write safe casts with the 
"int(x)" syntax, so there's less need of naked implicit casts.


 And I'd still like built-in tuple syntax in D.

 [... Just one more feature ...] is the road to hell.

It's one more feature, and probably if D will last ten more years 
other features will be added to D.
Built-in tuples have a mostly intuitive semantics, and they help 
de-clutter the code. So the language gets a little more complex, 
but the code becomes a little simpler.

Bye,
bearophile

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 2:20 PM, bearophile wrote:
 something like a "var" keyword to denote mutable values,

 Transitive const may make this problematic.

 I don't understand, but perhaps you misunderstood me. I am talking about
 variables. In strict mode they are constant by default. This means in this code
 both x and y are immutable:

 auto x = 10;
 foreach (y; 0 .. 10) {}

 So in strict mode if you want them mutable you need a new keyword like "var":

 var x = 10;
 foreach (var y; 0 .. 10) {}

Given:

     mutable int* p;
     int* q = p;

q cannot be made immutable. But q can be made const.


 static full tracking of memory ownership,

 Makes the language significantly more complex.

 You are probably right. But it also gives good things back to a system
language.
 In the last years I've seen that taking twice the time to write my code is a
 good deal if later I can avoid wasting stressful hours searching and fixing
 bugs. So now I am willing to pay a high price up front when I code to avoid
some
 bugs later. I have friends that have taken a look at Rust and have dismissed it
 for being too much fussy and hard to get code to compile (despite probably with
 practice the Rust rules should become quite simpler to follow), but Rust looks
 like the right language for me and I'd like the same qualities in the language
 that I like more (D). So in the end I don't know what's the best solution for
D.

Rust has indeed done a good job selling people on the complexity of their 
annotation system. But I think starting with 'return ref' and D's ability to do 
inference we're actually in good shape with a far simpler system.


 less implicit casts (because now we have the safe int(x) sytnax),

 I think D does very well with implicit casts.

 I am not sure of that. Implicit casts cause some troubles, you can see this if
 you program for a while in a language with no or with very little implicit
casts

 In D we have some implicit casts also because the "cast(int)x" syntax is
 dangerous. But now we can write safe casts with the "int(x)" syntax, so there's
 less need of naked implicit casts.

Again, too many casts can cause bugs.

I have used languages that did not have implicit casting (Pascal) and didn't 
have a positive experience with it. It didn't detect a single actual bug, and 
managed to be quite annoying.

Value Range Propagation is a big win.

"Almighty Bob" <bob almighty.com> writes:

On Sunday, 15 March 2015 at 05:06:41 UTC, Walter Bright wrote:
 On 3/13/2015 2:20 PM, bearophile wrote:

 I have used languages that did not have implicit casting 
 (Pascal) and didn't have a positive experience with it. It 
 didn't detect a single actual bug, and managed to be quite 
 annoying.

I've been using D for a month and already had 3 bugs caused by 
implicit casting. The fact that...

int a = 0;
float b = 1;
a = a+b; // Causes a compile time error and...
a += b; // does not

Is absolutely ludicrous.

FWIW maybe with the kind of programming your doing you wont see 
the issues with that. But for me, DSP and statistics, I dont ever 
want implcit casts between float and int.

In fact nine times out of ten I want specific rounding when 
converting from float to int.

Nick Treleaven <ntrel-pub mybtinternet.com> writes:

On 15/03/2015 05:06, Walter Bright wrote:
 In D we have some implicit casts also because the "cast(int)x" syntax is
 dangerous. But now we can write safe casts with the "int(x)" syntax,
 so there's
 less need of naked implicit casts.

 Again, too many casts can cause bugs.

You can have safe wrappers for casts. If you don't want to change the 
type, use something like std.conv.signed. Isn't that safe?

"bachmeier" <no spam.net> writes:

I made a choice between Go and D in 2013. I started with Go and 
was very happy when I switched to D. The languages appeal to 
different users. This is how I interpreted some of the 
"advantages" of Go:

 + very small language, very concise & simple

A limited, inflexible language

 + feels like a better C (mostly)

Feels like C

 + enforced style (indentation, exports)

Ridiculously restricted for no reason other than developer 
arrogance.



An intuitive language that actually does things.

 General feeling: "I don't feel smart enough for D and am 
 looking for a quick way to accomplish a goal.

If you want to be Rob Pike Jr., Go is great. If you want to 
program your way, not so much.

For someone coming from a Lisp background but wanting a better C, 
Go had very little appeal. Bottom line: Emphasize the different 
philosophies of Go and D.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/12/2015 5:20 PM, Andrei Alexandrescu wrote:
 * Golang: simple!

D1 was the simple version of D. People wanted more.

Java was originally sold as, and got a great of adoption because, it was a C++ 
like language with all that annoying complexity removed.

There's no doubt about it, people like simple languages. We should very much 
keep that in mind when evaluating proposals for new features.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Thu, 2015-03-12 at 20:24 -0700, Walter Bright via Digitalmars-d
wrote:
[…]
 
 There's no doubt about it, people like simple languages. We should very much 
 keep that in mind when evaluating proposals for new features.

How about lining up some features for removal.

C++, Fortran, and Java are big, complicated languages, that keep getting
bigger and more complicated because of the obsession with backward
compatibility. D is already a big, complicated language. If people like
straighforward (not necessarily simple) languages, then the inference is
quite easy.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Walter Bright <newshound2 digitalmars.com> writes:

On 3/12/2015 11:57 PM, Russel Winder via Digitalmars-d wrote:
 How about lining up some features for removal.

Easier said than done. I've proposed a couple things for removal, but got a lot 
of pushback. Some things have been successfully removed:

. octal literals
. 'bit' data type
. builtin complex numbers
. NCEG floating point comparison
. typedef
. local operators new & delete


 C++, Fortran, and Java are big, complicated languages, that keep getting
 bigger and more complicated because of the obsession with backward
 compatibility. D is already a big, complicated language. If people like
 straighforward (not necessarily simple) languages, then the inference is
 quite easy.

Has any language been successful at abandoning their user base (i.e. existing 
code)? Going from D1 to D2 nearly destroyed D. I'm not eager to try that again.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 00:22 -0700, Walter Bright via Digitalmars-d
wrote:
 On 3/12/2015 11:57 PM, Russel Winder via Digitalmars-d wrote:
 How about lining up some features for removal.

=20
 Easier said than done. I've proposed a couple things for removal, but got=

 a lot=20
 of pushback. Some things have been successfully removed:

Pushback can be ignored, and indeed should in some cases.

Java is going to come to this battle when primitive types finally get
removed from the language.

 . octal literals

C should be incinerated for the 0777 abomination. At least 0o777 can
work reasonably.

 . 'bit' data type
 . builtin complex numbers

Electronics folk love these. Many people use Python exactly for this
type.

 . NCEG floating point comparison
 . typedef
 . local operators new & delete
=20
=20
 C++, Fortran, and Java are big, complicated languages, that keep gettin=


g
 bigger and more complicated because of the obsession with backward
 compatibility. D is already a big, complicated language. If people like
 straighforward (not necessarily simple) languages, then the inference i=


s
 quite easy.

=20
 Has any language been successful at abandoning their user base (i.e. exis=

ting=20
 code)? Going from D1 to D2 nearly destroyed D. I'm not eager to try that =

again.

The war is being played out in the Python 2/3 arena certainly.
Interestingly though there are fewer and fewer Python 2 hold outs. Their
holding out has made Python 3 change a little, and for the better in my
view =E2=80=93 even though I refuse to write any Python 2 specific code.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Walter Bright <newshound2 digitalmars.com> writes:

On 3/14/2015 2:26 AM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 00:22 -0700, Walter Bright via Digitalmars-d
 wrote:
 On 3/12/2015 11:57 PM, Russel Winder via Digitalmars-d wrote:
 How about lining up some features for removal.

 Easier said than done. I've proposed a couple things for removal, but got a lot
 of pushback. Some things have been successfully removed:

 Pushback can be ignored, and indeed should in some cases.

Not ignored. But sometimes I do override others' judgement in the interest of 
doing what I believe is best. Somebody has to make decisions on controversial 
issues.

(I had proposed removing the 'lazy' storage class.)

 . octal literals

 C should be incinerated for the 0777 abomination. At least 0o777 can
 work reasonably.

Even better:

     octal!0777

The point is, with a library abstraction the core language can be simplified. 
D's ability to create user defined literals largely ends the pressure to make 
more complicated and specialized core language literals.


 . builtin complex numbers

 Electronics folk love these. Many people use Python exactly for this
 type.

Complex numbers are still available, but as a library type, which is not 
inferior to the (former) builtin type.


 Has any language been successful at abandoning their user base (i.e. existing
 code)? Going from D1 to D2 nearly destroyed D. I'm not eager to try that again.

 The war is being played out in the Python 2/3 arena certainly.
 Interestingly though there are fewer and fewer Python 2 hold outs. Their
 holding out has made Python 3 change a little, and for the better in my
 view – even though I refuse to write any Python 2 specific code.

It's a good example. Didn't Perl 6 go through a paroxysm, too? But not so 
successfully.

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
 The point is, with a library abstraction the core language can 
 be simplified. D's ability to create user defined literals 
 largely ends the pressure to make more complicated and 
 specialized core language literals.

It makes it sounds like you don't know the spec about string 
literals.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/14/2015 3:19 PM, deadalnix wrote:
 On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
 The point is, with a library abstraction the core language can be simplified.
 D's ability to create user defined literals largely ends the pressure to make
 more complicated and specialized core language literals.

 It makes it sounds like you don't know the spec about string literals.

I know I don't know what you're driving at :-)

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 14 March 2015 at 23:47:24 UTC, Walter Bright wrote:
 On 3/14/2015 3:19 PM, deadalnix wrote:
 On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright 
 wrote:
 The point is, with a library abstraction the core language 
 can be simplified.
 D's ability to create user defined literals largely ends the 
 pressure to make
 more complicated and specialized core language literals.

 It makes it sounds like you don't know the spec about string 
 literals.

 I know I don't know what you're driving at :-)

That we have a large number of string literals, in the core of 
the language, many of which could probably be language construct.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/14/2015 8:41 PM, deadalnix wrote:
 On Saturday, 14 March 2015 at 23:47:24 UTC, Walter Bright wrote:
 On 3/14/2015 3:19 PM, deadalnix wrote:
 On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
 The point is, with a library abstraction the core language can be simplified.
 D's ability to create user defined literals largely ends the pressure to make
 more complicated and specialized core language literals.

 It makes it sounds like you don't know the spec about string literals.

 I know I don't know what you're driving at :-)

 That we have a large number of string literals, in the core of the language,
 many of which could probably be language construct.

I haven't looked into it - anything in particular you have in mind?

I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful 
than they are.

"deadalnix" <deadalnix gmail.com> writes:

On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
 That we have a large number of string literals, in the core of 
 the language,
 many of which could probably be language construct.

 I haven't looked into it - anything in particular you have in 
 mind?

Not one precisely, but I'm sure we don't need as many as we have. 
", `, q", q{, r", x". I've never used several of theses and I'm 
sure most people here would say the same.

 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

I use them all the time, and cringe whenever I code in something 
else because i don't have them. Once you have /* comments */ in 
some piece of code, you can't comment blocks without going 
through hoops. that is very annoying./+ comments +/ are one of 
the simple thing that makes coding in D much more pleasant.

"Charles Cooper" <chevil gmail.com> writes:

I've been reading through the thread and it seems that the D 
community has an image problem of some sort. But why? D is great!

Were I to articulate D's key strengths I would say that it allows 
you to write precise code and be sure that it is correct. This is 
something you can neither do in the mainstream functional 
languages (fanatical insistence on hammering the GC as much as 
possible basically means you can never put any memory where you 
actually want it), or in low level but unsafe C/C++ where 
Everything Is Broke All The Time (TM). Don't even get me started 
on Python or Java which seem like they are trying to force the 
programmer to avoid both correctness and performance at all 
costs. D comes with many features for helping enforce algorithmic 
correctness as well as powerful code generation facilities to 
write code where you have low level guarantees on what it will do.

But you already knew that. So here comes The Big Question: Do 
those in the D community actually want it to be as mainstream as 
Java or Python? There are benefits and (in my view) big 
drawbacks. Right now the community is hobbyist, which means that 
the users and developers work on it *because they actually care*. 
And so far I have been impressed with the quality of the D 
ecosystem overall.

Well, who is the audience for D? The armies of corporate database 
programmers? Web developers? Kernel developers? Etc. Food for 
thought.

On Sunday, 15 March 2015 at 05:29:00 UTC, deadalnix wrote:
 On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
 That we have a large number of string literals, in the core 
 of the language,
 many of which could probably be language construct.

 I haven't looked into it - anything in particular you have in 
 mind?

 Not one precisely, but I'm sure we don't need as many as we 
 have. ", `, q", q{, r", x". I've never used several of theses 
 and I'm sure most people here would say the same.

 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

 I use them all the time, and cringe whenever I code in 
 something else because i don't have them. Once you have /* 
 comments */ in some piece of code, you can't comment blocks 
 without going through hoops. that is very annoying./+ comments 
 +/ are one of the simple thing that makes coding in D much more 
 pleasant.

"Alaksiej =?UTF-8?B?U3RhbmtpZXZpxI0i?= <harald_zealot tut.by> writes:

 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

 I use them all the time, and cringe whenever I code in 
 something else because i don't have them. Once you have /* 
 comments */ in some piece of code, you can't comment blocks 
 without going through hoops. that is very annoying./+ comments 
 +/ are one of the simple thing that makes coding in D much more 
 pleasant.

I have opened a fascinated behavior of /+ +/ not so long, and it 
is really cool. If you want to rid them, then /* */ have to get 
this behavior. And it doesn't broke anything, because they pass 
for examle principle "C code works properly, when it compiles".

Walter Bright <newshound2 digitalmars.com> writes:

On 3/14/2015 10:28 PM, deadalnix wrote:
 I use them all the time, and cringe whenever I code in something else because i
 don't have them. Once you have /* comments */ in some piece of code, you can't
 comment blocks without going through hoops. that is very annoying./+ comments
+/
 are one of the simple thing that makes coding in D much more pleasant.

Use:

    version (none)
    {
       ...
    }

instead of:

    /+
       ...
     +/

On a related note, see how difficult it is to remove a feature? Every time I 
propose one, someone pops up and says they built their life around it :-)

"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:

On Sunday, 15 March 2015 at 09:13:19 UTC, Walter Bright wrote:
 On 3/14/2015 10:28 PM, deadalnix wrote:
 I use them all the time, and cringe whenever I code in 
 something else because i
 don't have them. Once you have /* comments */ in some piece of 
 code, you can't
 comment blocks without going through hoops. that is very 
 annoying./+ comments +/
 are one of the simple thing that makes coding in D much more 
 pleasant.

 Use:

    version (none)
    {
       ...
    }

 instead of:

    /+
       ...
     +/

Nope, that requires the commented-out part to be syntactically 
correct. My primary use-case for /+ +/ is during development, 
when I quickly need to disable specific parts of code. These 
frequently don't coincide with syntactic boundaries.

 On a related note, see how difficult it is to remove a feature? 
 Every time I propose one, someone pops up and says they built 
 their life around it :-)

At least in this case, it's because they are actually useful, and 
there is no convenient replacement. Besides, why would you want 
to remove them again? Just so we can say, "Look, we removed a 
feature!"? They're so trivial to implement and support, and so 
easy to learn, that their presence does not add a significant 
cost.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/15/2015 4:02 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:
 Nope, that requires the commented-out part to be syntactically correct. My
 primary use-case for /+ +/ is during development, when I quickly need to
disable
 specific parts of code. These frequently don't coincide with syntactic
boundaries.

It's not an onerous limitation.


 On a related note, see how difficult it is to remove a feature? Every time I
 propose one, someone pops up and says they built their life around it :-)

 At least in this case, it's because they are actually useful, and there is no
 convenient replacement. Besides, why would you want to remove them again? Just
 so we can say, "Look, we removed a feature!"? They're so trivial to implement
 and support, and so easy to learn, that their presence does not add a
 significant cost.

It's the drip-drip-drip of a thousand features that adds up.

Anyhow, it obviously isn't going anywhere.

"deadalnix" <deadalnix gmail.com> writes:

On Monday, 16 March 2015 at 00:11:37 UTC, Walter Bright wrote:
 It's the drip-drip-drip of a thousand features that adds up.

 Anyhow, it obviously isn't going anywhere.

It mostly a problem when features are not orthogonals.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/14/2015 10:28 PM, deadalnix wrote:
 Not one precisely, but I'm sure we don't need as many as we have. ", `, q", q{,
 r", x". I've never used several of theses and I'm sure most people here would
 say the same.

The HexStrings http://dlang.org/lex.html#HexString can be easily replaced with
a 
user defined literal. That's probably a good idea. The others, not so.

"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:

On Sunday, 15 March 2015 at 09:24:36 UTC, Walter Bright wrote:
 On 3/14/2015 10:28 PM, deadalnix wrote:
 Not one precisely, but I'm sure we don't need as many as we 
 have. ", `, q", q{,
 r", x". I've never used several of theses and I'm sure most 
 people here would
 say the same.

 The HexStrings http://dlang.org/lex.html#HexString can be 
 easily replaced with a user defined literal. That's probably a 
 good idea. The others, not so.

This I agree with. Their usefulness is also greatly diminished by 
them being strings, instead of byte (ubyte?) arrays. When would 
you actually want to write a string (= text) using hex notation?

Walter Bright <newshound2 digitalmars.com> writes:

On 3/15/2015 4:06 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:
 This I agree with. Their usefulness is also greatly diminished by them being
 strings, instead of byte (ubyte?) arrays. When would you actually want to write
 a string (= text) using hex notation?

1. test data
2. strings that aren't in UTF format
3. strings with other data embedded in them

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

On Sun, Mar 15, 2015 at 05:12:55PM -0700, Walter Bright via Digitalmars-d wrote:
 On 3/15/2015 4:06 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:
This I agree with. Their usefulness is also greatly diminished by
them being strings, instead of byte (ubyte?) arrays. When would you
actually want to write a string (= text) using hex notation?

 
 1. test data

This is about the only valid use case I can think of. And it's really
only useful in druntime/Phobos test cases. I can't imagine users would
go out of their way to use generate binary test data where string input
is desired.


 2. strings that aren't in UTF format

Uhm... strings that aren't in UTF format really ought to be ubyte[]
(resp. ushort[], uint[]), not string, because pretty much everything in
D that takes a (|w|d)string argument expects UTF encoding.

(Or, in an ideal world where std.encoding is actually sane, we'd use
suitable wrapper types for ubyte[] that represent their respective
encoding.)


 3. strings with other data embedded in them

Again, shouldn't these be ubyte[]? Calling them string (i.e.
immutable(char)[]) is a wrong conflation of ubyte with char, that has
led to so much headache in C/C++. D should not repeat this mistake.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing
someone out a window", or more recently "to remove Windows from a computer and
replace it with something useful". :-) -- John Cowan

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Saturday, March 14, 2015 21:31:46 Walter Bright via Digitalmars-d wrote:
 I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful
 than they are.

Really? I love those. They're _way_ better than /* */. The fact that /* */
don't nest is _very_ annoying, and I think that /+ +/ is a big improvement.
If anything, I wouldn't mind it if /* */ were removed from the language.
They're just plain inferior to /+ +/. The only advantage of /* */ is that
they exist in other languages.

- Jonathan M Davis

"ponce" <contact gam3sfrommars.fr> writes:

On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

Using /+ +/ regularly.
Very useful to comment out large areas of code.

"w0rp" <devw0rp gmail.com> writes:

On Sunday, 15 March 2015 at 13:45:28 UTC, ponce wrote:
 On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

 Using /+ +/ regularly.
 Very useful to comment out large areas of code.

I like /+ +/ myself. It's great for temporarily disabling parts 
of code.

"bearophile" <bearophileHUGS lycos.com> writes:

Walter Bright:

 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

I prefer to get rid of /* */ instead :-) Because /++/ can do 
things /**/ can't.

Bye,
bearophile

"Nicolas Sicard" <dransic gmail.com> writes:

On Sunday, 15 March 2015 at 14:01:00 UTC, bearophile wrote:
 Walter Bright:

 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

 I prefer to get rid of /* */ instead :-) Because /++/ can do 
 things /**/ can't.

+1

And on my keyboard, /++/ is easier than /**/ :-)

"deadalnix" <deadalnix gmail.com> writes:

On Sunday, 15 March 2015 at 14:01:00 UTC, bearophile wrote:
 Walter Bright:

 I'd also prefer to get rid of /+ +/ comments, I thought they'd 
 be more useful than they are.

 I prefer to get rid of /* */ instead :-) Because /++/ can do 
 things /**/ can't.

 Bye,
 bearophile

/*

...

/*/

...

//*/

Is really hard to get with /+ and porting C code would become 
much more of a pain in the ass. It don't think we have a problem 
with comment as they are thrown away at the lexer stage, so they 
do not contribute by much to the language complexity.

"weaselcat" <weaselcat gmail.com> writes:

On Saturday, 14 March 2015 at 19:48:14 UTC, Walter Bright wrote:
 The point is, with a library abstraction the core language can 
 be simplified. D's ability to create user defined literals 
 largely ends the pressure to make more complicated and 
 specialized core language literals.


user defined literals can be quite ugly where sugar is 
expected(i.e, Tuples)

"Laeeth Isharc" <laeeth nospamlaeeth.com> writes:

Hi.

Some points I think are important follow.  I can't do much on 
these myself for now as computer use limited by a spinal injury.

1. Compilation speed of D under reference compiler compares very 
favourably to most (all?) other compiled languages.  This 
facilitates rapid iteration, which works nicely with the 
'plasticity' of D code.  This should be emphasized on the landing 
page, and there should be a few standardised concrete reference 
points since for better or for worse modern people don't take you 
seriously if you don't quantify it.

2. D is a very powerful language whose essential features are 
easy to learn.  Coming from C, and not having written a great 
deal of code since about twenty years ago, it took me a few 
months to be productive in D (about the same as python, which I 
learnt shortly before D).  The generics and metaprogramming are 
not so straightforward, but you don't need to use them to be 
productive very quickly.  We should emphasize D can be a native 
code python (but is more than this if that is what you need)

3. I have said so before (the GroupBy docs) - standard library 
documentation is 'perfectly clear' if you have a technical 
mindset and are used to reading formalisms, but it is 
horrendously intimidating if not (which applies to many people).  
We need more examples, and they should put the use in context 
rather than just being tiny fragments - ie show how to do 
something useful with the function (cf python docs).  There 
should also be a guide to functions writing from point of what 
one wants to achieve.  toLower in std.string, but I need to go to 
std.ascii for doing the same thing to a character.  Eminently 
logical, but not obvious if you don't know where to look.

4. Need a better guide to libraries and frameworks oriented to 
how to accomplish common tasks.  (I really don't see why you 
wouldn't bundle vibed with dmd+phobos since small frictions have 
large consequences when you are starting out).

5. Different channels for tutorials organized by use case 
(accessible from front page not sidebar) - writing a server, 
writing a script, pulling data from the Fed website and charting 
it, simple gui app, simple database app.  Take cybershadow's 
slides comparing nodejs code to vibed code.

6. More user stories accessible from front page and well 
organised.  Make it visual and personal.  Facebook (not just 
warp, but odbc, any other stories), Sociomantic, Adroll, Remedy, 
etc.

7. It doesn't make sense for D to 'concentrate on XYZ use case' 
(languages can't be centrally planned - which is not to say 
identifying impediments is not useful), and nor is it a problem 
that it 'hasn't gone anywhere' since 2001.  Things develop at 
their own pace, and periods of quiet building are often needed 
before breaking out into the next stage.  An overnight success is 
a long time indeed in the making.

8. Libraries are a rougher area.  RSS, XML, JSON, Redis, 
databases, MIME, IMAP, HDF5, etc - there are solutions, but 
nothing standard and no consistency in documentation.

9. Mobile seems important for future of the language but seems 
the effort of a small number of people.

10. Calling D a systems programming language makes me think I 
shouldn't use it for non-systems purposes.  That's no longer on 
the front page, but it is the next thing I see here: 
http://dlang.org/getstarted.html.  What proportion of newcomers 
to D want to use it for systems programming?

11. This week in D.  should there be a tour of useful frameworks 
from code.dlang?

12. a good part of Pandas style functionality is not so hard to 
do.  Vlad Levenfeld has written a framework that may be 
interesting here, but it is still under development.

13. charting?

"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:

On Sunday, 15 March 2015 at 03:26:01 UTC, Laeeth Isharc wrote:
 Hi.

 Some points I think are important follow.  I can't do much on 
 these myself for now as computer use limited by a spinal injury.

That sounds bad. I hope you'll get better!

 3. I have said so before (the GroupBy docs) - standard library 
 documentation is 'perfectly clear' if you have a technical 
 mindset and are used to reading formalisms, but it is 
 horrendously intimidating if not (which applies to many 
 people).  We need more examples, and they should put the use in 
 context rather than just being tiny fragments - ie show how to 
 do something useful with the function (cf python docs).  There 
 should also be a guide to functions writing from point of what 
 one wants to achieve.  toLower in std.string, but I need to go 
 to std.ascii for doing the same thing to a character.  
 Eminently logical, but not obvious if you don't know where to 
 look.

It seems the accessibility/discoverability of string handling is 
a common complaint. People expect certain functions to be 
available for strings, like startsWith, trim/ltrim/rtrim, repeat, 
maybe even regex matching. Now, these things are all available in 
other parts of Phobos, or easily implementable using components 
from all over the standard library, but a beginner won't know 
this, and even if, it's inconvenient.

Maybe we should add the most common functions to `std.string`? 
Either as aliases or re-exports, or even (re)implement them there 
with the appropriate semantics if necessary. For example, people 
would expect a hypothetical `std.string.repeat` to be eager, 
whereas `std.range.repeat("hello").take(5)` is lazy. Some 
operations may also decay to ranges of `dchar`, but we'd want to 
preserve the string type.

"Laeeth Isharc" <laeeth nospamlaeeth.com> writes:

On Sunday, 15 March 2015 at 10:53:21 UTC, Marc Schütz wrote:

 I hope you'll get better!

Thanks.  On the mend, but it takes time...

 3. I have said so before (the GroupBy docs) - standard library 
 documentation is 'perfectly clear' if you have a technical 
 mindset and are used to reading formalisms, but it is 
 horrendously intimidating if not (which applies to many 
 people).  We need more examples, and they should put the use 
 in context rather than just being tiny fragments - ie show how 
 to do something useful with the function (cf python docs).  
 There should also be a guide to functions writing from point 
 of what one wants to achieve.  toLower in std.string, but I 
 need to go to std.ascii for doing the same thing to a 
 character.  Eminently logical, but not obvious if you don't 
 know where to look.

 It seems the accessibility/discoverability of string handling 
 is a common complaint. People expect certain functions to be 
 available for strings, like startsWith, trim/ltrim/rtrim, 
 repeat, maybe even regex matching. Now, these things are all 
 available in other parts of Phobos, or easily implementable 
 using components from all over the standard library, but a 
 beginner won't know this, and even if, it's inconvenient.

 Maybe we should add the most common functions to `std.string`? 
 Either as aliases or re-exports, or even (re)implement them 
 there with the appropriate semantics if necessary. For example, 
 people would expect a hypothetical `std.string.repeat` to be 
 eager, whereas `std.range.repeat("hello").take(5)` is lazy. 
 Some operations may also decay to ranges of `dchar`, but we'd 
 want to preserve the string type.


No opinion on this myself, but aliases have a cost in terms of 
confusion (what's the difference?   err there is none) whereas 
there may be some value in reimplementation with appropriate 
semantics at some future point.

But I think the closest sticking point is not lack of order in 
library organisation - just that the documents are written from 
the perspective of the library writer and there is currently no 
coherent, complete, and polished set of documents primarily 
oriented to 'how do I accomplish this task'. I understand why 
that is, but if one identifies a problem one can work away at it 
slowly over time.

"Dejan Lekic" <dejan.lekic gmail.com> writes:

On Friday, 13 March 2015 at 06:57:29 UTC, Russel Winder wrote:
 On Thu, 2015-03-12 at 20:24 -0700, Walter Bright via 
 Digitalmars-d
 wrote:
 […]
 
 There's no doubt about it, people like simple languages. We 
 should very much keep that in mind when evaluating proposals 
 for new features.

 How about lining up some features for removal.

 C++, Fortran, and Java are big, complicated languages, that 
 keep getting
 bigger and more complicated because of the obsession with 
 backward
 compatibility. D is already a big, complicated language. If 
 people like
 straightforward (not necessarily simple) languages, then the 
 inference is
 quite easy.

Java big, complicated language?? :) I do not agree with that 
statement at all. Java *is* there where it is because it is 
SIMPLE language, and equally hated for being simple language.

We can't satisfy everybody.

D can be super-simple too - people do not have to use fancy 
features of the language. I think most tutorials/articles tell 
readers too much about D, and it may scare them away.

"w0rp" <devw0rp gmail.com> writes:

On Friday, 13 March 2015 at 03:24:44 UTC, Walter Bright wrote:
 On 3/12/2015 5:20 PM, Andrei Alexandrescu wrote:
 * Golang: simple!

 D1 was the simple version of D. People wanted more.

 Java was originally sold as, and got a great of adoption 
 because, it was a C++ like language with all that annoying 
 complexity removed.

 There's no doubt about it, people like simple languages. We 
 should very much keep that in mind when evaluating proposals 
 for new features.

I'll never forget what Bjarne said about people wanting a "simple 
language." His response to "I want a simple language" was, "No, 
you don't!" Because it's always "I want it to be simple... with 
just this one extra little feature in it."

It was in his list of "Language Myths" in his talk at Lang-NEXT. 
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 2:22 AM, w0rp wrote:
 I'll never forget what Bjarne said about people wanting a "simple language."
His
 response to "I want a simple language" was, "No, you don't!" Because it's
always
 "I want it to be simple... with just this one extra little feature in it."

Yes. I've often seen posts here from people writing that they wanted stability, 
and then give a list of new features they want.

"deadalnix" <deadalnix gmail.com> writes:

On Friday, 13 March 2015 at 10:02:02 UTC, Walter Bright wrote:
 On 3/13/2015 2:22 AM, w0rp wrote:
 I'll never forget what Bjarne said about people wanting a 
 "simple language." His
 response to "I want a simple language" was, "No, you don't!" 
 Because it's always
 "I want it to be simple... with just this one extra little 
 feature in it."

 Yes. I've often seen posts here from people writing that they 
 wanted stability, and then give a list of new features they 
 want.

Same old strawman again.

there is introduce this completely new feature thta may be good, 
but ultimately increase the language size and complexity and will 
come with its set of bugs, and there is introduce feature X, that 
will complete what feature A, B and C, that are already in, so 
they can actually provide what they are supposed to without any 
holes.

Putting the 2 in the same bag is the very reason why we get stuff 
added or rejected pretty much randomly and never get stable.

"Sativa" <Sativa Indica.org> writes:

On Friday, 13 March 2015 at 03:24:44 UTC, Walter Bright wrote:
 On 3/12/2015 5:20 PM, Andrei Alexandrescu wrote:
 * Golang: simple!

 D1 was the simple version of D. People wanted more.

 Java was originally sold as, and got a great of adoption 
 because, it was a C++ like language with all that annoying 
 complexity removed.

 There's no doubt about it, people like simple languages. We 
 should very much keep that in mind when evaluating proposals 
 for new features.

Um, This is wrong. You already have simple languages. People are 
not going to choose D no matter how much you dumb it down. What 
sets D apart is it's advanced features... remove them or stop 
such enhancements and it won't be able to compete with any other 
language.


In fact, the opposite thinking should be true. Add the most 
advanced feature rich set to D and then nothing will be able to 
compete with it. If, on top of that, you don't force someone to 
use them then you have the best of both words(power when you need 
it and simple when you don't).

There's reasons why people by luxury cars. D is like an Cadillac 
and Go is like a volt. If you turn D in a volt then what will 
people buy that like Cadillac's?
(Someone will create a new language trying to make a Cadillac and 
the whole process starts over...)

Walter Bright <newshound2 digitalmars.com> writes:

On 3/15/2015 7:46 AM, Sativa wrote:
 Um, This is wrong. You already have simple languages. People are not going to
 choose D no matter how much you dumb it down. What sets D apart is it's
advanced
 features... remove them or stop such enhancements and it won't be able to
 compete with any other language.


 In fact, the opposite thinking should be true. Add the most advanced feature
 rich set to D and then nothing will be able to compete with it. If, on top of
 that, you don't force someone to use them then you have the best of both
 words(power when you need it and simple when you don't).

What I mean is anyone can invent something complicated. It takes genius to find 
the underlying simplicity that is just as (or more) powerful. We should always 
be looking for the latter.


 There's reasons why people by luxury cars. D is like an Cadillac and Go is like
 a volt. If you turn D in a volt then what will people buy that like Cadillac's?
 (Someone will create a new language trying to make a Cadillac and the whole
 process starts over...)

I like the analogy of D being a fully equipped machine shop, as opposed to a 
collection of basic hand tools.

When I was younger it was hard working on my car, because I could not afford
the 
right tools. So I made do with whatever was available. The results were lots of 
scrapes and bruises, much time invested, and rather crappy repairs. Now I can 
buy the right tools, and boy what a difference that makes! I can get 
professional quality results with little effort.

(Ever try to install an engine without a proper hoist? Yowsa!)

"Zach the Mystic" <reachzach gggmail.com> writes:

On Monday, 16 March 2015 at 00:27:56 UTC, Walter Bright wrote:
 I like the analogy of D being a fully equipped machine shop, as 
 opposed to a collection of basic hand tools.

 When I was younger it was hard working on my car, because I 
 could not afford the right tools. So I made do with whatever 
 was available. The results were lots of scrapes and bruises, 
 much time invested, and rather crappy repairs. Now I can buy 
 the right tools, and boy what a difference that makes! I can 
 get professional quality results with little effort.

I agree with this. However, it actually implies a huge amount 
about what I would call D's brand. The fully equipped machine 
shop metaphor has some very serious tradeoffs when applied to 
computer programming languages, the steep learning curve required 
to use the machines correctly, for instance.

But I see advantage in this, because I can see a brand -- that 
is, an identity which distinguishes something from its rivals, 
not by flat-out superiority, but by its commitment to particulars 
-- for D here. I think D can market itself to a certain type of 
programmer, and win the language war by empowering this type of 
programmer, thereby inciting the envy of other types of 
programmers, who over time grudgingly concede the inferiority of 
their own styles and follow the herd.

Brands are all about types of people, rather than of products. I 
would love to see D consciously embrace its own kind of person, 
and not just because it feels good, but because of its value as a 
marketing strategy.

I see D attracting *really* good programmers, programmers from, 
let's say the 90-95th percentile in skill and talent in their 
field on average. By marketing to these programmers specifically 
-- that is, telling everyone that while D is for everyone, it is 
especially designed to give talented and experienced programmers 
the tools they need to get their work done -- even if you repel 
several programmers from, say, the 45th percentile or below in 
exchange for the brand loyalty of one from 92nd percentile or 
above, it's probably a winning strategy, because that one good 
programmer will get more done than all the rest combined.

"Joakim" <dlang joakim.fea.st> writes:

On Monday, 16 March 2015 at 08:33:43 UTC, Zach the Mystic wrote:
 I see D attracting *really* good programmers, programmers from, 
 let's say the 90-95th percentile in skill and talent in their 
 field on average. By marketing to these programmers 
 specifically -- that is, telling everyone that while D is for 
 everyone, it is especially designed to give talented and 
 experienced programmers the tools they need to get their work 
 done -- even if you repel several programmers from, say, the 
 45th percentile or below in exchange for the brand loyalty of 
 one from 92nd percentile or above, it's probably a winning 
 strategy, because that one good programmer will get more done 
 than all the rest combined.

Yep, this is what I meant by my Blackberry analogy earlier in 
this thread.  Blackberry used to own the smartphone market, when 
it was limited to professionals who emailed and texted a lot.  
When the market broadened to include everyone, they decided to go 
the popular route and sell touch-screen phones without physical 
keyboards like everyone else.  It was a disaster, from which 
they're only recently recovering by offering physical keyboards 
again.  I'm not saying it _had_ to fail, only that RIM clearly 
didn't have what it took to succeed there.

Similarly, D's never going to do very well with programmers who 
don't care about the efficiency of their code: simpler, slower 
languages like python or ruby have that niche sewn up.  The best 
we can do is point out that if you're already here for the 
advanced features, it can also be used for scripting and the 
like.  And of course, we should always strive to make things as 
easy as we can for both small and large projects, including 
better documentation.

One day, the tide may turn towards native efficiency again, say 
because of mobile or more people writing code that runs on large 
server clusters, and D will be well-positioned to benefit if and 
when that happens.

"bachmeier" <no spam.net> writes:

On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
 Similarly, D's never going to do very well with programmers who 
 don't care about the efficiency of their code: simpler, slower 
 languages like python or ruby have that niche sewn up.  The 
 best we can do is point out that if you're already here for the 
 advanced features, it can also be used for scripting and the 
 like.  And of course, we should always strive to make things as 
 easy as we can for both small and large projects, including 
 better documentation.

I don't necessarily agree with that. I'd say Python and Ruby will 
dominate among programmers that don't care about efficiency *and* 
are writing simple scripts. Ruby's my go-to language for writing 
small scripts to manipulate a little text or to move some files 
around. D is just a better language once you get into bigger 
tasks.

With respect to scripting, I see the main documentation problem 
being one of examples. You shouldn't have to understand how 
templates work in order to write a script. Documentation related 
to ranges is a big offender. Ranges are used all over the 
language, yet there's no way the average Joe is going to figure 
out how to use functions that return a range, and there's no 
reason it should be that way. I once proposed a ban on auto as a 
return type in documentation examples and the response was that 
you should know how to use the language before reading the 
documentation.

"ninja" <ninja ninjutsu.com> writes:

On Monday, 16 March 2015 at 10:12:53 UTC, bachmeier wrote:
 I once proposed a ban on auto as a return type in documentation 
 examples

This. Figuring out the return types in the examples was a daily 
struggle in the first few weeks.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/16/2015 4:29 AM, ninja wrote:
 This. Figuring out the return types in the examples was a daily struggle in the
 first few weeks.

When Voldemort types are returned, they must be by auto. The user isn't
supposed 
to know what the return type is, just how to use it.

"Almighty Bob" <bob almighty.com> writes:

On Tuesday, 17 March 2015 at 07:15:17 UTC, Walter Bright wrote:
 On 3/16/2015 4:29 AM, ninja wrote:
 This. Figuring out the return types in the examples was a 
 daily struggle in the
 first few weeks.

 When Voldemort types are returned, they must be by auto. The 
 user isn't supposed to know what the return type is, just how 
 to use it.

How do you keep it around if you cant declare a member to hold it?

It's all well and good explaining the reason for them but it 
doesnt void the fact that they are a PITA if you say want to use 
cvsReader to parse some records and keep the results as a class 
member.

"Panke" <tobias pankrath.net> writes:

 How do you keep it around if you cant declare a member to hold 
 it?

 It's all well and good explaining the reason for them but it 
 doesnt void the fact that they are a PITA if you say want to 
 use cvsReader to parse some records and keep the results as a 
 class member.

I don't think csvReader supports your point. The input range 
returned is not for permanent storage, just store the struct if 
you've used csvReadder!SomeStruct or store cells individually as 
Contents if you used csvReader!Contents. (by default Contents is 
string).

I think it's a very good api.

"Almighty Bob" <almighty bob.com> writes:

On Tuesday, 17 March 2015 at 09:25:57 UTC, Panke wrote:
 How do you keep it around if you cant declare a member to hold 
 it?

 It's all well and good explaining the reason for them but it 
 doesnt void the fact that they are a PITA if you say want to 
 use cvsReader to parse some records and keep the results as a 
 class member.

 I don't think csvReader supports your point. The input range 
 returned is not for permanent storage,

How do you know it's not meant for permanent storage? The docs
dont say that. Is that a typical idiom with returned ranges?

And what's the point of an all singing and dancing API if it
imposes pointless restrictions on the user for the sake of some
questionable benefit for the library writer?

It's far more useful for csvReader to return a type I know and
can use than it is to obscure the return type for the sake of
some philosophical ideal of increasing encapsulation.

In short, for the user, Voldomort types have no benefit and only
cost.

Nick Treleaven <ntrel-pub mybtinternet.com> writes:

On 17/03/2015 10:31, Almighty Bob wrote:
 It's far more useful for csvReader to return a type I know and
 can use than it is to obscure the return type for the sake of
 some philosophical ideal of increasing encapsulation.

Part of the art of API design is to hide implementation where it's not 
necessarily needed. Designers might err on the side of hiding things, 
because how you expose something is important as it has to be maintained 
indefinitely. If they expose everything then the internals can never be 
redesigned for better performance, etc.

"Almighty Bob" <bob almighty.com> writes:

On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote:
 On 17/03/2015 10:31, Almighty Bob wrote:
 It's far more useful for csvReader to return a type I know and
 can use than it is to obscure the return type for the sake of
 some philosophical ideal of increasing encapsulation.

 Part of the art of API design is to hide implementation where 
 it's not necessarily needed. Designers might err on the side of 
 hiding things, because how you expose something is important as 
 it has to be maintained indefinitely. If they expose everything 
 then the internals can never be redesigned for better 
 performance, etc.

They don't increase encapsulation. The public members of a 
voldomort type are still public, you still have to code to the 
API of the return type whether it's a regular or voldomort type. 
You can keep as much private or public in either case as you like.

All they do take the typename out of circulation, they make life 
harder for the user. There's no benefit. None.

But at least the library author can stroke his chin a feel smug 
that there's one less type in the modules' namespace.

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote:
 On 17/03/2015 10:31, Almighty Bob wrote:
 It's far more useful for csvReader to return a type I know and
 can use than it is to obscure the return type for the sake of
 some philosophical ideal of increasing encapsulation.

 Part of the art of API design is to hide implementation where 
 it's not necessarily needed. Designers might err on the side 
 of hiding things, because how you expose something is 
 important as it has to be maintained indefinitely. If they 
 expose everything then the internals can never be redesigned 
 for better performance, etc.

 They don't increase encapsulation. The public members of a 
 voldomort type are still public, you still have to code to the 
 API of the return type whether it's a regular or voldomort 
 type. You can keep as much private or public in either case as 
 you like.

 All they do take the typename out of circulation, they make 
 life harder for the user. There's no benefit. None.

 But at least the library author can stroke his chin a feel smug 
 that there's one less type in the modules' namespace.

Totally missing the point. The crux of the matter is this: 
changing a voldemort type (assuming the public semantics are the 
same) is not a breaking API change, because no-one else's code 
ever names it.

Admittedly this is sort-of true for any function that returns 
auto and doesn't document its return type, but that is by 
convention (the type is always readable in the relevant .d or .di 
file) whereas using a voldemort type enforces it.

Note that if you really want a name to use in your code:
alias IotaFloat = typeof(iota(0f, 2f, 1f));

"Almighty Bob" <bob almighty.com> writes:

On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
 On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven 
 wrote:
 On 17/03/2015 10:31, Almighty Bob wrote:
 It's far more useful for csvReader to return a type I know 
 and
 can use than it is to obscure the return type for the sake of
 some philosophical ideal of increasing encapsulation.

 Part of the art of API design is to hide implementation where 
 it's not necessarily needed. Designers might err on the side 
 of hiding things, because how you expose something is 
 important as it has to be maintained indefinitely. If they 
 expose everything then the internals can never be redesigned 
 for better performance, etc.

 They don't increase encapsulation. The public members of a 
 voldomort type are still public, you still have to code to the 
 API of the return type whether it's a regular or voldomort 
 type. You can keep as much private or public in either case as 
 you like.

 All they do take the typename out of circulation, they make 
 life harder for the user. There's no benefit. None.

 But at least the library author can stroke his chin a feel 
 smug that there's one less type in the modules' namespace.

 Totally missing the point. The crux of the matter is this: 
 changing a voldemort type (assuming the public semantics are 
 the same) is not a breaking API change, because no-one else's 
 code ever names it.

Seriously? You cant have a public API and private implementation 
with a regular type? That's something specific to voldomort types?

Ask yourself what exactly do voldomort types enable you to hide 
that cant be hidden with a regular type? Just one thing. Their 
name. As you said no one else can ever name the type.

That is no benefit to me the user. No-one has been able to even 
describe a benefit. Walters article on Dr Dobbs doesn't describe 
a benefit. It "increases encapsulation" you all squawk.

No it doesn't. The private bits are still private, the public 
bits are still public.

All it does is complicate the user side.

Its the emperor's new clothes.

"w0rp" <devw0rp gmail.com> writes:

On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
 On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
 On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven 
 wrote:
 On 17/03/2015 10:31, Almighty Bob wrote:
 It's far more useful for csvReader to return a type I know 
 and
 can use than it is to obscure the return type for the sake 
 of
 some philosophical ideal of increasing encapsulation.

 Part of the art of API design is to hide implementation 
 where it's not necessarily needed. Designers might err on 
 the side of hiding things, because how you expose something 
 is important as it has to be maintained indefinitely. If 
 they expose everything then the internals can never be 
 redesigned for better performance, etc.

 They don't increase encapsulation. The public members of a 
 voldomort type are still public, you still have to code to 
 the API of the return type whether it's a regular or 
 voldomort type. You can keep as much private or public in 
 either case as you like.

 All they do take the typename out of circulation, they make 
 life harder for the user. There's no benefit. None.

 But at least the library author can stroke his chin a feel 
 smug that there's one less type in the modules' namespace.

 Totally missing the point. The crux of the matter is this: 
 changing a voldemort type (assuming the public semantics are 
 the same) is not a breaking API change, because no-one else's 
 code ever names it.

 Seriously? You cant have a public API and private 
 implementation with a regular type? That's something specific 
 to voldomort types?

 Ask yourself what exactly do voldomort types enable you to hide 
 that cant be hidden with a regular type? Just one thing. Their 
 name. As you said no one else can ever name the type.

 That is no benefit to me the user. No-one has been able to even 
 describe a benefit. Walters article on Dr Dobbs doesn't 
 describe a benefit. It "increases encapsulation" you all squawk.

 No it doesn't. The private bits are still private, the public 
 bits are still public.

 All it does is complicate the user side.

 Its the emperor's new clothes.

It's not possible to construct a voldemort type outside of the 
function where it was declared, and you can't know what that type 
is, just what the API is. You can force type deduction so the 
type returned can be changed without breaking code, so long as 
the API is the same. That's how it increases encapsulation.

"weaselcat" <weaselcat gmail.com> writes:

On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote:
 On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
 On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
 On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven 
 wrote:
 On 17/03/2015 10:31, Almighty Bob wrote:
 It's far more useful for csvReader to return a type I know 
 and
 can use than it is to obscure the return type for the sake 
 of
 some philosophical ideal of increasing encapsulation.

 Part of the art of API design is to hide implementation 
 where it's not necessarily needed. Designers might err on 
 the side of hiding things, because how you expose something 
 is important as it has to be maintained indefinitely. If 
 they expose everything then the internals can never be 
 redesigned for better performance, etc.

 They don't increase encapsulation. The public members of a 
 voldomort type are still public, you still have to code to 
 the API of the return type whether it's a regular or 
 voldomort type. You can keep as much private or public in 
 either case as you like.

 All they do take the typename out of circulation, they make 
 life harder for the user. There's no benefit. None.

 But at least the library author can stroke his chin a feel 
 smug that there's one less type in the modules' namespace.

 Totally missing the point. The crux of the matter is this: 
 changing a voldemort type (assuming the public semantics are 
 the same) is not a breaking API change, because no-one else's 
 code ever names it.

 Seriously? You cant have a public API and private 
 implementation with a regular type? That's something specific 
 to voldomort types?

 Ask yourself what exactly do voldomort types enable you to 
 hide that cant be hidden with a regular type? Just one thing. 
 Their name. As you said no one else can ever name the type.

 That is no benefit to me the user. No-one has been able to 
 even describe a benefit. Walters article on Dr Dobbs doesn't 
 describe a benefit. It "increases encapsulation" you all 
 squawk.

 No it doesn't. The private bits are still private, the public 
 bits are still public.

 All it does is complicate the user side.

 Its the emperor's new clothes.

 It's not possible to construct a voldemort type outside of the 
 function where it was declared, and you can't know what that 
 type is, just what the API is. You can force type deduction so 
 the type returned can be changed without breaking code, so long 
 as the API is the same. That's how it increases encapsulation.

voldemort types sort of feel like a hack to work around the lack 
of real compile-time interfaces(concepts,) the same thing IMO 
currently plaguing template constraints and honestly causes a lot 
of compiler errors to be confusing.

I believe a few major patches in phobos were related to removing 
constraints and rewriting them as static asserts for better error 
handling.

see:

http://forum.dlang.org/thread/jronroxajqkrqitxwzlj forum.dlang.org

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/19/15 4:29 PM, weaselcat wrote:
 voldemort types sort of feel like a hack to work around the lack of real
 compile-time interfaces(concepts,)

No, they're largely unrelated. -- Andrei

"Almighty Bob" <bob almighty.com> writes:

On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote:
 No it doesn't. The private bits are still private, the public 
 bits are still public.

 All it does is complicate the user side.

 Its the emperor's new clothes.

 It's not possible to construct a voldemort type outside of the 
 function where it was declared, and you can't know what that 
 type is, just what the API is. You can force type deduction so 
 the type returned can be changed without breaking code, so long 
 as the API is the same. That's how it increases encapsulation.

Ok I can see the benefit of having a return type that can only be 
constructed by the function returning it. ***In some cases***

But being able to change the return type doesnt actualy increase 
encapsulation. you still have to return something with the same 
public API. Only now you have ***less*** guarantees over what 
your getting than you did before. Could be an array could be a 
linked list. Who knows?

Maybe I'm a bit long in the tooth but for something like 
cvsReader I want an array of records, there's isnt anything else 
that would ever make any sense. So the idea that I now how to 
jump through hoops to keep hold of whatever that function 
returns, just in case some divvy might want change what kind of 
structure it returns one day, is frankly absurd.

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Friday, 20 March 2015 at 00:28:24 UTC, Almighty Bob wrote:
 Maybe I'm a bit long in the tooth but for something like 
 cvsReader I want an array of records, there's isnt anything 
 else that would ever make any sense.

Just use std.array.array on it. You get your array, people who 
see the benefit of alternative approaches get what they want.

"deadalnix" <deadalnix gmail.com> writes:

On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
 Its the emperor's new clothes.

Type inference is useful. Deal with it.

"Almighty Bob" <bob almighty.com> writes:

On Friday, 20 March 2015 at 00:30:25 UTC, deadalnix wrote:
 On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
 Its the emperor's new clothes.

 Type inference is useful. Deal with it.

I like type inference.

I dont like voldomort types, the cost/benefit is fail.

"Atila Neves" <atila.neves gmail.com> writes:

On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 09:25:57 UTC, Panke wrote:
 How do you keep it around if you cant declare a member to 
 hold it?

 It's all well and good explaining the reason for them but it 
 doesnt void the fact that they are a PITA if you say want to 
 use cvsReader to parse some records and keep the results as a 
 class member.

 I don't think csvReader supports your point. The input range 
 returned is not for permanent storage,

 How do you know it's not meant for permanent storage? The docs
 dont say that. Is that a typical idiom with returned ranges?

 And what's the point of an all singing and dancing API if it
 imposes pointless restrictions on the user for the sake of some
 questionable benefit for the library writer?

 It's far more useful for csvReader to return a type I know and
 can use than it is to obscure the return type for the sake of
 some philosophical ideal of increasing encapsulation.

 In short, for the user, Voldomort types have no benefit and only
 cost.

This discussion happens often when discussing C++'s or D's 
`auto`. It doesn't matter what the type is, what matters is in 
the interface.

As for storing it:

auto foo = voldemort();

Oh, you meant in a struct?

struct Foo(T) {
    T thingie;
}

auto foo(T)(T thingie) {
     return Foo!T(thingie);
}

auto f = foo(voldemort());

Atila

"Almighty Bob" <bob almighty.com> writes:

On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
 On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:

 This discussion happens often when discussing C++'s or D's 
 `auto`. It doesn't matter what the type is, what matters is in 
 the interface.

 As for storing it:

 auto foo = voldemort();

 Oh, you meant in a struct?

 struct Foo(T) {
    T thingie;
 }

 auto foo(T)(T thingie) {
     return Foo!T(thingie);
 }

 auto f = foo(voldemort());

 Atila

That proves my point cost for the user just so the library 
designer can group his type inside the function that returns it.

How many times is csvReader used vs how many times is it written. 
It it's 100 to 1, that's 100 times the cost to the user vs 1 x 
the cost to the library author.

I cant help thinking it's like how when programmers first learn 
about design patterns they start trying to make everything they 
can into a ****ing singleton.

"amber" <swamberan gmail.com> writes:

On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
 On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:

 This discussion happens often when discussing C++'s or D's 
 `auto`. It doesn't matter what the type is, what matters is in 
 the interface.

 As for storing it:

 auto foo = voldemort();

 Oh, you meant in a struct?

 struct Foo(T) {
   T thingie;
 }

 auto foo(T)(T thingie) {
    return Foo!T(thingie);
 }

 auto f = foo(voldemort());

 Atila

 That proves my point cost for the user just so the library 
 designer can group his type inside the function that returns it.

 How many times is csvReader used vs how many times is it 
 written. It it's 100 to 1, that's 100 times the cost to the 
 user vs 1 x the cost to the library author.

 I cant help thinking it's like how when programmers first learn 
 about design patterns they start trying to make everything they 
 can into a ****ing singleton.

I have on a number of occasions wanted this:

struct S {
     Iota r; // ?? Would be nice, can it be done ??
}

if(something) {
     s.r = iota(10);
} else {
     s.r = iota(0, 10, 2);
}


As a new D user and relatively new to programming I've tried 
really hard to find a way to do this and given up. If it's 
possible I'd love to know!!

I did try the template approach with "function return type part 
of my struct type" route but it a) made my code very messy with 
templates everywhere even where I didn't want them and b) the 
compiler memory usage blew out to over 4Gb with 2.067 and I could 
not compile my project.

I had to take it all out again and in the end implemented my own 
iota with my original approach (as above). I'm not doing that 
again.


bye,
amber

"amber" <swamberan gmail.com> writes:

On Tuesday, 17 March 2015 at 22:58:42 UTC, amber wrote:
 I had to take it all out again and in the end implemented my 
 own iota with my original approach (as above). I'm not doing 
 that again.


 bye,
 amber


On a side note, to implement iota I copied it from Phobos with 
minor changes. I was really surprised at how clean and easy to 
understand the code was.

I'm now perusing Phobos code and in 30mins I've picked up some 
great D tricks for a novice :)

bye,
amber

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/17/15 3:58 PM, amber wrote:
 On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
 On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob wrote:

 This discussion happens often when discussing C++'s or D's `auto`. It
 doesn't matter what the type is, what matters is in the interface.

 As for storing it:

 auto foo = voldemort();

 Oh, you meant in a struct?

 struct Foo(T) {
   T thingie;
 }

 auto foo(T)(T thingie) {
    return Foo!T(thingie);
 }

 auto f = foo(voldemort());

 Atila

 That proves my point cost for the user just so the library designer
 can group his type inside the function that returns it.

 How many times is csvReader used vs how many times is it written. It
 it's 100 to 1, that's 100 times the cost to the user vs 1 x the cost
 to the library author.

 I cant help thinking it's like how when programmers first learn about
 design patterns they start trying to make everything they can into a
 ****ing singleton.

 I have on a number of occasions wanted this:

 struct S {
      Iota r; // ?? Would be nice, can it be done ??
 }

 if(something) {
      s.r = iota(10);
 } else {
      s.r = iota(0, 10, 2);
 }

import std.range;

void main()
{
     struct S {
         typeof(iota(0, 1, 1)) r;
     }

     S s;

     if(1) {
         s.r = iota(0, 10, 1);
     } else {
         s.r = iota(0, 10, 2);
     }
}

Also: there's a learn forum.


Andrei

"amber" <swamberan gmail.com> writes:

On Wednesday, 18 March 2015 at 00:04:26 UTC, Andrei Alexandrescu 
wrote:
 On 3/17/15 3:58 PM, amber wrote:
 On Tuesday, 17 March 2015 at 18:32:10 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 12:52:01 UTC, Atila Neves wrote:
 On Tuesday, 17 March 2015 at 10:31:06 UTC, Almighty Bob 
 wrote:

 This discussion happens often when discussing C++'s or D's 
 `auto`. It
 doesn't matter what the type is, what matters is in the 
 interface.

 As for storing it:

 auto foo = voldemort();

 Oh, you meant in a struct?

 struct Foo(T) {
  T thingie;
 }

 auto foo(T)(T thingie) {
   return Foo!T(thingie);
 }

 auto f = foo(voldemort());

 Atila

 That proves my point cost for the user just so the library 
 designer
 can group his type inside the function that returns it.

 How many times is csvReader used vs how many times is it 
 written. It
 it's 100 to 1, that's 100 times the cost to the user vs 1 x 
 the cost
 to the library author.

 I cant help thinking it's like how when programmers first 
 learn about
 design patterns they start trying to make everything they can 
 into a
 ****ing singleton.

 I have on a number of occasions wanted this:

 struct S {
     Iota r; // ?? Would be nice, can it be done ??
 }

 if(something) {
     s.r = iota(10);
 } else {
     s.r = iota(0, 10, 2);
 }

 import std.range;

 void main()
 {
     struct S {
         typeof(iota(0, 1, 1)) r;
     }

     S s;

     if(1) {
         s.r = iota(0, 10, 1);
     } else {
         s.r = iota(0, 10, 2);
     }
 }

 Also: there's a learn forum.


 Andrei

Thank you!

I'll move onto D.learn :-)

bye,
amber

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Tuesday, 17 March 2015 at 08:46:52 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 07:15:17 UTC, Walter Bright wrote:
 On 3/16/2015 4:29 AM, ninja wrote:
 This. Figuring out the return types in the examples was a 
 daily struggle in the
 first few weeks.

 When Voldemort types are returned, they must be by auto. The 
 user isn't supposed to know what the return type is, just how 
 to use it.

 How do you keep it around if you cant declare a member to hold 
 it?

 It's all well and good explaining the reason for them but it 
 doesnt void the fact that they are a PITA if you say want to 
 use cvsReader to parse some records and keep the results as a 
 class member.

typeof still works for voldemort types. The point isn't "You 
can't declare variables with a voldemort type" it's the subtly 
different "You can't declare variables with an *specific* 
voldemort type".

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Tuesday, 17 March 2015 at 11:39:04 UTC, John Colvin wrote:
 On Tuesday, 17 March 2015 at 08:46:52 UTC, Almighty Bob wrote:
 On Tuesday, 17 March 2015 at 07:15:17 UTC, Walter Bright wrote:
 On 3/16/2015 4:29 AM, ninja wrote:
 This. Figuring out the return types in the examples was a 
 daily struggle in the
 first few weeks.

 When Voldemort types are returned, they must be by auto. The 
 user isn't supposed to know what the return type is, just how 
 to use it.

 How do you keep it around if you cant declare a member to hold 
 it?

 It's all well and good explaining the reason for them but it 
 doesnt void the fact that they are a PITA if you say want to 
 use cvsReader to parse some records and keep the results as a 
 class member.

 typeof still works for voldemort types. The point isn't "You 
 can't declare variables with a voldemort type" it's the subtly 
 different "You can't declare variables with an *specific* 
 voldemort type".

s/ an / a /

Jacob Carlborg <doob me.com> writes:

On 2015-03-17 08:15, Walter Bright wrote:

 When Voldemort types are returned, they must be by auto. The user isn't
 supposed to know what the return type is, just how to use it.

I still don't like that there's no good way to describe the API. It's 
not possible to put a name (that can be used in code, or reference in 
the documentation) on an API like this. Something like this would be nice:

constraint InputRange (E)
{
     E front();
     void popFront();
     bool empty();
}

InputRange!(int) result = [1, 2, 3, 4].map(e => e * 2);

-- 
/Jacob Carlborg

"Sebastiaan Koppe" <mail skoppe.eu> writes:

On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
 One day, the tide may turn towards native efficiency again, say 
 because of mobile or more people writing code that runs on 
 large server clusters, and D will be well-positioned to benefit 
 if and when that happens.

I hear ya, we have a NodeJS app running that easily eats 100mb of 
memory. Every week it grows to 200mb and we have a process 
manager restart it gracefully (which takes another 50mb). Compare 
that with a vibe.d app we have: 7mb. And it has been running for 
over 260 days.

"Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:

On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
 On Monday, 16 March 2015 at 08:33:43 UTC, Zach the Mystic wrote:
 I see D attracting *really* good programmers, programmers 
 from, let's say the 90-95th percentile in skill and talent in 
 their field on average. By marketing to these programmers 
 specifically -- that is, telling everyone that while D is for 
 everyone, it is especially designed to give talented and 
 experienced programmers the tools they need to get their work 
 done -- even if you repel several programmers from, say, the 
 45th percentile or below in exchange for the brand loyalty of 
 one from 92nd percentile or above, it's probably a winning 
 strategy, because that one good programmer will get more done 
 than all the rest combined.


Isn't that implicitly what D is (and it is a compliment that you 
do a good job of unfolding it).  I agree with the economic 
understanding, and with the strategy.
 Yep, this is what I meant by my Blackberry analogy earlier in 
 this thread.  Blackberry used to own the smartphone market, 
 when it was limited to professionals who emailed and texted a 
 lot.  When the market broadened to include everyone, they 
 decided to go the popular route and sell touch-screen phones 
 without physical keyboards like everyone else.  It was a 
 disaster, from which they're only recently recovering by 
 offering physical keyboards again.  I'm not saying it _had_ to 
 fail, only that RIM clearly didn't have what it took to succeed 
 there.

 Similarly, D's never going to do very well with programmers who 
 don't care about the efficiency of their code: simpler, slower 
 languages like python or ruby have that niche sewn up.  The 
 best we can do is point out that if you're already here for the 
 advanced features, it can also be used for scripting and the 
 like.  And of course, we should always strive to make things as 
 easy as we can for both small and large projects, including 
 better documentation.

 One day, the tide may turn towards native efficiency again, say 
 because of mobile or more people writing code that runs on 
 large server clusters, and D will be well-positioned to benefit 
 if and when that happens.

The future is here already, but just not evenly distributed 
(Gibson).  It hit Andrei's employer early, but I am not sure 
Facebook is an edge case of no relevance to mortals.

http://www.extremetech.com/computing/165331-intels-former-chief-architect-moores-law-will-be-dead-within-a-decade

Data sets are exploding in size but the marginal dollar value 
commercially of every byte is collapsing
whilst the free lunch from Moore's Law is over.  That means you 
have to use a JIT or native code, and the latter is not going to 
be C++, Go, or Rust for uses within the enterprise that require 
rapid prototyping and iteration to help answer dynamic commercial 
questions.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Monday, 16 March 2015 at 13:16:33 UTC, Laeeth Isharc wrote:
 On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
 On Monday, 16 March 2015 at 08:33:43 UTC, Zach the Mystic 
 wrote:
 I see D attracting *really* good programmers, programmers 
 from, let's say the 90-95th percentile in skill and talent in 
 their field on average. By marketing to these programmers 
 specifically -- that is, telling everyone that while D is for 
 everyone, it is especially designed to give talented and 
 experienced programmers the tools they need to get their work 
 done -- even if you repel several programmers from, say, the 
 45th percentile or below in exchange for the brand loyalty of 
 one from 92nd percentile or above, it's probably a winning 
 strategy, because that one good programmer will get more done 
 than all the rest combined.


 Isn't that implicitly what D is (and it is a compliment that 
 you do a good job of unfolding it).  I agree with the economic 
 understanding, and with the strategy.
 Yep, this is what I meant by my Blackberry analogy earlier in 
 this thread.  Blackberry used to own the smartphone market, 
 when it was limited to professionals who emailed and texted a 
 lot.  When the market broadened to include everyone, they 
 decided to go the popular route and sell touch-screen phones 
 without physical keyboards like everyone else.  It was a 
 disaster, from which they're only recently recovering by 
 offering physical keyboards again.  I'm not saying it _had_ to 
 fail, only that RIM clearly didn't have what it took to 
 succeed there.

 Similarly, D's never going to do very well with programmers 
 who don't care about the efficiency of their code: simpler, 
 slower languages like python or ruby have that niche sewn up.  
 The best we can do is point out that if you're already here 
 for the advanced features, it can also be used for scripting 
 and the like.  And of course, we should always strive to make 
 things as easy as we can for both small and large projects, 
 including better documentation.

 One day, the tide may turn towards native efficiency again, 
 say because of mobile or more people writing code that runs on 
 large server clusters, and D will be well-positioned to 
 benefit if and when that happens.

 The future is here already, but just not evenly distributed 
 (Gibson).  It hit Andrei's employer early, but I am not sure 
 Facebook is an edge case of no relevance to mortals.

 http://www.extremetech.com/computing/165331-intels-former-chief-architect-moores-law-will-be-dead-within-a-decade

 Data sets are exploding in size but the marginal dollar value 
 commercially of every byte is collapsing
 whilst the free lunch from Moore's Law is over.  That means you 
 have to use a JIT or native code, and the latter is not going 
 to be C++, Go, or Rust for uses within the enterprise that 
 require rapid prototyping and iteration to help answer dynamic 
 commercial questions.

Hence why both Java and .NET are getting full AOT compilation to 
native code on their canonical toolchains in Java 9/10 and .NET 
4.6.

--
Paulo

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Monday, 16 March 2015 at 13:16:33 UTC, Laeeth Isharc wrote:
 The future is here already, but just not evenly distributed 
 (Gibson).  It hit Andrei's employer early, but I am not sure 
 Facebook is an edge case of no relevance to mortals.

Facebook is an edge case. Most computers run idle >90% of the 
time... If you need to complete something fast (but not low 
latency real time) you can do it in parallel paying by the hour, 
cheaper and more hassle free than ever before.

 whilst the free lunch from Moore's Law is over.

Not so sure about Moore's Law, keep in mind that Intel has very 
little pressure from AMD these days.

But faster/bigger things are out there:

http://en.wikipedia.org/wiki/Neurogrid
http://en.wikipedia.org/wiki/Memristor
http://en.wikipedia.org/wiki/Field-programmable_gate_array

But these kinds of technologies are more expensive to develop for.

 That means you have to use a JIT or native code, and the latter 
 is not going to be C++, Go, or Rust for uses within the 
 enterprise that require rapid prototyping and iteration to help 
 answer dynamic commercial questions.

Not very specific, so hard to address, but factor in the 
increased development cost and you might see that it becomes 
cheaper to run it on a rented cluster using dedicated tools even 
if the code is running at half speed.

Average programmers are less and less capable of writing fast 
code... and the work it takes to write fast code is expensive. 
Not many are willing to pay for it, so in most cases it is 
cheaper to buy/rent better tools/hardware. But that's only 
because hardware is cheap compared to programmer time in most 
cases! If hardware was expensive then more people would be 
willing to pay for hand optimised programming?

"Joakim" <dlang joakim.fea.st> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 A friend of mine needed to complete a small project and thought 
 of using a language he didn't know for it. He already knew I 
 work on D so he considered it alongside Go. He ended up 
 choosing the latter, and documented his decision making process 
 in a few notes that he subsequently shared with me. I'll paste 
 below a sort of transcript of his handwritten notes.

 I think this is valuable information from a relatively unbiased 
 potential user, and good ideas and action items on how we can 
 improve our curb appeal. Even mistaken perceptions are good 
 signal - it means our materials weren't explicit enough to 
 dispel them.

 ====================

 * Golang: simple!

 + very small language, very concise & simple
 + playground/tutorial
 + easy to start using it, no-nonsense
 + vast libraries
 + no inheritance
 + one binary to distribute
 + good for servers
 + feels like a better C (mostly)
 - can't write generic code involving arrays/slices
 - no good IDE
 + Google!
 + clear feeling it's here to stay
 + visible, many projects
 + enforced style (indentation, exports)

 * Dlang: big!










 it's open" sign but sits emtpy; by comparison Go -> condo in 
 hip, trendy area

When you said "curb appeal," I was prepared to read how a cursory 
look at both websites turned him off on D and on to Go.  But none 
of these qualities can be determined so easily, you have to look 
around for a while to know that D is bigger and Go is considered 
"hip, trendy" compared to a supposedly "unpopulated" D.

Comparing the front pages of the respective language websites, 
dlang.org does a good job of actually introducing the language, 
while golang.org simply says "Go is an open source programming 
language that makes it easy to build simple, reliable, and 
efficient software."  That's it.  You have to click a couple 
times to actually get to the Go tour or manual and find out what 
Go is: there's no pitch to sell you the language first.

The recent dlang.org redesign seems to have done a good job of 
simplifying the front page, including the addition of the 
previously unavailable "Getting Started" option.  Of course, the 
front page of dlang.org is not as spare and pretty as golang.org, 
will still take a designer to spiff it up a bit.

As to his actual points, it seems to come down to D replaces C++, 
while Go replaces C.  If you're looking for a better C, the more 
advanced, C++-esque features of D might distract and confuse you, 
even though you can ignore those and use it that way.

As for "will it be around?," presumably he thinks Go will stick 
around because of Google.  That cuts both ways, because if Google 
stops funding, maybe Pike and the other main devs abandon it, 
while D seemingly has never had anyone sponsoring Walter, so 
there's nobody holding the funding spigot here.

Not sure why he thinks D isn't good for servers, as that's what 
its key corporate backers all use it for.  I don't deny that some 
of these perceptions exist, not sure how being considered "hip, 
trendy" is combated other than by having more success.

 * Ideas for D






Good suggestion for the front page, perhaps a library of the 
month?


 once



Where is D advertised as being special or different with its 
ideas on networking?  I don't see it.





That's not D's approach, for better or worse.  It's offering a 
buffet of features, not just a great steak.



I agree that D's use in small programs and scripting could be 
better emphasized.  In trying to attract the C++ crowd, this 
orthogonal audience is sometimes ignored.



The D Wiki lists supported IDEs, maybe the "Getting Started" page 
should directly link there.





React is a UI framework, easy to state its purpose.  Go has 
essentially nothing on their front page, while Rust just has a 
feature list.  Java is the only one that talks about rationale 
and purpose:

https://www.java.com/en/about/


 every programming language design challenge there is, but less 
 focused on purpose (Andrei's note: I assume D more at fault 
 than C++ on this)

I agree that dlang.org could go a bit more into purpose, other 
than the single mention of "simple scripts to large projects" on 
the front page.  I can see how it's tough to articulate how 
widely D could be used though.

 General feeling: "I don't feel smart enough for D and am 
 looking for a quick way to accomplish a goal. I've read the 
 Wikipedia article on D and didn't understand a few things. The 
 examples seem to show off the language but that made them 
 confusing. I wanted to get more into it, but by that time Go 
 had already won - I looked at the tutorials, changed the sample 
 code a bit right in the browser to see how it'd work for me, it 
 was easy, I was in already. Some of my comments therefore 
 illustrate my shortcomings than the language's, but that's true 
 one way or another for all programmers (that's why technical 
 superiority of a language doesn't guarantee its success)."

On the one hand, yes, D beats you over the head with all its 
great advanced features.  On the other hand, a language like D, 
that wants to give you all the tools for your toolbelt, requires 
a programmer that is capable of knowing what each tool is and how 
to use it.  It's very tough to advertise it as a BMW, ie a 
driver's car, and then say, "oh yeah, you soccer dads will love 
it too."  Blackberry is dying for a reason.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/12/2015 8:40 PM, Joakim wrote:
 As for "will it be around?," presumably he thinks Go will stick around because
 of Google.  That cuts both ways, because if Google stops funding, maybe Pike
and
 the other main devs abandon it, while D seemingly has never had anyone
 sponsoring Walter, so there's nobody holding the funding spigot here.

Google does abandon significant projects now and then, such as this one:

http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

"Dicebot" <public dicebot.lv> writes:

On Friday, 13 March 2015 at 04:49:38 UTC, Walter Bright wrote:
 On 3/12/2015 8:40 PM, Joakim wrote:
 As for "will it be around?," presumably he thinks Go will 
 stick around because
 of Google.  That cuts both ways, because if Google stops 
 funding, maybe Pike and
 the other main devs abandon it, while D seemingly has never 
 had anyone
 sponsoring Walter, so there's nobody holding the funding 
 spigot here.

 Google does abandon significant projects now and then, such as 
 this one:

 http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

"Google Graveyard" is awesome 
http://www.slate.com/articles/technology/map_of_the_week/2013/03/google_reader_joins_graveyard_of_dead_
oogle_products.html 
:)

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Thu, 2015-03-12 at 21:49 -0700, Walter Bright via Digitalmars-d
wrote:
 On 3/12/2015 8:40 PM, Joakim wrote:
 As for "will it be around?," presumably he thinks Go will stick around because
 of Google.  That cuts both ways, because if Google stops funding, maybe Pike
and
 the other main devs abandon it, while D seemingly has never had anyone
 sponsoring Walter, so there's nobody holding the funding spigot here.


It is already clear that if Google stopped funding Go tomorrow and
re-assigned the entire current Go development team, and forbade them to
even talk about Go, the project ownership would be passed on, and it
would become just like any other language FOSS project.

Currently though, despite the core teams protestations to the contrary,
Go is definitely a Google project, owned by them lock stock and barrel.

 Google does abandon significant projects now and then, such as this one:
 
 http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

This needed to go, like many other CVCS project hosting systems it
failed to evolve with the move to DVCS for FOSS. Sourceforge is at least
trying to move with the times.
 
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Steve Wood" <emadera52 hotmail.com> writes:

On Friday, 13 March 2015 at 04:49:38 UTC, Walter Bright wrote:

 Google does abandon significant projects now and then, such as 
 this one:

 http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

In fairness pretty much everything that was on google-code has 
moved, mostly to GitHub. E.g. for Go stuff see 
https://github.com/golang

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Wednesday, 18 March 2015 at 18:40:41 UTC, Steve Wood wrote:
 On Friday, 13 March 2015 at 04:49:38 UTC, Walter Bright wrote:

 Google does abandon significant projects now and then, such as 
 this one:

 http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

 In fairness pretty much everything that was on google-code has 
 moved, mostly to GitHub. E.g. for Go stuff see 
 https://github.com/golang

https://cloud.google.com/tools/repo/source-tools

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Thu, 2015-03-12 at 17:20 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]
 - no good IDE

Not entirely true, there are Emacs, VIM, LiteIDE, and others for Go
development.


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"JN" <666total wp.pl> writes:

On Friday, 13 March 2015 at 06:58:59 UTC, Russel Winder wrote:
 On Thu, 2015-03-12 at 17:20 -0700, Andrei Alexandrescu via 
 Digitalmars-d
 wrote:
 […]
 - no good IDE

 Not entirely true, there are Emacs, VIM, LiteIDE, and others 
 for Go
 development.

Never heard of LiteIDE, but Emacs and VIM aren't really IDEs,
they are just glorified text editors. When people say IDE, they
not only mean the text editing part, but the management of the
build process and visual debugging, including watches,
breakpoints, step-by-step debugging etc.

"Wyatt" <wyatt.epp gmail.com> writes:

On Friday, 13 March 2015 at 08:53:16 UTC, JN wrote:
 Never heard of LiteIDE, but Emacs and VIM aren't really IDEs,
 they are just glorified text editors. When people say IDE, they
 not only mean the text editing part, but the management of the
 build process and visual debugging, including watches,
 breakpoints, step-by-step debugging etc.

"Unix is my IDE" is a meme for a reason.  I have all that stuff 
in my shell and more.  But you're kind of missing the point to 
fixate on that anyway.

-Wyatt

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 13:42:31 UTC, Wyatt wrote:
 On Friday, 13 March 2015 at 08:53:16 UTC, JN wrote:
 Never heard of LiteIDE, but Emacs and VIM aren't really IDEs,
 they are just glorified text editors. When people say IDE, they
 not only mean the text editing part, but the management of the
 build process and visual debugging, including watches,
 breakpoints, step-by-step debugging etc.

 "Unix is my IDE" is a meme for a reason.  I have all that stuff 
 in my shell and more.  But you're kind of missing the point to 
 fixate on that anyway.

 -Wyatt

To be fair, he's sort of right on the debugging thing. I could 
never stand using GDB.

"Wyatt" <wyatt.epp gmail.com> writes:

On Friday, 13 March 2015 at 13:47:28 UTC, weaselcat wrote:
 To be fair, he's sort of right on the debugging thing. I could 
 never stand using GDB.

That's certainly true; debug situation has been playing catch up 
and it's not "there" yet.  The base GDB experience is straight up 
bad and, while CGDB already makes it worlds better (and has some 
exciting stuff coming), it's not as good as Visual Studio.  (Big 
shoutout to LLVM/Clang/LLDB for giving the GNU folk a kick in the 
pants to up their game.)

-Wyatt

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 13 March 2015 at 13:42:31 UTC, Wyatt wrote:
 On Friday, 13 March 2015 at 08:53:16 UTC, JN wrote:
 Never heard of LiteIDE, but Emacs and VIM aren't really IDEs,
 they are just glorified text editors. When people say IDE, they
 not only mean the text editing part, but the management of the
 build process and visual debugging, including watches,
 breakpoints, step-by-step debugging etc.

 "Unix is my IDE" is a meme for a reason.  I have all that stuff 
 in my shell and more.  But you're kind of missing the point to 
 fixate on that anyway.

 -Wyatt

How do you do semantic refactoring in UNIX shell?

--
Paulo

"Wyatt" <wyatt.epp gmail.com> writes:

On Friday, 13 March 2015 at 13:51:05 UTC, Paulo  Pinto wrote:
 How do you do semantic refactoring in UNIX shell?

With tools.  (Can you be less abstract?  "Semantic refactoring" 
could be all sorts of things-- it's not a well-defined term of 
art, so I have no idea what you're really trying to accomplish.)

-Wyatt

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 13 March 2015 at 14:34:30 UTC, Wyatt wrote:
 On Friday, 13 March 2015 at 13:51:05 UTC, Paulo  Pinto wrote:
 How do you do semantic refactoring in UNIX shell?

 With tools.  (Can you be less abstract?  "Semantic refactoring" 
 could be all sorts of things-- it's not a well-defined term of 
 art, so I have no idea what you're really trying to accomplish.)

 -Wyatt

For example, rename an instance variable, while updating all its 
occurrences, including comments. While keeping all other symbols 
that happen to use the same name untouched.

Move a method to another class, keeping all references to 
imported libraries on the new location.

These are just the tip of the iceberg of what modern refactoring 
tools offer.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 1:53 AM, JN wrote:
 On Friday, 13 March 2015 at 06:58:59 UTC, Russel Winder wrote:
 On Thu, 2015-03-12 at 17:20 -0700, Andrei Alexandrescu via Digitalmars-d
 wrote:
 […]
 - no good IDE

 Not entirely true, there are Emacs, VIM, LiteIDE, and others for Go
 development.

 Never heard of LiteIDE, but Emacs and VIM aren't really IDEs,
 they are just glorified text editors. When people say IDE, they
 not only mean the text editing part, but the management of the
 build process and visual debugging, including watches,
 breakpoints, step-by-step debugging etc.

I've tried a couple of IDEs with D in Ubuntu. Geany crashed whenever I 
started a debug session, but that happens with C++ as well and is a bug 
in Geany (http://sourceforge.net/p/geany-plugins/bugs/119/).

Then I tried Code::Blocks and the debug experience has been almost 
shockingly good. I had no idea! Then I found indeed a wiki page 
describing the features: http://wiki.dlang.org/CodeBlocks. It is easy to 
find via google by searching e.g. for ``ides for dlang''. But there is 
no obvious way to get there from dlang.org. I think we should feature 
the IDEs page more prominently.


Andrei

"ezneh" <petitv.isat gmail.com> writes:

On Friday, 13 March 2015 at 14:48:11 UTC, Andrei Alexandrescu 
wrote:
 On 3/13/15 1:53 AM, JN wrote:

 Then I tried Code::Blocks and the debug experience has been 
 almost shockingly good. I had no idea! Then I found indeed a 
 wiki page describing the features: 
 http://wiki.dlang.org/CodeBlocks. It is easy to find via google 
 by searching e.g. for ``ides for dlang''. But there is no 
 obvious way to get there from dlang.org. I think we should 
 feature the IDEs page more prominently.


 Andrei

There is a dead link on the CodeBlocks page, at the bottom of it :
http://j.imagehost.org/0768/codeblocks.jpg -> Should be replaced.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 11:40 AM, ezneh wrote:
 On Friday, 13 March 2015 at 14:48:11 UTC, Andrei Alexandrescu wrote:
 On 3/13/15 1:53 AM, JN wrote:

 Then I tried Code::Blocks and the debug experience has been almost
 shockingly good. I had no idea! Then I found indeed a wiki page
 describing the features: http://wiki.dlang.org/CodeBlocks. It is easy
 to find via google by searching e.g. for ``ides for dlang''. But there
 is no obvious way to get there from dlang.org. I think we should
 feature the IDEs page more prominently.


 Andrei

 There is a dead link on the CodeBlocks page, at the bottom of it :
 http://j.imagehost.org/0768/codeblocks.jpg -> Should be replaced.

Thanks for pointing that out. I've beat off all other eager volunteers 
with a stick, went to archive.org, retrieved the image, uploaded it to 
imgur, and linked it from the wiki.

http://wiki.dlang.org/CodeBlocks#Screenshot


Andrei

"Atila Neves" <atila.neves gmail.com> writes:

I suspect most of the reason these IDE vs editor debates even 
happen is because the editors by default don't do what IDEs do, 
but can. All you've mentioned is possible in Emacs and has been 
for basically forever.

Atila

On Friday, 13 March 2015 at 08:53:16 UTC, JN wrote:
 On Friday, 13 March 2015 at 06:58:59 UTC, Russel Winder wrote:
 On Thu, 2015-03-12 at 17:20 -0700, Andrei Alexandrescu via 
 Digitalmars-d
 wrote:
 […]
 - no good IDE

 Not entirely true, there are Emacs, VIM, LiteIDE, and others 
 for Go
 development.

 Never heard of LiteIDE, but Emacs and VIM aren't really IDEs,
 they are just glorified text editors. When people say IDE, they
 not only mean the text editing part, but the management of the
 build process and visual debugging, including watches,
 breakpoints, step-by-step debugging etc.

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:



+1

 once






-1
 General feeling: "I don't feel smart enough for D and am 
 looking for a quick way to accomplish a goal.

+1

 safe by default would be a great change(and IMHO, immutable by 
default. But I highly doubt that would ever get through.)

I don't think the single idea part is a good suggestion. There's 
nothing wrong with a language featuring multiple 
paradigms/focusing on multiple areas as long as they're all well 
implemented(and D does this reasonably well!)

But I do agree with the "I don't feel smart enough for D." I 
really don't know how to fix this, maybe it's just a symptom of 
the above - I don't really feel smart enough for C++ and I've 
been using it for years : )

Getting prominent D projects more recognition should be a really 
high priority.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 1:17 AM, weaselcat wrote:
 Getting prominent D projects more recognition should be a really high
 priority.

Yah, my friend for example hadn't heard about vibe.d until I mentioned 
it. After looking over it he was like, "yeah, I could've used that". -- 
Andrei

"Gary Willoughby" <dev nomad.so> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:


On Friday, 13 March 2015 at 03:24:44 UTC, Walter Bright wrote:
 There's no doubt about it, people like simple languages. We 
 should very much keep that in mind when evaluating proposals 
 for new features.

This! I'm getting more and more disillusioned with D purely 
because of the constant feature creep. I just wish there was an 
actual goal for D2. When Rob Pike gets asked to add something 
(especially generics) he says "No, we're done.". This attitude 
breeds stability.

Keep all the other great ideas for D3 goals.

I've being using Go more and more and while it does have its 
shortcoming and is not as advanced as D (or as fast), it's easily 
understandable and gets stuff done. The built-in tools that ship 
with Go are particularly awesome.

"ponce" <contact gam3sfrommars.fr> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 * Golang: simple!
 + clear feeling it's here to stay

 * Dlang: big!



In my view, Go and Rust look more riskier, it would suffice of a 
high executive changing her mind for such projects to be stopped. 
They might be successful but to survive in corporations projects 
have to be successful enough.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 A friend of mine needed to complete a small project and thought 
 of using a language he didn't know for it. He already knew I 
 work on D so he considered it alongside Go. He ended up 
 choosing the latter, and documented his decision making process 
 in a few notes that he subsequently shared with me. I'll paste 
 below a sort of transcript of his handwritten notes.

 I think this is valuable information from a relatively unbiased 
 potential user, and good ideas and action items on how we can 
 improve our curb appeal. Even mistaken perceptions are good 
 signal - it means our materials weren't explicit enough to 
 dispel them.

 ====================

 * Golang: simple!

 + very small language, very concise & simple
 + playground/tutorial
 + easy to start using it, no-nonsense
 + vast libraries
 + no inheritance
 + one binary to distribute
 + good for servers
 + feels like a better C (mostly)
 - can't write generic code involving arrays/slices
 - no good IDE
 + Google!
 + clear feeling it's here to stay
 + visible, many projects
 + enforced style (indentation, exports)

 * Dlang: big!










 it's open" sign but sits emtpy; by comparison Go -> condo in 
 hip, trendy area

 * Ideas for D






 once











 every programming language design challenge there is, but less 
 focused on purpose (Andrei's note: I assume D more at fault 
 than C++ on this)

 General feeling: "I don't feel smart enough for D and am 
 looking for a quick way to accomplish a goal. I've read the 
 Wikipedia article on D and didn't understand a few things. The 
 examples seem to show off the language but that made them 
 confusing. I wanted to get more into it, but by that time Go 
 had already won - I looked at the tutorials, changed the sample 
 code a bit right in the browser to see how it'd work for me, it 
 was easy, I was in already. Some of my comments therefore 
 illustrate my shortcomings than the language's, but that's true 
 one way or another for all programmers (that's why technical 
 superiority of a language doesn't guarantee its success)."

 ===============

 I'd love us to derive a few action items from this and other 
 feedback.


 Andrei

A kind of D killer project is also needed.

Thanks to a few successful startups like Docker, and consequent 
adoption of Docker by Amazon, Google and Microsoft on their 
infrastructure, Go is now a "nice to have" skill for anyone doing 
distributed computing.


--
Paulo

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 2:41 AM, Paulo Pinto wrote:
 A kind of D killer project is also needed.

That's why I am pushing for making vibe more visible. -- Andrei

"Kagamin" <spam here.lot> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 + Google!
 hip, trendy area

These determined the decision and are unbeatable yet.

"Chris" <wendlec tcd.ie> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 A friend of mine needed to complete a small project and thought 
 of using a language he didn't know for it. He already knew I 
 work on D so he considered it alongside Go. He ended up 
 choosing the latter, and documented his decision making process 
 in a few notes that he subsequently shared with me. I'll paste 
 below a sort of transcript of his handwritten notes.

 I think this is valuable information from a relatively unbiased 
 potential user, and good ideas and action items on how we can 
 improve our curb appeal. Even mistaken perceptions are good 
 signal - it means our materials weren't explicit enough to 
 dispel them.

 ====================

 * Golang: simple!

 + very small language, very concise & simple

D is also simple, if you want to do simple things. You can keep 
things simple, if you want. But it allows you to do complicated 
things whenever the occasion arises, yet it doesn't enforce 
"difficult" or "complicated" code. This is a point I have made 
several times and it is probably not made clear enough on the D 
website.

When I advise people to use D, they think they have to learn 
programming all over again and opt for Python or C only to 
program a f***ing number grinding for-loop. When they have to 
implement arrays, it's good-bye to C and hello to Python, 
although D would give them Python's convenience with C's 
efficiency.

We do something wrong here. The perception is D = "you have to be 
a programming Einstein". Not true. You don't have to, but it 
allows you to be one.

 + playground/tutorial

Maybe a simple VAT calculator instead of "Computes average line 
length for standard input" on the start page? Some everyday task 
like find string in string? Would be better, I think. How do I 
find "ab" in "abc". std.string? std.regex? std.algorithm? These 
things are not clear at all, but this is what users usually need 
first. They don't need templates, they need "startsWith" kinda 
stuff.

 + easy to start using it, no-nonsense

Same goes for D. But we have failed to communicate this to people.

 + vast libraries

Yep. D is not great for this, unless you know the community and 
D's C(++)-interoptability.

 + no inheritance

 From C? C++?

 + one binary to distribute

This goes for D as well.

 + good for servers

Doable with D (vibe.d), but not part and parcel of the language, 
although important.

 + feels like a better C (mostly)
 - can't write generic code involving arrays/slices
 - no good IDE

 + Google!

Well, what can I say?

 + clear feeling it's here to stay

Sure?

 + visible, many projects

I agree, D is invisible. Everyone who's using D professionally 
should make it public.

 + enforced style (indentation, exports)

D is about freedom. No enforced style please. We already have 
Python.

 * Dlang: big!










 it's open" sign but sits emtpy; by comparison Go -> condo in 
 hip, trendy area

 * Ideas for D






 once











 every programming language design challenge there is, but less 
 focused on purpose (Andrei's note: I assume D more at fault 
 than C++ on this)

 General feeling: "I don't feel smart enough for D and am 
 looking for a quick way to accomplish a goal. I've read the 
 Wikipedia article on D and didn't understand a few things. The 
 examples seem to show off the language but that made them 
 confusing. I wanted to get more into it, but by that time Go 
 had already won - I looked at the tutorials, changed the sample 
 code a bit right in the browser to see how it'd work for me, it 
 was easy, I was in already. Some of my comments therefore 
 illustrate my shortcomings than the language's, but that's true 
 one way or another for all programmers (that's why technical 
 superiority of a language doesn't guarantee its success)."

I appreciate his honesty. Sometimes I don't feel smart enough to 
use D either, or Python or C. There's always something that 
escapes me, something I could have done better. I don't think 
that D has to become simpler, we just have to point out that it 
can be very simple _and_ safe. (Plus benchmarking)

And we have to reach out to the real world, i.e. GUI, web 
technologies, mobile platforms. Without these things, D will 
always be considered as "nice, but I can't really use it". This 
is why every new language builds up an infrastructure first. I 
used to say that D didn't need an IDE and toolchains and all the 
bells and whistles. It doesn't. But people do, because they have 
to get their work done. Maybe we have lived in an ivory tower for 
too long. D deserves better. D should be out there.

 ===============

 I'd love us to derive a few action items from this and other 
 feedback.


 Andrei

"Atila Neves" <atila.neves gmail.com> writes:

 + one binary to distribute

 This goes for D as well.

I always wonder about this, it comes up often when people discuss 
Go favourably. Like "compiles fast", there seems to be a 
perception problem that most people think only Go has these 
attributes.* Maybe something for us to stress? I'd never have 
thought this would be the thing to draw people in, but it keeps 
getting mentioned for Go so...

 + good for servers

 Doable with D (vibe.d), but not part and parcel of the 
 language, although important.

Similarly, there's a marketing problem here. A friend of mine who 
knows I like D said once "but you wouldn't use it to write a 
server". Which is funny since that's exactly the kind of task I'd 
use D for.

Is Go good for writing servers? Yes. Is D? Yes!**

There's a good chance that if the concurrency parts of vibe.d 
made it into the library that we could market the bejeezus out of 
that. Plus the networking parts of vibe.d as well, of course.

Atila

* I also love that they say "fast" as if that has meaning by 
itself. Faster than C++? Well done in beating a known slowcoach...
** with vibe.d anyway

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:


D's vim support is quite good(including intelligent autocomplete 
provided by DCD,) maybe if it's that unknown I could write a blog 
post on setting up vim for D - or just a survey of the available 
development environments.

"Dicebot" <public dicebot.lv> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 A friend of mine needed to complete a small project and thought 
 of using a language he didn't know for it. He already knew I 
 work on D so he considered it alongside Go. He ended up 
 choosing the latter, and documented his decision making process 
 in a few notes that he subsequently shared with me. I'll paste 
 below a sort of transcript of his handwritten notes.

In my opinion it is better to focus on tempting users with D 
strong bits than oversell it by trying it compete in topics it 
has inherent disadvantage. There is not point in try to compete 
with Go on topic of simplicity - they have crippled the language 
tremendeously to get that simplicity. Simple D has no value - I 
would simply prefer Go instead of it as it has head start 
advantage in toolchain.

Instead it is better to focus on explaining users that they don't 
want what they think they want, akin to that Bjarne quote. And 
don't be afraid to admit to certain users that D is not a best 
choice for them. It doesn't mean that such valuable feedback 
should be ignore - there is indeed a lot that can be improved in 
the learning curve. But trying to fight for user who makes choice 
with "trendy" and "simplicity" in mind is a battle lost from the 
very beginning.

"Chris" <wendlec tcd.ie> writes:

On Friday, 13 March 2015 at 13:18:03 UTC, Dicebot wrote:
 On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
 wrote:
 A friend of mine needed to complete a small project and 
 thought of using a language he didn't know for it. He already 
 knew I work on D so he considered it alongside Go. He ended up 
 choosing the latter, and documented his decision making 
 process in a few notes that he subsequently shared with me. 
 I'll paste below a sort of transcript of his handwritten notes.

 In my opinion it is better to focus on tempting users with D 
 strong bits than oversell it by trying it compete in topics it 
 has inherent disadvantage.

In theory I agree, but I've learned that this is not the way 
things work. I've learned that the way to "sell" a language is to 
give (potential) users an immediate reward and the feeling that 
they can do useful things with the language. D can do all that, 
but we repeatedly fail to bring this point across.

 There is not point in try to compete with Go on topic of 
 simplicity - they have crippled the language tremendeously to 
 get that simplicity. Simple D has no value - I would simply 
 prefer Go instead of it as it has head start advantage in 
 toolchain.

 Instead it is better to focus on explaining users that they 
 don't want what they think they want, akin to that Bjarne 
 quote. And don't be afraid to admit to certain users that D is 
 not a best choice for them. It doesn't mean that such valuable 
 feedback should be ignore - there is indeed a lot that can be 
 improved in the learning curve. But trying to fight for user 
 who makes choice with "trendy" and "simplicity" in mind is a 
 battle lost from the very beginning.

This is true. This battle is lost. But a lot of users, even 
people who are interested in D, shy away from D, because they 
don't have the feeling that "this is something really useful". We 
fail to communicate both its general usefulness and its strong 
points as opposed to other languages. What the big marketing 
machines behind Go etc. do is to make people feel good about a 
product (even if it's shit). We should do the same. Only because 
Google does it, doesn't mean it's a big taboo for us. The fact of 
the matter is that we have failed to win over:

1. the C/C++ expert nerdy-linuxy crowd
2. the average user

Crowd 1. we cannot win over easily, after all C/C++ are 
well-established and "high priests" and gurus are usually 
reluctant to learn something new. Crowd 2. we can win over, yet 
we have failed to communicate with them, to reach out to them. 
Most people I know have a look at D's homepage and say "Uh! Hm. 
Ah, I'll use Python." No, they are not hardcore programmers, they 
are engineers and scientists. But they are _users_, people who 
need to write software to analyze data, to create something. We 
should not ignore them, even if they are not (initially) 
interested in templates and metaprogramming. Neither was I, when 
I first learned D.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 14:20 +0000, Chris via Digitalmars-d wrote:
[…]

 reluctant to learn something new. Crowd 2. we can win over, yet 
 we have failed to communicate with them, to reach out to them. 
 Most people I know have a look at D's homepage and say "Uh! Hm. 
 Ah, I'll use Python." No, they are not hardcore programmers, they 
 are engineers and scientists. But they are _users_, people who 
 need to write software to analyze data, to create something. We 
 should not ignore them, even if they are not (initially) 
 interested in templates and metaprogramming. Neither was I, when 
 I first learned D.

It is not Python or R or Julia the language that people choose, it is
the superstructure built on top. So for Python, it is Pandas,
Matplotlib, SciPy, NumPy. And the ability to use ready made C, C++ and
Fortran libraries.   

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Chris" <wendlec tcd.ie> writes:

On Friday, 13 March 2015 at 14:34:23 UTC, Russel Winder wrote:
 On Fri, 2015-03-13 at 14:20 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 reluctant to learn something new. Crowd 2. we can win over, 
 yet we have failed to communicate with them, to reach out to 
 them. Most people I know have a look at D's homepage and say 
 "Uh! Hm. Ah, I'll use Python." No, they are not hardcore 
 programmers, they are engineers and scientists. But they are 
 _users_, people who need to write software to analyze data, to 
 create something. We should not ignore them, even if they are 
 not (initially) interested in templates and metaprogramming. 
 Neither was I, when I first learned D.

 It is not Python or R or Julia the language that people choose, 
 it is
 the superstructure built on top. So for Python, it is Pandas,
 Matplotlib, SciPy, NumPy. And the ability to use ready made C, 
 C++ and
 Fortran libraries.

Exactly, that's part of it. People don't understand that they can 
use all the C libraries with D as well. And if they do, "extern 
(C)" is too "complicated", at least more complicated than "import 
numbergrind". I'm really at loss here, I don't know how to 
communicate these things to people. Colleagues and text books 
that talk about R and Python weigh so much more than "D can 
actually interface to C without any effort".[1]

Also, sometimes I have the impression that people use any excuse 
not to use D.

[1] The problem is that all these nice Python and R 
implementations are practically useless for real world 
applications. Too slow, too cumbersome, too many dependencies. It 
has to be rewritten anyway. (I'd be happy, if they used at least 
C.)

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 7:51 AM, Chris wrote:
 On Friday, 13 March 2015 at 14:34:23 UTC, Russel Winder wrote:
 On Fri, 2015-03-13 at 14:20 +0000, Chris via Digitalmars-d wrote:
 […]

 reluctant to learn something new. Crowd 2. we can win over, yet we
 have failed to communicate with them, to reach out to them. Most
 people I know have a look at D's homepage and say "Uh! Hm. Ah, I'll
 use Python." No, they are not hardcore programmers, they are
 engineers and scientists. But they are _users_, people who need to
 write software to analyze data, to create something. We should not
 ignore them, even if they are not (initially) interested in templates
 and metaprogramming. Neither was I, when I first learned D.

 It is not Python or R or Julia the language that people choose, it is
 the superstructure built on top. So for Python, it is Pandas,
 Matplotlib, SciPy, NumPy. And the ability to use ready made C, C++ and
 Fortran libraries.

 Exactly, that's part of it. People don't understand that they can use
 all the C libraries with D as well. And if they do, "extern (C)" is too
 "complicated", at least more complicated than "import numbergrind". I'm
 really at loss here, I don't know how to communicate these things to
 people. Colleagues and text books that talk about R and Python weigh so
 much more than "D can actually interface to C without any effort".[1]

 Also, sometimes I have the impression that people use any excuse not to
 use D.

That may as well be basic psychology at work. Curb appeal (or lack 
thereof) is difficult to explain but is easy to rationalize with 
unrelated arguments.

There is something loosely related to curb appeal that has been 
discussed here before. Consider someone just starts with D and wants to 
figure whether there's a startsWith function in D.

So they google for something like ``dlang startswith''. Nicely enough 
http://dlang.org/phobos/std_algorithm.html comes up first. (Ideally the 
individual page http://dlang.org/library/std/algorithm/starts_with.html 
would come up.)

Anyhow, assuming the user clicks on the former, startsWith is easy to 
find at the top and then when you click on it...

====
uint startsWith(alias pred = "a == b", Range, Needles...)(Range 
doesThisStart, Needles withOneOfThese) if (isInputRange!Range && 
Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart, 
withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart, 
withOneOfThese[1..$])) : uint));
bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, R2 
withThis) if (isInputRange!R1 && isInputRange!R2 && 
is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool));
bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E 
withThis) if (isInputRange!R && 
is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : bool));
====

This in big bold font, too. The HTML way of saying, "you wanted 
startsWith? I'll give you more startsWith than you can carry." Picture 
the effect this has on someone who just wanted to see if a string starts 
with another.

We need to make the template constraints distinct for formatting in ddoc.

Sadly http://dlang.org/library/std/algorithm/starts_with.html is bad in 
other ways. It doesn't have any examples! In contrast, the unified page 
does have some decent examples.

This all is under the "curb appeal" category.


Andrei

"Chris" <wendlec tcd.ie> writes:

On Friday, 13 March 2015 at 15:17:06 UTC, Andrei Alexandrescu 
wrote:
 On 3/13/15 7:51 AM, Chris wrote:
 On Friday, 13 March 2015 at 14:34:23 UTC, Russel Winder wrote:
 On Fri, 2015-03-13 at 14:20 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 reluctant to learn something new. Crowd 2. we can win over, 
 yet we
 have failed to communicate with them, to reach out to them. 
 Most
 people I know have a look at D's homepage and say "Uh! Hm. 
 Ah, I'll
 use Python." No, they are not hardcore programmers, they are
 engineers and scientists. But they are _users_, people who 
 need to
 write software to analyze data, to create something. We 
 should not
 ignore them, even if they are not (initially) interested in 
 templates
 and metaprogramming. Neither was I, when I first learned D.

 It is not Python or R or Julia the language that people 
 choose, it is
 the superstructure built on top. So for Python, it is Pandas,
 Matplotlib, SciPy, NumPy. And the ability to use ready made 
 C, C++ and
 Fortran libraries.

 Exactly, that's part of it. People don't understand that they 
 can use
 all the C libraries with D as well. And if they do, "extern 
 (C)" is too
 "complicated", at least more complicated than "import 
 numbergrind". I'm
 really at loss here, I don't know how to communicate these 
 things to
 people. Colleagues and text books that talk about R and Python 
 weigh so
 much more than "D can actually interface to C without any 
 effort".[1]

 Also, sometimes I have the impression that people use any 
 excuse not to
 use D.

 That may as well be basic psychology at work. Curb appeal (or 
 lack thereof) is difficult to explain but is easy to 
 rationalize with unrelated arguments.

 There is something loosely related to curb appeal that has been 
 discussed here before. Consider someone just starts with D and 
 wants to figure whether there's a startsWith function in D.

 So they google for something like ``dlang startswith''. Nicely 
 enough http://dlang.org/phobos/std_algorithm.html comes up 
 first. (Ideally the individual page 
 http://dlang.org/library/std/algorithm/starts_with.html would 
 come up.)

 Anyhow, assuming the user clicks on the former, startsWith is 
 easy to find at the top and then when you click on it...

 ====
 uint startsWith(alias pred = "a == b", Range, Needles...)(Range 
 doesThisStart, Needles withOneOfThese) if (isInputRange!Range 
 && Needles.length > 1 && 
 is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : 
 bool) && is(typeof(.startsWith!pred(doesThisStart, 
 withOneOfThese[1..$])) : uint));
 bool startsWith(alias pred = "a == b", R1, R2)(R1 
 doesThisStart, R2 withThis) if (isInputRange!R1 && 
 isInputRange!R2 && 
 is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) 
 : bool));
 bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E 
 withThis) if (isInputRange!R && 
 is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : 
 bool));
 ====

 This in big bold font, too. The HTML way of saying, "you wanted 
 startsWith? I'll give you more startsWith than you can carry." 
 Picture the effect this has on someone who just wanted to see 
 if a string starts with another.

 We need to make the template constraints distinct for 
 formatting in ddoc.

 Sadly http://dlang.org/library/std/algorithm/starts_with.html 
 is bad in other ways. It doesn't have any examples! In 
 contrast, the unified page does have some decent examples.

 This all is under the "curb appeal" category.


 Andrei

Yep. This is part of the "make people feel good about it" 
approach. Plus, we're not selling shit, it's really a good 
product. In a way, we do it the other way around: bad marketing 
for a good product.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 8:37 AM, Chris wrote:
 Yep. This is part of the "make people feel good about it" approach.
 Plus, we're not selling shit, it's really a good product. In a way, we
 do it the other way around: bad marketing for a good product.

Yah, indeed. Continuing the experiment, I set out to find Go's 
startsWith. So I googled for ``startswith golang''. First hit is 
http://golang.org/pkg/strings/ but there's no StartsWith on that page. 
The second hit is 
http://stackoverflow.com/questions/13244048/no-startswith-endsw
th-functions-in-go, 
which puts me in the right direction - HasPrefix is the name. So I click 
on that and I get to http://golang.org/pkg/strings/#HasPrefix.

That has no example but the signature is obvious enough. Just to verify, 
I click on the "Example" link on the function "Index" below, and I edit 
these lines:

	fmt.Println(strings.Index("chicken", "ken"))
	fmt.Println(strings.Index("chicken", "dmr"))

to:

	fmt.Println(strings.HasPrefix("chicken", "chi"))
	fmt.Println(strings.HasPrefix("chicken", "dmr"))

Click Run produces "true\nfalse" and... I got it.

* * *

Now here's the interesting part. There's a world of difference between 
D's startsWith and Go's HasPrefix. (Not because there's anything wrong 
about HasPrefix.) It's just that startsWith is very powerful - 
disconcertingly so. It is quite literally the ultimate startsWith:

* Works with any combination of UTF8, UTF16, and UTF32.

* Works with not only strings, but any arrays

* Works with array and element (e.g. "abc".startsWith('a')), not only 
array and array

* Equality is too much? You can pass a predicate

* Efficiently looks for multiple prefixes in a single pass, e.g. 


* Scratch "array", works with any two ranges with comparable elements 
and for any range and comparable element

For example the expression (assuming s is e.g. a string)

   File("/tmp/a").byChunk(4096).joiner.startsWith(s)

opens a file, progressively reads chunks of 4KB, stitches them together 
at no cost, compares against a prefix until it makes a decision, then 
closes the file and returns the result. A putative Go user wouldn't even 
dream of using HasPrefix directly on a stream coming from a file; the 
whole endeavor would be a function that painstakingly takes all of these 
steps by hand.

We need to take the "disconcerting" out the documentation equation while 
still exposing the power. s1.startsWith(s2) is perfectly apt for two 
strings, and that should be immediately apparent to someone who just 
needs that.


Andrei

Joe Greer <Joe.Greer Visionsolutions.com> writes:

Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> wrote in
news:mdv6st$28mg$1 digitalmars.com: 

 
 Yah, indeed. Continuing the 

experiment, I set out to find Go's 
 startsWith. So I googled for 

``startswith golang''. First hit is 
 http://golang.org/pkg/strings/ but 

there's no StartsWith on that page.
 The second hit is 
 http://stackoverflow.com/questions/132

44048/no-startswith-endswith-func
 tions-in-go, which puts me in the 

right direction - HasPrefix is the
 name. So I click on that and I get to
 http://golang.org/pkg/strings/

#HasPrefix. 
 
 That has no example but the signature 

is obvious enough. Just to
 verify, I click on the "Example" link 

on the function "Index" below,
 and I edit these lines:
 
      fmt.Println(strings.Index

("chicken", "ken"))
      fmt.Println(strings.Index

("chicken", "dmr"))
 
 to:
 
      fmt.Println(strings.HasPrefix

("chicken", "chi"))
      fmt.Println(strings.HasPrefix

("chicken", "dmr"))
 
 Click Run produces "true\nfalse" 

and... I got it.
 
 * * *
 
 Now here's the interesting part. 

There's a world of difference between
 D's startsWith and Go's HasPrefix. 

(Not because there's anything wrong
 about HasPrefix.) It's just that 

startsWith is very powerful - 
 disconcertingly so. It is quite 

literally the ultimate startsWith:
 
 * Works with any combination of UTF8, 

UTF16, and UTF32.
 
 * Works with not only strings, but any 

arrays
 
 * Works with array and element (e.g. 

"abc".startsWith('a')), not only 
 array and array
 
 * Equality is too much? You can pass a 

predicate
 
 * Efficiently looks for multiple 

prefixes in a single pass, e.g. 

 
 * Scratch "array", works with any two 

ranges with comparable elements 
 and for any range and comparable 

element
 
 For example the expression (assuming s 

is e.g. a string)
 
    File("/tmp/a").byChunk

(4096).joiner.startsWith(s)
 
 opens a file, progressively reads 

chunks of 4KB, stitches them
 together at no cost, compares against 

a prefix until it makes a
 decision, then closes the file and 

returns the result. A putative Go
 user wouldn't even dream of using 

HasPrefix directly on a stream
 coming from a file; the whole endeavor 

would be a function that
 painstakingly takes all of these steps 

by hand.
 
 We need to take the "disconcerting" 

out the documentation equation
 while still exposing the power. 

s1.startsWith(s2) is perfectly apt for
 two strings, and that should be 

immediately apparent to someone who
 just needs that.
 
 
 Andrei
 

I think you're touching on what is bad 
about algorithms in general. 
That is, documenting them in a way that 
one could actually find them
when they are needed.  C++ has the same 
problem.  In this case, there
should really be an entry associated 
with the string class that
indicates that this algorithm works with 
it and for that matter, all
common string operations that are 
implemented as algorithms should be
referred to there.  Now, I am not saying 
that it is vitally important
that this be all inclusive, that is, 
functions that happen to work on
strings, but are really associated with 
string operations don't need to
be referenced in the string class.  
After all, by the time something
like that is wanted, the user knows way 
more about D and can find it
themselves, but certainly things like 
startWith() which started in the
string domain and moved out the 
generality should be referenced with
strings.  The same is true of other 
class types as well, but string
manipulating is very important in modern 
program development. 

Just my opinion,
joe

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 12:02 PM, Joe Greer wrote:
 In this case, there
 should really be an entry associated
 with the string class that
 indicates that this algorithm works with
 it and for that matter, all
 common string operations that are
 implemented as algorithms should be
 referred to there.

Yah, I think we should add references (with examples) to std.string's 
documentation to std.algorithm functions that typically apply to 
strings. -- Andrei

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 10:31 AM, Andrei Alexandrescu wrote:
 For example the expression (assuming s is e.g. a string)

    File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 opens a file, progressively reads chunks of 4KB, stitches them together at no
 cost, compares against a prefix until it makes a decision, then closes the file
 and returns the result. A putative Go user wouldn't even dream of using
 HasPrefix directly on a stream coming from a file; the whole endeavor would be
a
 function that painstakingly takes all of these steps by hand.

 We need to take the "disconcerting" out the documentation equation while still
 exposing the power. s1.startsWith(s2) is perfectly apt for two strings, and
that
 should be immediately apparent to someone who just needs that.

I suggest putting that snippet in the documentation as an example!

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 12:19 PM, Walter Bright wrote:
 On 3/13/2015 10:31 AM, Andrei Alexandrescu wrote:
 For example the expression (assuming s is e.g. a string)

    File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 opens a file, progressively reads chunks of 4KB, stitches them
 together at no
 cost, compares against a prefix until it makes a decision, then closes
 the file
 and returns the result. A putative Go user wouldn't even dream of using
 HasPrefix directly on a stream coming from a file; the whole endeavor
 would be a
 function that painstakingly takes all of these steps by hand.

 We need to take the "disconcerting" out the documentation equation
 while still
 exposing the power. s1.startsWith(s2) is perfectly apt for two
 strings, and that
 should be immediately apparent to someone who just needs that.

 I suggest putting that snippet in the documentation as an example!

Also: does /tmp/a have /tmp/b as a prefix?

File("/tmp/a").byChunk(4096).joiner.startsWith(
   File("/tmp/b").byChunk(4096).joiner)

I also wonder how efficient that is.


Andrei

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]

 
    File("/tmp/a").byChunk(4096).joiner.startsWith(s)
 

[…]

Conversely, this is exactly the sort of expression that Scala (and
Haskell sort of, Haskell insists on function application syntax) are
getting huge positive press for being able to write. As is Python. And
Java. And C++.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d
 wrote:
 […]

     File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 […]

 Conversely, this is exactly the sort of expression that Scala (and
 Haskell sort of, Haskell insists on function application syntax) are
 getting huge positive press for being able to write. As is Python. And
 Java. And C++.

How do you mean "conversely"? Maybe you meant "incidentally"? -- Andrei

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-=


d
 wrote:
 [=E2=80=A6]

     File("/tmp/a").byChunk(4096).joiner.startsWith(s)



[=E2=80=A6]
=20
 How do you mean "conversely"? Maybe you meant "incidentally"? -- Andrei

In functional languages, each stage in the pipeline returns Option to
avoid error handling. Go does not give you this facility as it refuses
to allow activity without proper error checking.

So if byChunk returns a failed read, functional language just carry on,
Go would force the error check, D does=E2=80=A6=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"weaselcat" <weaselcat gmail.com> writes:

On Saturday, 14 March 2015 at 08:40:53 UTC, Russel Winder wrote:
 On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via 
 Digitalmars-d
 wrote:
 On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via 
 Digitalmars-d
 wrote:
 […]

     File("/tmp/a").byChunk(4096).joiner.startsWith(s)



 […]
 
 How do you mean "conversely"? Maybe you meant "incidentally"? 
 -- Andrei

 In functional languages, each stage in the pipeline returns 
 Option to
 avoid error handling. Go does not give you this facility as it 
 refuses
 to allow activity without proper error checking.

 So if byChunk returns a failed read, functional language just 
 carry on,
 Go would force the error check,
D does…

D throws an exception that you would catch with a try block(or 
scope(failure) )?
I've never seen Go praised for its error handling, it is always 
the opposite.

Go error handling is verbose and ugly. 
http://blog.golang.org/error-handling-and-go

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 09:09 +0000, weaselcat via Digitalmars-d wrote:
[=E2=80=A6]

 I've never seen Go praised for its error handling, it is always=20
 the opposite.
=20
 Go error handling is verbose and ugly.=20
 http://blog.golang.org/error-handling-and-go

Go's mechanism of error handling is for me a horrible regression to
1960's programming. However, the feedback from those who really have
"drunk the Kool-Aid" is interesting: the tension between the way of
working and number of error in released systems does appear to indicate
that they may be getting many fewer errors. However some of the tortuous
argumentation about how the coding of error is the right way forward
does smack a bit of Stockholm Syndrome.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Walter Bright <newshound2 digitalmars.com> writes:

On 3/14/2015 2:18 AM, Russel Winder via Digitalmars-d wrote:
 coding of error

Sounds like the title of my next book!

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/14/15 1:40 AM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via Digitalmars-d
 wrote:
 On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmars-d
 wrote:
 […]

      File("/tmp/a").byChunk(4096).joiner.startsWith(s)



 […]
 How do you mean "conversely"? Maybe you meant "incidentally"? -- Andrei

 In functional languages, each stage in the pipeline returns Option to
 avoid error handling. Go does not give you this facility as it refuses
 to allow activity without proper error checking.

Go does not give you this facility for a multitude of reasons, starting 
with its lack of generic programming.

 So if byChunk returns a failed read, functional language just carry on,
 Go would force the error check, D does…

D throws an exception. Is that good or bad?


Andrei

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 09:56 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/14/15 1:40 AM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 16:13 -0700, Andrei Alexandrescu via Digitalmars-=


d
 wrote:
 On 3/13/15 2:22 PM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 10:31 -0700, Andrei Alexandrescu via Digitalmar=




s-d
 wrote:
 [=E2=80=A6]

      File("/tmp/a").byChunk(4096).joiner.startsWith(s)



 [=E2=80=A6]
 How do you mean "conversely"? Maybe you meant "incidentally"? -- Andre=



i
 In functional languages, each stage in the pipeline returns Option to
 avoid error handling. Go does not give you this facility as it refuses
 to allow activity without proper error checking.

=20
 Go does not give you this facility for a multitude of reasons, starting=

=20
 with its lack of generic programming.

This is not the reason, although it is a huge factor, the following is=E2=
=80=A6
=20
 So if byChunk returns a failed read, functional language just carry on,
 Go would force the error check, D does=E2=80=A6

=20
 D throws an exception. Is that good or bad?

Works for me, unacceptable in Go which forbids exceptions for anything
other than termination.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Elazar Leibovich" <elazarl gmail.com> writes:

On Friday, 13 March 2015 at 17:31:09 UTC, Andrei Alexandrescu 
wrote:
 For example the expression (assuming s is e.g. a string)

   File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 opens a file, progressively reads chunks of 4KB, stitches them 
 together at no cost, compares against a prefix until it makes a 
 decision, then closes the file and returns the result. A 
 putative Go user wouldn't even dream of using HasPrefix 
 directly on a stream coming from a file; the whole endeavor 
 would be a function that painstakingly takes all of these steps 
 by hand.

I personally, would have no idea what this piece of code is doing
upon first sight. I'll have to look at the documentation of
at least two functions to understand that, and I'll have to
think carefully about what and who would throw in case of an 
error.

Something like

     while (n != EOF) {
         n = read(fd, buf, sizeof(buf));
         if (n==-1) throw(...);
         if (strcmp(buf, PREFIX) == 0) {
              return buf;
         }
     }
     return NULL;

Requires no prior knowledge, and have similar effect.

I'd rather have a loop written by hand in my production code any 
day,
so that when debugging it, and reading it I'll have easier time
to understand it, even though it would cost me a few more lines
when writing the code.

What if this pattern repeats a few times in the code?

I'd rather have a single function that have the explicit loop than
having this pattern in slight variations spread in the code.

Writing code is easy, maintaining it afterwards is costly.

"bearophile" <bearophileHUGS lycos.com> writes:

Elazar Leibovich:

 I personally, would have no idea what this piece of code is 
 doing upon first sight. I'll have to look at the documentation 
 of
 at least two functions to understand that, and I'll have to
 think carefully about what and who would throw in case of an 
 error.

 Something like

     while (n != EOF) {
         n = read(fd, buf, sizeof(buf));
         if (n==-1) throw(...);
         if (strcmp(buf, PREFIX) == 0) {
              return buf;
         }
     }
     return NULL;

 Requires no prior knowledge, and have similar effect.

 I'd rather have a loop written by hand in my production code 
 any day, so that when debugging it, and reading it I'll have 
 easier time
 to understand it, even though it would cost me a few more lines
 when writing the code.

Unfortunately your thinking is mostly obsolete, the programming 
world (well, most of it, Go is one exception) is going in the 
opposite direction, and for good reasons. An explanation:
https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning

Bye,
bearophile

"CraigDillabaugh" <craig.dillabaugh gmail.com> writes:

On Wednesday, 18 March 2015 at 12:11:52 UTC, bearophile wrote:
 Elazar Leibovich:

 I personally, would have no idea what this piece of code is 
 doing upon first sight. I'll have to look at the documentation 
 of
 at least two functions to understand that, and I'll have to
 think carefully about what and who would throw in case of an 
 error.

 Something like

    while (n != EOF) {
        n = read(fd, buf, sizeof(buf));
        if (n==-1) throw(...);
        if (strcmp(buf, PREFIX) == 0) {
             return buf;
        }
    }
    return NULL;

 Requires no prior knowledge, and have similar effect.

 I'd rather have a loop written by hand in my production code 
 any day, so that when debugging it, and reading it I'll have 
 easier time
 to understand it, even though it would cost me a few more lines
 when writing the code.

 Unfortunately your thinking is mostly obsolete, the programming 
 world (well, most of it, Go is one exception) is going in the 
 opposite direction, and for good reasons. An explanation:
 https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning

 Bye,
 bearophile

Bearophile,

You said that "Unfortunately" this thinking is going out of style 
"for good reasons".   I am confused (sorry, I am at work, and 
didn't have time to watch the 1+ hour video you linked to - maybe 
some clues were there)!

I often find myself feeling a bit like Elazar.  Not long ago I 
wrote some Python code using a bunch of the functional style 
programming tools and I was very please with the very concise 
code I had generated.  Then, I had to make some modifications to 
the code. It took me an inordinate amount of time just to figure 
out what the code was doing, and I had written it myself just a 
few days earlier!

Craig

"bearophile" <bearophileHUGS lycos.com> writes:

CraigDillabaugh:

 You said that "Unfortunately" this thinking is going out of 
 style "for good reasons".   I am confused (sorry, I am at work, 
 and didn't have time to watch the 1+ hour video you linked to -

I said "unfortunately" because it's another reason for us to 
refactor and change our coding habits :-)



 maybe some clues were there)!

Of course.


 I often find myself feeling a bit like Elazar.  Not long ago I 
 wrote some Python code using a bunch of the functional style 
 programming tools and I was very please with the very concise 
 code I had generated.  Then, I had to make some modifications 
 to the code. It took me an inordinate amount of time just to 
 figure out what the code was doing, and I had written it myself 
 just a few days earlier!

There's not a single correct answer to this. Replacing long 
bug-prone explicit-loops code with pre-made safer algorithms is 
often a good idea. The effort of learning some very generic and 
reusable functions is usually worth it. But I've also seen plenty 
of Haskell code that requires you to know tens of tiny functions, 
often named with symbols like !<>!. This is worse than writing 
for loops. High level constructs in D are often slower than 
low-level code, so in some cases you don't want to use them.

So as usually you have to choose wisely, because most solutions 
aren't perfect if you use them everywhere, there are many ways to 
write bad code if you don't keep your eyes and brain switched on.

Bye,
bearophile

Walter Bright <newshound2 digitalmars.com> writes:

On 3/18/2015 5:59 AM, bearophile wrote:
 High level constructs in D are often slower than low-level code, so in
 some cases you don't want to use them.

They're often faster, too, for several reasons.

Like any programming construct, including traditional loops, one has to pay 
attention and use them with some skill in order to get max performance.

"weaselcat" <weaselcat gmail.com> writes:

On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
 High level constructs in D are often slower than low-level 
 code, so in some cases you don't want to use them.

I actually found that LDC does an _amazing_ job of optimizing 
high level constructs and converting "low level" code to higher 
level functional code resulted in minor speedups in a lot of 
cases.


(Other performance benefits include the algorithm primitives 
being extensively optimized in phobos.)

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
 On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
 High level constructs in D are often slower than low-level 
 code, so in some cases you don't want to use them.

 I actually found that LDC does an _amazing_ job of optimizing 
 high level constructs and converting "low level" code to higher 
 level functional code resulted in minor speedups in a lot of 
 cases.


 (Other performance benefits include the algorithm primitives 
 being extensively optimized in phobos.)

If the code/compiler generates suboptimal code in the first place 
then improvements can be somewhat random. But if you write code 
with good cache locality, filling the pipeline properly then  
there is no alternative to going low level.

Btw, take a look at this:
http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d

That's really bad marketing...

"weaselcat" <weaselcat gmail.com> writes:

On Thursday, 19 March 2015 at 16:59:36 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
 On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
 High level constructs in D are often slower than low-level 
 code, so in some cases you don't want to use them.

 I actually found that LDC does an _amazing_ job of optimizing 
 high level constructs and converting "low level" code to 
 higher level functional code resulted in minor speedups in a 
 lot of cases.


 (Other performance benefits include the algorithm primitives 
 being extensively optimized in phobos.)

 If the code/compiler generates suboptimal code in the first 
 place then improvements can be somewhat random. But if you 
 write code with good cache locality, filling the pipeline 
 properly then  there is no alternative to going low level.

 Btw, take a look at this:
 http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d

 That's really bad marketing...

python:
time python2 wc.py 
enwiki-latest-pages-articles1.xml-p000000010p000010000
There are 1245473 lines
python2 wc.py 
enwiki-latest-pages-articles1.xml-p000000010p000010000  0.21s 
user 0.08s system 99% cpu 0.294 total

wc -l:
time wc -l enwiki-latest-pages-articles1.xml-p000000010p000010000
1245472 enwiki-latest-pages-articles1.xml-p000000010p000010000
wc -l enwiki-latest-pages-articles1.xml-p000000010p000010000  
0.05s user 0.02s system 96% cpu 0.072 total


iterative version:
ldc -O5 -inline -release -boundscheck=off wc.d
time ./wc
There are 1245473 lines.
./wc enwiki-latest-pages-articles1.xml-p000000010p000010000  
0.59s user 0.07s system 99% cpu 0.661 total

functional version:
writeln("There are ", 
(cast(string)read(args[1])).splitter('\n').array.length, " 
lines.");

ldc -O5 -inline -release -boundscheck=off wc.d
time ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000
There are 1245473 lines.
./wc enwiki-latest-pages-articles1.xml-p000000010p000010000  
0.04s user 0.08s system 98% cpu 0.125 total


ahem
 I actually found that LDC does an _amazing_ job of optimizing 
 high level constructs and converting "low level" code to 
 higher level functional code resulted in minor speedups in a 
 lot of cases.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/19/15 10:40 AM, weaselcat wrote:
 On Thursday, 19 March 2015 at 16:59:36 UTC, Ola Fosheim Grøstad wrote:
 On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
 On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
 High level constructs in D are often slower than low-level code, so
 in some cases you don't want to use them.

 I actually found that LDC does an _amazing_ job of optimizing high
 level constructs and converting "low level" code to higher level
 functional code resulted in minor speedups in a lot of cases.


 (Other performance benefits include the algorithm primitives being
 extensively optimized in phobos.)

 If the code/compiler generates suboptimal code in the first place then
 improvements can be somewhat random. But if you write code with good
 cache locality, filling the pipeline properly then  there is no
 alternative to going low level.

 Btw, take a look at this:
 http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d


 That's really bad marketing...

 python:
 time python2 wc.py enwiki-latest-pages-articles1.xml-p000000010p000010000
 There are 1245473 lines
 python2 wc.py enwiki-latest-pages-articles1.xml-p000000010p000010000
 0.21s user 0.08s system 99% cpu 0.294 total

 wc -l:
 time wc -l enwiki-latest-pages-articles1.xml-p000000010p000010000
 1245472 enwiki-latest-pages-articles1.xml-p000000010p000010000
 wc -l enwiki-latest-pages-articles1.xml-p000000010p000010000 0.05s user
 0.02s system 96% cpu 0.072 total


 iterative version:
 ldc -O5 -inline -release -boundscheck=off wc.d
 time ./wc
 There are 1245473 lines.
 ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000 0.59s user
 0.07s system 99% cpu 0.661 total

 functional version:
 writeln("There are ",
 (cast(string)read(args[1])).splitter('\n').array.length, " lines.");

 ldc -O5 -inline -release -boundscheck=off wc.d
 time ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000
 There are 1245473 lines.
 ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000 0.04s user
 0.08s system 98% cpu 0.125 total

You may want to answer there, not here. I've also posted a response.

Andrei

"bearophile" <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

 You may want to answer there, not here. I've also posted a 
 response.

There is this, with an attach:
https://issues.dlang.org/show_bug.cgi?id=11810

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/19/15 6:30 PM, bearophile wrote:
 Andrei Alexandrescu:

 You may want to answer there, not here. I've also posted a response.

 There is this, with an attach:
 https://issues.dlang.org/show_bug.cgi?id=11810

I destroyed:

https://github.com/D-Programming-Language/phobos/pull/3089


Andrei

"Tobias Pankrath" <tobias pankrath.net> writes:

 You may want to answer there, not here. I've also posted a 
 response.

 Andrei

Nitpick: Your solutions that use readText validate their input 
and the python version probably doesn't. You could mention that 
(I cannot comment on SO).

Interestingly readText is faster than byChunck.joiner regardless.

Nitpick 2: http://www.unicode.org/versions/Unicode7.0.0/ch05.pdf 
(chapter 5.8) splitLines is still incomplete, missing to break on 
U+0085, U+000B, U+000C. Would a PR for this be accepted?

I'd say the coolest answer to this question would have been: D 
has not only one of the fastest, but the only correct solution to 
this that works with UTF8, UTF16 and UTF32 at the same time.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/20/15 10:26 AM, Tobias Pankrath wrote:
 You may want to answer there, not here. I've also posted a response.

 Andrei

 Nitpick: Your solutions that use readText validate their input and the
 python version probably doesn't. You could mention that (I cannot
 comment on SO).

Yah, nitpicks should go there too. We need to have an understanding that 
statistically everybody is on SO and nobody here :o).

 Interestingly readText is faster than byChunck.joiner regardless.

I'm not if it does the checking.

 Nitpick 2: http://www.unicode.org/versions/Unicode7.0.0/ch05.pdf
 (chapter 5.8) splitLines is still incomplete, missing to break on
 U+0085, U+000B, U+000C. Would a PR for this be accepted?

Prolly. Walter?

 I'd say the coolest answer to this question would have been: D has not
 only one of the fastest, but the only correct solution to this that
 works with UTF8, UTF16 and UTF32 at the same time.

Well then write that answer.


Andrei

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 5:36 PM, Andrei Alexandrescu wrote:
 Nitpick 2: http://www.unicode.org/versions/Unicode7.0.0/ch05.pdf
 (chapter 5.8) splitLines is still incomplete, missing to break on
 U+0085, U+000B, U+000C. Would a PR for this be accepted?

 Prolly. Walter?

Sure.

"Tobias Pankrath" <tobias pankrath.net> writes:

 Well then write that answer.

Not true, right now.

"Laeeth Isharc" <laeeth nospamlaeeth.com> writes:

 Yah, nitpicks should go there too. We need to have an 
 understanding that statistically everybody is on SO and nobody 
 here :o).

I have seen repeatedly - on stack overflow and elsewhere - people 
benchmarking 'D' against other languages using dmd.  The 
messaging on the home page and download page is not clear.  We 
might consider making it clearer - dmd for fast compilation and 
ldc/gdc for fast code if you need it - because not doing so 
undermines a key benefit of D.

And an article on general techniques to make D code fast would be 
good both for the web site and for Adam's newsletter.  I am not 
the person to write this for now.


Laeeth.

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Thursday, 19 March 2015 at 17:40:46 UTC, weaselcat wrote:
 On Thursday, 19 March 2015 at 16:59:36 UTC, Ola Fosheim Grøstad

 If the code/compiler generates suboptimal code in the first 
 place then improvements can be somewhat random. But if you 
 write code with good cache locality, filling the pipeline 
 properly then  there is no alternative to going low level.

 Btw, take a look at this:
 http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d

 That's really bad marketing...


[…]

 ldc -O5 -inline -release -boundscheck=off wc.d
 time ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000
 There are 1245473 lines.
 ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000  
 0.04s user 0.08s system 98% cpu 0.125 total


 ahem
 I actually found that LDC does an _amazing_ job of optimizing 
 high level constructs and converting "low level" code to



I think you missed my point here. A simple loop like this should 
result in similar execution times for all AoT languages with 
decent library support and optimisation because it ought to be 
bandwidth limited, not CPU limited. The issue here is that when 
decent programmers end up asking for help on stackoverflow it 
exposes underlying library/compiler/language issues that needs 
addressing on way or another.

When it comes to more complicated algorithms then it usually 
impossible for a high level construct to match a low level one 
for several reasons, a major one being that you need to tailor 
the algorithm to OS/caches/ALU/CPU. Pure high level code cannot 
easily be reduced to high quality iterative algorithms that match 
the hardware.

High level constructs may be  cleaner if done right, and 
sometimes saves programmer time, but it will never be as fast on 
the standard CPU architectures we have today. The hardware 
favours carefully planned iterative, imperative approaches. That 
was true before SIMD and caching, and it is even more true now.

Try to do some signal processing and you'll quickly learn that 
high level code is out of the question if you want high 
performance.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 3:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 High level constructs may be  cleaner if done right, and sometimes saves
 programmer time, but it will never be as fast on the standard CPU architectures
 we have today. The hardware favours carefully planned iterative, imperative
 approaches. That was true before SIMD and caching, and it is even more true
now.

It's less true for SIMD. To take advantage of SIMD, compilers have to reverse 
engineer low level loops into a higher level construct, then re-compile for
SIMD.

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Saturday, 21 March 2015 at 17:55:09 UTC, Walter Bright wrote:
 On 3/20/2015 3:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 High level constructs may be  cleaner if done right, and 
 sometimes saves
 programmer time, but it will never be as fast on the standard 
 CPU architectures
 we have today. The hardware favours carefully planned 
 iterative, imperative
 approaches. That was true before SIMD and caching, and it is 
 even more true now.

 It's less true for SIMD. To take advantage of SIMD, compilers 
 have to reverse engineer low level loops into a higher level 
 construct, then re-compile for SIMD.

No. You have to design so that you don't get dependencies on the 
same vector register.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/21/2015 11:02 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Saturday, 21 March 2015 at 17:55:09 UTC, Walter Bright wrote:
 On 3/20/2015 3:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 High level constructs may be  cleaner if done right, and sometimes saves
 programmer time, but it will never be as fast on the standard CPU architectures
 we have today. The hardware favours carefully planned iterative, imperative
 approaches. That was true before SIMD and caching, and it is even more true
now.

 It's less true for SIMD. To take advantage of SIMD, compilers have to reverse
 engineer low level loops into a higher level construct, then re-compile for
SIMD.

 No. You have to design so that you don't get dependencies on the same vector
 register.

I know I shouldn't, but I'll bite. Show me the "low level C code" that 
effectively uses SIMD vector registers.

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Saturday, 21 March 2015 at 19:35:02 UTC, Walter Bright wrote:
 I know I shouldn't, but I'll bite. Show me the "low level C 
 code" that effectively uses SIMD vector registers.

You are right, you should not bite. C code is superflous, this is 
a general issue with efficient parallel computations. You want to 
avoid dependencies within a single register.

E.g. Take a recurrence relation and make an efficient simd 
implementation for it.  You might need to try to expand the terms 
so you have N independent formulas. If it uses floating point you 
will have to be careful about drift between the N formulas that 
are computed in parallel.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/21/2015 2:08 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Saturday, 21 March 2015 at 19:35:02 UTC, Walter Bright wrote:
 I know I shouldn't, but I'll bite. Show me the "low level C code" that
 effectively uses SIMD vector registers.

 You are right, you should not bite. C code is superflous, this is a general
 issue with efficient parallel computations. You want to avoid dependencies
 within a single register.

 E.g. Take a recurrence relation and make an efficient simd implementation for
 it.  You might need to try to expand the terms so you have N independent
 formulas. If it uses floating point you will have to be careful about drift
 between the N formulas that are computed in parallel.

I.e. there isn't low level C code that effectively uses SIMD vector registers. 
You have to use the auto-vectorizer, which tries to reconstruct high level 
operations out of C low level code, then recompile.

"weaselcat" <weaselcat gmail.com> writes:

On Sunday, 22 March 2015 at 03:43:33 UTC, Walter Bright wrote:
 On 3/21/2015 2:08 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Saturday, 21 March 2015 at 19:35:02 UTC, Walter Bright 
 wrote:
 I know I shouldn't, but I'll bite. Show me the "low level C 
 code" that
 effectively uses SIMD vector registers.

 You are right, you should not bite. C code is superflous, this 
 is a general
 issue with efficient parallel computations. You want to avoid 
 dependencies
 within a single register.

 E.g. Take a recurrence relation and make an efficient simd 
 implementation for
 it.  You might need to try to expand the terms so you have N 
 independent
 formulas. If it uses floating point you will have to be 
 careful about drift
 between the N formulas that are computed in parallel.

 I.e. there isn't low level C code that effectively uses SIMD 
 vector registers. You have to use the auto-vectorizer, which 
 tries to reconstruct high level operations out of C low level 
 code, then recompile.

at least it still compiles into efficient code for the PDP11?

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Sunday, 22 March 2015 at 03:43:33 UTC, Walter Bright wrote:
 I.e. there isn't low level C code that effectively uses SIMD 
 vector registers. You have to use the auto-vectorizer, which 
 tries to reconstruct high level operations out of C low level 
 code, then recompile.

I don't think low level hardware registers qualify as "high level 
constructs" which is the term you used. Besides, all major C 
compilers ship with builtin vector types and support for standard 
hardware vendor SIMD intrinsics. But even if you dismiss that, 
then even less sophisticated contemporary compiler is capable of 
using SIMD for carefully manually unrolled expressions. Still, 
even without explicit simd instructions the superscalar nature of 
desktop CPUs require you to break dependencies to avoid bubbles 
in the pipeline.

So in order to optimize the filling of an array with the 
fibonacci sequence a plain high level library generator is 
insufficient. You also need to utilize the closed formula for 
fib(x) so that you can generate sequences in parallel, e.g. 
compute the sequence fib(0),fib(1)… in parallel with fib(N), 
fib(N+1) etc.

Without having the closed formula to obtain fib(N-2) and fib(N-1) 
a regular optimizer will simply not be able to break the 
dependencies as effectively as a handwritten low level loop.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/19/2015 9:59 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
 On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
 High level constructs in D are often slower than low-level code, so in some
 cases you don't want to use them.

 I actually found that LDC does an _amazing_ job of optimizing high level
 constructs and converting "low level" code to higher level functional code
 resulted in minor speedups in a lot of cases.


 (Other performance benefits include the algorithm primitives being extensively
 optimized in phobos.)

 If the code/compiler generates suboptimal code in the first place then
 improvements can be somewhat random. But if you write code with good cache
 locality, filling the pipeline properly then there is no alternative to going
 low level.

 Btw, take a look at this:
 http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d

 That's really bad marketing...

Sigh. The Python version:
-----------
import sys

if __name__ == "__main__":
     if (len(sys.argv) < 2):
         sys.exit()
     infile = open(sys.argv[1])
     linect = 0
     for line in infile:
         linect += 1
     print "There are %d lines" % linect
----------
does not allocate memory. The splitLines() version:
----------
import std.stdio;
import std.string;
import std.file;

int main(string[] args)
{
   if (args.length < 2) {
     return 1;
   }
   auto c = cast(string) read(args[1]);
   auto l = splitLines(c);
   writeln("There are ", l.length, " lines.");
   return 0;
}
---------
allocates memory for all the lines and an array of them. No wonder it's slow! 
The allocations are slow, and filling them all when they are cold-cached - 
AWFUL! (It also uselessly and maddeningly auto-decodes, a misfeature of Phobos 
if there ever was one.)

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 20 March 2015 at 05:17:11 UTC, Walter Bright wrote:
 On 3/19/2015 9:59 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
 On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
 High level constructs in D are often slower than low-level 
 code, so in some
 cases you don't want to use them.

 I actually found that LDC does an _amazing_ job of optimizing 
 high level
 constructs and converting "low level" code to higher level 
 functional code
 resulted in minor speedups in a lot of cases.


 (Other performance benefits include the algorithm primitives 
 being extensively
 optimized in phobos.)

 If the code/compiler generates suboptimal code in the first 
 place then
 improvements can be somewhat random. But if you write code 
 with good cache
 locality, filling the pipeline properly then there is no 
 alternative to going
 low level.

 Btw, take a look at this:
 http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d

 That's really bad marketing...

 Sigh. The Python version:
 -----------
 import sys

 if __name__ == "__main__":
     if (len(sys.argv) < 2):
         sys.exit()
     infile = open(sys.argv[1])
     linect = 0
     for line in infile:
         linect += 1
     print "There are %d lines" % linect
 ----------
 does not allocate memory. The splitLines() version:
 [...] cutted

Of course it does allocate memory.

Python's "for...in" makes use of iterators and generators, 
already there you have some allocations going around.

Not only that, there is one string being allocated for each line 
in the file being read, even if it isn't used.

Not counting the whole minor allocations going on.



--
Paulo

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 12:42 AM, Paulo Pinto wrote:
 On Friday, 20 March 2015 at 05:17:11 UTC, Walter Bright wrote:
 Sigh. The Python version:
 -----------
 import sys

 if __name__ == "__main__":
     if (len(sys.argv) < 2):
         sys.exit()
     infile = open(sys.argv[1])
     linect = 0
     for line in infile:
         linect += 1
     print "There are %d lines" % linect
 ----------
 does not allocate memory. The splitLines() version:
 [...] cutted

 Of course it does allocate memory.

 Python's "for...in" makes use of iterators and generators, already there you
 have some allocations going around.

 Not only that, there is one string being allocated for each line in the file
 being read, even if it isn't used.

Since 'line' is never referred to again after constructed, even a simple 
optimizer could elide it.

It would be easy to test - accumulate the lines in an array, and check the
times.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 20 March 2015 at 10:50:44 UTC, Walter Bright wrote:
 On 3/20/2015 12:42 AM, Paulo Pinto wrote:
 On Friday, 20 March 2015 at 05:17:11 UTC, Walter Bright wrote:
 Sigh. The Python version:
 -----------
 import sys

 if __name__ == "__main__":
    if (len(sys.argv) < 2):
        sys.exit()
    infile = open(sys.argv[1])
    linect = 0
    for line in infile:
        linect += 1
    print "There are %d lines" % linect
 ----------
 does not allocate memory. The splitLines() version:
 [...] cutted

 Of course it does allocate memory.

 Python's "for...in" makes use of iterators and generators, 
 already there you
 have some allocations going around.

 Not only that, there is one string being allocated for each 
 line in the file
 being read, even if it isn't used.

 Since 'line' is never referred to again after constructed, even 
 a simple optimizer could elide it.

 It would be easy to test - accumulate the lines in an array, 
 and check the times.

Which the default Python implementation doesn't have, hence my 
comment.

Also even if it did have one, it cannot elide it as it cannot 
guarantee the semantics of the generators/iterators side effects 
will be kept.

--
Paulo

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 3:59 AM, Paulo Pinto wrote:
 On Friday, 20 March 2015 at 10:50:44 UTC, Walter Bright wrote:
 Since 'line' is never referred to again after constructed, even a simple
 optimizer could elide it.

 It would be easy to test - accumulate the lines in an array, and check the
times.

 Which the default Python implementation doesn't have, hence my comment.

After all these years, the default Python implementation doesn't do fairly
basic 
optimizations? I find that a bit hard to believe.

 Also even if it did have one, it cannot elide it as it cannot guarantee the
 semantics of the generators/iterators side effects will be kept.

I wonder why keeping a string would be a side effect.

I'm not saying you're wrong, I don't know Python well enough to make such a 
judgement. It just causes me to raise one eyebrow like Spock if it does work 
this way.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 20 March 2015 at 20:31:49 UTC, Walter Bright wrote:
 On 3/20/2015 3:59 AM, Paulo Pinto wrote:
 On Friday, 20 March 2015 at 10:50:44 UTC, Walter Bright wrote:
 Since 'line' is never referred to again after constructed, 
 even a simple
 optimizer could elide it.

 It would be easy to test - accumulate the lines in an array, 
 and check the times.

 Which the default Python implementation doesn't have, hence my 
 comment.

 After all these years, the default Python implementation 
 doesn't do fairly basic optimizations? I find that a bit hard 
 to believe.

 Also even if it did have one, it cannot elide it as it cannot 
 guarantee the
 semantics of the generators/iterators side effects will be 
 kept.

 I wonder why keeping a string would be a side effect.

 I'm not saying you're wrong, I don't know Python well enough to 
 make such a judgement. It just causes me to raise one eyebrow 
 like Spock if it does work this way.

The side effect is not keeping the string, rather generating it.

for var in exp:
    do_something()

if exp represents a iteratable or a generator, even if var is 
thrown away the loop needs to be preserved to keep the semantics 
of calling next() on the instance object that executes the  
for..in loop.

Put other way, does DMD throw away foreach loops even if the 
compiler cannot prove if  opApply () or popFront() generate side 
effects, assuming the variable isn't being used?

--
Paulo

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 2:04 PM, Paulo Pinto wrote:
 The side effect is not keeping the string, rather generating it.

 for var in exp:
     do_something()

 if exp represents a iteratable or a generator, even if var is thrown away the
 loop needs to be preserved to keep the semantics of calling next() on the
 instance object that executes the for..in loop.

 Put other way, does DMD throw away foreach loops even if the compiler cannot
 prove if  opApply () or popFront() generate side effects, assuming the variable
 isn't being used?

D has pure functions, and if those pure functions return an unneeded string,
the 
call can be discarded.

BTW, it still is faster than splitLines simply because the line string is not 
stored. The GC can collect it and reuse the memory. Not so for splitLines,
which 
must hold it all, meaning it'll be using memory that is not in the cache.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/20/15 1:31 PM, Walter Bright wrote:
 On 3/20/2015 3:59 AM, Paulo Pinto wrote:
 On Friday, 20 March 2015 at 10:50:44 UTC, Walter Bright wrote:
 Since 'line' is never referred to again after constructed, even a simple
 optimizer could elide it.

 It would be easy to test - accumulate the lines in an array, and
 check the times.

 Which the default Python implementation doesn't have, hence my comment.

 After all these years, the default Python implementation doesn't do
 fairly basic optimizations? I find that a bit hard to believe.

It's in all likelihood the truth. -- Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/20/15 3:50 AM, Walter Bright wrote:
 On 3/20/2015 12:42 AM, Paulo Pinto wrote:
 On Friday, 20 March 2015 at 05:17:11 UTC, Walter Bright wrote:
 Sigh. The Python version:
 -----------
 import sys

 if __name__ == "__main__":
     if (len(sys.argv) < 2):
         sys.exit()
     infile = open(sys.argv[1])
     linect = 0
     for line in infile:
         linect += 1
     print "There are %d lines" % linect
 ----------
 does not allocate memory. The splitLines() version:
 [...] cutted

 Of course it does allocate memory.

 Python's "for...in" makes use of iterators and generators, already
 there you
 have some allocations going around.

 Not only that, there is one string being allocated for each line in
 the file
 being read, even if it isn't used.

 Since 'line' is never referred to again after constructed, even a simple
 optimizer could elide it.

It's not elided to the best of my knowledge. But it's reference counted 
so it goes from 0 to 1 and back. A simple caching allocator will have no 
trouble with this pattern. -- Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/20/15 12:42 AM, Paulo Pinto wrote:
 On Friday, 20 March 2015 at 05:17:11 UTC, Walter Bright wrote:
 On 3/19/2015 9:59 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
 On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
 High level constructs in D are often slower than low-level code, so
 in some
 cases you don't want to use them.

 I actually found that LDC does an _amazing_ job of optimizing high
 level
 constructs and converting "low level" code to higher level
 functional code
 resulted in minor speedups in a lot of cases.


 (Other performance benefits include the algorithm primitives being
 extensively
 optimized in phobos.)

 If the code/compiler generates suboptimal code in the first place then
 improvements can be somewhat random. But if you write code with good
 cache
 locality, filling the pipeline properly then there is no alternative
 to going
 low level.

 Btw, take a look at this:
 http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d


 That's really bad marketing...

 Sigh. The Python version:
 -----------
 import sys

 if __name__ == "__main__":
     if (len(sys.argv) < 2):
         sys.exit()
     infile = open(sys.argv[1])
     linect = 0
     for line in infile:
         linect += 1
     print "There are %d lines" % linect
 ----------
 does not allocate memory. The splitLines() version:
 [...] cutted

 Of course it does allocate memory.

Yah, and uses reference counting for management. -- Andrei

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 5:23 PM, Andrei Alexandrescu wrote:
 Yah, and uses reference counting for management. -- Andrei

Ref counting won't improve splitLines, because it must keep them all.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/20/15 5:56 PM, Walter Bright wrote:
 On 3/20/2015 5:23 PM, Andrei Alexandrescu wrote:
 Yah, and uses reference counting for management. -- Andrei

 Ref counting won't improve splitLines, because it must keep them all.

Yah, all solution based on "let's keep all lines so we count them at the 
end" are suboptimal. -- Andrei

"Sebastiaan Koppe" <mail skoppe.eu> writes:

On Saturday, 21 March 2015 at 01:31:21 UTC, Andrei Alexandrescu 
wrote:
 On 3/20/15 5:56 PM, Walter Bright wrote:
 On 3/20/2015 5:23 PM, Andrei Alexandrescu wrote:
 Yah, and uses reference counting for management. -- Andrei

 Ref counting won't improve splitLines, because it must keep 
 them all.

 Yah, all solution based on "let's keep all lines so we count 
 them at the end" are suboptimal. -- Andrei

What about `.count("\n")` ?

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/20/15 9:43 PM, Sebastiaan Koppe wrote:
 On Saturday, 21 March 2015 at 01:31:21 UTC, Andrei Alexandrescu wrote:
 On 3/20/15 5:56 PM, Walter Bright wrote:
 On 3/20/2015 5:23 PM, Andrei Alexandrescu wrote:
 Yah, and uses reference counting for management. -- Andrei

 Ref counting won't improve splitLines, because it must keep them all.

 Yah, all solution based on "let's keep all lines so we count them at
 the end" are suboptimal. -- Andrei

 What about `.count("\n")` ?

Using "count" is among the solutions I measured: 
http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in

-- Andrei

"Laeeth Isharc" <laeeth nospamlaeeth.com> writes:

On Saturday, 21 March 2015 at 15:09:32 UTC, Andrei Alexandrescu 
wrote:
 On 3/20/15 9:43 PM, Sebastiaan Koppe wrote:
 On Saturday, 21 March 2015 at 01:31:21 UTC, Andrei 
 Alexandrescu wrote:
 On 3/20/15 5:56 PM, Walter Bright wrote:
 On 3/20/2015 5:23 PM, Andrei Alexandrescu wrote:
 Yah, and uses reference counting for management. -- Andrei

 Ref counting won't improve splitLines, because it must keep 
 them all.

 Yah, all solution based on "let's keep all lines so we count 
 them at
 the end" are suboptimal. -- Andrei

 What about `.count("\n")` ?

 Using "count" is among the solutions I measured: 
 http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in

 -- Andrei

Fwiw I get similar timings to python and pypy using LDC optimized 
and the others are not bad.  Maybe it is a Windows specific 
problem (I use arch).  (Posted to SO).

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Wednesday, 18 March 2015 at 12:45:50 UTC, CraigDillabaugh 
wrote:
 On Wednesday, 18 March 2015 at 12:11:52 UTC, bearophile wrote:
 Elazar Leibovich:

 I personally, would have no idea what this piece of code is 
 doing upon first sight. I'll have to look at the 
 documentation of
 at least two functions to understand that, and I'll have to
 think carefully about what and who would throw in case of an 
 error.

 Something like

   while (n != EOF) {
       n = read(fd, buf, sizeof(buf));
       if (n==-1) throw(...);
       if (strcmp(buf, PREFIX) == 0) {
            return buf;
       }
   }
   return NULL;

 Requires no prior knowledge, and have similar effect.

 I'd rather have a loop written by hand in my production code 
 any day, so that when debugging it, and reading it I'll have 
 easier time
 to understand it, even though it would cost me a few more 
 lines
 when writing the code.

 Unfortunately your thinking is mostly obsolete, the 
 programming world (well, most of it, Go is one exception) is 
 going in the opposite direction, and for good reasons. An 
 explanation:
 https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning

 Bye,
 bearophile

 Bearophile,

 You said that "Unfortunately" this thinking is going out of 
 style "for good reasons".   I am confused (sorry, I am at work, 
 and didn't have time to watch the 1+ hour video you linked to - 
 maybe some clues were there)!

 I often find myself feeling a bit like Elazar.  Not long ago I 
 wrote some Python code using a bunch of the functional style 
 programming tools and I was very please with the very concise 
 code I had generated.  Then, I had to make some modifications 
 to the code. It took me an inordinate amount of time just to 
 figure out what the code was doing, and I had written it myself 
 just a few days earlier!

 Craig

Maybe your years of practice and deep familiarity with imperative 
code patterns - both general and individual to yourself - might 
have skewed the result somewhat.

It seems to me that much of practical programming is about having 
set up "quick paths" in your brain for recognising and 
manipulating common patterns. There's a big gap between 
understanding something intellectually and understanding 
something intuitively.

"CraigDillabaugh" <craig.dillabaugh gmail.com> writes:

clip

 Bearophile,

 You said that "Unfortunately" this thinking is going out of 
 style "for good reasons".   I am confused (sorry, I am at 
 work, and didn't have time to watch the 1+ hour video you 
 linked to - maybe some clues were there)!

 I often find myself feeling a bit like Elazar.  Not long ago I 
 wrote some Python code using a bunch of the functional style 
 programming tools and I was very please with the very concise 
 code I had generated.  Then, I had to make some modifications 
 to the code. It took me an inordinate amount of time just to 
 figure out what the code was doing, and I had written it 
 myself just a few days earlier!

 Craig

 Maybe your years of practice and deep familiarity with 
 imperative code patterns - both general and individual to 
 yourself - might have skewed the result somewhat.

 It seems to me that much of practical programming is about 
 having set up "quick paths" in your brain for recognising and 
 manipulating common patterns. There's a big gap between 
 understanding something intellectually and understanding 
 something intuitively.

There is quite possibly something too that, and as I imagine
with more functional experience it will come easier to me.

However, I still think imperative code is generally easier to
reason about because (usually) each line of code is performing
a single task, whereas with functional coding the goal seems
to be to cram as many operations as possible into a single line
(I know that isn't the real reason, it just seems that way at
times).  Trying to 'unroll' everything in your head can be a
challenge.  Throw in a lambda function or two with
the mess of braces/symbols and then you have a real puzzler.

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Wednesday, 18 March 2015 at 13:27:54 UTC, CraigDillabaugh 
wrote:
 clip

 Bearophile,

 You said that "Unfortunately" this thinking is going out of 
 style "for good reasons".   I am confused (sorry, I am at 
 work, and didn't have time to watch the 1+ hour video you 
 linked to - maybe some clues were there)!

 I often find myself feeling a bit like Elazar.  Not long ago 
 I wrote some Python code using a bunch of the functional 
 style programming tools and I was very please with the very 
 concise code I had generated.  Then, I had to make some 
 modifications to the code. It took me an inordinate amount of 
 time just to figure out what the code was doing, and I had 
 written it myself just a few days earlier!

 Craig

 Maybe your years of practice and deep familiarity with 
 imperative code patterns - both general and individual to 
 yourself - might have skewed the result somewhat.

 It seems to me that much of practical programming is about 
 having set up "quick paths" in your brain for recognising and 
 manipulating common patterns. There's a big gap between 
 understanding something intellectually and understanding 
 something intuitively.

 There is quite possibly something too that, and as I imagine
 with more functional experience it will come easier to me.

 However, I still think imperative code is generally easier to
 reason about because (usually) each line of code is performing
 a single task, whereas with functional coding the goal seems
 to be to cram as many operations as possible into a single line
 (I know that isn't the real reason, it just seems that way at
 times).  Trying to 'unroll' everything in your head can be a
 challenge.  Throw in a lambda function or two with
 the mess of braces/symbols and then you have a real puzzler.

Careful formatting is really important for long UFCS chains using 
lots of lambdas etc. in D for exactly this reason. It's very easy 
to go "ooooooo, that's so neat, it's all one 1 line!" but it's 
often better to spread it out to make the semantics more obvious.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Wed, 2015-03-18 at 13:27 +0000, CraigDillabaugh via Digitalmars-d wrote:
=20

[=E2=80=A6]
 There is quite possibly something too that, and as I imagine
 with more functional experience it will come easier to me.
=20
 However, I still think imperative code is generally easier to
 reason about because (usually) each line of code is performing
 a single task, whereas with functional coding the goal seems
 to be to cram as many operations as possible into a single line
 (I know that isn't the real reason, it just seems that way at
 times).  Trying to 'unroll' everything in your head can be a
 challenge.  Throw in a lambda function or two with
 the mess of braces/symbols and then you have a real puzzler.

Each imperative statement may (or may not) be easier to understand,=20
but the problem is putting them together in combination. The issue=20
here is creating chunks on which you put a label for reasoning with.=20
Everything is about the abstractions you reason with. A person who is=20
familiar only with C-style programming (as per OPs code fragment) has=20
built up various abstractions, but they are nonetheless at a very low=20
level and so many have to be combined.

Someone who has learned the internal iteration abstraction and higher-
order functions is actually working at a higher level of abstraction=20
and generally needs to combine fewer things to achieve the overall=20
goal. Cramming operations on a line is nothing to do with the=20
abstractions, that is to do with some people playing code golf.

If you find yourself reading declarative style code and having to=20
unroll to imperative equivalent to understand, it just means you have=20
not yet internalized the declarative abstraction yet into your mental=20
model and personal programming language.

There is a lot of work on all this sort of stuff in the psychology of=20
programming research literature. We can speculate all we like here=20
based on personal experience and anecdotal evidence, they do=20
experiments and have real data. Of course if you see any experimenting=20
on first and second year undergraduates of computer science, ignore=20
the results. I am talking about those who experiment with practicing=20
programmers, people with real experience and expertise.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Paulo Pinto" <pjmlp progtools.org> writes:

On Thursday, 19 March 2015 at 08:17:42 UTC, Russel Winder wrote:
 On Wed, 2015-03-18 at 13:27 +0000, CraigDillabaugh via 
 Digitalmars-d wrote:
 

 […]
 There is quite possibly something too that, and as I imagine
 with more functional experience it will come easier to me.
 
 However, I still think imperative code is generally easier to
 reason about because (usually) each line of code is performing
 a single task, whereas with functional coding the goal seems
 to be to cram as many operations as possible into a single line
 (I know that isn't the real reason, it just seems that way at
 times).  Trying to 'unroll' everything in your head can be a
 challenge.  Throw in a lambda function or two with
 the mess of braces/symbols and then you have a real puzzler.

 Each imperative statement may (or may not) be easier to 
 understand,
 but the problem is putting them together in combination. The 
 issue
 here is creating chunks on which you put a label for reasoning 
 with.
 Everything is about the abstractions you reason with. A person 
 who is
 familiar only with C-style programming (as per OPs code 
 fragment) has
 built up various abstractions, but they are nonetheless at a 
 very low
 level and so many have to be combined.

 Someone who has learned the internal iteration abstraction and 
 higher-
 order functions is actually working at a higher level of 
 abstraction
 and generally needs to combine fewer things to achieve the 
 overall
 goal. Cramming operations on a line is nothing to do with the
 abstractions, that is to do with some people playing code golf.

 If you find yourself reading declarative style code and having 
 to
 unroll to imperative equivalent to understand, it just means 
 you have
 not yet internalized the declarative abstraction yet into your 
 mental
 model and personal programming language.

 There is a lot of work on all this sort of stuff in the 
 psychology of
 programming research literature. We can speculate all we like 
 here
 based on personal experience and anecdotal evidence, they do
 experiments and have real data. Of course if you see any 
 experimenting
 on first and second year undergraduates of computer science, 
 ignore
 the results. I am talking about those who experiment with 
 practicing
 programmers, people with real experience and expertise.

I just saw a talk of one of those studies.

One of the points was that curly braces languages lead to more 
bugs than languages that follow the Algol more verbose style.

CodeMesh 2014 - Andreas Stefik - The Programming Language Wars

https://www.youtube.com/watch?v=mDZ-QSLQIB8

Quite interesting when one mixes psychology research with 
language features, backed by validated research data.

--
Paulo

"Chris" <wendlec tcd.ie> writes:

On Wednesday, 18 March 2015 at 12:45:50 UTC, CraigDillabaugh 
wrote:
 On Wednesday, 18 March 2015 at 12:11:52 UTC, bearophile wrote:
 Elazar Leibovich:

 I personally, would have no idea what this piece of code is 
 doing upon first sight. I'll have to look at the 
 documentation of
 at least two functions to understand that, and I'll have to
 think carefully about what and who would throw in case of an 
 error.

 Something like

   while (n != EOF) {
       n = read(fd, buf, sizeof(buf));
       if (n==-1) throw(...);
       if (strcmp(buf, PREFIX) == 0) {
            return buf;
       }
   }
   return NULL;

 Requires no prior knowledge, and have similar effect.

 I'd rather have a loop written by hand in my production code 
 any day, so that when debugging it, and reading it I'll have 
 easier time
 to understand it, even though it would cost me a few more 
 lines
 when writing the code.

 Unfortunately your thinking is mostly obsolete, the 
 programming world (well, most of it, Go is one exception) is 
 going in the opposite direction, and for good reasons. An 
 explanation:
 https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning

 Bye,
 bearophile

 Bearophile,

 You said that "Unfortunately" this thinking is going out of 
 style "for good reasons".   I am confused (sorry, I am at work, 
 and didn't have time to watch the 1+ hour video you linked to - 
 maybe some clues were there)!

 I often find myself feeling a bit like Elazar.  Not long ago I 
 wrote some Python code using a bunch of the functional style 
 programming tools and I was very please with the very concise 
 code I had generated.  Then, I had to make some modifications 
 to the code. It took me an inordinate amount of time just to 
 figure out what the code was doing, and I had written it myself 
 just a few days earlier!

 Craig

Simple solution: use comments :-)

Walter Bright <newshound2 digitalmars.com> writes:

On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
 You said that "Unfortunately" this thinking is going out of style "for good
 reasons".   I am confused (sorry, I am at work, and didn't have time to watch
 the 1+ hour video you linked to - maybe some clues were there)!

Consider this C code:

#include <stdbool.h>
#include <stdio.h>

typedef long T;
bool find(T *array, size_t dim, T t) {
  int i;
  for (i = 0; i <= dim; i++);
  {
     int v = array[i];
     if (v == t)
         return true;
  }
}

There are several bugs in it. I've showed this to probably over 1000 
programmers, and nobody found all the bugs in it (they are obvious once pointed 
out). It is not easy to write bug free loop code, and find() is a trivial
function.

"jkpl" <jkpl nowhere.fr> writes:

On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
 On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
 You said that "Unfortunately" this thinking is going out of 
 style "for good
 reasons".   I am confused (sorry, I am at work, and didn't 
 have time to watch
 the 1+ hour video you linked to - maybe some clues were there)!

 Consider this C code:

 #include <stdbool.h>
 #include <stdio.h>

 typedef long T;
 bool find(T *array, size_t dim, T t) {
  int i;
  for (i = 0; i <= dim; i++);
  {
     int v = array[i];
     if (v == t)
         return true;
  }
 }

 There are several bugs in it. I've showed this to probably over 
 1000 programmers, and nobody found all the bugs in it (they are 
 obvious once pointed out). It is not easy to write bug free 
 loop code, and find() is a trivial function.

just for fun:

1/ '<=' instead of '<'
2/ array should be tested against null before entering the loop
3/ 'int v' instead of 'T v'

Got them all ?

David Gileadi <gileadis NSPMgmail.com> writes:

On 3/18/15 4:48 PM, jkpl wrote:
 On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
 On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
 You said that "Unfortunately" this thinking is going out of style
 "for good
 reasons".   I am confused (sorry, I am at work, and didn't have time
 to watch
 the 1+ hour video you linked to - maybe some clues were there)!

 Consider this C code:

 #include <stdbool.h>
 #include <stdio.h>

 typedef long T;
 bool find(T *array, size_t dim, T t) {
  int i;
  for (i = 0; i <= dim; i++);
  {
     int v = array[i];
     if (v == t)
         return true;
  }
 }

 There are several bugs in it. I've showed this to probably over 1000
 programmers, and nobody found all the bugs in it (they are obvious
 once pointed out). It is not easy to write bug free loop code, and
 find() is a trivial function.

 just for fun:

 1/ '<=' instead of '<'
 2/ array should be tested against null before entering the loop
 3/ 'int v' instead of 'T v'

 Got them all ?

4. The semicolon after the for loop's closing paren...

David Gileadi <gileadis NSPMgmail.com> writes:

On 3/18/15 4:54 PM, David Gileadi wrote:
 On 3/18/15 4:48 PM, jkpl wrote:
 On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
 On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
 You said that "Unfortunately" this thinking is going out of style
 "for good
 reasons".   I am confused (sorry, I am at work, and didn't have time
 to watch
 the 1+ hour video you linked to - maybe some clues were there)!

 Consider this C code:

 #include <stdbool.h>
 #include <stdio.h>

 typedef long T;
 bool find(T *array, size_t dim, T t) {
  int i;
  for (i = 0; i <= dim; i++);
  {
     int v = array[i];
     if (v == t)
         return true;
  }
 }

 There are several bugs in it. I've showed this to probably over 1000
 programmers, and nobody found all the bugs in it (they are obvious
 once pointed out). It is not easy to write bug free loop code, and
 find() is a trivial function.

 just for fun:

 1/ '<=' instead of '<'
 2/ array should be tested against null before entering the loop
 3/ 'int v' instead of 'T v'

 Got them all ?

 4. The semicolon after the for loop's closing paren...

5. No return if the item isn't found, leading to undefined behavior.

There may well be more, but I'll stop spamming this topic. Sorry Walter.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/18/2015 4:58 PM, David Gileadi wrote:
 There may well be more,

Yup!


 but I'll stop spamming this topic. Sorry Walter.

Of course, what the bugs actually are is not really the point, although it is 
fun hunting them out.

But it isn't so much fun hunting them out in a large codebase, nor is it fun 
spending hours tracking down a bug. The ranges+algorithms method is far easier 
to check by inspection and get right.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/18/2015 4:48 PM, jkpl wrote:
 just for fun:

 1/ '<=' instead of '<'
 2/ array should be tested against null before entering the loop
 3/ 'int v' instead of 'T v'

 Got them all ?


Nope! I'll post late tonight.

"cym13" <cpicard openmailbox.org> writes:

On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
 On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
 You said that "Unfortunately" this thinking is going out of 
 style "for good
 reasons".   I am confused (sorry, I am at work, and didn't 
 have time to watch
 the 1+ hour video you linked to - maybe some clues were there)!

 Consider this C code:

 #include <stdbool.h>
 #include <stdio.h>

 typedef long T;
 bool find(T *array, size_t dim, T t) {
  int i;
  for (i = 0; i <= dim; i++);
  {
     int v = array[i];
     if (v == t)
         return true;
  }
 }

 There are several bugs in it. I've showed this to probably over 
 1000 programmers, and nobody found all the bugs in it (they are 
 obvious once pointed out). It is not easy to write bug free 
 loop code, and find() is a trivial function.

i is of type int and dim of type size_t which can grow bigger so 
the loop may overflow... I can't find more.

Either way, I think your point couldn't be clearer :)

Maybe there should be a "part 2" to the C-to-D little tutorial, 
one that shows how to code at a higher level introducing gently 
functional structures instead of just teaching how to write C in 
D. To stop thinking about steps to think about transformations 
isn't an easy thing.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/18/2015 5:34 PM, cym13 wrote:
 Maybe there should be a "part 2" to the C-to-D little tutorial, one that shows
 how to code at a higher level introducing gently functional structures instead
 of just teaching how to write C in D. To stop thinking about steps to think
 about transformations isn't an easy thing.

Andrei and I talked about this, how we are failing to point out how to 
idiomatically use D to advantage. We need to do a lot better at this.

"Joakim" <dlang joakim.fea.st> writes:

On Thursday, 19 March 2015 at 00:52:12 UTC, Walter Bright wrote:
 On 3/18/2015 5:34 PM, cym13 wrote:
 Maybe there should be a "part 2" to the C-to-D little 
 tutorial, one that shows
 how to code at a higher level introducing gently functional 
 structures instead
 of just teaching how to write C in D. To stop thinking about 
 steps to think
 about transformations isn't an easy thing.

 Andrei and I talked about this, how we are failing to point out 
 how to idiomatically use D to advantage. We need to do a lot 
 better at this.

One underused resource seems to be all the examples bearophile 
has put on Rosetta Code:

http://rosettacode.org/wiki/Category:D

If he, Adam, or some other proficient D user were to do a weekly 
series breaking down each of those 733 examples one at a time- 
what idioms were used, why certain variations were more 
efficient- that could go a long way to introduce the language and 
its idioms to beginners.  It would provide enough examples for 14 
years of such a weekly series, by which time D3 will be getting 
started!

Walter Bright <newshound2 digitalmars.com> writes:

On 3/19/2015 10:44 AM, Joakim wrote:
 One underused resource seems to be all the examples bearophile has put on
 Rosetta Code:

 http://rosettacode.org/wiki/Category:D

 If he, Adam, or some other proficient D user were to do a weekly series
breaking
 down each of those 733 examples one at a time- what idioms were used, why
 certain variations were more efficient- that could go a long way to introduce
 the language and its idioms to beginners.  It would provide enough examples for
 14 years of such a weekly series, by which time D3 will be getting started!

I didn't know about rosettacode. Thanks! It also might be a great resource for 
better examples to use in the Phobos documentation.

David Gileadi <gileadis NSPMgmail.com> writes:

On 3/19/15 10:22 PM, Walter Bright wrote:
 On 3/19/2015 10:44 AM, Joakim wrote:
 One underused resource seems to be all the examples bearophile has put on
 Rosetta Code:

 http://rosettacode.org/wiki/Category:D

 If he, Adam, or some other proficient D user were to do a weekly
 series breaking
 down each of those 733 examples one at a time- what idioms were used, why
 certain variations were more efficient- that could go a long way to
 introduce
 the language and its idioms to beginners.  It would provide enough
 examples for
 14 years of such a weekly series, by which time D3 will be getting
 started!

 I didn't know about rosettacode. Thanks! It also might be a great
 resource for better examples to use in the Phobos documentation.

Someone who knows about copyright/licensing would probably need to check 
that it's okay if we plan to use them verbatim. If we can't then it 
might be worth linking to the above page from somewhere on dlang.org.

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 20 March 2015 at 15:12:44 UTC, David Gileadi wrote:
 On 3/19/15 10:22 PM, Walter Bright wrote:
 On 3/19/2015 10:44 AM, Joakim wrote:
 One underused resource seems to be all the examples 
 bearophile has put on
 Rosetta Code:

 http://rosettacode.org/wiki/Category:D

 If he, Adam, or some other proficient D user were to do a 
 weekly
 series breaking
 down each of those 733 examples one at a time- what idioms 
 were used, why
 certain variations were more efficient- that could go a long 
 way to
 introduce
 the language and its idioms to beginners.  It would provide 
 enough
 examples for
 14 years of such a weekly series, by which time D3 will be 
 getting
 started!

 I didn't know about rosettacode. Thanks! It also might be a 
 great
 resource for better examples to use in the Phobos 
 documentation.

 Someone who knows about copyright/licensing would probably need 
 to check that it's okay if we plan to use them verbatim. If we 
 can't then it might be worth linking to the above page from 
 somewhere on dlang.org.


All of the content on rosettacode appears to be licensed under 
GNU FDL, I believe it would just have to be released under the 
GNU FDL or a similar copyleft license that fulfills the GNU FDL.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 8:25 AM, weaselcat wrote:
 All of the content on rosettacode appears to be licensed under GNU FDL, I
 believe it would just have to be released under the GNU FDL or a similar
 copyleft license that fulfills the GNU FDL.

http://www.gnu.org/licenses/fdl-1.2.html

Sigh, looks like we can't use it.

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 20 March 2015 at 20:34:36 UTC, Walter Bright wrote:
 On 3/20/2015 8:25 AM, weaselcat wrote:
 All of the content on rosettacode appears to be licensed under 
 GNU FDL, I
 believe it would just have to be released under the GNU FDL or 
 a similar
 copyleft license that fulfills the GNU FDL.

 http://www.gnu.org/licenses/fdl-1.2.html

 Sigh, looks like we can't use it.

all content on the dlang wiki is under the same license already?

Walter Bright <newshound2 digitalmars.com> writes:

On 3/20/2015 1:40 PM, weaselcat wrote:
 On Friday, 20 March 2015 at 20:34:36 UTC, Walter Bright wrote:
 On 3/20/2015 8:25 AM, weaselcat wrote:
 All of the content on rosettacode appears to be licensed under GNU FDL, I
 believe it would just have to be released under the GNU FDL or a similar
 copyleft license that fulfills the GNU FDL.

 http://www.gnu.org/licenses/fdl-1.2.html

 Sigh, looks like we can't use it.

 all content on the dlang wiki is under the same license already?

Phobos is under Boost.

"Laeeth Isharc" <laeeth nospamlaeeth.com> writes:

On Friday, 20 March 2015 at 20:34:36 UTC, Walter Bright wrote:
 On 3/20/2015 8:25 AM, weaselcat wrote:
 All of the content on rosettacode appears to be licensed under 
 GNU FDL, I
 believe it would just have to be released under the GNU FDL or 
 a similar
 copyleft license that fulfills the GNU FDL.

 http://www.gnu.org/licenses/fdl-1.2.html

 Sigh, looks like we can't use it.

Most of the content was written by bearophile, no?  He licensed 
it to rosettacode, but is this an exclusive license - has he 
actually given his sole rights to use his work them?  If not, you 
can use his work if he agrees.  And I would guess if one asks 
rosettacode nicely they might give rights to relicense all D 
examples (ie especially the ones bearophile didn't write) under 
boost for the dlang web site.  And even if not, it's still worth 
having them in a subdirectory under a different licence.

FG <home fgda.pl> writes:

On 2015-03-21 at 12:34, Laeeth Isharc wrote:
 has he actually given his sole rights to use his work them? [...]

ROTFL, we must be telepathically linked. :)

"Mike James" <foo bar.com> writes:

On Friday, 20 March 2015 at 20:34:36 UTC, Walter Bright wrote:
 On 3/20/2015 8:25 AM, weaselcat wrote:
 All of the content on rosettacode appears to be licensed under 
 GNU FDL, I
 believe it would just have to be released under the GNU FDL or 
 a similar
 copyleft license that fulfills the GNU FDL.

 http://www.gnu.org/licenses/fdl-1.2.html

 Sigh, looks like we can't use it.

Maybe bearophile can dual-licence them - he probably wrote most 
of them ;-)

-[=mike=-

FG <home fgda.pl> writes:

On 2015-03-20 at 16:25, weaselcat wrote:
 On Friday, 20 March 2015 at 15:12:44 UTC, David Gileadi wrote:
 Someone who knows about copyright/licensing would probably need to check that
it's okay if we plan to use them verbatim. If we can't then it might be worth
linking to the above page from somewhere on dlang.org.

 All of the content on rosettacode appears to be licensed under GNU FDL, I
believe it would just have to be released under the GNU FDL or a similar
copyleft license that fulfills the GNU FDL.

Definitely, having a link to http://rosettacode.org/wiki/Category:D would be
useful.

As for providing some of the examples in-place, there are two pieces of that
legal puzzle:

1. The definitions of the problem to solve
Most tasks on Rosetta code are common and generic: concatenate strings, sort a
collection of integers using merge/quick/whatever sort, etc., so they aren't
anything that had its first appearance on RC. Copy-pasting the exact phrasing
of those problems from RC would be a violation, but describing them on your own
certainly is not.

2. The solutions to problems
Copying those code snippets in general may violate GNU FDL (if it exceeds the
scope of citation), but if the complete D answer to a challenge on RC was
provided by bearophile, and wasn't a modification of an existing answer, *he
himself* can give you a separate licensing deal to re-use his code in whatever
way you want, because when posting a solution to RC there is no mention (I
assume that there isn't, because it would make no sense, but please verify)
that you sign over your work to them, giving RC an *exclusive* license to use
it.

"Arjan" <arjan ask.me.to> writes:

 One underused resource seems to be all the examples bearophile 
 has put on Rosetta Code:

 http://rosettacode.org/wiki/Category:D

Indeed, I found myself frequently looking though these examples. 
Thank you bearophile!

 If he, Adam, or some other proficient D user were to do a 
 weekly series breaking down each of those 733 examples one at a 
 time- what idioms were used, why certain variations were more 
 efficient- that could go a long way to introduce the language 
 and its idioms to beginners.

+1000

"weaselcat" <weaselcat gmail.com> writes:

On Thursday, 19 March 2015 at 00:52:12 UTC, Walter Bright wrote:
 On 3/18/2015 5:34 PM, cym13 wrote:
 Maybe there should be a "part 2" to the C-to-D little 
 tutorial, one that shows
 how to code at a higher level introducing gently functional 
 structures instead
 of just teaching how to write C in D. To stop thinking about 
 steps to think
 about transformations isn't an easy thing.

 Andrei and I talked about this, how we are failing to point out 
 how to idiomatically use D to advantage. We need to do a lot 
 better at this.

related:
https://p0nce.github.io/d-idioms/
http://wiki.dlang.org/Tutorials

Walter Bright <newshound2 digitalmars.com> writes:

On 3/18/2015 4:41 PM, Walter Bright wrote:
 #include <stdbool.h>
 #include <stdio.h>

 typedef long T;
 bool find(T *array, size_t dim, T t) {
   int i;
   for (i = 0; i <= dim; i++);
   {
      int v = array[i];
      if (v == t)
          return true;
   }
 }

Bugs:

1. i should be size_t
2. <= should be <
3. extraneous ;
4. v should be type T
5. missing return

FG <home fgda.pl> writes:

On 2015-03-19 at 09:41, Walter Bright wrote:
 On 3/18/2015 4:41 PM, Walter Bright wrote:
 #include <stdbool.h>
 #include <stdio.h>

 typedef long T;
 bool find(T *array, size_t dim, T t) {
   int i;
   for (i = 0; i <= dim; i++);
   {
      int v = array[i];
      if (v == t)
          return true;
   }
 }

 Bugs:

 1. i should be size_t
 2. <= should be <
 3. extraneous ;
 4. v should be type T
 5. missing return

Two more things, I believe, but they aren't really internal bugs of find:
a null array or array > 2GB on 32-bit that would cause negative indexing:

assert(array != 0);
assert(dim <= PTRDIFF_MAX);

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/18/15 4:53 AM, Elazar Leibovich wrote:
 On Friday, 13 March 2015 at 17:31:09 UTC, Andrei Alexandrescu wrote:
 For example the expression (assuming s is e.g. a string)

   File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 opens a file, progressively reads chunks of 4KB, stitches them
 together at no cost, compares against a prefix until it makes a
 decision, then closes the file and returns the result. A putative Go
 user wouldn't even dream of using HasPrefix directly on a stream
 coming from a file; the whole endeavor would be a function that
 painstakingly takes all of these steps by hand.

 I personally, would have no idea what this piece of code is doing
 upon first sight. I'll have to look at the documentation of
 at least two functions to understand that, and I'll have to
 think carefully about what and who would throw in case of an error.

Yah, that's a problem with documentation. Such idioms should be well known.

 Something like

      while (n != EOF) {
          n = read(fd, buf, sizeof(buf));
          if (n==-1) throw(...);
          if (strcmp(buf, PREFIX) == 0) {
               return buf;
          }
      }
      return NULL;

 Requires no prior knowledge, and have similar effect.

And doesn't work. The code that works is a fair amount less trivial than 
that, and actually needs to do pretty much what the algorithms do.

 I'd rather have a loop written by hand in my production code any day,
 so that when debugging it, and reading it I'll have easier time
 to understand it, even though it would cost me a few more lines
 when writing the code.

No.

 What if this pattern repeats a few times in the code?

So much the better.

 I'd rather have a single function that have the explicit loop than
 having this pattern in slight variations spread in the code.

No.

 Writing code is easy, maintaining it afterwards is costly.

Agreed but works against your point.


Andrei

"weaselcat" <weaselcat gmail.com> writes:

On Wednesday, 18 March 2015 at 11:53:06 UTC, Elazar Leibovich 
wrote:
 On Friday, 13 March 2015 at 17:31:09 UTC, Andrei Alexandrescu 
 wrote:
 For example the expression (assuming s is e.g. a string)

  File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 opens a file, progressively reads chunks of 4KB, stitches them 
 together at no cost, compares against a prefix until it makes 
 a decision, then closes the file and returns the result. A 
 putative Go user wouldn't even dream of using HasPrefix 
 directly on a stream coming from a file; the whole endeavor 
 would be a function that painstakingly takes all of these 
 steps by hand.

 I personally, would have no idea what this piece of code is 
 doing
 upon first sight. I'll have to look at the documentation of
 at least two functions to understand that, and I'll have to
 think carefully about what and who would throw in case of an 
 error.

 Something like

     while (n != EOF) {
         n = read(fd, buf, sizeof(buf));
         if (n==-1) throw(...);
         if (strcmp(buf, PREFIX) == 0) {
              return buf;
         }
     }
     return NULL;

 Requires no prior knowledge, and have similar effect.

 I'd rather have a loop written by hand in my production code 
 any day,
 so that when debugging it, and reading it I'll have easier time
 to understand it, even though it would cost me a few more lines
 when writing the code.

 What if this pattern repeats a few times in the code?

 I'd rather have a single function that have the explicit loop 
 than
 having this pattern in slight variations spread in the code.

 Writing code is easy, maintaining it afterwards is costly.

I don't want to come off as rude, but your response sounds like 
someone who has little to no experience with functional 
programming(i.e, a C background given your example.)

One of the major ways D parts with the C-family is it has a 
strong foothold in functional programming and blends it together 
extremely well. IMO using D like a better C is hurting only 
yourself - functional programming is great. : )

Walter Bright <newshound2 digitalmars.com> writes:

On 3/18/2015 4:53 AM, Elazar Leibovich wrote:
 On Friday, 13 March 2015 at 17:31:09 UTC, Andrei Alexandrescu wrote:
   File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 Something like

      while (n != EOF) {
          n = read(fd, buf, sizeof(buf));
          if (n==-1) throw(...);
          if (strcmp(buf, PREFIX) == 0) {
               return buf;
          }
      }
      return NULL;

 Requires no prior knowledge, and have similar effect.

The trouble with the latter example is it's full of bugs. Part of the whole 
point of the former example is it's much more likely to be correct.

* should use memcmp, not strcmp which depends on a 0 termination

* the entire buf is not necessarily read

* what happens when buf is entirely read, and strcmp reads past the end

* read() sometimes requires multiple calls to fill a buffer

* the former example is complete while the latter is missing a LOT of code,
like 
opening the file, closing it, etc.

I don't want to rag too much on you for the bugs, but having buggy file reading 
loops like this is terribly commonplace. (I've done it wrong many times, too, 
and I even implemented read() and strcmp().)

Ranges+algorithms are much more likely to be correct. Yes, there is a learning 
curve to it, one has to reorient one's thinking and learn new names and what 
they do. But it's worth it, the payoff is big.

"krzaq" <dlangmailinglist krzaq.cc> writes:

 Something like

     while (n != EOF) {
         n = read(fd, buf, sizeof(buf));
         if (n==-1) throw(...);
         if (strcmp(buf, PREFIX) == 0) {
              return buf;
         }
     }
     return NULL;

 Requires no prior knowledge, and have similar effect.

I'm surprised nobody commented on "no prior knowledge". How are 
you supposed to guess what strcmp(buf, PREFIX) does if you don't 
know the function? Why is it being compared to 0? What's this -1 
magic number? What does read do? What is EOF? Unless you're born 
with C/POSIX programming knowledge, this is prior knowledge. I 
know C well enough, but it took me some time to understand what 
it does.

And honestly, compared to
   File("/tmp/a").byChunk(4096).joiner.startsWith(s)

you can easily guess that you have a file - do some nonobvious 
magic on it - and check if it starts with `s` just by reading it 
as plain English.

FG <home fgda.pl> writes:

On 2015-03-23 at 00:15, krzaq wrote:
 Something like

     while (n != EOF) {
         n = read(fd, buf, sizeof(buf));
         if (n==-1) throw(...);
         if (strcmp(buf, PREFIX) == 0) {
              return buf;
         }
     }
     return NULL;

 Requires no prior knowledge, and have similar effect.

 I'm surprised nobody commented on "no prior knowledge". How are you supposed
to guess what strcmp(buf, PREFIX) does if you don't know the function? Why is
it being compared to 0? What's this -1 magic number? What does read do? What is
EOF? Unless you're born with C/POSIX programming knowledge, this is prior
knowledge. I know C well enough, but it took me some time to understand what it
does.

Indeed. I know of strcmp (because of prior knowledge) but had to have a look at
"man 2 read" just in case to verify if read was used correctly. Of course there
is also this conveniently omitted part in throw(...). Throw what? Use switch to
go over errno and pick the suitable Exception or rather pick one generic
Exception and put the output of strerror as its msg? Why should we be bothered
with such low-level tasks?

 And honestly, compared to
   File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 you can *easily* guess that you have a file - do some nonobvious magic on it -
and check if *it* starts with `s` just by reading it as plain English.

Now you've injured yourself with your own weapon. I can guess that File(path)
opens the file for reading (probably because of other language libraries) and
that byChunk(size) reads it one chunk at a time (but frankly only because it
looked similar to byLine which I've known before), but what the hell is joiner?
Does it glue ranges together so that they appear as a single contiguous one?
Oh, wait, I may have actually read about it somewhere already. But if I didn't,
I wouldn't have a clue.

What should start with s? The file, any chunk, the joiner - whatever it meant?
It is much clearer than the loop, but I'm not sure I'd guess what it does,
because of the two middle elements in the UFCS chain. This *nonobvious magic*
may have transformed the contents of the file in a way that makes startsWith(s)
do something different.

"krzaq" <dlangmailinglist krzaq.cc> writes:

On Monday, 23 March 2015 at 11:31:16 UTC, FG wrote:
 And honestly, compared to
  File("/tmp/a").byChunk(4096).joiner.startsWith(s)

 you can *easily* guess that you have a file - do some 
 nonobvious magic on it - and check if *it* starts with `s` 
 just by reading it as plain English.

 Now you've injured yourself with your own weapon. I can guess 
 that File(path) opens the file for reading (probably because of 
 other language libraries)

That's why I used the word "guess" ;)
 and that byChunk(size) reads it one chunk at a time (but 
 frankly only because it looked similar to byLine which I've 
 known before), but what the hell is joiner? Does it glue ranges 
 together so that they appear as a single contiguous one? Oh, 
 wait, I may have actually read about it somewhere already. But 
 if I didn't, I wouldn't have a clue.

I'd argue that joiner is intuitive enough, but I agree on 
byChunk. I am also baffled why this byLine/byChunk madness is 
necessary at all, it should be something like
File("path").startsWith(s)
or
File("path").data.startswith(s)

The same goes for stdin, something as simple as cin >> 
intvariable in C++ rises to an almost insurmountable task in D.

 What should start with s? The file, any chunk, the joiner - 
 whatever it meant? It is much clearer than the loop, but I'm 
 not sure I'd guess what it does, because of the two middle 
 elements in the UFCS chain. This *nonobvious magic* may have 
 transformed the contents of the file in a way that makes 
 startsWith(s) do something different.

You're right, I didn't even think of that.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/23/15 4:59 AM, krzaq wrote:
 File("path").data.startswith(s)

We could define File.byByte, but that's minor. I appreciate the ability 
to decide on the buffering strategy. -- Andrei

FG <home fgda.pl> writes:

On 2015-03-23 at 12:59, krzaq wrote:
 I'd argue that joiner is intuitive enough, but I agree on byChunk. I am also
baffled why this byLine/byChunk madness is necessary at all, it should be
something like
 File("path").startsWith(s)
 or
 File("path").data.startswith(s)

Yeah, that would be useful for example to test magic values at the beginning of
files:

     string[] scripts;
     foreach (string path; dirEntries(topDir, SpanMode.depth))

             scripts ~= path;

but that's the simplest case of a bigger problem, because here you just need
the first few bytes, and you don't want to read the whole file, nor anything
more than a sector.

OTOH, there are also file formats like ZIP that put the meta information at the
end of the file and scatter the rest of the data all over the place using
offset information. You don't need to read everything just to grab the
metadata. But, when I had a look at the sources of libzip, I went crazy seeing
all the code performing tons of file seeking, reading into buffers and handling
them[1].

D's std.zip took a simple approach and doesn't deal with that at all; it reads
the whole file into the memory. That makes the algorithm more clearly visible,
but at the same time it makes the module completely useless if you want to
handle archives that are larger than the available memory, and over-the-top if
all you wanted was to extract a single file from the archive or only read the
directory structure.

So, how do you envision something representing a file, i.e. a mix of
"BufferedRange" and "SeekableRange", that would neatly handle buffering and
seeking, without you dropping to stdc IO or wanting to shoot yourself when you
look at the code?


[1] for your amusement: http://hg.nih.at/libzip/file/78b8e3fa72a0/lib/zip_open.c

Leandro Motta Barros via Digitalmars-d <digitalmars-d puremagic.com> writes:

I've not being following this list too closely, so forgive me if this has
been discussed before. Here's a simple suggestion that maybe could improve
D docs a bit.

Perhaps, psychologically, the worst about the docs is that the function
signature is used as a kind of section title. What about just reordering
things a bit? Something like:

------

**startsWith**  [this is the title, rendered in some very prominent way.
Just the function name, no parameters or anything else]

*Examples:*
// ...    [the examples section we already have today.]

*Detailed description*:  [the complete docs, as we have today]

-----

I believe the examples would do a better first impression than the full
function signature, with all runtime and template parameters. I guess most
people searching just want to see how to use the thing in the simplest
cases anyway.

This could be improved in many ways. I actually started to write some other
suggestions, but then gave up. My strongest point is that just reordering
the things could be a way to improve the perception of D with minimal
effort.

Cheers,

LMB







On Fri, Mar 13, 2015 at 12:17 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On 3/13/15 7:51 AM, Chris wrote:

 On Friday, 13 March 2015 at 14:34:23 UTC, Russel Winder wrote:

 On Fri, 2015-03-13 at 14:20 +0000, Chris via Digitalmars-d wrote:
 [...]

  reluctant to learn something new. Crowd 2. we can win over, yet we
 have failed to communicate with them, to reach out to them. Most
 people I know have a look at D's homepage and say "Uh! Hm. Ah, I'll
 use Python." No, they are not hardcore programmers, they are
 engineers and scientists. But they are _users_, people who need to
 write software to analyze data, to create something. We should not
 ignore them, even if they are not (initially) interested in templates
 and metaprogramming. Neither was I, when I first learned D.

 It is not Python or R or Julia the language that people choose, it is
 the superstructure built on top. So for Python, it is Pandas,
 Matplotlib, SciPy, NumPy. And the ability to use ready made C, C++ and
 Fortran libraries.

 Exactly, that's part of it. People don't understand that they can use
 all the C libraries with D as well. And if they do, "extern (C)" is too
 "complicated", at least more complicated than "import numbergrind". I'm
 really at loss here, I don't know how to communicate these things to
 people. Colleagues and text books that talk about R and Python weigh so
 much more than "D can actually interface to C without any effort".[1]

 Also, sometimes I have the impression that people use any excuse not to
 use D.

 That may as well be basic psychology at work. Curb appeal (or lack
 thereof) is difficult to explain but is easy to rationalize with unrelated
 arguments.

 There is something loosely related to curb appeal that has been discussed
 here before. Consider someone just starts with D and wants to figure
 whether there's a startsWith function in D.

 So they google for something like ``dlang startswith''. Nicely enough
 http://dlang.org/phobos/std_algorithm.html comes up first. (Ideally the
 individual page http://dlang.org/library/std/algorithm/starts_with.html
 would come up.)

 Anyhow, assuming the user clicks on the former, startsWith is easy to find
 at the top and then when you click on it...

 ====
 uint startsWith(alias pred = "a == b", Range, Needles...)(Range
 doesThisStart, Needles withOneOfThese) if (isInputRange!Range &&
 Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart,
 withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart,
 withOneOfThese[1..$])) : uint));
 bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, R2
 withThis) if (isInputRange!R1 && isInputRange!R2 &&
 is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool));
 bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E withThis)
 if (isInputRange!R && is(typeof(binaryFun!pred(doesThisStart.front,
 withThis)) : bool));
 ====

 This in big bold font, too. The HTML way of saying, "you wanted
 startsWith? I'll give you more startsWith than you can carry." Picture the
 effect this has on someone who just wanted to see if a string starts with
 another.

 We need to make the template constraints distinct for formatting in ddoc.

 Sadly http://dlang.org/library/std/algorithm/starts_with.html is bad in
 other ways. It doesn't have any examples! In contrast, the unified page
 does have some decent examples.

 This all is under the "curb appeal" category.


 Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 10:03 AM, Leandro Motta Barros via Digitalmars-d wrote:
 **startsWith**  [this is the title, rendered in some very prominent way.
 Just the function name, no parameters or anything else]

Yah, that'd be nice, and hopefully somewhat automatic with the new-style 
documentation page-per-function.

One issue I see here is that it's difficult to group together functions 
with slightly different names but related functionality (e.g. findSplit, 
findSplitBefore, findSplitAfter).


Andrei

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 10:35 AM, Andrei Alexandrescu wrote:
 One issue I see here is that it's difficult to group together functions with
 slightly different names but related functionality (e.g. findSplit,
 findSplitBefore, findSplitAfter).

That's what

   See Also:
        findSplit, findSplitBefore, findSplitAfter

is for.

"Jacob Carlborg" <doob me.com> writes:

On Friday, 13 March 2015 at 15:17:06 UTC, Andrei Alexandrescu 
wrote:

 There is something loosely related to curb appeal that has been 
 discussed here before. Consider someone just starts with D and 
 wants to figure whether there's a startsWith function in D.

 So they google for something like ``dlang startswith''. Nicely 
 enough http://dlang.org/phobos/std_algorithm.html comes up 
 first. (Ideally the individual page 
 http://dlang.org/library/std/algorithm/starts_with.html would 
 come up.)

 Anyhow, assuming the user clicks on the former, startsWith is 
 easy to find at the top and then when you click on it...

 ====
 uint startsWith(alias pred = "a == b", Range, Needles...)(Range 
 doesThisStart, Needles withOneOfThese) if (isInputRange!Range 
 && Needles.length > 1 && 
 is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : 
 bool) && is(typeof(.startsWith!pred(doesThisStart, 
 withOneOfThese[1..$])) : uint));
 bool startsWith(alias pred = "a == b", R1, R2)(R1 
 doesThisStart, R2 withThis) if (isInputRange!R1 && 
 isInputRange!R2 && 
 is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) 
 : bool));
 bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E 
 withThis) if (isInputRange!R && 
 is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : 
 bool));
 ====

 This in big bold font, too. The HTML way of saying, "you wanted 
 startsWith? I'll give you more startsWith than you can carry." 
 Picture the effect this has on someone who just wanted to see 
 if a string starts with another.

I agree https://issues.dlang.org/show_bug.cgi?id=13676

--
Jacob Carlborg

"Almighty Bob" <bob almighty.com> writes:

On Friday, 13 March 2015 at 15:17:06 UTC, Andrei Alexandrescu 
wrote:
 This in big bold font, too. The HTML way of saying, "you wanted 
 startsWith? I'll give you more startsWith than you can carry." 
 Picture the effect this has on someone who just wanted to see 
 if a string starts with another.

 We need to make the template constraints distinct for 
 formatting in ddoc.

 Sadly http://dlang.org/library/std/algorithm/starts_with.html 
 is bad in other ways. It doesn't have any examples! In 
 contrast, the unified page does have some decent examples.

 This all is under the "curb appeal" category.

The language reference is pretty abysmal too. EG...

The language "Introduction" spends all it's time talking about 
phases of compilation. That's like introducing someone to driving 
by explaining how the internal combustion engine works.

The page on templates starts with scope and instantiation 
details. The examples at the start have alias parameters which 
aren't explained until half way down the page.

I mean why no start the template page with something that people 
will find familiar and then build on that?

It has that feel all the way through. You go looking for things 
and they never seem to be where you expect, or they are so 
tersely explained, it feels like it's a reference for people 
already experts in D. Which is fine if that's what it's meant to 
be ... but if you want to attract new people you need a "guided 
tour" rather than a "technical spec".

"Alex Parrill" <initrd.gz gmail.com> writes:

On Friday, 13 March 2015 at 21:02:39 UTC, Almighty Bob wrote:
 The language reference is pretty abysmal too. EG...

 The language "Introduction" spends all it's time talking about 
 phases of compilation. That's like introducing someone to 
 driving by explaining how the internal combustion engine works.

 The page on templates starts with scope and instantiation 
 details. The examples at the start have alias parameters which 
 aren't explained until half way down the page.

 I mean why no start the template page with something that 
 people will find familiar and then build on that?

 It has that feel all the way through. You go looking for things 
 and they never seem to be where you expect, or they are so 
 tersely explained, it feels like it's a reference for people 
 already experts in D. Which is fine if that's what it's meant 
 to be ... but if you want to attract new people you need a 
 "guided tour" rather than a "technical spec".

The language reference is a reference; it's supposed to be a
technical spec, not a starting point. That said, the only links 
to starting points are the book (which isn't free) and the 
"Programming in D" pages at
http://ddili.org/ders/d.en/index.html (which are now buried in 
the Articles tab)

"Almighty Bob" <bob almighty.com> writes:

On Friday, 13 March 2015 at 21:11:46 UTC, Alex Parrill wrote:
 On Friday, 13 March 2015 at 21:02:39 UTC, Almighty Bob wrote:
 The language reference is pretty abysmal too. EG...


 It has that feel all the way through. You go looking for 
 things and they never seem to be where you expect, or they are 
 so tersely explained, it feels like it's a reference for 
 people already experts in D. Which is fine if that's what it's 
 meant to be ... but if you want to attract new people you need 
 a "guided tour" rather than a "technical spec".

 The language reference is a reference; it's supposed to be a
 technical spec, not a starting point. That said, the only links 
 to starting points are the book (which isn't free) and the 
 "Programming in D" pages at
 http://ddili.org/ders/d.en/index.html (which are now buried in 
 the Articles tab)

Well I figured that was probably the case.

It's just not very smart to have that as the only obvious guide 
to the language on the home page.

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 21:52:30 UTC, Almighty Bob wrote:
 On Friday, 13 March 2015 at 21:11:46 UTC, Alex Parrill wrote:
 On Friday, 13 March 2015 at 21:02:39 UTC, Almighty Bob wrote:
 The language reference is pretty abysmal too. EG...


 It has that feel all the way through. You go looking for 
 things and they never seem to be where you expect, or they 
 are so tersely explained, it feels like it's a reference for 
 people already experts in D. Which is fine if that's what 
 it's meant to be ... but if you want to attract new people 
 you need a "guided tour" rather than a "technical spec".

 The language reference is a reference; it's supposed to be a
 technical spec, not a starting point. That said, the only 
 links to starting points are the book (which isn't free) and 
 the "Programming in D" pages at
 http://ddili.org/ders/d.en/index.html (which are now buried in 
 the Articles tab)

 Well I figured that was probably the case.

 It's just not very smart to have that as the only obvious guide 
 to the language on the home page.

There's a "Books and Articles" dropdown on the frontpage, Ali's 
book is the first link.

It's very good. I refer to it constantly.

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 22:02:42 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 21:52:30 UTC, Almighty Bob wrote:
 On Friday, 13 March 2015 at 21:11:46 UTC, Alex Parrill wrote:
 On Friday, 13 March 2015 at 21:02:39 UTC, Almighty Bob wrote:
 The language reference is pretty abysmal too. EG...


 It has that feel all the way through. You go looking for 
 things and they never seem to be where you expect, or they 
 are so tersely explained, it feels like it's a reference for 
 people already experts in D. Which is fine if that's what 
 it's meant to be ... but if you want to attract new people 
 you need a "guided tour" rather than a "technical spec".

 The language reference is a reference; it's supposed to be a
 technical spec, not a starting point. That said, the only 
 links to starting points are the book (which isn't free) and 
 the "Programming in D" pages at
 http://ddili.org/ders/d.en/index.html (which are now buried 
 in the Articles tab)

 Well I figured that was probably the case.

 It's just not very smart to have that as the only obvious 
 guide to the language on the home page.

 There's a "Books and Articles" dropdown on the frontpage, Ali's 
 book is the first link.

 It's very good. I refer to it constantly.

Wow, I failed at reading. Didn't realize that section was already
mentioned.

"Almighty Bob" <bob almighty.com> writes:

On Friday, 13 March 2015 at 22:02:42 UTC, weaselcat wrote:
 On Friday, 13 March 2015 at 21:52:30 UTC, Almighty Bob wrote:
 Well I figured that was probably the case.

 It's just not very smart to have that as the only obvious 
 guide to the language on the home page.

 There's a "Books and Articles" dropdown on the frontpage, Ali's 
 book is the first link.

 It's very good. I refer to it constantly.

I would bet someone new to the D website and wanting to learn the 
language will click on things in this order...

1. Tutorial, only to be taken to the first chapter of a book that 
is not free.
2. Language reference, to be taken to terse reference docs for 
experienced users.
3. If they are still around they may try "Articles". When they 
click on articles up pops a page entitled..."Real Close to the 
Machine: Floating Point in D".

Why does clicking on "Articles" open an article on floating point 
math?

Why is Ali's book just linked as "Online Book (free)".

Where's the "getting Started"???

Yes the information is there but its "hidden in the bottom of a 
locked filing cabinet stuck in a disused lavatory with a sign on 
the door saying Beware of the Leopard."

"Israel" <tl12000 live.com> writes:

On Saturday, 14 March 2015 at 01:40:50 UTC, Almighty Bob wrote:
 1. Tutorial, only to be taken to the first chapter of a book 
 that is not free.
 2. Language reference, to be taken to terse reference docs for 
 experienced users.
 3. If they are still around they may try "Articles". When they 
 click on articles up pops a page entitled..."Real Close to the 
 Machine: Floating Point in D".

 Why does clicking on "Articles" open an article on floating 
 point math?

 Why is Ali's book just linked as "Online Book (free)".

 Where's the "getting Started"???

This is what i proposed but i guess we have to step up and write
a "Proper" getting started page...

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 2:02 PM, Almighty Bob wrote:
 The language reference is pretty abysmal too. EG...

 The language "Introduction" spends all it's time talking about phases of
 compilation. That's like introducing someone to driving by explaining
 how the internal combustion engine works.

 The page on templates starts with scope and instantiation details. The
 examples at the start have alias parameters which aren't explained until
 half way down the page.

 I mean why no start the template page with something that people will
 find familiar and then build on that?

 It has that feel all the way through. You go looking for things and they
 never seem to be where you expect, or they are so tersely explained, it
 feels like it's a reference for people already experts in D. Which is
 fine if that's what it's meant to be ... but if you want to attract new
 people you need a "guided tour" rather than a "technical spec".

The language reference is fine if arid. One shouldn't learn the language 
from its reference. It should be, however, complemented by tutorials. -- 
Andrei

"Charles Pritchard" <chuck jumis.com> writes:

On Friday, 13 March 2015 at 23:10:21 UTC, Andrei Alexandrescu 
wrote:
 On 3/13/15 2:02 PM, Almighty Bob wrote:
 The language reference is pretty abysmal too. EG...


...
 The page on templates starts with scope and instantiation 
 details. The
 examples at the start have alias parameters which aren't 
 explained until
 half way down the page.

 The language reference is fine if arid. One shouldn't learn the 
 language from its reference. It should be, however, 
 complemented by tutorials. -- Andrei


On the language reference:

The D documentation as an introduction is readable, though large. 
Relative to that, the DLib documentation hurts.
http://dlang.org/arrays.html
http://dlang.org/phobos/std_array.html

When I was new to PHP, I can tell you that the php.net/<funcname> 
method of learning was a big help. It redirected me to the 
appropriate manual page and manual pages had code snippets, often 
provided in the comments section.


As an example, I want to do something random, and the PHP docs 
are much easier to understand.
http://php.net/rand
http://dlang.org/phobos/std_random.html


-Charles

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 7:51 AM, Chris wrote:
 Also, sometimes I have the impression that people use any excuse not to use D.

I've learned to be careful when people say "I can't use [insert your product] 
because of X." All too often, it isn't X at all. I discovered this by
addressing 
the problem, and going back to the person and saying "X is solved", and they 
just kind of mumble a bit and say "that's great, but I still can't use it 
because of Y."

(Ironically, they'll often be using Product Z that also has flaw X and Y.)

In other words, X and Y are not the real reasons. The real reason may be 
something that isn't too palatable to say, so they look around for a real or 
imagined flaw, something that is more presentable, and say that.

It's important for us to find the real reasons, instead of chasing pots 'o gold 
at the end of rainbows.

"Paolo Invernizzi" <paolo.invernizzi no.address> writes:

On Friday, 13 March 2015 at 19:18:27 UTC, Walter Bright wrote:
 It's important for us to find the real reasons, instead of 
 chasing pots 'o gold at the end of rainbows.

I suggest reading something about the lean startup methodology...
It really opens mind about issues like that.
---
Paolo

"engnieer" <engineer eng.com> writes:

 [1] The problem is that all these nice Python and R 
 implementations are practically useless for real world 
 applications. Too slow, too cumbersome, too many dependencies. 
 It has to be rewritten anyway. (I'd be happy, if they used at 
 least C.)

No, no, no. Your "real world" doesn't seem to include all the 
engineering industries. I work for an engineer company and use 
python everywhere for application code, and of course 
matlab-simulink for hard realtime code.

For us, Russel's comment on super structure is right on target.

- engineer.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 5:33 PM, engnieer wrote:
 [1] The problem is that all these nice Python and R implementations
 are practically useless for real world applications. Too slow, too
 cumbersome, too many dependencies. It has to be rewritten anyway. (I'd
 be happy, if they used at least C.)

 No, no, no. Your "real world" doesn't seem to include all the
 engineering industries. I work for an engineer company and use python
 everywhere for application code, and of course matlab-simulink for hard
 realtime code.

 For us, Russel's comment on super structure is right on target.

I, too, have friends who use panda and such at work, -- Andrei

"Chris" <wendlec tcd.ie> writes:

On Saturday, 14 March 2015 at 00:33:43 UTC, engnieer wrote:
 [1] The problem is that all these nice Python and R 
 implementations are practically useless for real world 
 applications. Too slow, too cumbersome, too many dependencies. 
 It has to be rewritten anyway. (I'd be happy, if they used at 
 least C.)

 No, no, no. Your "real world" doesn't seem to include all the 
 engineering industries. I work for an engineer company and use 
 python everywhere for application code, and of course 
 matlab-simulink for hard realtime code.

 For us, Russel's comment on super structure is right on target.

 - engineer.

Unfortunately, for speech and language processing (synthesis, 
speech recognition etc) Python is too slow. Everybody uses Python 
at first, but the serious code that is later put into real world 
applications is usually written in C or C++. This is a fact. I 
know people who developed speech analysis frameworks in Python 
and are now thinking of rewriting it in C++ for commercial 
purposes.

Python is good for protoyping, but if you need fast applications, 
it is usually C/C++ (or D).

"Chris" <wendlec tcd.ie> writes:

On Saturday, 14 March 2015 at 17:22:27 UTC, Chris wrote:
 On Saturday, 14 March 2015 at 00:33:43 UTC, engnieer wrote:
 [1] The problem is that all these nice Python and R 
 implementations are practically useless for real world 
 applications. Too slow, too cumbersome, too many 
 dependencies. It has to be rewritten anyway. (I'd be happy, 
 if they used at least C.)

 No, no, no. Your "real world" doesn't seem to include all the 
 engineering industries. I work for an engineer company and use 
 python everywhere for application code, and of course 
 matlab-simulink for hard realtime code.

 For us, Russel's comment on super structure is right on target.

 - engineer.

 Unfortunately, for speech and language processing (synthesis, 
 speech recognition etc) Python is too slow. Everybody uses 
 Python at first, but the serious code that is later put into 
 real world applications is usually written in C or C++. This is 
 a fact. I know people who developed speech analysis frameworks 
 in Python and are now thinking of rewriting it in C++ for 
 commercial purposes.

 Python is good for protoyping, but if you need fast 
 applications, it is usually C/C++ (or D).

And by the way, the fast Python code is usually a module written 
in C or some Cython magic. So it's back to C again.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 17:24 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]
=20
 And by the way, the fast Python code is usually a module written=20
 in C or some Cython magic. So it's back to C again.

What is wrong with that. It is entirely reasonable for there to be C, C
++ or D components to a Python system. There is no law forbidding this
mix.

And people are using Numba these days which uses LLVM and not C to
create native code from Python. Using Numba avoids all the annotations
that are needed for Cython.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 17:22 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]
=20
 Unfortunately, for speech and language processing (synthesis,=20
 speech recognition etc) Python is too slow. Everybody uses Python=20
 at first, but the serious code that is later put into real world=20
 applications is usually written in C or C++. This is a fact. I=20
 know people who developed speech analysis frameworks in Python=20
 and are now thinking of rewriting it in C++ for commercial=20
 purposes.

I can believe it is believed to be true, but this is based on metrics
for using only pure Python. I bet you can get good performance just with
judicious profiling and use of Cython or better still Numba.

"Commercial reasons" may well include "we are not prepared to ship
Python source code, so you will rewrite in C or C++ so we can ship a
binary executable" and be nothing to do with performance. I have had
this in the past.

 Python is good for protoyping, but if you need fast applications,=20
 it is usually C/C++ (or D).

If you just use pure Python yes. But no-one does. it is always mixed
systems. Why rewrite the Python that is not performance critical in C, C
++, or D, there is no point.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Chris" <wendlec tcd.ie> writes:

On Saturday, 14 March 2015 at 18:01:57 UTC, Russel Winder wrote:
 On Sat, 2015-03-14 at 17:22 +0000, Chris via Digitalmars-d 
 wrote:
 […]
 
 Unfortunately, for speech and language processing (synthesis, 
 speech recognition etc) Python is too slow. Everybody uses 
 Python at first, but the serious code that is later put into 
 real world applications is usually written in C or C++. This 
 is a fact. I know people who developed speech analysis 
 frameworks in Python and are now thinking of rewriting it in 
 C++ for commercial purposes.

 I can believe it is believed to be true, but this is based on 
 metrics
 for using only pure Python. I bet you can get good performance 
 just with
 judicious profiling and use of Cython or better still Numba.

 "Commercial reasons" may well include "we are not prepared to 
 ship
 Python source code, so you will rewrite in C or C++ so we can 
 ship a
 binary executable" and be nothing to do with performance. I 
 have had
 this in the past.

This may be part of it. But I know that open source free software 
in this sector is also written in C/C++ or Java. I haven't seen a 
single system that was acceptable in Python. Sooner or later they 
all go back to C.

I just don't see the point in using Python only to rewrite 
performance critical parts in C/C++ or D. Why not start with D or 
C from scratch. Also, I know that this Cython and C module mixing 
becomes a mess very quickly which makes development tricky and 
deployment a pain in the a**. I believe that as soon as you have 
to mix languages like that, there is something wrong, and you 
begin to rely heavily on an infrastructure that helps you to keep 
track of the whole mess.

 Python is good for protoyping, but if you need fast 
 applications, it is usually C/C++ (or D).

 If you just use pure Python yes. But no-one does. it is always 
 mixed
 systems. Why rewrite the Python that is not performance 
 critical in C, C
 ++, or D, there is no point.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sat, 2015-03-14 at 18:11 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]
=20
 This may be part of it. But I know that open source free software=20
 in this sector is also written in C/C++ or Java. I haven't seen a=20
 single system that was acceptable in Python. Sooner or later they=20
 all go back to C.

Java will have the same problem as Python regarding shipping source to
anyone who knowns how to decompile Java.

 I just don't see the point in using Python only to rewrite=20
 performance critical parts in C/C++ or D. Why not start with D or=20
 C from scratch. Also, I know that this Cython and C module mixing=20
 becomes a mess very quickly which makes development tricky and=20
 deployment a pain in the a**. I believe that as soon as you have=20
 to mix languages like that, there is something wrong, and you=20
 begin to rely heavily on an infrastructure that helps you to keep=20
 track of the whole mess.

I would reject C as a language of implementation for everything except
small operating systems =E2=80=93 which includes many embedded things, most
being effectively operating systems. I can see people using C++, but it
would be better if they used D, but I doubt this will happen :-(

Mixing Python, Cython, and C does require standard compiled project
management, but is no worse than pure C, C++ or D systems. I would
suggest that the "messiness" is due to the Python people not doing the
Cython and C properly, and the C people objecting to having Python
involved. It usually comes down to the people and not the technology.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Chris" <wendlec tcd.ie> writes:

On Saturday, 14 March 2015 at 18:33:24 UTC, Russel Winder wrote:
 On Sat, 2015-03-14 at 18:11 +0000, Chris via Digitalmars-d 
 wrote:
 […]
 
 This may be part of it. But I know that open source free 
 software in this sector is also written in C/C++ or Java. I 
 haven't seen a single system that was acceptable in Python. 
 Sooner or later they all go back to C.

 Java will have the same problem as Python regarding shipping 
 source to
 anyone who knowns how to decompile Java.

 I just don't see the point in using Python only to rewrite 
 performance critical parts in C/C++ or D. Why not start with D 
 or C from scratch. Also, I know that this Cython and C module 
 mixing becomes a mess very quickly which makes development 
 tricky and deployment a pain in the a**. I believe that as 
 soon as you have to mix languages like that, there is 
 something wrong, and you begin to rely heavily on an 
 infrastructure that helps you to keep track of the whole mess.

 I would reject C as a language of implementation for everything 
 except
 small operating systems – which includes many embedded things, 
 most
 being effectively operating systems. I can see people using 
 C++, but it
 would be better if they used D, but I doubt this will happen :-(

 Mixing Python, Cython, and C does require standard compiled 
 project
 management, but is no worse than pure C, C++ or D systems. I 
 would
 suggest that the "messiness" is due to the Python people not 
 doing the
 Cython and C properly, and the C people objecting to having 
 Python
 involved. It usually comes down to the people and not the 
 technology.

But why do they keep inventing new technologies and compilation 
methods for Python when it's already soooo good? Every year I 
hear "now Python is fast", "now you can write fast and efficient 
code in Python", and more often than not it is some C-based 
stuff, some additional layer of complexity.

Try to integrate Python into third party software or some OS 
framework, and you'll begin to hate it. The question of which 
version of Python to use is enough to put you off. Some programs 
are delivered with their own Python version to avoid problems. 
All this is messy, not clean. I've seen it, and I've done it. I 
prefer D that gives me native efficiency and can interface with 
C. No Cython magic needed.

"stewarth" <growlercab gmail.com> writes:

On Saturday, 14 March 2015 at 18:33:24 UTC, Russel Winder wrote:
 On Sat, 2015-03-14 at 18:11 +0000, Chris via Digitalmars-d 
 wrote:
 […]
 
 This may be part of it. But I know that open source free 
 software in this sector is also written in C/C++ or Java. I 
 haven't seen a single system that was acceptable in Python. 
 Sooner or later they all go back to C.

 Java will have the same problem as Python regarding shipping 
 source to
 anyone who knowns how to decompile Java.

 I just don't see the point in using Python only to rewrite 
 performance critical parts in C/C++ or D. Why not start with D 
 or C from scratch. Also, I know that this Cython and C module 
 mixing becomes a mess very quickly which makes development 
 tricky and deployment a pain in the a**. I believe that as 
 soon as you have to mix languages like that, there is 
 something wrong, and you begin to rely heavily on an 
 infrastructure that helps you to keep track of the whole mess.

 I would reject C as a language of implementation for everything 
 except
 small operating systems – which includes many embedded things, 
 most
 being effectively operating systems. I can see people using 
 C++, but it
 would be better if they used D, but I doubt this will happen :-(

 Mixing Python, Cython, and C does require standard compiled 
 project
 management, but is no worse than pure C, C++ or D systems. I 
 would
 suggest that the "messiness" is due to the Python people not 
 doing the
 Cython and C properly, and the C people objecting to having 
 Python
 involved. It usually comes down to the people and not the 
 technology.

+1

Using Python with C++ for small critical sections reduces our 
code development and maintenance costs significantly. The C++ 
constitutes about 3% of our code base. For the rest Python does 
the job very well.

There is no mess, the code base and build system are nicely 
segregated into performance critical code and the rest.

My hope is that D can replace the Python/C++ mix with one 
language that is both cheap for development/maintenance and 
achieve the C++ performance when necessary.

But even with a single language the performance critical code 
would still be kept separate. It can often get messy and it's 
important that only those with specific algorithm and low-level 
expertise make changes in it.

Cheers,
Stew

"engnieer" <engineer eng.com> writes:

 Unfortunately, for speech and language processing (synthesis, 
 speech recognition etc) Python is too slow. Everybody uses 
 Python at first, but the serious code that is later put into 
 real world applications is usually written in C or C++. This is 
 a fact. I know people who developed speech analysis frameworks 
 in Python and are now thinking of rewriting it in C++ for 
 commercial purposes.

 Python is good for protoyping, but if you need fast 
 applications, it is usually C/C++ (or D).


What you are saying is not wrong, except for the generalizations 
to "everybody".

Obviously you are not aware of the other people/industries who 
use python for non-performane critical applications (not 
prototype, but real large applications), there are several 
reasons, but don't want to bore you with details (one of which is 
the "super structure").

I do wish we were using D everywhere, and I do use it for 
personal and small tools at the job.

- engineer

"Chris" <wendlec tcd.ie> writes:

On Sunday, 15 March 2015 at 00:14:44 UTC, engnieer wrote:
 Unfortunately, for speech and language processing (synthesis, 
 speech recognition etc) Python is too slow. Everybody uses 
 Python at first, but the serious code that is later put into 
 real world applications is usually written in C or C++. This 
 is a fact. I know people who developed speech analysis 
 frameworks in Python and are now thinking of rewriting it in 
 C++ for commercial purposes.

 Python is good for protoyping, but if you need fast 
 applications, it is usually C/C++ (or D).


 What you are saying is not wrong, except for the 
 generalizations to "everybody".

 Obviously you are not aware of the other people/industries who 
 use python for non-performane critical applications (not 
 prototype, but real large applications), there are several 
 reasons, but don't want to bore you with details (one of which 
 is the "super structure").

 I do wish we were using D everywhere, and I do use it for 
 personal and small tools at the job.

 - engineer

Of course, we all can only talk about our own experiences.

Apart from performance issues, for language processing, string 
handling etc., Python quickly becomes a nightmare (UTF-8). Then 
there are issues like the one that classes cannot really have 
private variables.

Sometimes advocacy of Python seems a bit absurd to me when it is 
along the lines of "Use Python, because it's easy. But don't use 
real Python, use Cython or Numba (and whatnot), Python is too 
slow". I.e. "Use it, but don't use it!" This shows that there is 
something wrong. You don't have this problem with D. You too wish 
you were using D everywhere, which tells me that the Python + 
C(++) solution is not optimal.

All I'm saying is that when people start a new project, I advise 
them to use D instead of Python. But there is no way to win 
against the cult of Python in scientific programming. It's too 
easy, too tempting at the start. Instant gratification and the 
feeling that you're on safe ground. D can't compete with this 
easily.

Maybe we should invent (or continue with existing efforts) to 
write a scripting language based on D (or a Python interpreter or 
something that serves as a bridge to existing technologies (other 
than C)).

If I have time, I might also put together some code snippets with 
the most common tasks in programming, like startsWith and so on.

"Laeeth Isharc" <laeeth nospamlaeeth.com> writes:

On Sunday, 15 March 2015 at 12:52:37 UTC, Chris wrote:
 Apart from performance issues, for language processing, string 
 handling etc., Python quickly becomes a nightmare (UTF-8). Then 
 there are issues like the one that classes cannot really have 
 private variables.

[I am by no means expert in Python, but python 3 does not seem to 
be an improvement if you want to be able to accomplish tasks 
involving simple processing of ASCII files]

 Sometimes advocacy of Python seems a bit absurd to me when it 
 is along the lines of "Use Python, because it's easy. But don't 
 use real Python, use Cython or Numba (and whatnot), Python is 
 too slow". I.e. "Use it, but don't use it!" This shows that 
 there is something wrong. You don't have this problem with D. 
 You too wish you were using D everywhere, which tells me that 
 the Python + C(++) solution is not optimal.

Modern people are not very good with deferred gratification.  
Python allows you to throw something working up quickly, but then 
there are less obvious costs that are deferred.  I agree that it 
doesn't seem to be a positive to have your codebase split between 
different languages - having to keep things in sync and have 
people understand both codebases.  That's one of the reasons I am 
trying to do everything in D (although for javascript charting 
looks like I have no easy alternative to using bokeh in python - 
until I can get around to writing a D implementation to make the 
JSON).

I think it would be a positive to have some user stories from 
people who have moved from Python+Cython or Python+C to D and 
seen significant benefits.  I am sure there are plenty - most 
users don't seem to be active in the forum.  And we should 
collect user stories, pretty them up, and have them reachable 
from the front page very easily.  People make decisions based 
upon feelings (indeed without feelings there can be no decision), 
and so stories - based in reality - can be more persuasive than 
dry facts in persuading people.

We should try to identify what the biggest sticking points are 
for people considering making the switch, both real (like 
documentation) and perception (like 'D has no web/server 
framework'.

 All I'm saying is that when people start a new project, I 
 advise them to use D instead of Python. But there is no way to 
 win against the cult of Python in scientific programming. It's 
 too easy, too tempting at the start. Instant gratification and 
 the feeling that you're on safe ground. D can't compete with 
 this easily.

Of course there is, but it will take time.  One wants a very high 
appeal to a small group of the potential user base initially 
(which no doubt will be the best part) and from there things will 
diffuse.  Peter Thiel makes the same point I did (based on the 
Innovator's Dilemma) in his book "Zero to One".

 Maybe we should invent (or continue with existing efforts) to 
 write a scripting language based on D (or a Python interpreter 
 or something that serves as a bridge to existing technologies 
 (other than C)).

I was thinking about this just recently.  There used to be a D 
scripting language (now rebranded as something else - I forget 
the name), but this fell into disuse post rdmd.  Rdmd is great, a 
real simple win, but doesn't substitute for a scripting language 
in all uses.

In particular, I do agree with Russell about the value of an 
ipython/Jupyter notebook for scientific computing (which means 
also parts of finance) - especially for playing with data.  Excel 
won't cut the mustard any more for many modern data sets, which 
means new tools like ipython notebooks come into focus.

For the time being it's not the lack of a notebook, but the lack 
of dataframes and pandas style functionality that prevent using D 
easily in this domain.  But dataframes are not that complicated 
or difficult, and it is just a bit of work, and Vlad Levenfeld 
has made a good start on some of this.

I wonder whether it would be feasible to integrate the D REPL 
with Jupyter.  Russell?

 If I have time, I might also put together some code snippets 
 with the most common tasks in programming, like startsWith and 
 so on.

This would be great.  I bet more generally there are many 
sections of code one has oneself (or knows of on github) that 
could be extracted and documented in a nice, aesthetically 
appealing, and structured way as part of a D tutorial series.

It would not be right to expect Herr Doktor Ruppe to do this 
work, but maybe a few could get together and start on this and 
send to him if he is open to featuring.  If/when I can, I will 
try to help.  The advantage of doing in this manner is the 
project is less overwhelming than trying to eat the elephant in a 
bite.  (The disadvantage is a loss of coherence).

"cym13" <cpicard openmailbox.org> writes:

If stories are wanted, I might as well tell mine.

It is not a success story but as a newcommer to D I feel like 
writing it down somewhere before forgetting my first impressions. 
But first, a bit of background.

I'm a CS student and an autodidact before that. I grew up with 
GNU/Linux and never worked with a Windows environment. My first 
languages were bash with which I discovered programming, a 
Scheme/Lisp (SICP) for which I did not really found it any useful 
use at the time and python in this order. I had later to learn C, 
C++, java, D and many others but bash, Scheme and python defined 
my vision of programming.

 From bash I got the Unix philosophy (simple bricks that combine 
well) and a taste for interactivity and incremental development. 
SICP gave me the mental framework needed to tackle real 
programming and a taste for functional programming. Python gave 
me a language that combined almost anything I liked from bash and 
scheme (well... I still miss my pipes) and the access to the best 
ecosystem I know about. Great and very specialized libraries, a 
mostly FOSS-oriented community, great package management (pip), 
great online docs (always clear, good search functions, 
examples), virtualenv, many repls and a *lot* of articles and 
videos on the internet. Most of all it achieved its supreme goal 
of readability.

I've been using python for many years now, mostly on little 
projects because I feel like it.

Today my time is mainly divided between teaching, software 
auditing and reverse-engineering. In the field of offensive 
security only two languages count: C for understanding low-level 
code and manipulating library structures directly and python for 
everything else. Its dev speed and *really really good* libraries 
(scapy...) make it the way to go for many.

So why use D? Well, one day I grew tired of python and almost at 
the same time I had a project that had a need for performance. I 
had tried calling python in C before and it is such a ugly mess 
that I wanted to do anything to avoid that. There are other ways 
to link the two (FFI...) but mixing python and C in the same 
files didn't feel very comfortable. Python's strength is its 
readability, putting C in it would defeat the purpose.

I had a look at Go, Rust and such but they didn't impress me at 
the time. Frankly, the one thing that sold D to me was that 
snippet on the wikipedia page:

import std.stdio : writeln;
import std.range : iota;
import std.parallelism : parallel;

void main()
{
     foreach (i; iota(10).parallel) {
         // The body of the foreach loop is executed in parallel 
for each i
         writeln("processing ", i);
     }
}

It is funny because I didn't actually have any opportunity to use 
yet it but it just felt so much like python and yet was so much 
better (python's multiprocessing is not its best point).

It is anecdotic but after reading everywhere about how fast is 
compiling D, I was very surprised to see it taking 2s for a 
regular "Hello World". I understand it better now but at the time 
I was disapointed.

Porting my python code was interesting. I could basically get 
quite the same expressiveness but getting to it was harder. At 
first I couldn't use the D documentation at all, because all the 
constraints on functions were really frightening, so my first 
documentation was actually the site 
http://rosettacode.org/wiki/Rosetta_Code where I learned many 
basic constructs.

HINT 1: this site is great, either link to and nurture it or do 
something similar on dlang.org

HINT 2: it took me about a month and a good tutorial on templates 
(btw, thanks G.Willoughby) to start understanding the full 
prototypes of standard functions. I really recommend putting the 
constraint part in slight grey so that it is still here and 
readable but the immediatly useful part of the prototype stands 
out.

HINT 3: no beginner cares about how exactly it is compiled or 
advanced metaprogramming options. This should not be more than 
mentionned in a "getting started" page. It is cool stuff, it 
should be said, but it definitely does not fit in an introduction 
to any language.

The more I used D, the better I liked its functional side (UCFS 
<3) and its safety. And the fact that it has ranges everywhere is 
great, but I still wonder why in a language that wants to use 
ranges everywhere they are so complicated to build... Not 
everybody wants to build a struct for everything. Python has 
generators everywhere, why is that? Because the syntax is easy 
and simple. Either use yield like you would use a return, either 
build one on the fly with generator expansion:

for i in (2*x for x in range(100) if x%3==0):
     print(x)

The closest I could find is foreach over a function, which is 
cool but not as easy as yield. InputRange can do more than simple 
generators but a "real" yield would cover the 90% case IMO.

But right now the real reason why I hesitate advising it to my 
friends is because of its stability. I mean, come on! I've only 
been here for something like 5 month and I've seen many 
propositions to add new features and change others. Right now is 
discussed the possibility of changing the default constness of 
variables which would most likely break a lot of code. I can't 
see how a company could think about investing into a project in D 
if they can't have any vision of how long it will be before they 
have to change theyre whole code because "such commenting syntax 
is better" or anything like that.

HINT 4: D is great. It is a good language already. Stop mutating 
it! Fix bugs, improve the standard library, work on the 
ecosystem, reduce compile-time, but do not try breaking things 
all the time. Don't even think of improving yield as I suggested 
before, I'd prefer a standard library based solution at this 
point.

Here is my feeling after some month of D. I know I'm not the 
typical target so don't take it too seriously but I felt like it 
wasn't totally pointless to report my experience.

"deadalnix" <deadalnix gmail.com> writes:

On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote:
 It is anecdotic but after reading everywhere about how fast is 
 compiling D, I was very surprised to see it taking 2s for a 
 regular "Hello World". I understand it better now but at the 
 time I was disapointed.

It would be interesting to know why you get these results. This 
is way slower than what I've experienced myself.

For instance, compiling SDC, and then using this newly compiled 
SDC to compile its runtime, from scratch, takes ~13s on my old 
laptop (Core 2 DUO P8700) and ~5s on the macbook pro.

This is tens of thousands of line of code.

Compiling an hello world is almost instantaneous as far as I 
experienced it. I do think it is interesting for you to share 
your setup so we can understand what is going on and avoid for 
another newbie to have the same experience.

Jacob Carlborg <doob me.com> writes:

On 2015-03-16 04:25, deadalnix wrote:

 Compiling an hello world is almost instantaneous as far as I experienced
 it. I do think it is interesting for you to share your setup so we can
 understand what is going on and avoid for another newbie to have the
 same experience.

It's most likely linking that takes most of the time. I think most users 
will just run the compiler (including the linking) and time it. Most 
won't care if it's the compile time or link time that is slow.

-- 
/Jacob Carlborg

"Israel" <tl12000 live.com> writes:

On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote:
 HINT 2: it took me about a month and a good tutorial on 
 templates (btw, thanks G.Willoughby) to start understanding the 
 full prototypes of standard functions. I really recommend 
 putting the constraint part in slight grey so that it is still 
 here and readable but the immediatly useful part of the 
 prototype stands out.

 HINT 3: no beginner cares about how exactly it is compiled or 
 advanced metaprogramming options. This should not be more than 
 mentionned in a "getting started" page. It is cool stuff, it 
 should be said, but it definitely does not fit in an 
 introduction to any language.

Its hard to get this across but i too would like to see a simpler 
and easier to understand tutorial on D rather than seeing all 
these complicated things. Even Ahlis book isnt that great. Its 
good, but not great.

 HINT 4: D is great. It is a good language already. Stop 
 mutating it! Fix bugs, improve the standard library, work on 
 the ecosystem, reduce compile-time, but do not try breaking 
 things all the time. Don't even think of improving yield as I 
 suggested before, I'd prefer a standard library based solution 
 at this point.

You definitely have a point. The problem is that everyone else 
see's D as an open source community driven language so everyone 
and their mother wants to contribute their own features, stuff 
like this is bound to happen.
This could also be a bad thing because if D falls behind on its 
bleeding edge mutation it could cause a collapse on people being 
interested.

"ninja" <ninja ninjutsu.com> writes:

On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote:
 If stories are wanted, I might as well tell mine.

I am an attorney and a typical "programming-language-user": I
love to code my own utilities for the job (document-creation,
bookkeeping, etc.), but I use Windows and have an android smart
phone. In the last 15 years, I tried C (which I still use for

now. I avoided Python and PHP because a good roofer listens to
his heart, not his wallet* :) My experiences so far:

1. D has to worst docs I happened to meet. I am still having
difficulties figuring out functions like 'any' and 'all', while I
understood the Ruby Enumerables at the first time. Same goes to
string manipulation. Last time I used std.zip I had to read it's
source to make my code work. That's a big warning sign.

2. Please stop changing the (core) language all the time. There
are like 3 new proposals every week in the forums and at least 2
of those are seriously considered. Please, just stop.

3. Improve Windows support. Include
http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
fact that D needs Visual Studio for 64bit apps in 2015 is a shame.

4. D needs some kind of default GUI toolkit. I can't give my
utilities to associates/friends because no one wants to use a
console any more. I know it is not a small feat, but look at Ruby
- they just bundle the last version of Tk with their installer
and maintain a thin wrapper. Tk can be love/hated (I actually
like its flat and winnative theme) but it enables out-of-the-box
platform independent desktop-developement for Ruby.

* sorry for the ancient Star Wars/Clerks reference

"bearophile" <bearophileHUGS lycos.com> writes:

ninja:

 2. Please stop changing the (core) language all the time. There
 are like 3 new proposals every week in the forums and at least 2
 of those are seriously considered. Please, just stop.

D is not yet finished. Ownership of memory in D is a 
work-in-progress. Tuples are a hole in a language that wants to 
be a little functional. Alternative ways to allocate memory are 
needed by some people. The GC needs improvements. Purity is not 
yet finished. And there are minor things that can be improved. D3 
is not planned, so the only way is to improve D2.

Bye,
bearophile

Mike Parker <aldacron gmail.com> writes:

On 3/16/2015 5:07 PM, ninja wrote:

 3. Improve Windows support. Include
 http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
 fact that D needs Visual Studio for 64bit apps in 2015 is a shame.

Including the WindowsAPI won't change this. D uses the MS toolchain to 
generate the final binaries.

Mike Parker <aldacron gmail.com> writes:

On 3/16/2015 6:02 PM, Mike Parker wrote:
 On 3/16/2015 5:07 PM, ninja wrote:

 3. Improve Windows support. Include
 http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
 fact that D needs Visual Studio for 64bit apps in 2015 is a shame.

 Including the WindowsAPI won't change this. D uses the MS toolchain to
 generate the final binaries.

Rather, DMD uses the MS toolchain.

"rumbu" <rumbu rumbu.ro> writes:

On Monday, 16 March 2015 at 09:02:20 UTC, Mike Parker wrote:
 On 3/16/2015 5:07 PM, ninja wrote:

 3. Improve Windows support. Include
 http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
 fact that D needs Visual Studio for 64bit apps in 2015 is a 
 shame.

 Including the WindowsAPI won't change this. D uses the MS 
 toolchain to generate the final binaries.

The WindowsAPI static linking model is obsolete. Since the usage 
of new Windows API Sets, a dynamic linking model integrated in 
the language is needed 
(https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx)

Something similar with the external directive from Delphi -> 
http://docwiki.embarcadero.com/RADStudio/XE6/en/Procedures_and_Functions

So instead of writing:

extern(Windows) DWORD GetVersion(),

we can write:

extern(Windows, "api-ms-win-core-sysinfo-l1-2-1.dll", [optional 
funcname]) DWORD GetVersion() or
extern(Windows, "kernel32.dll") DWORD GetVersion() for older 
Windows versions (<8).


I know probably a mixin will partially solve this, but this will 
save some important boilerplate code (just look at DerelictOrg 
bindings, thousands LOC just to load some functions from a dll).

Rikki Cattermole <alphaglosined gmail.com> writes:

On 16/03/2015 10:31 p.m., rumbu wrote:
 On Monday, 16 March 2015 at 09:02:20 UTC, Mike Parker wrote:
 On 3/16/2015 5:07 PM, ninja wrote:

 3. Improve Windows support. Include
 http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
 fact that D needs Visual Studio for 64bit apps in 2015 is a shame.

 Including the WindowsAPI won't change this. D uses the MS toolchain to
 generate the final binaries.

 The WindowsAPI static linking model is obsolete. Since the usage of new
 Windows API Sets, a dynamic linking model integrated in the language is
 needed
 (https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx)


 Something similar with the external directive from Delphi ->
 http://docwiki.embarcadero.com/RADStudio/XE6/en/Procedures_and_Functions

 So instead of writing:

 extern(Windows) DWORD GetVersion(),

 we can write:

 extern(Windows, "api-ms-win-core-sysinfo-l1-2-1.dll", [optional
 funcname]) DWORD GetVersion() or
 extern(Windows, "kernel32.dll") DWORD GetVersion() for older Windows
 versions (<8).


 I know probably a mixin will partially solve this, but this will save
 some important boilerplate code (just look at DerelictOrg bindings,
 thousands LOC just to load some functions from a dll).


Don't, please don't dare me...
I could totally do this with UDA's and CTFE for function pointers.
Plus my new total secret API could make this trivial to hook into.

"rumbu" <rumbu rumbu.ro> writes:

On Monday, 16 March 2015 at 10:02:46 UTC, Rikki Cattermole wrote:
 So instead of writing:

 extern(Windows) DWORD GetVersion(),

 we can write:

 extern(Windows, "api-ms-win-core-sysinfo-l1-2-1.dll", [optional
 funcname]) DWORD GetVersion() or
 extern(Windows, "kernel32.dll") DWORD GetVersion() for older 
 Windows
 versions (<8).


 I know probably a mixin will partially solve this, but this 
 will save
 some important boilerplate code (just look at DerelictOrg 
 bindings,
 thousands LOC just to load some functions from a dll).


 Don't, please don't dare me...
 I could totally do this with UDA's and CTFE for function 
 pointers.
 Plus my new total secret API could make this trivial to hook 
 into.

Been there, done that: 
https://github.com/rumbu13/sharp/blob/master/src/system/runtime/interopservices/package.d

alias GetVersion = 
DllImport!("api-ms-win-core-sysinfo-l1-2-1.dll", "GetVersion", 
DWORD function())

I didn't achieve more than that, i consider this ugly, 
non-intellisense friendly, that's whay a builtin language 
construct will be better. Can't wait to see your total super 
secret API :)

"Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:

On Monday, 16 March 2015 at 08:07:26 UTC, ninja wrote:
 On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote:
 If stories are wanted, I might as well tell mine.

 I am an attorney and a typical "programming-language-user": I
 love to code my own utilities for the job (document-creation,
 bookkeeping, etc.), but I use Windows and have an android smart
 phone. In the last 15 years, I tried C (which I still use for

 now. I avoided Python and PHP because a good roofer listens to
 his heart, not his wallet* :) My experiences so far:

 1. D has to worst docs I happened to meet. I am still having
 difficulties figuring out functions like 'any' and 'all', while 
 I
 understood the Ruby Enumerables at the first time. Same goes to
 string manipulation. Last time I used std.zip I had to read it's
 source to make my code work. That's a big warning sign.

 2. Please stop changing the (core) language all the time. There
 are like 3 new proposals every week in the forums and at least 2
 of those are seriously considered. Please, just stop.

 3. Improve Windows support. Include
 http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
 fact that D needs Visual Studio for 64bit apps in 2015 is a 
 shame.

 4. D needs some kind of default GUI toolkit. I can't give my
 utilities to associates/friends because no one wants to use a
 console any more. I know it is not a small feat, but look at 
 Ruby
 - they just bundle the last version of Tk with their installer
 and maintain a thin wrapper. Tk can be love/hated (I actually
 like its flat and winnative theme) but it enables out-of-the-box
 platform independent desktop-developement for Ruby.

 * sorry for the ancient Star Wars/Clerks reference

Smart phones seem to have an under allocation of attention to 
them in the D community given the stakes.  If I had the free 
cashflow I would pay for someone to work on that full time for a 
bit, but that's not practicable for the time being.

Interesting to hear about your experience using D for your work.  
Would you be willing to write a little more about it and share 
your experience in a way that could be added to a collection of 
user stories?

For the GUI, have you considered creating a local web front end ? 
  Less work than a pure GUI, but people are used to using a 
browser.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Sun, 2015-03-15 at 14:13 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[=E2=80=A6]
 [I am by no means expert in Python, but python 3 does not seem to=20
 be an improvement if you want to be able to accomplish tasks=20
 involving simple processing of ASCII files]

Not entirely true, this is a "belief" being put about by those who wish
to stay with Python 2 and not move to Python 3 for reasons other than
practical ones.

There are some cases, cf. Mercurial, where the code has been founded on
the equivalence of byte and character, which means they have to use
Python 2 or undertake a very serious rewrite of everything so as to use
Python 3 =E2=80=93 which to date they are saying will never happen.

For most people though the fact that strings are sequences of Unicode
codepoints in Python 3 is not a problem processing files as long as they
remember that a file has an encoding. I can see that many like to slide
back to everything is ASCII encoded ergo bytes are strings of length 1
(there are no characters in Python). However once you get over the
barrier of "there are byte sequences and there are strings and they are
different", life becomes very much easier. Certainly I find I have no
problem doing networking with Python 3 having made the mental jump to
"remember about encodings".
=20
[=E2=80=A6]
 I think it would be a positive to have some user stories from=20
 people who have moved from Python+Cython or Python+C to D and=20
 seen significant benefits.  I am sure there are plenty - most=20
 users don't seem to be active in the forum.  And we should=20
 collect user stories, pretty them up, and have them reachable=20
 from the front page very easily.  People make decisions based=20
 upon feelings (indeed without feelings there can be no decision),=20
 and so stories - based in reality - can be more persuasive than=20
 dry facts in persuading people.

This would be a good addition to the website. Along with any C++ =E2=86=92 =
D
stories.

It might be worth collecting D =E2=86=92 =E2=80=A6 stories as well, not per=
haps to
publish but to ascertain what the issues were.=20
=20
 We should try to identify what the biggest sticking points are=20
 for people considering making the switch, both real (like=20
 documentation) and perception (like 'D has no web/server=20
 framework'.

I am fairly confident that the major issue is "presence in the market".
D is not a language that is known about, or talked about, in the same
sentences as Java, Python, C++, Fortran, Go, Scala, Groovy, etc. All too
often when I mention D in a conversation about language choice, the
reaction is "I've not heard of that one.". Nim, Ceylon, Kotlin are in
the same boat. Raising the presence of D in the minds of programmers and
their bosses so it get used in the same sentences as the other languages
is the task at hand.

[=E2=80=A6]
=20
 I was thinking about this just recently.  There used to be a D=20
 scripting language (now rebranded as something else - I forget=20
 the name), but this fell into disuse post rdmd.  Rdmd is great, a=20
 real simple win, but doesn't substitute for a scripting language=20
 in all uses.

Unless a REPL is needed (see previous rant of mine on REPLs, but you
possibly have a genuine need for one), editor+fast compilation is almost
certainly a better solution that a single line REPL. So rdmd almost
certainly its most people needs for "scripting with D".

The question is how to deal with evolving a persistent data set that
takes a long time to construct. I wonder if, rather than writing an
interpreter/REPL =C3=A0 la Scala, it might be better to build a small
framework for managing a persistent dataset. On Posix at least wrapping
something around mmap should do the job. This would then allow
snapshotting.

 In particular, I do agree with Russell about the value of an=20
 ipython/Jupyter notebook for scientific computing (which means=20
 also parts of finance) - especially for playing with data.  Excel=20
 won't cut the mustard any more for many modern data sets, which=20
 means new tools like ipython notebooks come into focus.

s/Russell/Russel/ ?

Excel is still the most used tool in quant work in many financial
institutions :-( Some banks are even going to the extent of


 For the time being it's not the lack of a notebook, but the lack=20
 of dataframes and pandas style functionality that prevent using D=20
 easily in this domain.  But dataframes are not that complicated=20
 or difficult, and it is just a bit of work, and Vlad Levenfeld=20
 has made a good start on some of this.
=20
 I wonder whether it would be feasible to integrate the D REPL=20
 with Jupyter.  Russell?

Jupyter's aim is to be as language agnostic as possible. Hence it's
separation from IPython: having a separate identity makes it easier for
people to acknowledge the UI can be used with R, Julia, Markdown, LaTeX
as well as Python.

[=E2=80=A6]

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 14:51 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]
=20
 [1] The problem is that all these nice Python and R=20
 implementations are practically useless for real world=20
 applications. Too slow, too cumbersome, too many dependencies. It=20
 has to be rewritten anyway. (I'd be happy, if they used at least=20
 C.)

I am not sure which "real world" you are living in, but I have Python
code that executes computationally intensive codes at least as fast as
C, C++, and Fortran. R is slow in comparison. Python code is generally
easier to read and write than C, C++ and Fortran, so not cumbersome.
Dependencies depends on what you want to use in any programming
languages so all fail on that metric. No-one in 2015 should be writing
any application in C; it is too low-level a language for the current
state of programming.

In the real world as I know it people use Python for masses of stuff and
it does the job well. Statisticians use R.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 7:34 AM, Russel Winder via Digitalmars-d wrote:
 On Fri, 2015-03-13 at 14:20 +0000, Chris via Digitalmars-d wrote:
 […]

 reluctant to learn something new. Crowd 2. we can win over, yet
 we have failed to communicate with them, to reach out to them.
 Most people I know have a look at D's homepage and say "Uh! Hm.
 Ah, I'll use Python." No, they are not hardcore programmers, they
 are engineers and scientists. But they are _users_, people who
 need to write software to analyze data, to create something. We
 should not ignore them, even if they are not (initially)
 interested in templates and metaprogramming. Neither was I, when
 I first learned D.

 It is not Python or R or Julia the language that people choose, it is
 the superstructure built on top. So for Python, it is Pandas,
 Matplotlib, SciPy, NumPy. And the ability to use ready made C, C++ and
 Fortran libraries.

That's right. Offer solid value, and make learning the language just 
aftermath. Again, that's why I'm pushing for vibe. -- Andrei

"Florin Mihaila" <fm objectline.com> writes:

On Friday, 13 March 2015 at 14:59:42 UTC, Andrei Alexandrescu 
wrote:

 [...] Offer solid value, and make learning the language just 
 aftermath.

Yes, this one-sentence distillation is the key point.

--Florin

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Fri, 2015-03-13 at 07:59 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/13/15 7:34 AM, Russel Winder via Digitalmars-d wrote:

[=E2=80=A6]
 It is not Python or R or Julia the language that people choose, it is
 the superstructure built on top. So for Python, it is Pandas,
 Matplotlib, SciPy, NumPy. And the ability to use ready made C, C++ and
 Fortran libraries.

=20
 That's right. Offer solid value, and make learning the language just=20
 aftermath. Again, that's why I'm pushing for vibe. -- Andrei

That's OK for its domain of event-driven systems, but there is much,
much more.

If D is to compete in the financial computing arena where Python and R
currently rule, there needs to be all the libraries for doing time
series analysis, and rendering them graphically. There also needs to be
a workflow that fits the users of the domain. The market leader is
currently Jupyter (*) in the finance places I have connection with.

The point here is that these folk (and all the bioinformatics, and
others using computers for modelling systems) need a highly interactive,
stitched together code fragment, based system. 1960s edit-compile-run
workflows do not work for these people. REPLs sort of work, but not
well. Jupyter really gets these people moving. They are writing HTML/PDF
documents with embedded, executable code. It is the 2015s version of
literate programming. Except that they are writing about their domain,
not about the code.

What D should do is ensure that it can be a language usable from
Jupyter?


(*) IPython grew out of Python and become the de facto system, but was a
mess structurally. IPython is splitting into IPython the original thing
and Jupyter all the UI related stuff that grew on IPython but made it
messy. The new structuring makes things better and allows Jupyter to be
clearly not just a Python thing. So you can run R, Julia,=E2=80=A6 as well =
as
Python as the code fragments.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"bearophile" <bearophileHUGS lycos.com> writes:

Russel Winder:

 (*) IPython grew out of Python and become the de facto system, 
 but was a mess structurally. IPython is splitting into IPython
 the original thing and Jupyter all the UI related stuff

Jupyter looks like a nice idea and a nice project. I'd like to 
understand how Jupyter compared to Sage.

Bye,
bearophile

"bachmeier" <no spam.net> writes:

On Saturday, 14 March 2015 at 09:00:11 UTC, Russel Winder wrote:

 If D is to compete in the financial computing arena where 
 Python and R
 currently rule, there needs to be all the libraries for doing 
 time
 series analysis, and rendering them graphically. There also 
 needs to be
 a workflow that fits the users of the domain. The market leader 
 is
 currently Jupyter (*) in the finance places I have connection 
 with.

D can gain popularity by doing what Rcpp has done, by making it 
easy to embed C++ code inside R. Rcpp is currently the most 
common dependency among all R packages. I have done the same with 
D though it's not yet in a form that others can really use it 
(https://bitbucket.org/bachmeil/dmdinline).

The best thing to happen to D was the ability to create shared 
libraries on Linux. You can add D to your existing codebase 
incrementally. That is, in my opinion, D's "killer application". 
And D has an advantage over C++. R users will write C++ because 
they have to, whereas D is a language they'll use because they 
want to.

"rumbu" <rumbu rumbu.ro> writes:

I watched silently this discussion and turns out that it will end 
- as always - in some obscure debate about some obscure languages 
or more than obscure features.

I take the risk to be blamed, but let me tell you that the  
developer world does not spin around R, Python, Fortran, Haskell 
and Go. These are nice languages for a bunch of *nix nerds or 
very specialized engineers but their usage is very limited. The 

abominable Javascript has a larger user base that these languages.

Secondly, the same futile waste of energy is consumed in debates 
about portability. 97% of desktop system, believe-it-or-not, are 
using various flavours of Windows and some of them OSX. 95% of 
mobile devices are built on top of Androis/iOS. There is 
important *nix usage in the server OSes, but the usual developer 
will not start his programming career writing server applications.

The third mistake in my opinion is that the same "bunch of nerds" 
are making and documenting the standard library. What the heck is 
levenshteinDistance? What about 
largestPartialIntersectionWeighted? boyerMooreFinder? When the 
usual developer will try to eagerly learn D, he will say: "My 
place is not here, you must be some computer/mathematics genius 
to learn this language".

About built-in functionality: Let's say that I want to sort some 
strings. After I am shocked enough to find out that D has three 
types of string which in fact they are not strings but some weird 
arrays of something called immutable(char), I'll look at the sort 
function prototype:

SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy 
ss = SwapStrategy.unstable, Range)(Range r) if ((ss == 
SwapStrategy.unstable && (hasSwappableElements!Range || 
hasAssignableElements!Range) || ss != SwapStrategy.unstable && 
hasAssignableElements!Range) && isRandomAccessRange!Range && 
hasSlicing!Range && hasLength!Range);

Do you like it? I'll be very scared to use this unreadable brain 
damaging enumeration of characters. To sum things up, if someone 
wants to sort some strings, one must already mastering:
- templates;
- eponymous templates;
- alias declarations;
- ranges;
- enums;
- traits;
- dive enough into phobos to understand the meaning of another 8 
templates depending maybe on another 1676327672 templates.

Now let's say my name is Hans and I live in Germany or my name is 
Ali and I live in Turkey. Do you think that the sort function 
above will meet my expectations? No, because, despite the fact 
that sort function will sort anything I can imagine, does not 
take into account the most used scenario: culture sensitivity.

You know, comparing strings with culture sensitivity is just one 
call to an API function on Windows, but I suppose that that 
"portability" obsession keeps phobos ignoring it. Let's say that 
I am not so lazy to call that function: this function is not 
declared in the so 1990ish std.c.windows, nor in the 
corresponding lib. So, to use that bloody function, I have two 
solutions: learn to use coffimplib or link it dynamically with 
LoadLibrary/GetProcAddress. Fighting the lazyness, I'll find that 
before using it, I must convert my string to UTF-16 and 
eventually zero-terminate it.

Another one: there is standard library support for complex 
numbers. Who's using these complex numbers? But who's using 
currencies? I bet that more people are using currencies then 
complex numbers. Despite the evidence, D has no standard support 
for them. We, mortals, are expecting that 1 / 10 is 0.1 not 
0.1000000001 and we don't give a damn about the meaning of 2 + 3i.

So, IMHO, if you want to attract users, here is my list:
- concentrate on most used OSes - Windows/OSX and Android/iOS.
- don't write scary documentation;
- offer standard functionality instead of the obscure one. It's 
nice to have it, but the use case scenarios are rare.
- a GUI will be nice. You know, that thing allowing the developer 
to put a button and writing events... instead of the sad black 
console used by nobody I know.

As you can see, there is nothing wrong with the language itself, 
but with the library.

"weaselcat" <weaselcat gmail.com> writes:

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
 I watched silently this discussion and turns out that it will 
 end - as always - in some obscure debate about some obscure 
 languages or more than obscure features.

 I take the risk to be blamed, but let me tell you that the  
 developer world does not spin around R, Python, Fortran, 
 Haskell and Go. These are nice languages for a bunch of *nix 
 nerds or very specialized engineers but their usage is very 

 Even the abominable Javascript has a larger user base that 
 these languages.

 Secondly, the same futile waste of energy is consumed in 
 debates about portability. 97% of desktop system, 
 believe-it-or-not, are using various flavours of Windows and 
 some of them OSX. 95% of mobile devices are built on top of 
 Androis/iOS. There is important *nix usage in the server OSes, 
 but the usual developer will not start his programming career 
 writing server applications.

Regular desktop usage statistics don't apply to developer 
communities. The few times an OS survey was done here, it was 
overwhelmingly Linux IIRC. You can't expect people who don't 
use(or have access to) Windows/OSX to cater to those platforms.

D does not have a big corporation like Microsoft or Google 
backing it, it has people donating their own time.

D focuses on portability because it's a systems programming 
language, not .NET in native form.

 About built-in functionality: Let's say that I want to sort 
 some strings. After I am shocked enough to find out that D has 
 three types of string which in fact they are not strings but 
 some weird arrays of something called immutable(char), I'll 
 look at the sort function prototype:

I can't really think of any language that doesn't implement 
strings as an array of characters.

 Another one: there is standard library support for complex 
 numbers. Who's using these complex numbers? But who's using 
 currencies? I bet that more people are using currencies then 
 complex numbers. Despite the evidence, D has no standard 
 support for them. We, mortals, are expecting that 1 / 10 is 0.1 
 not 0.1000000001 and we don't give a damn about the meaning of 
 2 + 3i.

complex numbers are much easier to implement than a good currency 
system.


 So, IMHO, if you want to attract users, here is my list:
 - concentrate on most used OSes - Windows/OSX and Android/iOS.
 - don't write scary documentation;
 - offer standard functionality instead of the obscure one. It's 
 nice to have it, but the use case scenarios are rare.
 - a GUI will be nice. You know, that thing allowing the 
 developer to put a button and writing events... instead of the 
 sad black console used by nobody I know.

"rumbu" <rumbu rumbu.ro> writes:

On Saturday, 14 March 2015 at 15:13:44 UTC, weaselcat wrote:

 Regular desktop usage statistics don't apply to developer 
 communities. The few times an OS survey was done here, it was 
 overwhelmingly Linux IIRC. You can't expect people who don't 
 use(or have access to) Windows/OSX to cater to those platforms.

This is the keyword: here. Don't expect to attract other kind of 
developers if you have nothing to offer them. I am using D for 4 
years now and I didn't even respond to these polls because I fill 
as an outsider here. I don't find any use of levenshteinDistance 
in my LOB applications, i'm keeping to use D for personal 
experimental projects.

 D does not have a big corporation like Microsoft or Google 
 backing it, it has people donating their own time.

 D focuses on portability because it's a systems programming 
 language, not .NET in native form.

Portability limited to an OS with 3% usage? std.c.windows is 
older than my grandma and contains ANSI Windows bindings. But 
nothing about WinRT. Even the Windows API model has changed in 
the meantime: 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx

"D is a language with C-like syntax and static typing. It 
pragmatically combines efficiency, control, and modeling power, 
with safety and programmer productivity." - this is on the 
landing page.

I see nothing about "system programming language". But I saw 
something about productivity.

 I can't really think of any language that doesn't implement 
 strings as an array of characters.

I understand very well the meaning of "immutable(char)[]" but I 
try to walk in the first time user's shoes. The problem is that 
using a string you must understand before concepts like 
immutability. To sort them, well, you must buy a book.

 complex numbers are much easier to implement than a good 
 currency system.

Again, just a some calls to WinAPI - 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms221612(v=vs.85).aspx

Oops, I forgot, we need portability and probably a very versatile 
kind of currency supporting n bits instead a simple 128 bit 
standard one and we must write some efficient code, not like the 
one written by these illiterate programmers from MS. And these 
functions are not pure and  safe. Let's rewrite them.

 So, IMHO, if you want to attract users, here is my list:
 - concentrate on most used OSes - Windows/OSX and Android/iOS.
 - don't write scary documentation;
 - offer standard functionality instead of the obscure one. 
 It's nice to have it, but the use case scenarios are rare.
 - a GUI will be nice. You know, that thing allowing the 
 developer to put a button and writing events... instead of the 
 sad black console used by nobody I know.



So having built-in Windows/OSX/Andoroid/iOS support, nice 
documentation, real world functionality and a GUI system makes D 

pun?

"Paolo Invernizzi" <paolo.invernizzi no.address> writes:

On Saturday, 14 March 2015 at 16:24:19 UTC, rumbu wrote:
 On Saturday, 14 March 2015 at 15:13:44 UTC, weaselcat wrote:
 I can't really think of any language that doesn't implement 
 strings as an array of characters.

 I understand very well the meaning of "immutable(char)[]" but I 
 try to walk in the first time user's shoes. The problem is that 
 using a string you must understand before concepts like 
 immutability. To sort them, well, you must buy a book.

I'm the only one so old, that for me, studying a language from a 
book is the normal pattern to follow for learning it?

I remember well all the big books packed in Borland's products....
---
Paolo

"bearophile" <bearophileHUGS lycos.com> writes:

Paolo Invernizzi:

 I'm the only one so old, that for me, studying a language from 
 a book is the normal pattern to follow for learning it?

I think it's also a matter of how you usually learn. If you are a 
person that loves nonfinction books a lot, that reads nonfinction 
books a lot, then probably you also like to read a language with 
the help of a book.

Bye,
bearophile

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
 So, IMHO, if you want to attract users, here is my list:
 - concentrate on most used OSes - Windows/OSX and Android/iOS.

I actually think that going "populist" is a serious mistake. 
Abstraction layers create inefficiencies and inflexibility and D 
will be best suited for server programming in the near future. D 
eco system is nowhere near a state where D is suitable for 
commercial applications.

I'd much rather use a tool that has strong focus on one platform 
and totally kill on that platform than one that is being mediocre 
everywhere. D is spreading itself thin, chasing too many trails. 
OS/iOS/Android/Windows are very expensive trails to follow, 
because you have to provide comparable tooling which will never 
happen...

D could have chosen to be excellent on Linux server programming, 
but then you need to embrace Linux, and make the most out of the 
platform.

Linux devs are happy with an Emacs mode. Put a lot of effort on a 
single IDE, like Emacs, and you have something. Creating 10 
different IDEs and N different GUI libs that supposedly will make 
commercial application programming a breeze... goes nowhere. 
Because it lacks realism.

"jack death" <death cybera.com> writes:

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
 I watched silently this discussion and turns out that it will 
 end - as always - in some obscure debate about some obscure 
 languages or more than obscure features.

 I take the risk to be blamed, but let me tell you that the  
 developer world does not spin around R, Python, Fortran, 
 Haskell and Go. These are nice languages for a bunch of *nix 
 nerds or very specialized engineers but their usage is very 

 Even the abominable Javascript has a larger user base that 
 these languages.

 Secondly, the same futile waste of energy is consumed in 
 debates about portability. 97% of desktop system, 
 believe-it-or-not, are using various flavours of Windows and 
 some of them OSX. 95% of mobile devices are built on top of 
 Androis/iOS. There is important *nix usage in the server OSes, 
 but the usual developer will not start his programming career 
 writing server applications.

 The third mistake in my opinion is that the same "bunch of 
 nerds" are making and documenting the standard library. What 
 the heck is levenshteinDistance? What about 
 largestPartialIntersectionWeighted? boyerMooreFinder? When the 
 usual developer will try to eagerly learn D, he will say: "My 
 place is not here, you must be some computer/mathematics genius 
 to learn this language".

 About built-in functionality: Let's say that I want to sort 
 some strings. After I am shocked enough to find out that D has 
 three types of string which in fact they are not strings but 
 some weird arrays of something called immutable(char), I'll 
 look at the sort function prototype:

 SortedRange!(Range, less) sort(alias less = "a < b", 
 SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if 
 ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || 
 hasAssignableElements!Range) || ss != SwapStrategy.unstable && 
 hasAssignableElements!Range) && isRandomAccessRange!Range && 
 hasSlicing!Range && hasLength!Range);

 Do you like it? I'll be very scared to use this unreadable 
 brain damaging enumeration of characters. To sum things up, if 
 someone wants to sort some strings, one must already mastering:
 - templates;
 - eponymous templates;
 - alias declarations;
 - ranges;
 - enums;
 - traits;
 - dive enough into phobos to understand the meaning of another 
 8 templates depending maybe on another 1676327672 templates.

 Now let's say my name is Hans and I live in Germany or my name 
 is Ali and I live in Turkey. Do you think that the sort 
 function above will meet my expectations? No, because, despite 
 the fact that sort function will sort anything I can imagine, 
 does not take into account the most used scenario: culture 
 sensitivity.

 You know, comparing strings with culture sensitivity is just 
 one call to an API function on Windows, but I suppose that that 
 "portability" obsession keeps phobos ignoring it. Let's say 
 that I am not so lazy to call that function: this function is 
 not declared in the so 1990ish std.c.windows, nor in the 
 corresponding lib. So, to use that bloody function, I have two 
 solutions: learn to use coffimplib or link it dynamically with 
 LoadLibrary/GetProcAddress. Fighting the lazyness, I'll find 
 that before using it, I must convert my string to UTF-16 and 
 eventually zero-terminate it.

 Another one: there is standard library support for complex 
 numbers. Who's using these complex numbers? But who's using 
 currencies? I bet that more people are using currencies then 
 complex numbers. Despite the evidence, D has no standard 
 support for them. We, mortals, are expecting that 1 / 10 is 0.1 
 not 0.1000000001 and we don't give a damn about the meaning of 
 2 + 3i.

 So, IMHO, if you want to attract users, here is my list:
 - concentrate on most used OSes - Windows/OSX and Android/iOS.
 - don't write scary documentation;
 - offer standard functionality instead of the obscure one. It's 
 nice to have it, but the use case scenarios are rare.
 - a GUI will be nice. You know, that thing allowing the 
 developer to put a button and writing events... instead of the 
 sad black console used by nobody I know.

 As you can see, there is nothing wrong with the language 
 itself, but with the library.

+1000

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/14/15 7:45 AM, rumbu wrote:
 As you can see, there is nothing wrong with the language itself, but
 with the library.

s/library/documentation/

"bachmeier" <no spam.net> writes:

On Saturday, 14 March 2015 at 14:45:07 UTC, rumbu wrote:
 I take the risk to be blamed, but let me tell you that the  
 developer world does not spin around R, Python, Fortran, 
 Haskell and Go. These are nice languages for a bunch of *nix 
 nerds or very specialized engineers but their usage is very 
 limited.

For some definition of "very limited" - the developers you hang 
out with. The developer world is a big place.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/14/15 1:59 AM, Russel Winder via Digitalmars-d wrote:
 What D should do is ensure that it can be a language usable from
 Jupyter?

It should secure a strong champion with the interest and expertise in 
making that work. -- Andrei

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 13 March 2015 at 14:34:23 UTC, Russel Winder wrote:
 On Fri, 2015-03-13 at 14:20 +0000, Chris via Digitalmars-d 
 wrote:
 […]

 reluctant to learn something new. Crowd 2. we can win over, 
 yet we have failed to communicate with them, to reach out to 
 them. Most people I know have a look at D's homepage and say 
 "Uh! Hm. Ah, I'll use Python." No, they are not hardcore 
 programmers, they are engineers and scientists. But they are 
 _users_, people who need to write software to analyze data, to 
 create something. We should not ignore them, even if they are 
 not (initially) interested in templates and metaprogramming. 
 Neither was I, when I first learned D.

 It is not Python or R or Julia the language that people choose, 
 it is
 the superstructure built on top. So for Python, it is Pandas,
 Matplotlib, SciPy, NumPy. And the ability to use ready made C, 
 C++ and
 Fortran libraries.

Ecosystems play a big role in language choice.

In our case, C++ has for a long time been pushed for plumbing at 
the OS level or that last performance that the JIT cannot help.

So any C++ replacement has to be able to be exposed as JNI, 
P/Invoke, COM, WinRT, V8.

As well as offer similar level of mixed debugging across 
boundaries.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 7:20 AM, Chris wrote:
 This is true. This battle is lost. But a lot of users, even people who are
 interested in D, shy away from D, because they don't have the feeling that
"this
 is something really useful". We fail to communicate both its general usefulness
 and its strong points as opposed to other languages. What the big marketing
 machines behind Go etc. do is to make people feel good about a product (even if
 it's shit). We should do the same. Only because Google does it, doesn't mean
 it's a big taboo for us. The fact of the matter is that we have failed to win
over:

I gave a talk at Digipen recently. (Digipen is a private college aimed at 
teaching professional game programmers.) They are mostly a C++ house. So I was 
talking to college students who were deep into programming.

I thought I'd try something different, and wrote a presentation that simply 
showed some neato things that D could do without diving deep into how those 
things work.

The home run, though, was showing how unittests combine with -cov testing to 
make code robust. Yes, you can do this in other languages, but it is so simple 
to do in D. It really struck a chord with these people.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 6:18 AM, Dicebot wrote:
 On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu wrote:
 A friend of mine needed to complete a small project and thought of
 using a language he didn't know for it. He already knew I work on D so
 he considered it alongside Go. He ended up choosing the latter, and
 documented his decision making process in a few notes that he
 subsequently shared with me. I'll paste below a sort of transcript of
 his handwritten notes.

 In my opinion it is better to focus on tempting users with D strong bits
 than oversell it by trying it compete in topics it has inherent
 disadvantage. There is not point in try to compete with Go on topic of
 simplicity - they have crippled the language tremendeously to get that
 simplicity. Simple D has no value - I would simply prefer Go instead of
 it as it has head start advantage in toolchain.

Yah, simplicity is hard to add later :o).

 Instead it is better to focus on explaining users that they don't want
 what they think they want, akin to that Bjarne quote. And don't be
 afraid to admit to certain users that D is not a best choice for them.
 It doesn't mean that such valuable feedback should be ignore - there is
 indeed a lot that can be improved in the learning curve. But trying to
 fight for user who makes choice with "trendy" and "simplicity" in mind
 is a battle lost from the very beginning.

Simplicity yes, but trends do change.


Andrei

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 6:18 AM, Dicebot wrote:
 In my opinion it is better to focus on tempting users with D strong bits than
 oversell it by trying it compete in topics it has inherent disadvantage. There
 is not point in try to compete with Go on topic of simplicity - they have
 crippled the language tremendeously to get that simplicity. Simple D has no
 value - I would simply prefer Go instead of it as it has head start advantage
in
 toolchain.

 Instead it is better to focus on explaining users that they don't want what
they
 think they want, akin to that Bjarne quote. And don't be afraid to admit to
 certain users that D is not a best choice for them. It doesn't mean that such
 valuable feedback should be ignore - there is indeed a lot that can be improved
 in the learning curve. But trying to fight for user who makes choice with
 "trendy" and "simplicity" in mind is a battle lost from the very beginning.

Yup. There are fashions in language design, and if one is always chasing the 
fashion one will always be behind. We should be looking forward in anticipating 
future developments. I think D has done very well in this, such as array
slicing 
which other languages are adopting. C++ is now adopting UFCS, too :-)

Having a "me too" language is not an easy way to sell it - especially in the 
panoply of free languages. People will default choose the original.

Much of Go's and Java's simplicity comes from having a garbage collector. As we 
all well know, there are limitations that come with that. Moving beyond a GC is 
not simple.


I strongly believe that one can write simple and effective code in D. 
Unfortunately, there seems to be a learning curve to writing simple and 
effective code. I find much of Phobos to be excessively complex. (Though Boost 
C++ takes the cake in being terrifically complex code.)

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 3/13/15 12:05 PM, Walter Bright wrote:
 Having a "me too" language is not an easy way to sell it

Well Go is the epitome of "me too" but is doing well for other reasons. 
-- Andrei

"yawniek" <dlang srtnwz.com> writes:

On Friday, 13 March 2015 at 13:18:03 UTC, Dicebot wrote:
 In my opinion it is better to focus on tempting users with D 
 strong bits than oversell it by trying it compete in topics it 
 has inherent disadvantage. There is not point in try to compete 
 with Go on topic of simplicity - they have crippled the 
 language tremendeously to get that simplicity. Simple D has no 
 value - I would simply prefer Go instead of it as it has head 
 start advantage in toolchain.

 Instead it is better to focus on explaining users that they 
 don't want what they think they want, akin to that Bjarne 
 quote. And don't be afraid to admit to certain users that D is 
 not a best choice for them. It doesn't mean that such valuable 
 feedback should be ignore - there is indeed a lot that can be 
 improved in the learning curve. But trying to fight for user 
 who makes choice with "trendy" and "simplicity" in mind is a 
 battle lost from the very beginning.

this.
imo D's feature set is awesome and still it is reasonably easy to 
get a start with just a simple subset
of D.
one thing Go did really well was focusing on getting a complete 
set of basic libraries.
a foundation with support of most protocols.

i did two small projects for work within the last month, one in D 
(a multithreaded crawler that hammered a json API) and a uploader 
that can upload to S3 or Openstack Swift in Go.

So here goes my personal list:

D:
+ speed
+ the language itself and its features. i love how you can write 
pretty dense code with
UFCS, lambdas and ranges.
- stdlib. lots of missing pieces (e.g. email parsing, native http 
client)
- iv'e also spent a lot of time fighting with external libraries, 
reading their code (especially vibe-d as i used its http client 
and concurrency features). sometimes it was the missing 
documentation, sometimes just the complexity.
- debugging and tracing (osx/linux, and to be fair, i haven't 
tried with Go)

Go
+ libraries, yes the hipster factor also produces a lot of crap. 
but still, i needed to get stuff done yesterday. 
documentation/apis are often straight forward, i rarely had to 
look into the sources.
+ support: documentation, build tools, formatting. "it just 
works" (just today i discovered the awesome dfmt. this should 
come with dmd...).
there is also sites that just explain a couple of concepts, e.g. 
http://www.golangpatterns.info . very helpful
- the language itself. the code just looks ugly and shoehorned 
around their simple concepts
- error handling...

something that would have helped me would be a nice guide on how 
to setup a whole development chain:
- list of utilities needed (e.g. dmd, vim, DCD, dfmt...) and 
their configuration
- build tools (dub),
- debugging, tracing
- code organization best practices.

in general the current "D crowd" seems mostly game and language 
people.
Distributed systems, databases and high performance web services 
is something i
think D would really shine. Not sure on how to better serve this 
market though.

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 3/12/15 8:20 PM, Andrei Alexandrescu wrote:


 sign but sits emtpy; by comparison Go -> condo in hip, trendy area

I like wide opens spaces and hate crowded trendy hip things.

Must be why I like D so much ;)

-Steve

"Florin Mihaila" <fm objectline.com> writes:

Hi everyone,

I'm the guy who threw the rock in the pond. I should probably
clarify a few things about the notes (which Andrei posted with my
permission).

They are stream-of-consciousness scribbles, which I took down
while I was going through the process (I actually sent Andrei a
photo of my notebook pages). I wrote them because I thought he
would be interested to know what went through this programmer's
head when looking at D for a small project, with no prior
exposure to the language. The experiment took one day. I was
planning to discuss it over the phone with Andrei (which we did),
and I wanted to make sure I wouldn't forget anything. It was
definitely not crafted as a well-thought-out critique, but that
was the point. People learn languages one misconception at a
time, and I wanted to give Andrei the raw material. This makes
certain things confusing as written, so I'd like to add a bit
more context.

1) When I wrote "focus on one [feature]", I wasn't suggesting
that features be removed from the language. Instead, I was
referring to the presentation of the language to newcomers. The
thing is, I wasn't visiting the D website to learn D; I was there
because I needed to write a small, self-contained server with a
minimum of fuss. I had a single purpose in mind and a very
limited time budget. Go made it easier for me to zoom in on my
goal, and the main factor was its (perceived) simplicity. This
led to the phrase "designers think of features, users think of
purpose", but it applied to _presentation_. It was like I wanted
to rent a car for one specific day trip, and D was trying to sell
me the car. In contrast, Go was light and easy; I felt I could
catch it after minimal contact, like a dog catches fleas (those
who dislike Go will think of other metaphors here).

D absolutely should not be robbed of its richness to become
"simpler". It's not the language that needs fixing (well, it
might, but only to make it even better). Rather, I look at it
through a newbie's eyes: every person visiting the dlang site has
some purpose in mind. Topical articles/tutorials showing how to
accomplish one thing only (for relevant values of "thing") could
go a long way in lowering the barrier to entry. For those who
want an overview, an interactive tutorial like the one on the Go
playground would be excellent.

2) "Go is a condo in a hip, trendy area". This could be taken to
mean that I was led to Go's neighbourhood because I wanted to be
hip. Instead, that note was in contrast with an adjacent one,
where I saw D like a new house (spacious, comfortable, all
appliances included) that sits empty. I didn't write it down, but
I was thinking it sat empty because the neighbourhood was empty.
As a new user, I want to be where everybody is, because that's
where my community needs are likely to be satisfied. There will
be bakeries, coffee shops, independent bookstores, bike lanes,
parks, theaters, and a subway. It's not the prestige, it's the
livability. This is where those libraries make a difference, and
why Stackoverflow is overflowing, as it were, with Go questions
and answers: that's what all those latte drinkers type away on
their Macbooks. (Yes, I know there are D questions answered on
Stackoverflow; work with me here.)

3) "IDEs". Here, Go isn't doing that great, either. The most
glaringly missing piece is a proper debugger. GDB is unusable
with Go (I'm comfortable with using GDB itself). That was
actually something I was planning to ask Andrei about on the
phone; it wasn't a statement about the current state of D.

4) "Not feeling smart enough for D". As in, to pick up in one day
and get on with my life and my little server. I was actually
thinking of the Wikipedia article on D. I simply could not
understand the example just by looking at that page, and without
opening Andrei's book that sits on my bookshelf. That might be
more a comment about me, but I really think it's the article.
(For context, I write routinely in C++, Java, Scheme, Prolog,
Unix shell, etc., and when those languages don't suffice for my
projects, I write new ones.)

Finally, I feel I should respond to this:

On Friday, 13 March 2015 at 02:28:53 UTC, bachmeier wrote:
 If you want to be Rob Pike Jr., Go is great. If you want to 
 program your way, not so much.

I have no reason to take this personally, seeing as I'm pretty
secure in my non-Rob-Pike-ness, but from a product design (and
selling) standpoint, blaming or insulting the user is, of course,
missing the point. I felt equally put-off by the dismissive tone
of some of the creators of Go towards those who "don't
understand" Go's ethos. I still ended up using their language,
but it wasn't for their persuasion skills. Thankfully, it seems
this isn't the general tone of D's community, and the level of
healthy, open debate over here appears to be much higher than for
Go.

This note is getting too long, so if some of what I wrote needs
more clarification, feel free to ask. I'm glad my humble notes
are sparking discussion, and I hope D continues to grow.

--Florin

"bearophile" <bearophileHUGS lycos.com> writes:

Florin Mihaila:

 This note is getting too long, so if some of what I wrote needs
 more clarification, feel free to ask. I'm glad my humble notes
 are sparking discussion, and I hope D continues to grow.

Constructive notes (as yours) are always welcome in this friendly 
community. Thank you for your help.

Bye,
bearophile

"weaselcat" <weaselcat gmail.com> writes:

On Friday, 13 March 2015 at 15:18:33 UTC, Florin Mihaila wrote:
 3) "IDEs". Here, Go isn't doing that great, either. The most
 glaringly missing piece is a proper debugger. GDB is unusable
 with Go (I'm comfortable with using GDB itself). That was
 actually something I was planning to ask Andrei about on the
 phone; it wasn't a statement about the current state of D.

GDB works great with D, including source analysis. I personally 
use Nemiver frontend.

"Dicebot" <public dicebot.lv> writes:

On Friday, 13 March 2015 at 15:18:33 UTC, Florin Mihaila wrote:
 Hi everyone,

 I'm the guy who threw the rock in the pond. I should probably
 clarify a few things about the notes (which Andrei posted with 
 my
 permission).

Thanks for an extended feedback.

"bachmeier" <no spam.com> writes:

 Finally, I feel I should respond to this:

 On Friday, 13 March 2015 at 02:28:53 UTC, bachmeier wrote:
 If you want to be Rob Pike Jr., Go is great. If you want to 
 program your way, not so much.

 I have no reason to take this personally, seeing as I'm pretty
 secure in my non-Rob-Pike-ness, but from a product design (and
 selling) standpoint, blaming or insulting the user is, of 
 course,
 missing the point. I felt equally put-off by the dismissive tone
 of some of the creators of Go towards those who "don't
 understand" Go's ethos. I still ended up using their language,
 but it wasn't for their persuasion skills. Thankfully, it seems
 this isn't the general tone of D's community, and the level of
 healthy, open debate over here appears to be much higher than 
 for
 Go.


Sorry if it appeared I was being critical of you. I was only 
giving the reasons that I didn't like Go. Maybe I should have 
said Go forces you to program like Rob Pike. That works for a lot 
of programmers, but not for me.

I feel compelled to say that I don't represent the D community. 
Although I use D for work 
(https://bitbucket.org/bachmeil/dmdinline) I've never contributed 
anything to its development. I'm just a random guy on the 
internet that compared Go against D but came to a different 
conclusion.

"Florin Mihaila" <fm objectline.com> writes:

On Friday, 13 March 2015 at 18:20:48 UTC, bachmeier wrote:
 Finally, I feel I should respond to this:

 On Friday, 13 March 2015 at 02:28:53 UTC, bachmeier wrote:
 If you want to be Rob Pike Jr., Go is great. If you want to 
 program your way, not so much.

 I have no reason to take this personally, seeing as I'm pretty
 secure in my non-Rob-Pike-ness, but from a product design (and
 selling) standpoint, blaming or insulting the user is, of 
 course,
 missing the point. I felt equally put-off by the dismissive 
 tone
 of some of the creators of Go towards those who "don't
 understand" Go's ethos. I still ended up using their language,
 but it wasn't for their persuasion skills. Thankfully, it seems
 this isn't the general tone of D's community, and the level of
 healthy, open debate over here appears to be much higher than 
 for
 Go.


 Sorry if it appeared I was being critical of you. I was only 
 giving the reasons that I didn't like Go. Maybe I should have 
 said Go forces you to program like Rob Pike. That works for a 
 lot of programmers, but not for me.

 I feel compelled to say that I don't represent the D community. 
 Although I use D for work 
 (https://bitbucket.org/bachmeil/dmdinline) I've never 
 contributed anything to its development. I'm just a random guy 
 on the internet that compared Go against D but came to a 
 different conclusion.

Ok, no worries.

Walter Bright <newshound2 digitalmars.com> writes:

On 3/13/2015 8:18 AM, Florin Mihaila wrote:
 Hi everyone,

 I'm the guy who threw the rock in the pond. I should probably
 clarify a few things about the notes (which Andrei posted with my
 permission).

Thank you very much. You've performed an invaluable service for us.

"Wyatt" <wyatt.epp gmail.com> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 A friend of mine needed to complete a small project and thought 
 of using a language he didn't know for it.

Come to think of it, this reminds me of a different post I saw 
recently by the author of a certain famous(?) PHP roast:
http://eev.ee/blog/2015/02/28/sylph-the-programming-language-i-want/

D doesn't hit it out of the park on every point, but I think it's 
pleasingly close overall.  Unfortunately, D wasn't on the 
author's radar at all.  Didn't even get mentioned until the 
comments, and it's not really encouraging even then:
"I've had a look at D before (back when it uh didn't really have 
a compiler?) and it certainly seemed like a huge breath of fresh 
air over C. But I really appreciate how effortless it feels to 
get something up and running in Python, and I feel like by now we 
should be able to preserve that without paying so dearly for it."

IMO, D has both an image problem and a visibility problem (both 
with a lot of inertia), and their synergy is driving people from 
all "factions" away.

Unfortunately, I don't think there's any one "marketing push" or 
breakthrough that could possibly rectify this; it's going to be a 
thousand-cuts situation, where each panel, tech talk, or Cool 
Thing of the Week does a little more to dispel the pariah status 
(this YOW2015 talk I'm listening to right now is really 
entertaining).

-Wyatt

"Israel" <tl12000 live.com> writes:

On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 A friend of mine needed to complete a small project and thought 
 of using a language he didn't know for it. He already knew I 
 work on D so he considered it alongside Go. He ended up 
 choosing the latter, and documented his decision making process 
 in a few notes that he subsequently shared with me. I'll paste 
 below a sort of transcript of his handwritten notes.

 I think this is valuable information from a relatively unbiased 
 potential user, and good ideas and action items on how we can 
 improve our curb appeal. Even mistaken perceptions are good 
 signal - it means our materials weren't explicit enough to 
 dispel them.

 I'd love us to derive a few action items from this and other 
 feedback.


 Andrei

Well see the real problem is that D cant seem to cater to one 
group or another.

It cant cater to new/inexperienced people because it isnt 
portrayed that way.

It cant cater to the hardcore/DieHard C/C++ people because it is 
difficult to convince them.

You need to pick a target audience and stick with it...

"Piotrek" <no_data no_data.pl> writes:

On Friday, 13 March 2015 at 17:11:06 UTC, Israel wrote:
 Well see the real problem is that D cant seem to cater to one 
 group or another.
 It cant cater to new/inexperienced people because it isnt 
 portrayed that way.

I don't think D is a priori not suitable for  rookies. It just 
needs more paint. Just show me what Go has what can't be simple 
in D :)

 It cant cater to the hardcore/DieHard C/C++ people because it 
 is difficult to convince them.

Or even impossible for some kind of personalities. C++ couldn't 
convince Linus to abandon C. Tell him about D then ;) I suggest 
to leave that type of people with their own toys. The better is 
going to win eventually.

 You need to pick a target audience and stick with it...

Or create multipurpose tool. I think D is the best multipurpose 
tool in the programming languages business. Of course D community 
doesn't have enough resources to produces high quality products 
on all fronts.

Number of resources is critical. D fights using its brilliance to 
overcome lack of resources. Go is on opposite position.

Piotrek

Xavier Bigand <flamaros.xavier gmail.com> writes:

Le 13/03/2015 01:20, Andrei Alexandrescu a écrit :
 A friend of mine needed to complete a small project and thought of using
 a language he didn't know for it. He already knew I work on D so he
 considered it alongside Go. He ended up choosing the latter, and
 documented his decision making process in a few notes that he
 subsequently shared with me. I'll paste below a sort of transcript of
 his handwritten notes.

 I think this is valuable information from a relatively unbiased
 potential user, and good ideas and action items on how we can improve
 our curb appeal. Even mistaken perceptions are good signal - it means
 our materials weren't explicit enough to dispel them.

 ====================

 * Golang: simple!

 + very small language, very concise & simple
 + playground/tutorial
 + easy to start using it, no-nonsense
 + vast libraries
 + no inheritance
 + one binary to distribute
 + good for servers
 + feels like a better C (mostly)
 - can't write generic code involving arrays/slices
 - no good IDE
 + Google!
 + clear feeling it's here to stay
 + visible, many projects
 + enforced style (indentation, exports)

 * Dlang: big!










 sign but sits emtpy; by comparison Go -> condo in hip, trendy area

 * Ideas for D

















 programming language design challenge there is, but less focused on
 purpose (Andrei's note: I assume D more at fault than C++ on this)

 General feeling: "I don't feel smart enough for D and am looking for a
 quick way to accomplish a goal. I've read the Wikipedia article on D and
 didn't understand a few things. The examples seem to show off the
 language but that made them confusing. I wanted to get more into it, but
 by that time Go had already won - I looked at the tutorials, changed the
 sample code a bit right in the browser to see how it'd work for me, it
 was easy, I was in already. Some of my comments therefore illustrate my
 shortcomings than the language's, but that's true one way or another for
 all programmers (that's why technical superiority of a language doesn't
 guarantee its success)."

 ===============

 I'd love us to derive a few action items from this and other feedback.


 Andrei

IMO D seems more complicated than it really is. Mostly cause of 
presentation of documentation, lack of examples, tutorials,...

Even there is some great changes can appear between versions, it's not a 
big issue, cause it will not impact small projects.

I think that the main issue is the first impression the user can have of 
the D ecosystem. Newbies want to be taken by hand during their first 
steps with a new language.

And the First page a the web site need to show what can be/is achieved 
with D, talk about main features, market benefits,...
Documentation is only interesting for someone already use D, so it can 
be in a dedicated domain name.

Take a look to the new Qt web site :
http://www.qt.io/

Documentation :
http://doc.qt.io/

I also want encourage everybody, cause the D website made some really 
good changes during last months.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On 03/14/2015 08:49 PM, Xavier Bigand wrote:
 Take a look to the new Qt web site :
 http://www.qt.io/

While I personally think the latest D homepage redesign looks 
stylistically inconsistent and a bit cluttered and messy (I don't mean 
that to insult, merely an opinion/critique), I'm REALLY glad we haven't 
jumped on that hideous bandwagon above.

Even ignoring all subjective and objective specifics of the style, the 
mere concept of designing a site "mobile-first (and desktop if we ever 
feel like it, as it usually turns out)" is entirely inappropriate for 
websites relating to software development - a field which even today 
still takes place almost entirely on desktop/laptop, not phone or tablet.

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Tue, 2015-03-17 at 02:31 -0400, Nick Sabalausky via Digitalmars-d
wrote:
 On 03/14/2015 08:49 PM, Xavier Bigand wrote:
 Take a look to the new Qt web site :
 http://www.qt.io/

=20
 While I personally think the latest D homepage redesign looks=20
 stylistically inconsistent and a bit cluttered and messy (I don't mean=

=20
 that to insult, merely an opinion/critique), I'm REALLY glad we haven't=

=20
 jumped on that hideous bandwagon above.

I think the main issue is that a huge majority of webpage designers have
got lazy and just use the same design as everyone else. I have had this
debate about "all websites looking the same, and so there is no
branding" with a couple of new website owners, but to no avail. It seems
the fashion has been encoded into the rules of webpage design. The fact
that it leads to bad UX appears not to be an issue for them.

For me the biggest problem with the D website, is that it is dark on
light surrounded by light on dark. I prefer light on dark across the
whole page. As you say these things are personal. In the end having a
nicely branded page is actually more important that any personal taste.

 Even ignoring all subjective and objective specifics of the style, the=

=20
 mere concept of designing a site "mobile-first (and desktop if we ever=

=20
 feel like it, as it usually turns out)" is entirely inappropriate for=20
 websites relating to software development - a field which even today=20
 still takes place almost entirely on desktop/laptop, not phone or tablet.

You mean you don't do all your documentation lookup on your phablet? How
can this be, it is 2015. ;-)

Me, I'm a technology dinosaur, I use my phone for making phone calls.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On 03/17/2015 02:51 AM, Russel Winder via Digitalmars-d wrote:
 I have had this
 debate about "all websites looking the same, and so there is no
 branding" with a couple of new website owners, but to no avail. It seems
 the fashion has been encoded into the rules of webpage design. The fact
 that it leads to bad UX appears not to be an issue for them.

It's been my observation for quite some time that the majority of people 
in the tech sector seem to have come here primarily as a "follow the 
leader" reaction to computers being "the big, hot new thing". 
Consequently, we've become completely overrun by folk with a 
predominantly trend/fashion-based mentality.

IMO, this explains a LOT of things, such as why (ex.) Node.js and Go 
(among many, many, many others) have been big despite questionable 
merit, and why anything like D (or pretty much ANY attempt at persuasion 
by logical reasoning, such as your UX experiences above) which has 
strong merit but requires a greater attention span and IQ than that of a 
gnat, usually faces an uphill battle at best.

I think the "by comparison Go -> condo in hip, trendy area" from the OP 
is even more appropriate and accurate than the author may have even 
realized. And a good argument for what makes D better.

Lately I've been thinking we're just chasing our tails with the whole "D 
marketing" thing. Obviously a larger audience and improved (ie, more 
accurate) public image would be very good for us, of course. But the way 
I figure: D already appeals, and will continue to attract more of, 
*exactly* the audience that it's most suited to - intelligent 
professionals. The other 90% of field will continue darting around 
sniffing each others rears no matter WHAT we do, even if we DO manage to 
catch their attention for the day or two it inevitably takes before the 
next shiny random object trots across their path.

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Tuesday, 17 March 2015 at 06:31:32 UTC, Nick Sabalausky wrote:
 On 03/14/2015 08:49 PM, Xavier Bigand wrote:
 Take a look to the new Qt web site :
 http://www.qt.io/

 While I personally think the latest D homepage redesign looks 
 stylistically inconsistent and a bit cluttered and messy (I 
 don't mean that to insult, merely an opinion/critique), I'm 
 REALLY glad we haven't jumped on that hideous bandwagon above.

Yes, the 
scroll-scroll-scroll-scroll-where-did-they-hide-the-info-design 
is annoying and probably the result of using generic templates. 
Looks cheap.

 Even ignoring all subjective and objective specifics of the 
 style, the mere concept of designing a site "mobile-first (and 
 desktop if we ever feel like it, as it usually turns out)" is 
 entirely inappropriate for websites relating to software 
 development - a field which even today still takes place almost 
 entirely on desktop/laptop, not phone or tablet.

The site is the epitome of inappropriate:

«This site is optimized with the Yoast WordPress SEO plugin»

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On 03/17/2015 03:45 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 Yes, the scroll-scroll-scroll-scroll-where-did-they-hide-the-info-design
 is annoying and probably the result of using generic templates. Looks
 cheap.

Funny thing is, I've seen a LOT of generic-template sites that look & 
feel WAY better than the "mobile first"-style ones.

I'm still a little bit irked that Linode ditched their formerly 
fantastic homepage for yet-another-useless-PITA-mobile-first-style homepage.

 Even ignoring all subjective and objective specifics of the style, the
 mere concept of designing a site "mobile-first (and desktop if we ever
 feel like it, as it usually turns out)" is entirely inappropriate for
 websites relating to software development - a field which even today
 still takes place almost entirely on desktop/laptop, not phone or tablet.

 The site is the epitome of inappropriate:

 «This site is optimized with the Yoast WordPress SEO plugin»

Sometimes I'm truly amazed by the lengths people will go JUST to contort 
WordPress into whatever not-remotely-related purpose they have in mind.

It's like being the only carpenter in the world who uses a hammer 
instead of stringing up a frozen pizza to the end of a rubber squeeze toy.

"jmh530" <john.michael.hall gmail.com> writes:

I thoroughly enjoyed reading this thread. I don't have much 
experience with Go, but for a quick project, my goto language is 
typically Python. However, there are definitely areas that Python 
can be frustrating (where you have to have a loop, parallel 
processing). I would view D as an ideal language to complement 
Python's downsides.

As a frequent user of R and the various scientific Python 
libraries, I found myself agreeing a lot with Russell's comments, 
particularly that idea of getting D in Jupyter. To me, the 
infrastructure/community of R or Python is the biggest benefit of 
those languages. My work is typically at a high enough level that 
it just doesn't make sense to re-invent the wheel on a lot of 
things. I don't have the programming knowledge to do something 
like get armadillo or nlopt or MC Stan to work in D. Tools, like 
Calypso, that would make it easier to get C++ libraries working 
would be very important in using D more. I've looked at the 
source code to a few of those libraries and they look 
sufficiently complicated that it puts me off the idea of trying 
to get any of them working myself.

In addition, further development of the ability to call D from R 
or Python* or Julia (or vice-versa) would also be a positive.

One point that has been discussed thoroughly was learning D from 
the website. The book is a much better resource than the 
reference materials on the website for learning D. For instance, 
if I google d language classes, it takes me to the reference 
page, which is too confusing for a beginner to the D language. 
I've learned a lot from it, but it is very hard to make much 
headway without having read the books section on classes first. 
Improving tutorials and examples might go a long way. Moreover, 
quality of tutorials and examples would also be very helpful in 
terms of getting C/C++ libraries to work and calling code in 
other languages. The Interfacing to C page in the reference 
materials is written at a sufficiently high level that I'm still 
not confident I understand it well enough to use it myself.

*When I google pyd python d language, it takes me to an old link 
at dsource.org that requires two jumps before hitting a github 
page with the more recent version of the project (new release 3 
days ago!). However, that page doesn't really give you much 
information about how to use it or anything else.

"bachmeier" <no spam.net> writes:

On Tuesday, 17 March 2015 at 19:00:06 UTC, jmh530 wrote:
 In addition, further development of the ability to call D from 
 R or Python* or Julia (or vice-versa) would also be a positive.

What do you have in mind? I no longer work much with Python so my 
knowledge is limited, but calling D from R or Julia should be no 
different from calling C from those languages, as you normally 
compile your C code into a shared library anyway.

I've done the R->D thing many times and in the process have 
worked with a big chunk of the R API. Things like allocating R 
data structures from a D function, adding assertions to your D 
code to allow for an easy exit when things don't work out, and 
calling functions in the R math library, among other things, are 
not difficult.

"jmh530" <john.michael.hall gmail.com> writes:

On Tuesday, 17 March 2015 at 21:00:11 UTC, bachmeier wrote:
 What do you have in mind? I no longer work much with Python so 
 my knowledge is limited, but calling D from R or Julia should 
 be no different from calling C from those languages, as you 
 normally compile your C code into a shared library anyway.

 I've done the R->D thing many times and in the process have 
 worked with a big chunk of the R API. Things like allocating R 
 data structures from a D function, adding assertions to your D 
 code to allow for an easy exit when things don't work out, and 
 calling functions in the R math library, among other things, 
 are not difficult.

(For work at least) I find myself in situations where I'm forced 
into using loops in R or Python. Sometimes the loops can be 
parallelized, but not always. Python is not good for 
parallelizing, and R is only good on a Linux machine (which I 
can't use at work). Both are bad when you really have to do a 
loop. Julia is better for that, but I can't get the package 
manager to work on my work computer because of a corporate 
firewall. Anyway, all the calculations I would be doing would 
involve matrix math/regressions/optimization, most of which could 
be done in C++ (so being able to call C++ libraries would go a 
long way).

I've looked at calling C code from R before and using Cython in 
Python. However, I think it's another step altogether to get an R 
library (like lme4) to work in a D program. I have zero idea how 
to go about doing that. It has seemed like a bit of a hassle for 
anything complex. For instance, suppose I wanted to create a loop 
in C that calls an R function from lme4 multiple times and then I 
wanted to call that C function from R. Makes my head hurt just 
thinking about it.

Nevertheless, I think that there would be a lot of value in 
writing up what you have done with R and D. That sounds very 
interesting.

"bachmeier" <no spam.net> writes:

On Tuesday, 17 March 2015 at 22:04:08 UTC, jmh530 wrote:
 Nevertheless, I think that there would be a lot of value in 
 writing up what you have done with R and D. That sounds very 
 interesting.

I posted a link elsewhere in this thread, but it's buried in all 
these posts, so here it is again:

https://bitbucket.org/bachmeil/dmdinline

Unfortunately there is little documentation (though I'm working 
on that). I only use Linux but I would be happy if someone that 
knows Windows would find that it works there. I do a lot of 
matrix algebra, regressions, and simple rewriting of loops.

I don't personally use lme4. I looked at the source on Github. 
Everything has to be passed as an SEXP struct from R to C++ and 
you have to return a single SEXP struct. I believe all the C++ 
code used with Rcpp is marked extern "C". D can create and take 
as function arguments SEXP's, so you should be able to call into 
the code the same way that R does. That's not to say it's trivial 
but it is doable. It might make a good example of the dmdinline 
package. It depends on how much time it takes to get it working 
and how much of the R code would have to be rewritten in D.

"jmh530" <john.michael.hall gmail.com> writes:

On Wednesday, 18 March 2015 at 02:00:40 UTC, bachmeier wrote:
 Unfortunately there is little documentation (though I'm working 
 on that). I only use Linux but I would be happy if someone that 
 knows Windows would find that it works there.

Work machine's firewall isn't letting me run install_bitbucket, 
which doesn't surprise me as I can't get anything like 
bitbucket/git or whatever to work. I can try it on my home 
machine when I have time. I can tell that it might be a little 
challenging to get libgretl1-dev installed. The gretl 
sourceforge's Windows page only has zips and binaries. I found 
the Debian source, so I might try making it with Cygwin and see 
if that works.

"Bayan Rafeh" <bayan.rafeh92 gmail.com> writes:

I'm sorry to disrupt the conversation, but I feel like I should 
weigh in since I'm a user the original critic felt D should be 
attracting. I'm a CS undergrad doing my graduation project in D, 
and the only other languages I worked with seriously were Python 
and Java(For personal projects and coursework respectively). I 
actually knew about D a couple of years ago and I wanted to try 
it because I saw the nice features and wanted to use them for 
something, and only recently I got a chance to use it seriously.

I was put off at first(when I learned about it) because the 
rhetoric was that you need to be a serious programmer to use D, 
it's not for hobbyists. I dove into it anyway a couple of months 
ago because the code snippet on the old page showcased some stuff 
I wanted to try using and I thought they were cool. I don't think 
I've ever enjoyed programming as much as I did with D. Anything 
that I needed to do was doable. It's only been a few months 
programming with it and already I feel very comfortable using it. 
This is despite the various bugs and weird api design choices of 
the standard library.

It's only when I actually started seriously programming with it 
that I actually got a feel for it's features and how they were 
supposed to be used. This is where it differs from Go as far as I 
can tell from this thread. I learned D just by doing what I 
wanted to do in it, and looking up any features I needed or 
wanted when I wanted to use, and 99 times out of 100 I found them.

This should be how D is sold. It has a higher learning curve than 
Go or Python, but in the end you can use it in a style you're 
comfortable with whether you come from C, Java, Haskell, Lisp, 
whatever.

"bachmeier" <no spam.net> writes:

On Wednesday, 18 March 2015 at 16:26:44 UTC, Bayan Rafeh wrote:

 I don't think I've ever enjoyed programming as much as I did 
 with D. Anything that I needed to do was doable. It's only been 
 a few months programming with it and already I feel very 
 comfortable using it.

I'm with you. Although Guile Scheme is still my favorite 
language, working with D has been the most fun I've had with a 
programming language, and I've tried dozens of languages over a 
period of almost thirty years.

 It's only when I actually started seriously programming with it 
 that I actually got a feel for it's features and how they were 
 supposed to be used. This is where it differs from Go as far as 
 I can tell from this thread. I learned D just by doing what I 
 wanted to do in it, and looking up any features I needed or 
 wanted when I wanted to use, and 99 times out of 100 I found 
 them.

Same for me. When using C, I find myself saying, "I want to do X" 
for many different values of X. There's always a reason you can't 
do X. In D I start with the assumption that I can do anything 
that comes to mind. When using Go, there's a lot of stuff you 
can't do, but there's only one reason you can't do it. Because 
the Go team thinks anyone wanting do it doesn't know how to 
program.

 This should be how D is sold. It has a higher learning curve 
 than Go or Python, but in the end you can use it in a style 
 you're comfortable with whether you come from C, Java, Haskell, 
 Lisp, whatever.

I would characterize it more as a longer learning curve than a 
higher learning curve. It's not like C++ where you have to master 
so much complicated sh*t in order to use the language. One of the 
first things I was told to do when I started with C++ was learn 
Boost. Bjarne Stroustrup has complained that Boost is excessively 
complicated, and a beginner's supposed to learn it? You don't get 
that with D. It was probably six months before I even bothered to 
learn D's templates. I have seen so many times "big language" and 
"complicated language" used interchangeably wrt D. It's a big 
language but not a complicated one IMO.

"bachmeier" <no spam.net> writes:

On Wednesday, 18 March 2015 at 15:13:24 UTC, jmh530 wrote:
 On Wednesday, 18 March 2015 at 02:00:40 UTC, bachmeier wrote:
 Unfortunately there is little documentation (though I'm 
 working on that). I only use Linux but I would be happy if 
 someone that knows Windows would find that it works there.

 Work machine's firewall isn't letting me run install_bitbucket, 
 which doesn't surprise me as I can't get anything like 
 bitbucket/git or whatever to work. I can try it on my home 
 machine when I have time. I can tell that it might be a little 
 challenging to get libgretl1-dev installed. The gretl 
 sourceforge's Windows page only has zips and binaries. I found 
 the Debian source, so I might try making it with Cygwin and see 
 if that works.

I'd greatly appreciate hearing about your experiences. I was lost 
when I tried it on Windows, but then I don't have any experience 
developing on Windows (that was a big part of why I moved to 
Linux). Technically, the gretl dependency isn't needed, but it's 
got such a nice interface to the matrix algebra and regression 
routines.

You might be able to download the zip here:

https://bitbucket.org/bachmeil/dmdinline/downloads

and then install from a USB disk using install_local.

"jmh530" <john.michael.hall gmail.com> writes:

On Wednesday, 18 March 2015 at 18:48:59 UTC, bachmeier wrote:
 On Wednesday, 18 March 2015 at 15:13:24 UTC, jmh530 wrote:

 You might be able to download the zip here:

 https://bitbucket.org/bachmeil/dmdinline/downloads

 and then install from a USB disk using install_local.

I ended up trying this on my home computer because it makes life 
much easier.

The Debian file I was trying to get for libgretl-dev was a 
package rather than the source, I think, and I couldn't find the 
source or any sort of Windows version. Anyway commands like
 install_librtod2(gretl="usr/lib/libgretl-1.0.so", 
 libr="usr/lib/R/lib/libR.so")

don't make much sense as .so is only for linux. I tried it anyway 
and got an error about the cd command not being found (wasn't the 
error I expected, but oh well).

I seem to be able to import the dmdinline library just fine. When 
I run
compileD("foo", txt)
I get

Error in file(filename, "r", encoding = encoding) :
   cannot open the connection
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
   cannot open file 'C:/Users/John/Documents/.rtod2/config.R': No 
such file or directory

I don't know where the config.R file is located.

"bachmeier" <no spam.com> writes:

Just saw this message. Thanks for trying it out.

I will have to look at what Rcpp does on Windows. I've never used 
D on Windows either so will have to figure that out as well.


On Friday, 20 March 2015 at 02:38:02 UTC, jmh530 wrote:
 On Wednesday, 18 March 2015 at 18:48:59 UTC, bachmeier wrote:
 On Wednesday, 18 March 2015 at 15:13:24 UTC, jmh530 wrote:

 You might be able to download the zip here:

 https://bitbucket.org/bachmeil/dmdinline/downloads

 and then install from a USB disk using install_local.

 I ended up trying this on my home computer because it makes 
 life much easier.

 The Debian file I was trying to get for libgretl-dev was a 
 package rather than the source, I think, and I couldn't find 
 the source or any sort of Windows version. Anyway commands like
 install_librtod2(gretl="usr/lib/libgretl-1.0.so", 
 libr="usr/lib/R/lib/libR.so")

 don't make much sense as .so is only for linux. I tried it 
 anyway and got an error about the cd command not being found 
 (wasn't the error I expected, but oh well).

 I seem to be able to import the dmdinline library just fine. 
 When I run
 compileD("foo", txt)
 I get

 Error in file(filename, "r", encoding = encoding) :
   cannot open the connection
 In addition: Warning message:
 In file(filename, "r", encoding = encoding) :
   cannot open file 'C:/Users/John/Documents/.rtod2/config.R': 
 No such file or directory

 I don't know where the config.R file is located.

config.R will be created by install_librtod2, but it is unlikely 
to work on Windows, because I

"Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:

On Tuesday, 17 March 2015 at 21:00:11 UTC, bachmeier wrote:
 On Tuesday, 17 March 2015 at 19:00:06 UTC, jmh530 wrote:
 In addition, further development of the ability to call D from 
 R or Python* or Julia (or vice-versa) would also be a positive.

 What do you have in mind? I no longer work much with Python so 
 my knowledge is limited, but calling D from R or Julia should 
 be no different from calling C from those languages, as you 
 normally compile your C code into a shared library anyway.

 I've done the R->D thing many times and in the process have 
 worked with a big chunk of the R API. Things like allocating R 
 data structures from a D function, adding assertions to your D 
 code to allow for an easy exit when things don't work out, and 
 calling functions in the R math library, among other things, 
 are not difficult.

PyD is pretty nice, although one wouldn't want to call it from an 
inner loop.  And it's easy to go via cython also.  (I wonder how 
well cython works with interfacing with D via the C++ interface, 
because that way you could extend python with D classes and have 
them be faster than going through PyD).

PyD also works with numpy memoryviews I think.

For Julia, easy to call D.  It would be nice to port julia.h to D 
(I started, but got distracted) so D can call back Julia.

"bachmeier" <no spam.net> writes:

On Wednesday, 18 March 2015 at 01:52:00 UTC, Laeeth Isharc wrote:
 PyD is pretty nice, although one wouldn't want to call it from 
 an inner loop.

Why wouldn't you want to call it from an inner loop?

"Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:

On Wednesday, 18 March 2015 at 02:02:27 UTC, bachmeier wrote:
 On Wednesday, 18 March 2015 at 01:52:00 UTC, Laeeth Isharc 
 wrote:
 PyD is pretty nice, although one wouldn't want to call it from 
 an inner loop.

 Why wouldn't you want to call it from an inner loop?

See benchmark someone did a while back that had D relatively 
slow, which prob was PyD judging by comment from the developer.  
But there are different kinds of demands, and I can't say I am 
highly experienced with using pyD in that context.  So if you 
found different I would love to hear more.

If I had time I would experiment, but I don't right now unfort.

"Chris" <wendlec tcd.ie> writes:

On Wednesday, 18 March 2015 at 01:52:00 UTC, Laeeth Isharc wrote:
 On Tuesday, 17 March 2015 at 21:00:11 UTC, bachmeier wrote:
 On Tuesday, 17 March 2015 at 19:00:06 UTC, jmh530 wrote:
 In addition, further development of the ability to call D 
 from R or Python* or Julia (or vice-versa) would also be a 
 positive.

 What do you have in mind? I no longer work much with Python so 
 my knowledge is limited, but calling D from R or Julia should 
 be no different from calling C from those languages, as you 
 normally compile your C code into a shared library anyway.

 I've done the R->D thing many times and in the process have 
 worked with a big chunk of the R API. Things like allocating R 
 data structures from a D function, adding assertions to your D 
 code to allow for an easy exit when things don't work out, and 
 calling functions in the R math library, among other things, 
 are not difficult.

 PyD is pretty nice, although one wouldn't want to call it from 
 an inner loop.  And it's easy to go via cython also.  (I wonder 
 how well cython works with interfacing with D via the C++ 
 interface, because that way you could extend python with D 
 classes and have them be faster than going through PyD).

 PyD also works with numpy memoryviews I think.

 For Julia, easy to call D.  It would be nice to port julia.h to 
 D (I started, but got distracted) so D can call back Julia.

I once wrote a little test server with vibe.d and LuaD to have 
Lua server pages. It compiles the pages into Lua functions and 
executes them from memory. (Rikki gave me the idea). No use to 
parse every page when it's called.

It's not much code at all. It's only a test and very simple, not 
optimized or anything. The function in vibe.d that handled it 
looks like this:

/**
* Function that handles LSP using LuaD and a home made
* parser.
*/
void luaHandler(HTTPServerRequest req, HTTPServerResponse res) {

   auto url = URL(req.requestURL);

   // Set url arguments (note: should decode URL)
   lua["args"] = req.query;

   // If html/lsp page is not yet compiled, parse, compile and 
store it in _S
   if (!canFind(_S.keys, url.pathString[1..$])) {
     auto file = std.stdio.File("public/"~url.pathString[1..$], 
"r");
     string txt;
     foreach (line; file.byLine(KeepTerminator.yes)) {
       txt ~= to!string(line);  // to!string really necessary?
     }
     auto asLua = parseLua(txt);
     auto func = lua.loadString(asLua);
     _S[url.pathString[1..$]] = func;
   }
   // Call the compiled Lua function
   auto ret = _S[url.pathString[1..$]].call!(LuaTable)();
   string html;
   foreach(size_t i, string s; ret) {
     html ~= s;
   }
   res.writeBody(cast(ubyte[])html);
}

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Wednesday, 18 March 2015 at 01:52:00 UTC, Laeeth Isharc wrote:
 On Tuesday, 17 March 2015 at 21:00:11 UTC, bachmeier wrote:
 On Tuesday, 17 March 2015 at 19:00:06 UTC, jmh530 wrote:
 In addition, further development of the ability to call D 
 from R or Python* or Julia (or vice-versa) would also be a 
 positive.

 What do you have in mind? I no longer work much with Python so 
 my knowledge is limited, but calling D from R or Julia should 
 be no different from calling C from those languages, as you 
 normally compile your C code into a shared library anyway.

 I've done the R->D thing many times and in the process have 
 worked with a big chunk of the R API. Things like allocating R 
 data structures from a D function, adding assertions to your D 
 code to allow for an easy exit when things don't work out, and 
 calling functions in the R math library, among other things, 
 are not difficult.

 (I wonder how well cython works with interfacing with D via the 
 C++ interface, because that way you could extend python with D 
 classes and have them be faster than going through PyD).

This is a good idea. dtoh could speed up this workflow, see 
https://github.com/adamdruppe/dtoh/blob/master/dtoh.d and 
http://forum.dlang.org/post/uyuwdptkpukshxzygqpn forum.dlang.org

"Carl Sturtivant" <sturtivant gmail.com> writes:

Characterizing the problem as "Go versus D" is framing it to D's 
disadvantage. Broadly speaking Go is one thing & D is many things.

The whole difficulty with D encountered by a person choosing 
which of (e.g.) Go and D to use lies in this difference. D as a 
whole is overwhelming in this situation.

D may be spoken naturally in many different ways. This is its 
strength. We need to make this strength accessible to outsiders. 
If an outsider can speak D at first in a way somewhat familiar 
from their previous experience, that will provide accessibility.

We may classify outsiders as coming from C, C++, Java, Python, Go 
and more. Make your own list.

Each kind of outsider needs to see an approximate reflection in D 
of the machinery of their usual means of expression and its 
attendant conceptual models, plus exciting possibilities to 
improve and extend these. This reflection must be made workable 
on all scales, from details of idioms and techniques up to the 
big picture.

An outsider needs a well developed specialized way in! One that 
is designed for that specific class of outsider. Given such, in 
the short run the D written by one class of outsider will be 
quite different in its use of the language to that written by 
another, which will be quite different again to that written by 
contributors to phobos.

We should accept this. They may expand their horizons within D 
later. The community may find ways to help such people do this, 
for example by gently suggesting better parts of D to use for 
technical parts of their purposes when they post to the forums. 
In the meantime they have come to D because there was a 
relatively efficient way for them to do that, not a bewildering 
collection of possibilities that deflected them to the 
certainties of the overly prescribed ways of (e.g.) Go.

Now consider outsiders from C, C++, Java, Python, Go.

I'll leave you to consider C, C++. The articles
   http://dlang.org/ctod.html
   http://dlang.org/cpptod.html
   http://dlang.org/pretod.html
have made a detail-oriented start with tacit assumptions about 
what is going on at wider scales. These languages are closely 
entangled with D's development, and so are special cases given 
better treatment. These could be expanded into an entire 
introduction to D for C outsiders and an entire introduction to D 
for C++ outsiders.

Java is not too hard especially given the design of D's classes. 
Java is almost a small sublanguage of D.

Python and Go are harder. But D is a system programming language 
with [long list of powerful abstraction facilities, many 
supported paradigms, "wonderfulness of D"]. And as such one may 
hope it is possible to arrange to program in D in Pythonesque or 
Goish ways. Especially if this provides a way for D to win rather 
than lose out to these languages, by providing an incremental way 
in.

The yield facility in Python can serve as a first example here. 
This is not a part of the D language. The Fiber class in 
core.thread can be made to emulate it with additional 
superstructure with some effort. But this is exactly the kind of 
effort an outsider from Python is not immediately equipped to 
make. Go's goroutine and its attendant machinery could be 
examined with a similar end in view.

What all of this suggests is that some library code may need to 
be written to accomodate the way into D for a class of outsiders. 
The administration of where such goes needs to make it simple to 
import with a standard D installation. And if D is too inflexible 
to provide something important via a library, as is possibly the 
case with yield, serious consideration should be given to (don't 
scream) adding it to the language.

In conclusion, D is not gaining the traction it deserves as a 
potential lingua franca. I am making the case that we need to 
treat it as several programming languages for the purpose of 
making it rapidly usable by typical outsiders. D-python, D-java, 
D-whatever --- facets of D.

This entails library additions, and possibly language additions. 
This entails a lot of writing of documentation, in effect a small 
book for each facet of D.

There is much to be decided about how this could be best done. I 
will not pursue that here. But I do believe something 
approximately like this is the only way for D to start to win out 
when someone decides whether to use (e.g.) Go or D in a new 
situation, or even whether to use D or stay back in Python with 
all of its disadvantages. The complex cliff face of D needs some 
overtly navigated paths for all kinds of explorers.

"Chris" <wendlec tcd.ie> writes:

On Tuesday, 17 March 2015 at 21:16:38 UTC, Carl Sturtivant wrote:
 Characterizing the problem as "Go versus D" is framing it to 
 D's disadvantage. Broadly speaking Go is one thing & D is many 
 things.

 The whole difficulty with D encountered by a person choosing 
 which of (e.g.) Go and D to use lies in this difference. D as a 
 whole is overwhelming in this situation.

 D may be spoken naturally in many different ways. This is its 
 strength. We need to make this strength accessible to 
 outsiders. If an outsider can speak D at first in a way 
 somewhat familiar from their previous experience, that will 
 provide accessibility.

 We may classify outsiders as coming from C, C++, Java, Python, 
 Go and more. Make your own list.

 Each kind of outsider needs to see an approximate reflection in 
 D of the machinery of their usual means of expression and its 
 attendant conceptual models, plus exciting possibilities to 
 improve and extend these. This reflection must be made workable 
 on all scales, from details of idioms and techniques up to the 
 big picture.

 An outsider needs a well developed specialized way in! One that 
 is designed for that specific class of outsider. Given such, in 
 the short run the D written by one class of outsider will be 
 quite different in its use of the language to that written by 
 another, which will be quite different again to that written by 
 contributors to phobos.

 We should accept this. They may expand their horizons within D 
 later. The community may find ways to help such people do this, 
 for example by gently suggesting better parts of D to use for 
 technical parts of their purposes when they post to the forums. 
 In the meantime they have come to D because there was a 
 relatively efficient way for them to do that, not a bewildering 
 collection of possibilities that deflected them to the 
 certainties of the overly prescribed ways of (e.g.) Go.

 Now consider outsiders from C, C++, Java, Python, Go.

 I'll leave you to consider C, C++. The articles
   http://dlang.org/ctod.html
   http://dlang.org/cpptod.html
   http://dlang.org/pretod.html
 have made a detail-oriented start with tacit assumptions about 
 what is going on at wider scales. These languages are closely 
 entangled with D's development, and so are special cases given 
 better treatment. These could be expanded into an entire 
 introduction to D for C outsiders and an entire introduction to 
 D for C++ outsiders.

 Java is not too hard especially given the design of D's 
 classes. Java is almost a small sublanguage of D.

 Python and Go are harder. But D is a system programming 
 language with [long list of powerful abstraction facilities, 
 many supported paradigms, "wonderfulness of D"]. And as such 
 one may hope it is possible to arrange to program in D in 
 Pythonesque or Goish ways. Especially if this provides a way 
 for D to win rather than lose out to these languages, by 
 providing an incremental way in.

 The yield facility in Python can serve as a first example here. 
 This is not a part of the D language. The Fiber class in 
 core.thread can be made to emulate it with additional 
 superstructure with some effort. But this is exactly the kind 
 of effort an outsider from Python is not immediately equipped 
 to make. Go's goroutine and its attendant machinery could be 
 examined with a similar end in view.

 What all of this suggests is that some library code may need to 
 be written to accomodate the way into D for a class of 
 outsiders. The administration of where such goes needs to make 
 it simple to import with a standard D installation. And if D is 
 too inflexible to provide something important via a library, as 
 is possibly the case with yield, serious consideration should 
 be given to (don't scream) adding it to the language.

 In conclusion, D is not gaining the traction it deserves as a 
 potential lingua franca. I am making the case that we need to 
 treat it as several programming languages for the purpose of 
 making it rapidly usable by typical outsiders. D-python, 
 D-java, D-whatever --- facets of D.

 This entails library additions, and possibly language 
 additions. This entails a lot of writing of documentation, in 
 effect a small book for each facet of D.

 There is much to be decided about how this could be best done. 
 I will not pursue that here. But I do believe something 
 approximately like this is the only way for D to start to win 
 out when someone decides whether to use (e.g.) Go or D in a new 
 situation, or even whether to use D or stay back in Python with 
 all of its disadvantages. The complex cliff face of D needs 
 some overtly navigated paths for all kinds of explorers.

I think this is a good approach. The beauty of D is that it can 
be a lot of different things to different people. Do you have any 
examples yet, as in "D for Python programmers"? E.g. loops:

Python:
for item in list:
   print "The item is %s" % item

D:
import std.stdio : writefln;
foreach(ref item; list) {
   writefln("The item is %s", item);
}