www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A few notes on choosing between Go and D for a quick project

reply 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!

# big language
# IDE?
# small subset?
# libraries?
# will it be around?
# Perception matters
## how stable is it?
## not great for servers or UIs; what then?
## new house in unpopulated neighborhood; there's an "Enter, it's open" 
sign but sits emtpy; by comparison Go -> condo in hip, trendy area

* Ideas for D

# what C++ should be but cannot
## too late for C++, but not for D
## some or all of  safe, immutable, pure should be the default
# libraries, projects should be prominently listed and nurtured
# single-idea advantage; D seems to embody too many ideas at once
## concurrency?
## networking?
## generics?
## interoperability with C and C++?
## focus on one!
# must attract/hook casual users
# unclear what's a good IDE - JetBrains? is there Vim support?
# what's D's equivalent to frameworks such as react.js?
# language designers think of features, users think of purpose
## react, go, rust, java -> purpose
## D, C++ -> "Ivy league candidates" having a response for 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
Mar 12 2015
next sibling parent reply "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.
Mar 12 2015
parent reply "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
Mar 15 2015
parent reply "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?)
Mar 15 2015
next sibling parent reply "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.
Mar 15 2015
parent reply "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.
Mar 16 2015
parent "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.
Mar 16 2015
prev sibling next sibling parent reply "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).
Mar 15 2015
parent "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.
Mar 15 2015
prev sibling parent "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.
Mar 15 2015
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 ## some or all of  safe, immutable, pure should be the default
+1 I have a ER on safe by default and Walter seems to agree. But I'd like more. A "strict D" mode? :-)
 # libraries, projects should be prominently listed and nurtured
 # single-idea advantage; D seems to embody too many ideas at 
 once
 ## concurrency?
 ## networking?
 ## generics?
 ## interoperability with C and C++?
 ## focus on one!
D can't be a single-purpose language. And it has more moving parts compared to Go. Bye, bearophile
Mar 12 2015
next sibling parent reply "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.
Mar 12 2015
parent reply 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
Mar 12 2015
parent reply "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
Mar 13 2015
next sibling parent reply 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
Mar 13 2015
parent reply 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
Mar 13 2015
parent reply 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
Mar 14 2015
next sibling parent reply "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.
Mar 14 2015
parent reply 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
Mar 14 2015
parent reply "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.
Mar 14 2015
parent 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
Mar 15 2015
prev sibling parent reply 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) }
Mar 14 2015
parent reply 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
Mar 14 2015
next sibling parent reply 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
Mar 14 2015
parent 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
Mar 17 2015
prev sibling next sibling parent reply "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.
Mar 14 2015
parent 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
Mar 17 2015
prev sibling parent reply "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
Mar 17 2015
next sibling parent reply 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
Mar 17 2015
next sibling parent reply "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.
Mar 17 2015
parent 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
Mar 18 2015
prev sibling parent 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
Mar 18 2015
prev sibling next sibling parent reply "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
Mar 18 2015
next sibling parent reply "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 :-).
Mar 18 2015
parent 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
Mar 18 2015
prev sibling parent 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
Mar 21 2015
prev sibling parent reply 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
Mar 18 2015
parent "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.
Mar 18 2015
prev sibling parent reply 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
Mar 13 2015
parent reply "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.
Mar 13 2015
parent reply 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
Mar 13 2015
next sibling parent "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.
Mar 13 2015
prev sibling parent reply 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
Mar 14 2015
next sibling parent "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.
Mar 14 2015
prev sibling parent 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! :-)
Mar 14 2015
prev sibling next sibling parent "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.
Mar 12 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote:
 Andrei Alexandrescu:

 ## some or all of  safe, immutable, pure should be the default
+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).
Mar 13 2015
parent reply "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
Mar 13 2015
next sibling parent "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.
Mar 13 2015
prev sibling next sibling parent "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
Mar 13 2015
prev sibling next sibling parent reply 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
Mar 13 2015
parent reply "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
Mar 13 2015
parent "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.
Mar 19 2015
prev sibling parent reply 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.
Mar 13 2015
next sibling parent reply "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?
Mar 13 2015
next sibling parent reply "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. ;)
Mar 13 2015
parent reply "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.
Mar 13 2015
parent reply "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.
Mar 13 2015
parent reply "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.
Mar 13 2015
parent reply 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
Mar 13 2015
parent "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: Example #1: ---- pure: nothrow: // ... some stuff default: // not pure/nothrow ---- Example #2: ---- class Foo { final: // ... default: // virtual // ... } ----
Mar 13 2015
prev sibling parent reply 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 ...
Mar 13 2015
next sibling parent "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.
Mar 13 2015
prev sibling parent reply 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
Mar 13 2015
next sibling parent reply "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
Mar 13 2015
parent reply 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
Mar 13 2015
parent "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.
Mar 13 2015
prev sibling parent "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 :(
Mar 14 2015
prev sibling next sibling parent "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
Mar 13 2015
prev sibling parent reply "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 with very little implicit casts like Haskell, and F#. 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
Mar 13 2015
parent reply 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 like Haskell, and F#. 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.
Mar 14 2015
next sibling parent "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.
Mar 15 2015
prev sibling parent 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?
Mar 16 2015
prev sibling next sibling parent "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.
 # big language
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.
Mar 12 2015
prev sibling next sibling parent reply 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.
Mar 12 2015
next sibling parent reply 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
Mar 12 2015
next sibling parent reply 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.
Mar 13 2015
parent reply 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
Mar 14 2015
parent reply 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.
Mar 14 2015
next sibling parent reply "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.
Mar 14 2015
parent reply 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 :-)
Mar 14 2015
parent reply "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.
Mar 14 2015
parent reply 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.
Mar 14 2015
next sibling parent reply "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.
Mar 14 2015
next sibling parent "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.
Mar 14 2015
prev sibling next sibling parent "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".
Mar 14 2015
prev sibling next sibling parent reply 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 :-)
Mar 15 2015
parent reply "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.
Mar 15 2015
parent reply 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.
Mar 15 2015
parent "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.
Mar 15 2015
prev sibling parent reply 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.
Mar 15 2015
parent reply "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?
Mar 15 2015
parent reply 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
Mar 15 2015
parent "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
Mar 15 2015
prev sibling next sibling parent 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
Mar 15 2015
prev sibling next sibling parent reply "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.
Mar 15 2015
parent "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.
Mar 15 2015
prev sibling parent reply "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
Mar 15 2015
next sibling parent "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 /**/ :-)
Mar 15 2015
prev sibling parent "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.
Mar 15 2015
prev sibling next sibling parent "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)
Mar 14 2015
prev sibling parent reply "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?
Mar 14 2015
parent reply "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.
Mar 15 2015
parent "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.
Mar 15 2015
prev sibling parent "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.
Mar 13 2015
prev sibling next sibling parent reply "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
Mar 13 2015
parent reply 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.
Mar 13 2015
parent "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.
Mar 13 2015
prev sibling parent reply "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...)
Mar 15 2015
parent reply 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!)
Mar 15 2015
parent reply "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.
Mar 16 2015
parent reply "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.
Mar 16 2015
next sibling parent reply "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.
Mar 16 2015
parent reply "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.
Mar 16 2015
parent reply 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.
Mar 17 2015
next sibling parent reply "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.
Mar 17 2015
next sibling parent reply "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.
Mar 17 2015
parent reply "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.
Mar 17 2015
next sibling parent reply 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.
Mar 17 2015
parent reply "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.
Mar 17 2015
parent reply "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));
Mar 19 2015
parent reply "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.
Mar 19 2015
next sibling parent reply "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.
Mar 19 2015
next sibling parent reply "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
Mar 19 2015
parent 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
Mar 20 2015
prev sibling parent reply "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.
Mar 19 2015
parent "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.
Mar 20 2015
prev sibling parent reply "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.
Mar 19 2015
parent "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.
Mar 19 2015
prev sibling parent reply "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
Mar 17 2015
parent reply "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.
Mar 17 2015
parent reply "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
Mar 17 2015
next sibling parent "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
Mar 17 2015
prev sibling parent reply 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
Mar 17 2015
parent "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
Mar 17 2015
prev sibling parent reply "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".
Mar 17 2015
parent "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 /
Mar 17 2015
prev sibling parent 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
Mar 18 2015
prev sibling next sibling parent "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.
Mar 16 2015
prev sibling parent reply "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.
Mar 16 2015
next sibling parent "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
Mar 16 2015
prev sibling parent "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?
Mar 16 2015
prev sibling next sibling parent reply "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!

 # big language
 # IDE?
 # small subset?
 # libraries?
 # will it be around?
 # Perception matters
 ## how stable is it?
 ## not great for servers or UIs; what then?
 ## new house in unpopulated neighborhood; there's an "Enter, 
 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

 # what C++ should be but cannot
 ## too late for C++, but not for D
 ## some or all of  safe, immutable, pure should be the default
 # libraries, projects should be prominently listed and nurtured
Good suggestion for the front page, perhaps a library of the month?
 # single-idea advantage; D seems to embody too many ideas at 
 once
 ## concurrency?
 ## networking?
Where is D advertised as being special or different with its ideas on networking? I don't see it.
 ## generics?
 ## interoperability with C and C++?
 ## focus on one!
That's not D's approach, for better or worse. It's offering a buffet of features, not just a great steak.
 # must attract/hook casual users
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.
 # unclear what's a good IDE - JetBrains? is there Vim support?
The D Wiki lists supported IDEs, maybe the "Getting Started" page should directly link there.
 # what's D's equivalent to frameworks such as react.js?
 # language designers think of features, users think of purpose
 ## react, go, rust, java -> purpose
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/
 ## D, C++ -> "Ivy league candidates" having a response for 
 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.
Mar 12 2015
parent reply 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
Mar 12 2015
next sibling parent "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 :)
Mar 12 2015
prev sibling next sibling parent 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
Mar 13 2015
prev sibling parent reply "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
Mar 18 2015
parent "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
Mar 18 2015
prev sibling next sibling parent reply 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
Mar 12 2015
parent reply "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.
Mar 13 2015
next sibling parent reply "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
Mar 13 2015
next sibling parent reply "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.
Mar 13 2015
parent "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
Mar 13 2015
prev sibling parent reply "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
Mar 13 2015
parent reply "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
Mar 13 2015
parent "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.
Mar 13 2015
prev sibling next sibling parent reply 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
Mar 13 2015
parent reply "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.
Mar 13 2015
parent 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
Mar 13 2015
prev sibling parent "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.
Mar 14 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 ## some or all of  safe, immutable, pure should be the default
 # libraries, projects should be prominently listed and nurtured
+1
 # single-idea advantage; D seems to embody too many ideas at 
 once
 ## concurrency?
 ## networking?
 ## generics?
 ## interoperability with C and C++?
 ## focus on one!
-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.
Mar 13 2015
parent 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
Mar 13 2015
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 # language designers think of features, users think of purpose
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.
Mar 13 2015
prev sibling next sibling parent "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!
 # will it be around?
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.
Mar 13 2015
prev sibling next sibling parent reply "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!

 # big language
 # IDE?
 # small subset?
 # libraries?
 # will it be around?
 # Perception matters
 ## how stable is it?
 ## not great for servers or UIs; what then?
 ## new house in unpopulated neighborhood; there's an "Enter, 
 it's open" sign but sits emtpy; by comparison Go -> condo in 
 hip, trendy area

 * Ideas for D

 # what C++ should be but cannot
 ## too late for C++, but not for D
 ## some or all of  safe, immutable, pure should be the default
 # libraries, projects should be prominently listed and nurtured
 # single-idea advantage; D seems to embody too many ideas at 
 once
 ## concurrency?
 ## networking?
 ## generics?
 ## interoperability with C and C++?
 ## focus on one!
 # must attract/hook casual users
 # unclear what's a good IDE - JetBrains? is there Vim support?
 # what's D's equivalent to frameworks such as react.js?
 # language designers think of features, users think of purpose
 ## react, go, rust, java -> purpose
 ## D, C++ -> "Ivy league candidates" having a response for 
 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
Mar 13 2015
parent 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
Mar 13 2015
prev sibling next sibling parent "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.
Mar 13 2015
prev sibling next sibling parent reply "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!

 # big language
 # IDE?
 # small subset?
 # libraries?
 # will it be around?
 # Perception matters
 ## how stable is it?
 ## not great for servers or UIs; what then?
 ## new house in unpopulated neighborhood; there's an "Enter, 
 it's open" sign but sits emtpy; by comparison Go -> condo in 
 hip, trendy area

 * Ideas for D

 # what C++ should be but cannot
 ## too late for C++, but not for D
 ## some or all of  safe, immutable, pure should be the default
 # libraries, projects should be prominently listed and nurtured
 # single-idea advantage; D seems to embody too many ideas at 
 once
 ## concurrency?
 ## networking?
 ## generics?
 ## interoperability with C and C++?
 ## focus on one!
 # must attract/hook casual users
 # unclear what's a good IDE - JetBrains? is there Vim support?
 # what's D's equivalent to frameworks such as react.js?
 # language designers think of features, users think of purpose
 ## react, go, rust, java -> purpose
 ## D, C++ -> "Ivy league candidates" having a response for 
 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
Mar 13 2015
parent "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
Mar 14 2015
prev sibling next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu 
wrote:
 # unclear what's a good IDE - JetBrains? is there Vim support?
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.
Mar 13 2015
prev sibling next sibling parent reply "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.
Mar 13 2015
next sibling parent reply "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.
Mar 13 2015
next sibling parent reply 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
Mar 13 2015
next sibling parent reply "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.)
Mar 13 2015
next sibling parent reply 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
Mar 13 2015
next sibling parent reply "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.
Mar 13 2015
parent reply 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. "abc".startsWith("ab", '#') * 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
Mar 13 2015
next sibling parent reply 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.
 "abc".startsWith("ab", '#')
 
 * 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
Mar 13 2015
parent 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
Mar 13 2015
prev sibling next sibling parent reply 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!
Mar 13 2015
parent 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
Mar 13 2015
prev sibling next sibling parent reply 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
Mar 13 2015
parent reply 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
Mar 13 2015
parent reply 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
Mar 14 2015
next sibling parent reply "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
Mar 14 2015
parent reply 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
Mar 14 2015
parent 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!
Mar 20 2015
prev sibling parent reply 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
Mar 14 2015
parent 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
Mar 14 2015
prev sibling parent reply "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.
Mar 18 2015
next sibling parent reply "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
Mar 18 2015
parent reply "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
Mar 18 2015
next sibling parent reply "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
Mar 18 2015
next sibling parent 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.
Mar 18 2015
prev sibling parent reply "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.)
Mar 18 2015
parent reply "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...
Mar 19 2015
next sibling parent reply "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.
Mar 19 2015
next sibling parent reply 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
Mar 19 2015
next sibling parent reply "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
Mar 19 2015
parent 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
Mar 21 2015
prev sibling parent reply "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.
Mar 20 2015
parent reply 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
Mar 20 2015
next sibling parent 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.
Mar 20 2015
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 Well then write that answer.
Not true, right now.
Mar 21 2015
prev sibling parent "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.
Mar 21 2015
prev sibling parent reply "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.
Mar 20 2015
parent reply 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.
Mar 21 2015
parent reply "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.
Mar 21 2015
parent reply 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.
Mar 21 2015
parent reply "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.
Mar 21 2015
parent reply 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.
Mar 21 2015
next sibling parent "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?
Mar 21 2015
prev sibling parent "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.
Mar 22 2015
prev sibling parent reply 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.) http://dlang.org/phobos/std_string.html#.splitLines
Mar 19 2015
parent reply "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
Mar 20 2015
next sibling parent reply 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.
Mar 20 2015
next sibling parent reply "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
Mar 20 2015
parent reply 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.
Mar 20 2015
next sibling parent reply "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
Mar 20 2015
parent 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.
Mar 20 2015
prev sibling parent 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
Mar 20 2015
prev sibling parent 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
Mar 20 2015
prev sibling parent reply 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
Mar 20 2015
parent reply 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.
Mar 20 2015
parent reply 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
Mar 20 2015
parent reply "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")` ?
Mar 20 2015
parent reply 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 d/29153508#29153508 -- Andrei
Mar 21 2015
parent "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 d/29153508#29153508 -- 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).
Mar 22 2015
prev sibling next sibling parent reply "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.
Mar 18 2015
parent reply "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.
Mar 18 2015
next sibling parent "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.
Mar 18 2015
prev sibling parent reply 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
Mar 19 2015
parent "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
Mar 19 2015
prev sibling next sibling parent "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 :-)
Mar 18 2015
prev sibling parent reply 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.
Mar 18 2015
next sibling parent reply "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 ?
Mar 18 2015
next sibling parent reply 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...
Mar 18 2015
parent reply 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.
Mar 18 2015
parent 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.
Mar 18 2015
prev sibling parent 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.
Mar 18 2015
prev sibling next sibling parent reply "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.
Mar 18 2015
parent reply 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.
Mar 18 2015
next sibling parent reply "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!
Mar 19 2015
next sibling parent reply 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.
Mar 19 2015
parent reply 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.
Mar 20 2015
parent reply "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.
Mar 20 2015
next sibling parent reply 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.
Mar 20 2015
next sibling parent reply "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?
Mar 20 2015
parent 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.
Mar 20 2015
prev sibling next sibling parent reply "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.
Mar 21 2015
parent 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. :)
Mar 21 2015
prev sibling parent "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=-
Mar 24 2015
prev sibling parent 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.
Mar 21 2015
prev sibling parent "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
Mar 20 2015
prev sibling parent "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
Mar 20 2015
prev sibling parent reply 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
Mar 19 2015
parent 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);
Mar 21 2015
prev sibling next sibling parent 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
Mar 18 2015
prev sibling next sibling parent "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. : )
Mar 18 2015
prev sibling next sibling parent 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.
Mar 18 2015
prev sibling parent reply "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.
Mar 22 2015
parent reply 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.
Mar 23 2015
parent reply "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.
Mar 23 2015
next sibling parent 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
Mar 23 2015
prev sibling parent 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)) if (isFile(path) && File(path).startsWith("#!")) 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
Mar 23 2015
prev sibling next sibling parent reply 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
Mar 13 2015
parent reply 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
Mar 13 2015
parent 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.
Mar 13 2015
prev sibling next sibling parent "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
Mar 13 2015
prev sibling parent reply "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".
Mar 13 2015
next sibling parent reply "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)
Mar 13 2015
parent reply "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.
Mar 13 2015
parent reply "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.
Mar 13 2015
next sibling parent "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.
Mar 13 2015
prev sibling parent reply "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."
Mar 13 2015
parent "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...
Mar 13 2015
prev sibling parent reply 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
Mar 13 2015
parent "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
Mar 14 2015
prev sibling next sibling parent reply 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.
Mar 13 2015
parent "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
Mar 13 2015
prev sibling next sibling parent reply "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.
Mar 13 2015
next sibling parent 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
Mar 13 2015
prev sibling parent reply "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).
Mar 14 2015
next sibling parent reply "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.
Mar 14 2015
parent 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
Mar 14 2015
prev sibling next sibling parent reply 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
Mar 14 2015
parent reply "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.
Mar 14 2015
parent reply 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
Mar 14 2015
next sibling parent "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.
Mar 14 2015
prev sibling parent "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
Mar 14 2015
prev sibling parent reply "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
Mar 14 2015
parent reply "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.
Mar 15 2015
parent reply "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).
Mar 15 2015
next sibling parent reply "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.
Mar 15 2015
next sibling parent reply "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.
Mar 15 2015
parent 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
Mar 18 2015
prev sibling next sibling parent "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.
Mar 15 2015
prev sibling parent reply "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 specific tasks), C++, C#, Pascal, Java, Perl, Ruby, Lua and D 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
Mar 16 2015
next sibling parent "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
Mar 16 2015
prev sibling next sibling parent reply 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.
Mar 16 2015
next sibling parent 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.
Mar 16 2015
prev sibling parent reply "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).
Mar 16 2015
parent reply 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.
Mar 16 2015
parent "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 :)
Mar 16 2015
prev sibling parent "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 specific tasks), C++, C#, Pascal, Java, Perl, Ruby, Lua and D 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.
Mar 16 2015
prev sibling parent 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 incorporating its use into their Python/C#/C++ workflows.
 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
Mar 17 2015
prev sibling parent 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
Mar 14 2015
prev sibling next sibling parent reply 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
Mar 13 2015
next sibling parent "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
Mar 13 2015
prev sibling parent reply 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
Mar 14 2015
next sibling parent "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
Mar 14 2015
prev sibling next sibling parent reply "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.
Mar 14 2015
parent reply "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 
battle now is between C/C++/C#/Objective C/Java. 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.
Mar 14 2015
next sibling parent reply "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 
 limited. The battle now is between C/C++/C#/Objective C/Java. 
 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.
Followed by renaming it to D#?
Mar 14 2015
parent reply "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.
Followed by renaming it to D#?
So having built-in Windows/OSX/Andoroid/iOS support, nice documentation, real world functionality and a GUI system makes D some kind of C#? Did I understand it correctly, or it's just a pun?
Mar 14 2015
parent reply "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
Mar 14 2015
parent "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
Mar 14 2015
prev sibling next sibling parent "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.
Mar 14 2015
prev sibling next sibling parent "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 
 limited. The battle now is between C/C++/C#/Objective C/Java. 
 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
Mar 14 2015
prev sibling next sibling parent 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/
Mar 14 2015
prev sibling parent "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.
Mar 14 2015
prev sibling parent 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
Mar 14 2015
prev sibling parent "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.
Mar 13 2015
prev sibling parent 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.
Mar 13 2015
prev sibling next sibling parent 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
Mar 13 2015
prev sibling next sibling parent reply 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.)
Mar 13 2015
parent 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
Mar 13 2015
prev sibling parent "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.
Mar 14 2015
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/12/15 8:20 PM, Andrei Alexandrescu wrote:

 ## new house in unpopulated neighborhood; there's an "Enter, it's open"
 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
Mar 13 2015
prev sibling next sibling parent reply "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
Mar 13 2015
next sibling parent "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
Mar 13 2015
prev sibling next sibling parent "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.
Mar 13 2015
prev sibling next sibling parent "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.
Mar 13 2015
prev sibling next sibling parent reply "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.
Mar 13 2015
parent "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.
Mar 13 2015
prev sibling parent 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.
Mar 13 2015
prev sibling next sibling parent "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
Mar 13 2015
prev sibling next sibling parent reply "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...
Mar 13 2015
parent "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
Mar 13 2015
prev sibling next sibling parent reply 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!

 # big language
 # IDE?
 # small subset?
 # libraries?
 # will it be around?
 # Perception matters
 ## how stable is it?
 ## not great for servers or UIs; what then?
 ## new house in unpopulated neighborhood; there's an "Enter, it's open"
 sign but sits emtpy; by comparison Go -> condo in hip, trendy area

 * Ideas for D

 # what C++ should be but cannot
 ## too late for C++, but not for D
 ## some or all of  safe, immutable, pure should be the default
 # libraries, projects should be prominently listed and nurtured
 # single-idea advantage; D seems to embody too many ideas at once
 ## concurrency?
 ## networking?
 ## generics?
 ## interoperability with C and C++?
 ## focus on one!
 # must attract/hook casual users
 # unclear what's a good IDE - JetBrains? is there Vim support?
 # what's D's equivalent to frameworks such as react.js?
 # language designers think of features, users think of purpose
 ## react, go, rust, java -> purpose
 ## D, C++ -> "Ivy league candidates" having a response for 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
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.
Mar 14 2015
parent reply 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.
Mar 16 2015
next sibling parent reply 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
Mar 16 2015
parent 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.
Mar 17 2015
prev sibling parent reply "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»
Mar 17 2015
parent 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.
Mar 17 2015
prev sibling next sibling parent reply "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.
Mar 17 2015
parent reply "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.
Mar 17 2015
next sibling parent reply "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.
Mar 17 2015
parent reply "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.
Mar 17 2015
parent reply "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.
Mar 18 2015
next sibling parent reply "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.
Mar 18 2015
parent "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.
Mar 18 2015
prev sibling parent reply "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.
Mar 18 2015
parent reply "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.
Mar 19 2015
parent "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
Mar 24 2015
prev sibling parent reply "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.
Mar 17 2015
next sibling parent reply "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?
Mar 17 2015
parent "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.
Mar 17 2015
prev sibling next sibling parent "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); }
Mar 18 2015
prev sibling parent "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
Mar 19 2015
prev sibling parent reply "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.
Mar 17 2015
parent "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); }
Mar 18 2015