www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Gary Willoughby: "Why Go's design is a disservice to intelligent

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/

Andrei
Mar 25 2015
next sibling parent reply Mathias Lang via Digitalmars-d-announce writes:
I just wish D examples didn't include string lambdas.

2015-03-25 22:00 GMT+01:00 Andrei Alexandrescu via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com>:

 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_
 disservice_to_intelligent/

 Andrei
Mar 25 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/25/15 2:55 PM, Mathias Lang via Digitalmars-d-announce wrote:
 I just wish D examples didn't include string lambdas.
There was an initiative to just change them everywhere, seems to have petered out. "Just do it." -- Andrei
Mar 25 2015
prev sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Wednesday, 25 March 2015 at 21:55:53 UTC, Mathias Lang wrote:
 I just wish D examples didn't include string lambdas.
+100
Mar 26 2015
parent reply "Gary Willoughby" <dev nomad.so> writes:
I wrote the article in a rush last night (girlfriend calling me 
to bed) and as a result it has a few spelling/grammar errors 
which I've hopefully corrected.

The article is a total rant about Go after using it over the last 
month or so for a project. I honestly was getting so bored with 
Go and the article that I was literally falling asleep writing 
it. lol! Is started liking Go but after a while I found it 
increasing difficult trying to change me way of working to 
shoehorn solutions into such a simple language.

I know it's a bit unfair in places and it's got a click bait 
title but who cares? I got my point across and I think people 
understand where i'm coming from. It seems to have got really 
popular and I've been swamped with mail, etc. I think it's the 
most read article i've ever written. ha! :o)
Mar 26 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/26/2015 04:44 AM, Gary Willoughby wrote:
 I wrote the article in a rush last night (girlfriend calling me to bed)
 and as a result it has a few spelling/grammar errors which I've
 hopefully corrected.

 The article is a total rant about Go after using it over the last month
 or so for a project. I honestly was getting so bored with Go and the
 article that I was literally falling asleep writing it. lol! Is started
 liking Go but after a while I found it increasing difficult trying to
 change me way of working to shoehorn solutions into such a simple language.

 I know it's a bit unfair in places and it's got a click bait title but
 who cares? I got my point across and I think people understand where i'm
 coming from. It seems to have got really popular and I've been swamped
 with mail, etc. I think it's the most read article i've ever written.
 ha! :o)
It's funny how the posts that people love to hate are the biggest successes. On my site, I've made probably about about a hundred or so posts, but by FAR the most popular one based on hits and number of comments (in fact one of the very few that ever gets any hits/comments *at all*), was the one where I just bitched and ranted and swore and vented all about dynamic languages and especially Python. Heck, I got as much appreciative comments as I did disapproving ones. And more still roll in now and then. I really need to put up an ad there ;) But it really is true, controversy sells. Of course I'm not saying that makes trolling "good" (although I'm absolutely *amazed* that so many on reddit actually see your article as trolling - it obviously isn't, they clearly didn't even read it. Some of them even think *you're* the one who's calling many programmers "lesser" rather than Rob Pike), but it's amazing how much dissonance there is between what people think they hate to read and what they reward with their time and energy and comments. Oh, also, I wanted to point out one other thing. On a modern net where sites that look like this are common: http://thedailywtf.com/articles/are-you-down-with-php- http://thedailywtf.com/series/code-sod The visual style on your site is refreshingly easy to look at and read.
Mar 26 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 26 Mar 2015 13:17:47 -0400, Nick Sabalausky wrote:

 Of course I'm not saying that makes trolling "good" (although I'm
 absolutely *amazed* that so many on reddit actually see your article as
 trolling - it obviously isn't, they clearly didn't even read it. Some of
 them even think *you're* the one who's calling many programmers "lesser"
 rather than Rob Pike)
that's why i never read comments. especially comments on sites like HN or=20 reddit.=
Mar 26 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/26/2015 06:36 PM, ketmar wrote:
 On Thu, 26 Mar 2015 13:17:47 -0400, Nick Sabalausky wrote:

 Of course I'm not saying that makes trolling "good" (although I'm
 absolutely *amazed* that so many on reddit actually see your article as
 trolling - it obviously isn't, they clearly didn't even read it. Some of
 them even think *you're* the one who's calling many programmers "lesser"
 rather than Rob Pike)
that's why i never read comments. especially comments on sites like HN or reddit.
I always tell myself to avoid them, but I usually can't help browsing at least a few anyway :) I see reddit more as a topic-driven discussion board though, rather than a comment section, but I'll grant it's a rather blurry line. YouTube comments are notorious for being the real bad ones though. Those ones are easy enough to avoid reading!
Mar 26 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2015 1:44 AM, Gary Willoughby wrote:
 I know it's a bit unfair in places and it's got a click bait title but who
 cares? I got my point across and I think people understand where i'm coming
 from. It seems to have got really popular and I've been swamped with mail, etc.
 I think it's the most read article i've ever written. ha! :o)
You've managed to get 376 points and 663 comments, which is probably a record for any Reddit D related article! For better or worse, you've clearly struck a nerve.
Mar 26 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Thu, 2015-03-26 at 12:33 -0700, Walter Bright via Digitalmars-d-announce=
 wrote:
 On 3/26/2015 1:44 AM, Gary Willoughby wrote:
 I know it's a bit unfair in places and it's got a click bait title=20
 but who
 cares? I got my point across and I think people understand where=20
 i'm coming
 from. It seems to have got really popular and I've been swamped=20
 with mail, etc.
 I think it's the most read article i've ever written. ha! :o)
=20 You've managed to get 376 points and 663 comments, which is probably=20 a record=20 for any Reddit D related article! =20 For better or worse, you've clearly struck a nerve.
Welcome to the world of guerilla marketing. (Almost) All publicity is good publicity. --=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 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2015 12:40 PM, Russel Winder via Digitalmars-d-announce wrote:
 (Almost) All publicity is good publicity.
I attended a presentation at NWCPP on Go last week. I have never written a Go program, so filter my opinion on that. It seems to me that every significant but one feature of Go has a pretty much direct analog in D, i.e. you can write "Go" code in D much like you can write "C" code in D. The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it.
Mar 26 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote:
 On 3/26/2015 12:40 PM, Russel Winder via Digitalmars-d-announce 
 wrote:
 (Almost) All publicity is good publicity.
I attended a presentation at NWCPP on Go last week. I have never written a Go program, so filter my opinion on that. It seems to me that every significant but one feature of Go has a pretty much direct analog in D, i.e. you can write "Go" code in D much like you can write "C" code in D. The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it.
vibe has (experimental?) green threads, doesn't it? I don't keep up with vibe, so I may be wrong.
Mar 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2015 7:06 PM, weaselcat wrote:
 vibe has (experimental?) green threads, doesn't it?
 I don't keep up with vibe, so I may be wrong.
I don't know, but if it does have good 'uns they should be moved into Phobos!
Mar 26 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 27 March 2015 at 04:24:52 UTC, Walter Bright wrote:
 On 3/26/2015 7:06 PM, weaselcat wrote:
 vibe has (experimental?) green threads, doesn't it?
 I don't keep up with vibe, so I may be wrong.
I don't know, but if it does have good 'uns they should be moved into Phobos!
It does, and it should. In fact, I'd consider it massive selling point for D if it were; "you want easy Go-like concurrency? D has that too". Right now, it's available easily for writing servers: just use vibe.d. But it'd be great if the concurrency was available without depending on the rest of the library. I see no difference between "go func" and "runTask()". "select" might be a different matter, though, I don't know. Atila
Mar 28 2015
parent Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-28 at 12:58 +0000, Atila Neves via Digitalmars-d-announce w=
rote:
=20
[=E2=80=A6]
 It does, and it should. In fact, I'd consider it massive selling=20
 point for D if it were; "you want easy Go-like concurrency? D has=20
 that too". Right now, it's available easily for writing servers:=20
 just use vibe.d. But it'd be great if the concurrency was=20
 available without depending on the rest of the library.
=20
 I see no difference between "go func" and "runTask()". "select"=20
 might be a different matter, though, I don't know.
I need to be convinced that the concurrency and parallelism model of=20 vibe.d is in fact equivalent to that of goroutines, currently I would=20 say they are very, very different. --=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 28 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote:
 The one difference was Go's support for green threads. There's 
 no technical reason why D can't have green threads, it's just 
 that nobody has written the library code to do it.
Go can move stacks and extend them. Go is closer to having a low latency GC. These are not small language issues for D.
Mar 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2015 11:40 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 Go can move stacks and extend them.
That has no value on 64 bit systems, and is not a language issue (it's an implementation issue).
 Go is closer to having a low latency GC.
I.e. it doesn't have one.
 These are not small language issues for D.
GC issues are library issues, not language issues.
Mar 26 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote:
 On 3/26/2015 11:40 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 Go can move stacks and extend them.
That has no value on 64 bit systems,
It has.
 and is not a language issue (it's an implementation issue).
It is if you cannot control references to the stack.
 Go is closer to having a low latency GC.
I.e. it doesn't have one.
Comes in Go 1.5. https://docs.google.com/document/d/1wmjrocXIWTr1JxU-3EQBI6BK6KgtiFArkG47XK73xIQ/preview?sle=true
 These are not small language issues for D.
GC issues are library issues, not language issues.
It is a language issue if you want it to perform well.
Mar 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 12:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote:
 On 3/26/2015 11:40 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 Go can move stacks and extend them.
That has no value on 64 bit systems,
It has.
The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. The MMU can map and remap that to physical memory on demand through the address translation tables. Moving stacks is a great solution for 1995 computers.
Mar 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote:
 The MMU makes it pointless. The virtual address space allows 
 for 4 billion goroutines with 4 billion bytes each of stack.
If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables
Mar 27 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 08:41:40 UTC, Ola Fosheim Grøstad 
wrote:
 tables? If you want to address more than 512GB you need to move 
 to 1MiB pages.
Actually, it is 2MiB. Also keep in mind that there is an advantage to having very small stacks (e.g. 1-2K) when you do simulations.
Mar 27 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 1:41 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote:
 The MMU makes it pointless. The virtual address space allows for 4 billion
 goroutines with 4 billion bytes each of stack.
If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables
So what? The point is there is PLENTY of virtual address space. You can "allocate" absurd amounts of address space for each goroutine, and still have plenty without physically moving anything.
Mar 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 09:44:27 UTC, Walter Bright wrote:
 On 3/27/2015 1:41 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote:
 The MMU makes it pointless. The virtual address space allows 
 for 4 billion
 goroutines with 4 billion bytes each of stack.
If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables
So what? The point is there is PLENTY of virtual address space. You can "allocate" absurd amounts of address space for each goroutine, and still have plenty without physically moving anything.
If you don't care about performance, bloated page tables and laying waste to memory: 1. Page tables are hierarchical, to save space nodes can point back to themselves. IFF the node is similar. Throwing shit all over the memory space makes this impossible. So you get BLOATed page tables. 2. All dirty pages maps to physical memory. So one recursion chain on a fiber will create a big physical mem allocation. To get rid of it you would have make a slow syscall. 3. You have no way to go below the page size for a stack. 4. Operating system calls like mmap are slow. 5. Trapped pages are slow and so are modifying page tables. 6. You cannot expect to get more than 47-53 bits of address space from the OS. It's not like 64 bits CPUs provide 64 bits address space. There is a big hole in the middle. Have you actually thought about these issues or done performance tests?
Mar 27 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-27 at 10:14 +0000, via Digitalmars-d-announce wrote:
[=E2=80=A6]
=20
 Have you actually thought about these issues or done performance=20
 tests?
The Go team certainly have, and have changed their goroutine model twice because of it. No matter what they do in Go 0.0 =E2=86=921.4, 1.5 onwards w= ill be different since the who system is being revised: Go implemented Go toolchain, new GC, new runtime. I suspect Go 1.6 will be the watershed for this, but that will likely be 2016. The question is though what should happen in D. If Vibe.d fibres are a single threaded system, then they are not suitable for the actor, dataflow, CSP implementation needed in D since that must sit on a kernel thread pool where each lightweight thread is animated by whichever work stealing kernel thread comes along. Erlang, Go, GPars, Quasar, etc. all have different solutions to the problem of thread pools and task switching since the context is all important. --=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 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 10:37:01 UTC, Russel Winder wrote:
 The question is though what should happen in D. If Vibe.d 
 fibres are a
 single threaded system, then they are not suitable for the 
 actor,
 dataflow, CSP implementation needed in D since that must sit on 
 a kernel
 thread pool where each lightweight thread is animated by 
 whichever work
 stealing kernel thread comes along. Erlang, Go, GPars, Quasar, 
 etc. all
 have different solutions to the problem of thread pools and task
 switching since the context is all important.
Yes, I agree that the question is what should happen in D. But the claim was that D provides everything Go does and there is only a tiny scheduler that is missing. I don't think D benefits from these claims. Benchmark D thoroughly against Go before making claims or just give Go credit for being better in some areas. If it was up to me then co-routines would be ripped out of the language. They are a cross cutting feature that makes significant optimizations and improvements difficult or impossible.
Mar 27 2015
parent "w0rp" <devw0rp gmail.com> writes:
I don't think it's such a good idea to dump on another language 
too much. My reaction to Go is that it doesn't have what I want 
in it, and that's about it. People can write Go if they want to, 
and I won't.

I think I'd prefer to just present a good tool. If it's good 
enough for a particular job people will use it.
Mar 27 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Thu, 2015-03-26 at 18:47 -0700, Walter Bright via
Digitalmars-d-announce wrote:
 On 3/26/2015 12:40 PM, Russel Winder via Digitalmars-d-announce wrote:
 (Almost) All publicity is good publicity.
=20 =20 I attended a presentation at NWCPP on Go last week. I have never written =
a Go=20
 program, so filter my opinion on that.
=20
 It seems to me that every significant but one feature of Go has a pretty =
much=20
 direct analog in D, i.e. you can write "Go" code in D much like you can w=
rite=20
 "C" code in D.
That is almost certainly true. I suspect you can write Go in C++ as well. D and C++ are definitely supersets of Go.
 The one difference was Go's support for green threads. There's no technic=
al=20
 reason why D can't have green threads, it's just that nobody has written =
the=20
 library code to do it.
I think the way go handles interfaces and their composition would require a few tricks in D and C++, but I am sure it can be done. Aren't "green threads" now given the label fibres? And I think Vibe.d has an implementation for these =E2=80=93 but I do not know for certain. The dataflow way of working and the special case CSP, also actors are clearly the right abstraction for most parallel computation, using as we all agree, a kernel thread pool animating tasks. std.parallelism has something along these lines but focussed on data parallelism. Given the existence of C++CSP2 (http://www.cs.kent.ac.uk/projects/ofa/c ++csp/) D can get a CSP implementation for free, especially if the recent innovation on C++ working come to fruition. As work on GPars and Quasar in the JVM arena, and Erlang and Go since they were created, show, lightweight processes with communication channels is the next step in providing good abstractions for CPU and IO bound processing. Anthony Williams (Just Software, https://www.justsoftwaresolutions.co.uk/)) has been at work trying to put actors and dataflow on top of C++11 threads, with some success. D needs to corral all the bits, which I think are there, to create a good offering. However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. =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 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote:
 I think the way go handles interfaces and their composition would
 require a few tricks in D and C++, but I am sure it can be done.
Interfaces can be done with D templates. It'll be compile time polymorphism rather than run time, but the same effect will result (and of course it'll be faster). It's pretty much how Ranges work in D.
 Aren't "green threads" now given the label fibres?
My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another.
 And I think Vibe.d
 has an implementation for these – but I do not know for certain.
I don't know, either.
 D needs to corral all the bits, which I think are there, to create a
 good offering.
Yes.
 However, I cannot see this happening purely on volunteer,
 hobbyist resource. We need to find an organization or three willing to
 resource this activity.
I don't think it's that hard of a problem.
Mar 27 2015
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-27 at 03:11 -0700, Walter Bright via
Digitalmars-d-announce wrote:
 On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote:
[=E2=80=A6]
 However, I cannot see this happening purely on volunteer,
 hobbyist resource. We need to find an organization or three willing to
 resource this activity.
=20 I don't think it's that hard of a problem.
If no-one is resourced to write the code, it will not get written. --=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 27 2015
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.03.2015 um 11:11 schrieb Walter Bright:
 On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote:
 Aren't "green threads" now given the label fibres?
My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another.
 And I think Vibe.d
 has an implementation for these – but I do not know for certain.
I don't know, either.
It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).
Mar 27 2015
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
 Am 27.03.2015 um 11:11 schrieb Walter Bright:
 On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce 
 wrote:
 Aren't "green threads" now given the label fibres?
My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another.
 And I think Vibe.d
 has an implementation for these – but I do not know for 
 certain.
I don't know, either.
It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).
I've always wondered whether thread-local fibers with a stop-the-world (or at least part of the world) load balancer that can move them would be a good model. You could get away without a lot of synchronisation e.g. tls could be fixed-up from the scheduler thread while all the others are stopped. Perhaps there are good reasons why not, I don't know enough to say...
Mar 27 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
 distribution across the cores, but in most scenarios the number 
 of concurrent tasks should be high enough to keep all cores 
 busy anyhow. There are also additional costs for moving fibers 
 (synchronization, cache misses).
It is a complete disaster to not move fibers between threads if you want good latency.
Mar 27 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 March 2015 at 14:18:33 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
 distribution across the cores, but in most scenarios the 
 number of concurrent tasks should be high enough to keep all 
 cores busy anyhow. There are also additional costs for moving 
 fibers (synchronization, cache misses).
It is a complete disaster to not move fibers between threads if you want good latency.
Only if execution time between fibers is very unevenly distributed and/or their amount is low.
Mar 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 14:47:08 UTC, Dicebot wrote:
 On Friday, 27 March 2015 at 14:18:33 UTC, Ola Fosheim Grøstad 
 wrote:
 On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
 distribution across the cores, but in most scenarios the 
 number of concurrent tasks should be high enough to keep all 
 cores busy anyhow. There are also additional costs for moving 
 fibers (synchronization, cache misses).
It is a complete disaster to not move fibers between threads if you want good latency.
Only if execution time between fibers is very unevenly distributed and/or their amount is low.
No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free.
Mar 27 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad 
wrote:
 No... E.g.:

 On the same thread:
 1. fiber A receives request and queries DB (async)
 2. fiber B computes for 1 second
 3. fiber A sends response.

 Latency: 1 second even if all the other threads are free.
This is a problem of having blocking 1 second computation in same fiber pool as request handlers -> broken application design. Hiding that issue by moving fibers between threads is just making things worse.
Mar 27 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 16:06:55 UTC, Dicebot wrote:
 On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad 
 wrote:
 No... E.g.:

 On the same thread:
 1. fiber A receives request and queries DB (async)
 2. fiber B computes for 1 second
 3. fiber A sends response.

 Latency: 1 second even if all the other threads are free.
This is a problem of having blocking 1 second computation in same fiber pool as request handlers -> broken application design. Hiding that issue by moving fibers between threads is just making things worse.
Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? You can create more complicated setups where multiple 200ms computations cause the same latency when the CPU is 90% idle. This is simply not good enough, if fibers carry this cost then it is better to just use an event driven design.
Mar 27 2015
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.03.2015 um 17:11 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>":
 On Friday, 27 March 2015 at 16:06:55 UTC, Dicebot wrote:
 On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote:
 No... E.g.:

 On the same thread:
 1. fiber A receives request and queries DB (async)
 2. fiber B computes for 1 second
 3. fiber A sends response.

 Latency: 1 second even if all the other threads are free.
This is a problem of having blocking 1 second computation in same fiber pool as request handlers -> broken application design. Hiding that issue by moving fibers between threads is just making things worse.
Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform? You can create more complicated setups where multiple 200ms computations cause the same latency when the CPU is 90% idle. This is simply not good enough, if fibers carry this cost then it is better to just use an event driven design.
So what happens if 10 requests come in at the same time? Does moving things around still help you? No. BTW, why would an event driven design be any better? You'd have exactly the same issue.
Mar 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 16:18:33 UTC, Sönke Ludwig wrote:
 So what happens if 10 requests come in at the same time? Does 
 moving things around still help you? No.
Load balancing is probabilistic in nature. Caching also makes it unlikely that you get 10 successive high computation requests.
 BTW, why would an event driven design be any better? You'd have 
 exactly the same issue.
1. No stack. 2. Batching. But it is more tedious.
Mar 27 2015
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.03.2015 um 17:31 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>":
 On Friday, 27 March 2015 at 16:18:33 UTC, Sönke Ludwig wrote:
 So what happens if 10 requests come in at the same time? Does moving
 things around still help you? No.
Load balancing is probabilistic in nature. Caching also makes it unlikely that you get 10 successive high computation requests.
You could say the same for the non-moving case. If you have a fully loaded node and mix request handling and lengthy computations like this, you'll run into this no matter what. The simple solution is to just either separate lengthy computations (easy) or to split them up into shorter parts using yield() (usually easy, too). Caching *may* make it unlikely, but that completely depends on the application. If you have some kind of server-side image processing web service with many concurrent users, you'd have a lot of computation heavy requests with no opportunities for caching.
 BTW, why would an event driven design be any better? You'd have
 exactly the same issue.
1. No stack.
That reduces the memory footprint, but doesn't reduce latency.
 2. Batching.
Can you elaborate?
 But it is more tedious.
Mar 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 16:48:26 UTC, Sönke Ludwig wrote:
 1. No stack.
That reduces the memory footprint, but doesn't reduce latency.
It removes hard to spot dependencies on thread local storage.
 2. Batching.
Can you elaborate?
Using fibers you deal with a single unit. Using events you deal with a request broken down into "atomic parts". You take a group of events by timed priority and sort them by type. Then you process all events of type A, then all events of type B etc. Better cache locality, more fine grained control over scheduling, easier to migrate to other servers etc. But the fundamental problem with using fibers that are bound to a thread does not depend on long running requests. You get this also for multiple requests with normal workloads, it is rather obvious: time tick 0: Thread 1…N-1: 100 ms workloads Thread N: Fiber A: async request from memcache (1ms) Fiber B: async request from memcache (1ms) ... Fiber M: async request from memcache… time tick 101: Thread 1...N-1: free Thread N: Fiber A: compute load 100ms time tick 201: Fiber B: compute load 100ms etc. Also keep in mind that in a real world setting you deal with spikes, so the load balancer should fire up new instances a long time before your capacity is saturated. That means you need to balance loads over your threads if you want good average latency. Antyhing less makes fibers a toy language feature IMO.
Mar 28 2015
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.03.2015 um 10:17 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>":
 On Friday, 27 March 2015 at 16:48:26 UTC, Sönke Ludwig wrote:
 1. No stack.
That reduces the memory footprint, but doesn't reduce latency.
It removes hard to spot dependencies on thread local storage.
You can access TLS from an event callback just as easy as from a fiber.
 2. Batching.
Can you elaborate?
Using fibers you deal with a single unit. Using events you deal with a request broken down into "atomic parts". You take a group of events by timed priority and sort them by type. Then you process all events of type A, then all events of type B etc. Better cache locality, more fine grained control over scheduling, easier to migrate to other servers etc.
And why can't you do the same with fibers and schedule the fibers accordingly? There is no difference between the two models, except that fibers provide additional persistent state in the form of a stack.
 But the fundamental problem with using fibers that are bound to a thread
 does not depend on long running requests. You get this also for multiple
 requests with normal workloads, it is rather obvious:

  time tick 0:

 Thread 1…N-1:
 100 ms workloads

 Thread N:
 Fiber A: async request from memcache (1ms)
 Fiber B: async request from memcache (1ms)
 ...
 Fiber M: async request from memcache…

  time tick 101:

 Thread 1...N-1:
 free

 Thread N:
 Fiber A: compute load 100ms

  time tick 201:
 Fiber B: compute load 100ms

 etc.
It's you who brought up the randomization argument. Tasks are assigned to a more or less random thread that is currently in the scheduling phase, so that your constructed situation is simply *highly* unlikely.
 Also keep in mind that in a real world setting you deal with spikes, so
 the load balancer should fire up new instances a long time before your
 capacity is saturated. That means you need to balance loads over your
 threads if you want good average latency.
They *do* get balanced over threads, just like requests get balanced over instances by the load balancer, even if requests are not moved between instances. But IMO it doesn't make sense to go further with this argument with some actual benchmarks. It's not at all as clear as you'd like what the effects on overall performance and on average/~maximum latency are in practice for different applications.
 Antyhing less makes fibers a toy language feature IMO.
Mar 28 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 March 2015 at 11:52:34 UTC, Sönke Ludwig wrote:
 You can access TLS from an event callback just as easy as from 
 a fiber.
Yes, but it is much easier to verify that you don't hold onto references to TLS if get rid of arbitrary call stacks when moving to a new thread.
 And why can't you do the same with fibers and schedule the 
 fibers accordingly?
You could, but that's even more work since you then need to encode progress in a way the scheduler can use to estimate when the task can complete and when it must complete.
 It's you who brought up the randomization argument. Tasks are 
 assigned to a more or less random thread that is currently in 
 the scheduling phase, so that your constructed situation is 
 simply *highly* unlikely.
I don't understand how randomization can help you here.
 They *do* get balanced over threads, just like requests get 
 balanced over instances by the load balancer, even if requests
A good load balancer measure back-pressure (load information from the instance) and fire up new instances.
 are not moved between instances. But IMO it doesn't make sense 
 to go further with this argument with some actual benchmarks. 
 It's not at all as clear as you'd like what the effects on 
 overall performance and on average/~maximum latency are in 
 practice for different applications.
This is something you can do on paper. A language feature should support a wide set of applications.
Mar 28 2015
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.03.2015 um 13:32 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>":
 On Saturday, 28 March 2015 at 11:52:34 UTC, Sönke Ludwig wrote:
 You can access TLS from an event callback just as easy as from a fiber.
Yes, but it is much easier to verify that you don't hold onto references to TLS if get rid of arbitrary call stacks when moving to a new thread.
It's not mainly about holding references to TLS data, but about program correctness. You store something in a TLS variable and the next time you read it, there is something different in it. This is not only an issue for your own code, but also for external libraries that you have no control or even insight of. Apart from that, what is stopping you to hold such references implicitly in a callback closure?
 And why can't you do the same with fibers and schedule the fibers
 accordingly?
You could, but that's even more work since you then need to encode progress in a way the scheduler can use to estimate when the task can complete and when it must complete.
The fiber part is purely additive. Anything you can to to schedule events in an event based programming model, you can do in a fiber backed one, too. You just have the additional state of the fiber that gets carried around, nothing more.
 It's you who brought up the randomization argument. Tasks are assigned
 to a more or less random thread that is currently in the scheduling
 phase, so that your constructed situation is simply *highly* unlikely.
I don't understand how randomization can help you here.
Your constructed case will simply not happen in practice.
 They *do* get balanced over threads, just like requests get balanced
 over instances by the load balancer, even if requests
A good load balancer measure back-pressure (load information from the instance) and fire up new instances.
That depends a lot on your infrastructure, but is irrelevant to the point. Tasks get distributed among threads with a sufficiently large number of tasks (like it would happen for a busy web service), you'll have a high load on all threads, so it simply doesn't matter if you move tasks between threads. If you have a low number of requests you may be able to avoid some bad corner cases, but only if you did something stupid in the first place, like mixing long CPU computations without any yield() calls with I/O processing tasks in the same thread (since you seem like a smart person I'll leave it up to you construct cases where moving between threads doesn't help either).
 are not moved between instances. But IMO it doesn't make sense to go
 further with this argument with some actual benchmarks. It's not at
 all as clear as you'd like what the effects on overall performance and
 on average/~maximum latency are in practice for different applications.
This is something you can do on paper. A language feature should support a wide set of applications.
*I* can't do that on paper. I invite you to do it and then we can verify your claims with actual measurements. If you don't, this is nothing more than hot air.
Mar 28 2015
prev sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-28 at 12:52 +0100, S=C3=B6nke Ludwig via Digitalmars-d-anno=
unce wrote:
 [=E2=80=A6]
=20
 You can access TLS from an event callback just as easy as from a=20
 fiber.
[=E2=80=A6] TLS is the evil here. Anyone working with TLS is either writing an=20 operating system or doing it wrong. --=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 28 2015
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.03.2015 um 15:33 schrieb Russel Winder via Digitalmars-d-announce:
 On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via Digitalmars-d-announce
wrote:
 […]

 You can access TLS from an event callback just as easy as from a
 fiber.
[…] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong.
As long as we are talking about a closed system that works exclusively on this fiber based concurrency model, I completely agree with you (fiber local storage would be fine, though). But we have the "unfortunate" situation that the language is not an isolated ecosystem. There are many C libraries that do thread-specific things in one way or another, or worse, make use of ordinary global variables without any protection against data races, and we simply cannot ignore that.
Mar 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2015 8:41 AM, Sönke Ludwig wrote:
 Am 28.03.2015 um 15:33 schrieb Russel Winder via Digitalmars-d-announce:
 TLS is the evil here. Anyone working with TLS is either writing an
 operating system or doing it wrong.
As long as we are talking about a closed system that works exclusively on this fiber based concurrency model, I completely agree with you (fiber local storage would be fine, though). But we have the "unfortunate" situation that the language is not an isolated ecosystem. There are many C libraries that do thread-specific things in one way or another, or worse, make use of ordinary global variables without any protection against data races, and we simply cannot ignore that.
One solution (that seems entirely reasonable to me) is to make the droutines (i.e. "goroutines") pure. Then the TLS problem goes away. Of course, then I/O isn't possible either, but perhaps a solution can be found for that.
Mar 28 2015
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.03.2015 um 19:51 schrieb Walter Bright:
 On 3/28/2015 8:41 AM, Sönke Ludwig wrote:
 Am 28.03.2015 um 15:33 schrieb Russel Winder via Digitalmars-d-announce:
 TLS is the evil here. Anyone working with TLS is either writing an
 operating system or doing it wrong.
As long as we are talking about a closed system that works exclusively on this fiber based concurrency model, I completely agree with you (fiber local storage would be fine, though). But we have the "unfortunate" situation that the language is not an isolated ecosystem. There are many C libraries that do thread-specific things in one way or another, or worse, make use of ordinary global variables without any protection against data races, and we simply cannot ignore that.
One solution (that seems entirely reasonable to me) is to make the droutines (i.e. "goroutines") pure. Then the TLS problem goes away. Of course, then I/O isn't possible either, but perhaps a solution can be found for that.
I/O is crucial of course, but there are also a lot of other important and inherently impure things such as message passing. I think such a restriction would go way too far. Both fiber and task local storage can also be very useful at times, so it would be a pity to rule them out completely. You'd also usually have the whole application running on "droutines" and not simply use them as a local tool for occasional parallelism needs. This is especially true for any kind of server application. So effectively such a limitation may in practice end up as a limitation of the entire language.
Mar 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2015 1:32 PM, Sönke Ludwig wrote:
 I/O is crucial of course, but there are also a lot of other important and
 inherently impure things such as message passing.
If the message channel is passed as a parameter to the droutine, then the droutine can still be pure.
 I think such a restriction
 would go way too far. Both fiber and task local storage can also be very useful
 at times, so it would be a pity to rule them out completely.

 You'd also usually have the whole application running on "droutines" and not
 simply use them as a local tool for occasional parallelism needs. This is
 especially true for any kind of server application. So effectively such a
 limitation may in practice end up as a limitation of the entire language.
On the other hand, if purity can make droutines much more practical, the tradeoff might be worth it.
Mar 28 2015
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.03.2015 um 21:51 schrieb Walter Bright:
 On 3/28/2015 1:32 PM, Sönke Ludwig wrote:
 I/O is crucial of course, but there are also a lot of other important and
 inherently impure things such as message passing.
If the message channel is passed as a parameter to the droutine, then the droutine can still be pure.
Only if the methods of the channel are also pure. But they potentially have to interact with the system event loop, which involves impure system API calls.
 I think such a restriction
 would go way too far. Both fiber and task local storage can also be
 very useful
 at times, so it would be a pity to rule them out completely.

 You'd also usually have the whole application running on "droutines"
 and not
 simply use them as a local tool for occasional parallelism needs. This is
 especially true for any kind of server application. So effectively such a
 limitation may in practice end up as a limitation of the entire language.
On the other hand, if purity can make droutines much more practical, the tradeoff might be worth it.
If you ask me, they are very practical as they are - in fact much more practical than if they could move between threads, not just because of purity or not. I'm for example heavily using vibe.d's tasks for all kinds of UI, 3D graphics, sound and physics related things. All of these require calling various C libraries that are not be compatible with such a scheme. We could of course add an optional pure+moving mode for those that absolutely need it, but IMHO we should first have hard evidence for practical performance improvements before going such a route.
Mar 28 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2015 3:24 PM, Sönke Ludwig wrote:
 If you ask me, they are very practical as they are - in fact much more
practical
 than if they could move between threads, not just because of purity or not. I'm
 for example heavily using vibe.d's tasks for all kinds of UI, 3D graphics,
sound
 and physics related things. All of these require calling various C libraries
 that are not be compatible with such a scheme.

 We could of course add an optional pure+moving mode for those that absolutely
 need it, but IMHO we should first have hard evidence for practical performance
 improvements before going such a route.
Sounds very sensible. When can we get it into Phobos? :-)
Mar 28 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 March 2015 at 14:33:14 UTC, Russel Winder wrote:
 On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via 
 Digitalmars-d-announce wrote:
 […]
 
 You can access TLS from an event callback just as easy as from 
 a fiber.
[…] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong.
I don't think it is that simple. From the purist academical parallelism POV - most likely. In practice it often can be quite the contrary, TLS is your best friend (depending on how efficient platfrom implementation is). To get best high-load performance best strategy is to actually design applications with specific hardware traits in mind, including pre-defined amount of CPU cores and their task affinity. Computation parallelism is relatively easy, it is memory parallelism that remains a challenging task as long as you try to get rid of locking overhead, costly synchronizations and optimize cache loads. Something like moving fibers between threads is absolute disaster in this sense even if it looks like a tempting abstraction on paper. But if you prohibit that by design and maintain strict affinity between fibers and threads, using TLS allows for very nice optimizations (as it is effectively limited sharing without locking / atomics). It can be complicated to design (which is why Go choice makes sense for their target audience) but benefits are also very good.
Mar 28 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-28 at 18:55 +0000, Dicebot via Digitalmars-d-announce wrote=
:
=20
[=E2=80=A6]
 I don't think it is that simple. From the purist academical=20
 parallelism POV - most likely. In practice it often can be quite=20
 the contrary, TLS is your best friend (depending on how efficient=20
 platfrom implementation is).
I suggest it really is that simple even for non-academic applications=E2=80= =A6
 To get best high-load performance best strategy is to actually=20
 design applications with specific hardware traits in mind,=20
 including pre-defined amount of CPU cores and their task=20
 affinity. Computation parallelism is relatively easy, it is=20
 memory parallelism that remains a challenging task as long as you=20
 try to get rid of locking overhead, costly synchronizations and=20
 optimize cache loads. Something like moving fibers between=20
 threads is absolute disaster in this sense even if it looks like=20
 a tempting abstraction on paper. But if you prohibit that by=20
 design and maintain strict affinity between fibers and threads,=20
 using TLS allows for very nice optimizations (as it is=20
 effectively limited sharing without locking / atomics). It can be=20
 complicated to design (which is why Go choice makes sense for=20
 their target audience) but benefits are also very good.
If you write your software to fit a particular platform, including=20 hardware features, then you are writing an operating system dedicated=20 to that one specific platform and no other. If the idea is to write=20 portable applications then: a. you must abstract away from a specific platform; b. you must accept some overhead. The very fact that people are writing in D (or C++, Java, C#,=E2=80=A6) mea= ns=20 you have accepted some abstraction =E2=80=93 otherwise you would be writing= in=20 assembly language. Having made the jump to high-level languages why=20 baulk at a small overhead to abstract concurrency and parallelism?=20 Making tasks lightweight processes rather than maintaining shared=20 memory, and using channels to move data around rather than using=20 shared memory and locks, makes applications' concurrency and=20 parallelism easier to construct and manage (*). If we are prepared to=20 accept overhead for stack and heap management, we must accept the=20 overhead of processor management via thread pooling with work stealing. (*) Andrei, this is something of a claim really just now, since=20 although there is anecdotal evidence, I haven't managed to get the=20 psychology of programming people to do statistically significant=20 experiments. I will be trying again at PPIG 2015 to motivate the=20 experiments. --=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 28 2015
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 March 2015 at 19:16:32 UTC, Russel Winder wrote:
 If you write your software to fit a particular platform, 
 including
 hardware features, then you are writing an operating system 
 dedicated
 to that one specific platform and no other.
Yes and I believe writing dedicated specialized operating systems for certain network services ("OS as a library") is the future of high load server programming - at least in domains where you can afford the investment.
 If the idea is to write
 portable applications then:
"portable" and "fast network service" aren't really best friends :( I have to encounter a single project that even tries to achieve portability of server code..
 The very fact that people are writing in D (or C++, Java, C#,…) 
 means
 you have accepted some abstraction – otherwise you would be 
 writing in
 assembly language. Having made the jump to high-level languages 
 why
 baulk at a small overhead to abstract concurrency and 
 parallelism?
1) "some abstractions" != "any abstractions". One of reasons to use D as opposed to Java or C# is exactly because latter force you into overly expensive abstractions. D in its current state is closer to C++ in this context and this is huge selling point. 2) So far my experience has shown that overhead is not small at all. It depends on type of application of course.
 Making tasks lightweight processes rather than maintaining 
 shared
 memory, and using channels to move data around rather than using
 shared memory and locks, makes applications' concurrency and
 parallelism easier to construct and manage (*).
This comment makes me wonder if we really speak about the same things. Concurrency model based on pinned fibers/threads is not the same thing as getting back to 90s shared memory multi-threading madness. "lightweight processes" - yes, pinned fibers are very lightweight "channels to move data around" - message passing between worker threads At no point I have proposed to use shared memory and locks, there is no objection here.
 If we are prepared to
 accept overhead for stack and heap management, we must accept 
 the
 overhead of processor management via thread pooling with work 
 stealing.
Custom allocators exist pretty much for the very reason that in certain cases heap management overhead cannot be accepted. For concurrency primitives stakes are much higher.
Mar 28 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 28 March 2015 at 14:33:14 UTC, Russel Winder wrote:
 On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via 
 Digitalmars-d-announce wrote:
 […]
 
 You can access TLS from an event callback just as easy as from 
 a fiber.
[…] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong.
Or, you know, doing it safe. Unlike Go.
Mar 29 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 March 2015 at 16:11:42 UTC, Ola Fosheim Grøstad 
wrote:
 Not a broken design. If I have to run multiple servers just to 
 handle an image upload or generating a PDF then you are driving 
 up the cost of the project and developers would be better off 
 with a different platform?

 You can create more complicated setups where multiple 200ms 
 computations cause the same latency when the CPU is 90% idle. 
 This is simply not good enough, if fibers carry this cost then 
 it is better to just use an event driven design.
I have no interest in arguing with you, just calling out especially harmful lies that may mislead random readers.
Mar 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 16:27:48 UTC, Dicebot wrote:
 I have no interest in arguing with you, just calling out 
 especially harmful lies that may mislead random readers.
Nice one. I am sure your attitude is very helpful for D.
Mar 27 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 27 March 2015 at 16:40:14 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 27 March 2015 at 16:27:48 UTC, Dicebot wrote:
 I have no interest in arguing with you, just calling out 
 especially harmful lies that may mislead random readers.
Nice one. I am sure your attitude is very helpful for D.
Actually, it really is. He does a lot of useful work that has helped improve many parts of D and it's ecosystem. Mostly I see you sniping from the sidelines with in-actionable comments; not because you're necessarily wrong, but because despite what appears to be a significant body of knowledge, your arguments lack detail and are often supported by a bunch of academic knowledge that - at best - you refer to in overly general terms. Sorry if that sounds harsh, but it's frustrating seeing you throw knowledge at topics without making any of it stick.
Mar 27 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 Not a broken design. If I have to run multiple servers just to handle an
 image upload or generating a PDF then you are driving up the cost of the
 project and developers would be better off with a different platform?
but it is broken! the whole point of async i/o servers is that such=20 servers spend most of their time waiting for i/o. and if you need to do=20 some lengthy calculations, you either spawns a "real thread" and commands=20 it to wake you up when it is finished, or asking external server to do=20 the job (and wake you when it is finished). what moving fibers from thread to thread does is bringing in state=20 copying (we want our threads fairly isolated, aren't we? so either=20 copying, or ownership management). the whole thing of cooperative multitasking is to be... cooperative. in=20 several years some Shiny New Async Framework will use "no transferring=20 fibers between worker threads" as Spectacular Invention.=
Mar 27 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
 On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim Grøstad wrote:

 Not a broken design. If I have to run multiple servers just to 
 handle an
 image upload or generating a PDF then you are driving up the 
 cost of the
 project and developers would be better off with a different 
 platform?
but it is broken! the whole point of async i/o servers is that such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a "real thread" and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished). what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management). the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use "no transferring fibers between worker threads" as Spectacular Invention.
as an outsider to the web-scale world, this entire thing seems like a half-baked fork reimplementation
Mar 27 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 27 Mar 2015 22:37:21 +0000, weaselcat wrote:

 On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
 On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim Gr=C3=83=C2=B8stad wrote=
:
 Not a broken design. If I have to run multiple servers just to handle
 an image upload or generating a PDF then you are driving up the cost
 of the project and developers would be better off with a different
 platform?
but it is broken! the whole point of async i/o servers is that such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a "real thread" and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished). what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management). the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use "no transferring fibers between worker threads" as Spectacular Invention.
=20 as an outsider to the web-scale world, this entire thing seems like a half-baked fork reimplementation
the whole "userspace threads" concept is a reimplementation of kernel=20 threads and sheduling. ;-) the main question is the amount of work required to switch between=20 threads. if we have a little amount of threads that does heavy work, it's=20 ok to use kernel mechanics: the time of context switching is neglible. but it we have alot of threads that mostly waits for i/o, then does very=20 little amount of work and waits for i/o again, context switching time=20 starts to show itself. so we moving the whole "treading" thing to user=20 application, thus minimising thread context switching time. all in all this is a half-baked kernel thread reimplementation, yes. but=20 it has it's own pros. and cons, of course: such as unresponsive user=20 thread can block the whole app, like in good old windows 3 times.=
Mar 27 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-27 at 22:48 +0000, ketmar via Digitalmars-d-announce wrote:
=20
[=E2=80=A6]
 the whole "userspace threads" concept is a reimplementation of=20
 kernel=20
 threads and sheduling. ;-)
=20
And kernel threads are a reimplementation of user space threads. --=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 28 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 28 Mar 2015 11:02:23 +0000, Russel Winder via
Digitalmars-d-announce wrote:

 On Fri, 2015-03-27 at 22:48 +0000, ketmar via Digitalmars-d-announce
 wrote:
=20
[=E2=80=A6]
 the whole "userspace threads" concept is a reimplementation of kernel
 threads and sheduling. ;-)
=20
=20
And kernel threads are a reimplementation of user space threads.
hm. yes, that was "coroutines on steroids".=
Mar 28 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-28 at 11:16 +0000, ketmar via Digitalmars-d-announce wrote:
 [=E2=80=A6]
=20
 hm. yes, that was "coroutines on steroids".
But that's the point isn't it: 1. Processes are too heavyweight, invent threads. 2. We have masses of cores, let's map threads to cores via the kernel. 3. Processes and threads are too heavyweight, invent lightweight=20 threads (aka fibres, sort of). It could be argued that it is all just co-routines underneath, but I=20 think that would be missing the point that we have 55 years more=20 experience of doing these things since that single processor operating=20 system model was created. We really should be doing this all a lot=20 better these days. --=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 28 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 28 Mar 2015 14:28:00 +0000, Russel Winder via
Digitalmars-d-announce wrote:

 It could be argued that it is all just co-routines underneath, but I
 think that would be missing the point that we have 55 years more
 experience of doing these things since that single processor operating
 system model was created. We really should be doing this all a lot
 better these days.
yet current CPUs are still the same as 50 years before, that is the=20 problem. ;-)=
Mar 28 2015
next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-28 at 17:57 +0000, ketmar via Digitalmars-d-announce wrote:
 On Sat, 28 Mar 2015 14:28:00 +0000, Russel Winder via
 Digitalmars-d-announce wrote:
=20
 It could be argued that it is all just co-routines underneath, but=20
 I
 think that would be missing the point that we have 55 years more
 experience of doing these things since that single processor=20
 operating
 system model was created. We really should be doing this all a lot
 better these days.
=20 yet current CPUs are still the same as 50 years before, that is the=20 problem. ;-)
I'd suggest that a Intel x86_64 of 2015 bears only a passing=20 relationship to an IBM 360 of the 1960s. It is true that hardware design has been constrained by a weird=20 constraint that no-one has investigated alternative architectures to=20 the register/CPU that software people insist is the only way forward. With all the transistors available per mm=C2=B2 these days, it is about=20 time we investigated alternate, implicitly parallel ways of working.=20 Intel had a go a few years ago with various alternative dataflow based=20 architectures, but they were told by the software people that they had=20 no future because software inertia was more important than innovation. =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 28 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 28 March 2015 at 18:39:47 UTC, Russel Winder wrote:
 On Sat, 2015-03-28 at 17:57 +0000, ketmar via 
 Digitalmars-d-announce wrote:
 On Sat, 28 Mar 2015 14:28:00 +0000, Russel Winder via
 Digitalmars-d-announce wrote:
 
 It could be argued that it is all just co-routines 
 underneath, but I
 think that would be missing the point that we have 55 years 
 more
 experience of doing these things since that single processor 
 operating
 system model was created. We really should be doing this all 
 a lot
 better these days.
yet current CPUs are still the same as 50 years before, that is the problem. ;-)
I'd suggest that a Intel x86_64 of 2015 bears only a passing relationship to an IBM 360 of the 1960s. It is true that hardware design has been constrained by a weird constraint that no-one has investigated alternative architectures to the register/CPU that software people insist is the only way forward. With all the transistors available per mm² these days, it is about time we investigated alternate, implicitly parallel ways of working. Intel had a go a few years ago with various alternative dataflow based architectures, but they were told by the software people that they had no future because software inertia was more important than innovation.
Thoughts on mill architecture?
Mar 28 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 28 Mar 2015 18:39:34 +0000, Russel Winder via
Digitalmars-d-announce wrote:

 yet current CPUs are still the same as 50 years before, that is the
 problem. ;-)
=20 I'd suggest that a Intel x86_64 of 2015 bears only a passing relationship to an IBM 360 of the 1960s.
but core principles are still there. it's implementation that is changed,=20 not high-level design.
 With all the transistors available per mm=C2=B2 these days, it is about t=
ime
 we investigated alternate, implicitly parallel ways of working.
 Intel had a go a few years ago with various alternative dataflow based
 architectures, but they were told by the software people that they had
 no future because software inertia was more important than innovation.
yes. "computers" are huge industry now, and industry resists to=20 innovations that requires industry players to change their processes. on the other side of the spectrum was Chuck Moore, for example, who=20 imagines modern computers filled with many cheap and average RISC=20 processors, and using parallel multiprocessor execution to achieve great=20 performance. and people with expirience on 8-bit Atari, NES or C64 knows by their=20 hearts that having specialized processors can greatly help (and it's a=20 great PITA too ;-).=
Mar 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2015 5:34 PM, ketmar wrote:
 on the other side of the spectrum was Chuck Moore, for example, who
 imagines modern computers filled with many cheap and average RISC
 processors, and using parallel multiprocessor execution to achieve great
 performance.
Isn't that what a GPU is?
Mar 29 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 29 March 2015 at 21:43:21 UTC, Walter Bright wrote:
 On 3/28/2015 5:34 PM, ketmar wrote:
 on the other side of the spectrum was Chuck Moore, for 
 example, who
 imagines modern computers filled with many cheap and average 
 RISC
 processors, and using parallel multiprocessor execution to 
 achieve great
 performance.
Isn't that what a GPU is?
This is exactly what a GPU is.
Mar 29 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 29 Mar 2015 14:43:14 -0700, Walter Bright wrote:

 On 3/28/2015 5:34 PM, ketmar wrote:
 on the other side of the spectrum was Chuck Moore, for example, who
 imagines modern computers filled with many cheap and average RISC
 processors, and using parallel multiprocessor execution to achieve
 great performance.
=20 Isn't that what a GPU is?
yes, GPU is a good example of that.=
Mar 29 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 28 March 2015 at 17:57:35 UTC, ketmar wrote:
 On Sat, 28 Mar 2015 14:28:00 +0000, Russel Winder via
 Digitalmars-d-announce wrote:

 It could be argued that it is all just co-routines underneath, 
 but I
 think that would be missing the point that we have 55 years 
 more
 experience of doing these things since that single processor 
 operating
 system model was created. We really should be doing this all a 
 lot
 better these days.
yet current CPUs are still the same as 50 years before, that is the problem. ;-)
heavily disagree
Mar 28 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 28 Mar 2015 18:41:04 +0000, weaselcat wrote:

 On Saturday, 28 March 2015 at 17:57:35 UTC, ketmar wrote:
 On Sat, 28 Mar 2015 14:28:00 +0000, Russel Winder via
 Digitalmars-d-announce wrote:

 It could be argued that it is all just co-routines underneath,
 but I think that would be missing the point that we have 55 years more
 experience of doing these things since that single processor operating
 system model was created. We really should be doing this all a lot
 better these days.
yet current CPUs are still the same as 50 years before, that is the problem. ;-)
=20 heavily disagree
it's still good old "me dumb computer bip bip" with all that low-level=20 register crap and so on. it doesn't matter how much advanced current=20 designs are in their cores, 'cause we -- as users -- see the same old bip- bip shit.=
Mar 28 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
 but it is broken! the whole point of async i/o servers is that 
 such
 servers spend most of their time waiting for i/o. and if you 
 need to do
 some lengthy calculations, you either spawns a "real thread" 
 and commands
 it to wake you up when it is finished, or asking external 
 server to do
 the job (and wake you when it is finished).
Nah. The point is to get parallel work done with less complexity, but at some performance cost. A design where you have to accurately predict running time per task in order to get decent latency is basically adding back the complexity in order to get a simplistic language/runtime with no benefits to the programmer. In essence, you should ideally be able to break a task into all it's independent parts and run them in parallel (i.e.. futures, events etc). Preferably batch them to get better performance, and sort them based on when they have to complete. Then have a mechanism that exerts back-pressure if deadlines are in danger, telling the load balancer to back off. How you go about it depends on the application, but that ought to be the ideal for anything that resembles a modern soft realtime platform.
 the whole thing of cooperative multitasking is to be... 
 cooperative.
Nah. Cooperative multitasking is a sorry excuse that belongs to the 80s. This should be as transparent as possible. You cannot insert "yield" into an external library.
Mar 28 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 March 2015 at 13:27:56 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
 but it is broken! the whole point of async i/o servers is that
Note: I presume that you meant servers and no OS-level async i/o (the limitations of unix select() is a different story).
Mar 28 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 28 Mar 2015 13:27:55 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 In essence, you should ideally be able to break a task into all it's
 independent parts and run them in parallel (i.e.. futures, events etc).
 Preferably batch them to get better performance, and sort them based on
 when they have to complete. Then have a mechanism that exerts
 back-pressure if deadlines are in danger, telling the load balancer to
 back off. How you go about it depends on the application, but that ought
 to be the ideal for anything that resembles a modern soft realtime
 platform.
then you have to switch to some functional language, preferably one that=20 does cps transformations in the compiler. as you told somewhere else, D=20 is too broad to be restricted to this.=
Mar 28 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 March 2015 at 13:52:54 UTC, ketmar wrote:
 then you have to switch to some functional language, preferably 
 one that
 does cps transformations in the compiler. as you told somewhere 
 else, D
 is too broad to be restricted to this.
Fibers is really not a system level thing. So I don't think D MUST have them as it is claimed that D is meant to be a system level language. I rate D against C/C++/Rust, but not Go per se. I see that Bearophile sometimes express that D should be be pitted with Java/C# rather than C/C++/Rust, but that does not fit for what is claimed for D… The bottom line is: if you decide to make fibers a language/runtime feature you have to make them work well across the board because you are evaluated against other languages that provide them. If it is just an "extras" library features, then you can make do with "basic features", nobody expects more.
Mar 28 2015
prev sibling parent Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-28 at 13:27 +0000, via Digitalmars-d-announce wrote:
 [=E2=80=A6]
=20
 Nah. Cooperative multitasking is a sorry excuse that belongs to=20
 the 80s. This should be as transparent as possible. You cannot=20
 insert "yield" into an external library.
1960s. Software developers have spent 50+ years trying to use 1960s operating=20 system concurrency techniques for all of software development. It's=20 time there was some innovation and less conservatism in software=20 concurrency and parallelism. --=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 28 2015
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.03.2015 um 17:06 schrieb Dicebot:
 On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote:
 No... E.g.:

 On the same thread:
 1. fiber A receives request and queries DB (async)
 2. fiber B computes for 1 second
 3. fiber A sends response.

 Latency: 1 second even if all the other threads are free.
This is a problem of having blocking 1 second computation in same fiber pool as request handlers -> broken application design. Hiding that issue by moving fibers between threads is just making things worse.
Exactly, the problem will remain there, even with moving fibers around, because you might as well have the same situation in all of the threads at the same time like that. It always makes sense to have dedicated threads for lengthy computations. Apart from that, long computations can call yield() every now and then to avoid this kind of issue in the first place.
Mar 27 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 5:15 AM, Sönke Ludwig wrote:
 It has, that is more or less the original selling point. It also keeps an
 internal thread pool where each thread has a dynamic set of reusable fibers to
 execute tasks. Each fiber is bound to a certain thread, though, and they have
 to, because otherwise things like thread local storage or other thread specific
 code (e.g. the classic OpenGL model, certain COM modes etc.) would break.
It's awesome that vibe has that! How about replacing the fiber support in druntime with that?
 Apart from these concerns, It's also not clear to me that moving tasks between
 threads is necessarily an improvement. There are certainly cases where that
 leads to a better distribution across the cores, but in most scenarios the
 number of concurrent tasks should be high enough to keep all cores busy anyhow.
 There are also additional costs for moving fibers (synchronization, cache
misses).
I agree that moving between threads can wait.
Mar 27 2015
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.03.2015 um 19:56 schrieb Walter Bright:
 On 3/27/2015 5:15 AM, Sönke Ludwig wrote:
 It has, that is more or less the original selling point. It also keeps an
 internal thread pool where each thread has a dynamic set of reusable
 fibers to
 execute tasks. Each fiber is bound to a certain thread, though, and
 they have
 to, because otherwise things like thread local storage or other thread
 specific
 code (e.g. the classic OpenGL model, certain COM modes etc.) would break.
It's awesome that vibe has that! How about replacing the fiber support in druntime with that?
It's actually based on the fiber support in Druntime. It would definitely be great to get the event loop and the scheduler into Druntime/Phobos, too. But it needs to be integrated in many places at the same time (core.sync.*, std.concurrency, std.stdio, std.socket etc.) to avoid bad surprises for users. We'd need to decide how to cut that work into manageable pieces. Fortunately there is now already an event loop abstraction written in pure D [1], which should be integrated first, because the fiber scheduler itself isn't worth much without an event loop. [1]: https://github.com/etcimon/libasync
Mar 27 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/26/2015 09:47 PM, Walter Bright wrote:
 It seems to me that every significant but one feature of Go has a pretty
 much direct analog in D
I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole "minimalism" approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to.
Mar 27 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 27 March 2015 at 20:20:07 UTC, Nick Sabalausky wrote:
 On 03/26/2015 09:47 PM, Walter Bright wrote:
 It seems to me that every significant but one feature of Go 
 has a pretty
 much direct analog in D
I'm no Go expert, but AIUI, Go seems to be one of those languages that considers *lacking* certain features to *be* a feature. Ie the whole "minimalism" approach to language design. For people who value that (not for me personally though), it's a feature D doesn't offer and deliberately doesn't try to.
there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years.
Mar 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 1:35 PM, weaselcat wrote:
 there's a difference between minimalism and blatantly not adopting core
advances
 in language design over the past 40 years.
Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot.
Mar 27 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote:
 On 3/27/2015 1:35 PM, weaselcat wrote:
 there's a difference between minimalism and blatantly not 
 adopting core advances
 in language design over the past 40 years.
Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot.
I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled.
Mar 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 2:47 PM, weaselcat wrote:
 On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote:
 On 3/27/2015 1:35 PM, weaselcat wrote:
 there's a difference between minimalism and blatantly not adopting core
advances
 in language design over the past 40 years.
Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot.
I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled.
I tried to program in Java, and found it went too far in the simplicity department. I haven't programmed in Go, but it has also gone too far for my taste. I just don't want to program that way anymore. I am not going to claim that D has hit the sweet spot, either, but I'd rather err on the side of having the power I want.
Mar 27 2015
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Friday, March 27, 2015 16:03:01 Walter Bright via Digitalmars-d-announce
wrote:
 On 3/27/2015 2:47 PM, weaselcat wrote:
 On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote:
 On 3/27/2015 1:35 PM, weaselcat wrote:
 there's a difference between minimalism and blatantly not adopting core
advances
 in language design over the past 40 years.
Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity. It's a tricky thing finding the sweet spot.
I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled.
I tried to program in Java, and found it went too far in the simplicity department. I haven't programmed in Go, but it has also gone too far for my taste. I just don't want to program that way anymore. I am not going to claim that D has hit the sweet spot, either, but I'd rather err on the side of having the power I want.
Exactly! I'd _much_ rather have a language be a bit too complicated than too simple - especially way too simple. And if I wanted simple, I'd program in Java, but I don't want to simple - not at the price of power anyway - so I don't program in Java if I can help it. And I have stayed away from Go for the same reason. The more I learn of it, the clearer it is that its design goals and the audience that it targets is at complete odds with what I'm looking for. From what I've seen, I'd expect your average Go programmer to dislike D, and your average D programmer to dislike Go, because they seem to be at completely different ends of the simplicity vs power spectrum. Of course, it's nice when a language can be powerful without adding a lot of complexity in the process, but I'd much rather have to worry about some extra complexity than not be able to do something in a language. For instance, in the case of Java, it's not even possible to write a swap function in it! And that doesn't even get into the more complex topics like RAII or code generation. I'll take power over simplicity almost every time if that's the tradeoff (though obviously, that can be taken too far if you're not careful). Personally, I'm not sure that much is gained in pitting Go against D precisely because they're so different that they're likely to appeal to completely different sets of people. - Jonathan M Davis
Mar 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go against D
 precisely because they're so different that they're likely to appeal to
 completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
Mar 28 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
 On 3/28/2015 3:20 AM, Jonathan M Davis via 
 Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go 
 against D
 precisely because they're so different that they're likely to 
 appeal to
 completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
I find most people I know using Go are from the python camp and either wanted static typing or faster runtime execution.
Mar 28 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-28 at 18:51 +0000, weaselcat via Digitalmars-d-announce wro=
te:
 On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
 On 3/28/2015 3:20 AM, Jonathan M Davis via=20
 Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go=20
 against D
 precisely because they're so different that they're likely to=20
 appeal to
 completely different sets of people.
=20 I also do not regard Go as a competitor to D. It's more of a=20 competitor to Java and Ruby.
=20 I find most people I know using Go are from the python camp and=20 either wanted static typing or faster runtime execution.
It is a pity that D is not pitching as a Python replacement. =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 28 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 28 Mar 2015 19:17:23 +0000, Russel Winder via
Digitalmars-d-announce wrote:

 It is a pity that D is not pitching as a Python replacement.
D can't: it doesn't dumb enough to attract people that requires compiler=20 enforcements on whitespace to correctly format their code.=
Mar 28 2015
parent reply "cym13" <cpicard openmailbox.org> writes:
On Sunday, 29 March 2015 at 00:24:36 UTC, ketmar wrote:
 On Sat, 28 Mar 2015 19:17:23 +0000, Russel Winder via
 Digitalmars-d-announce wrote:

 It is a pity that D is not pitching as a Python replacement.
D can't: it doesn't dumb enough to attract people that requires compiler enforcements on whitespace to correctly format their code.
Urr.... As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently. On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^" Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). UFCS FTW!
Mar 28 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 29 Mar 2015 02:15:38 +0000, cym13 wrote:

 On Sunday, 29 March 2015 at 00:24:36 UTC, ketmar wrote:
 On Sat, 28 Mar 2015 19:17:23 +0000, Russel Winder via
 Digitalmars-d-announce wrote:

 It is a pity that D is not pitching as a Python replacement.
D can't: it doesn't dumb enough to attract people that requires compiler enforcements on whitespace to correctly format their code.
=20 Urr.... As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently.
it was a joke... at least it was almost a joke.=
Mar 28 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:
 Moreover, it is possible to reach a good expressiveness (maybe 
 not as good as python, but that's the whole goal of python so 
 there's no shame in not matching it).
There are many alternatives to Python. Like Nim or Dart: https://www.dartlang.org/articles/beyond-async/ https://www.dartlang.org/articles/await-async/
Mar 29 2015
parent reply "cym13" <cpicard openmailbox.org> writes:
On Sunday, 29 March 2015 at 12:21:01 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:
 Moreover, it is possible to reach a good expressiveness (maybe 
 not as good as python, but that's the whole goal of python so 
 there's no shame in not matching it).
There are many alternatives to Python. Like Nim or Dart: https://www.dartlang.org/articles/beyond-async/ https://www.dartlang.org/articles/await-async/
Nim seems quite interesting indeed, even if I'm not sure how well it scales. It looks like a language that is prowd of a heavy use of macros and DSL definition à la lisp. I know lisp enough to know that it's not a problem in itself, but that it should be developed wisely. It may look at first as a better alternative than D for a pure python developer, but I'll stick with D. However, I can't see a pythonista being excited in Dart at all, at least not for what he finds in python. More restricted in any way, no clear functional orientation possible, a clear lack of expressiveness... D clearely has the advantage there.
Mar 29 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 29 March 2015 at 12:50:38 UTC, cym13 wrote:
 Nim seems quite interesting indeed, even if I'm not sure how 
 well it scales. It looks like a language that is prowd of a 
 heavy use of macros and DSL definition à la lisp.
Nim is also too young to know if it stays around.
 However, I can't see a pythonista being excited in Dart at all, 
 at least not for what he finds in python. More restricted in 
 any way, no clear functional orientation possible, a clear lack
Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE. I don't think any language without comprehensions can attract Python programmers for real, but the recent Dart 1.9 release also have compact Pythonesque generators (iterators/ranges) as you can see on the link above so I like the direction they are taking now. Anyway, my point was more that making Python a target means you have to compete with a large set of other languages in the same vein. In the system language area you only have C++/Rust so it is an easier target. Unfortunately C++ still has a lot of advantages over other languages for real world projects, so it will remain my system level language until a better language starts polishing their low level stuff... :-/
Mar 29 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad 
wrote:
 Actually, there is quite a large overlap if you look beyond the 
 syntax. Dart is completely unexciting, but I also find it very 
 productive when used with the IDE.
Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case).
 Anyway, my point was more that making Python a target means you 
 have to compete with a large set of other languages in the same 
 vein. In the system language area you only have C++/Rust so it 
 is an easier target. Unfortunately C++ still has a lot of 
 advantages over other languages for real world projects, so it 
 will remain my system level language until a better language 
 starts polishing their low level stuff... :-/
Peter Thiel is right. Competition is overrated, and it is much better to have a monopoly in a small domain and build out from there - one shouldn't think in terms of acquiring market share if one is not already one of the dominant players (and even then to do so is often counterproductive). D isn't a product marketed by Proctor and Gamble. So nobody is going to make Python a target, as best I can tell. But one can surely learn from what they do right, to the extent that it applies to new conditions of the future. The obvious things are documentation, libraries, and having a nice, easy-to-install, and low-friction set of choices in development stacks organised and available. Knuth is also right that people think in different ways, and it's an entirely natural thing to see a multiplicity of languages emerging that are adapted to these different ways (and of course the particular challenges people face are also different). That's why religious wars about these things have a bad name. That doesn't mean people shouldn't have a perspective and argue for it when such discussions are generative. D will continue to gather success if it keeps getting better and confronting the painful challenges of growth, as seems to me to be happening in my short time here. Naysayers are an asset if one doesn't get discouraged, because it is difficult to buy good criticism at any price.
Mar 29 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 29 March 2015 at 19:03:06 UTC, Laeeth Isharc wrote:
 On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad 
 wrote:
 Actually, there is quite a large overlap if you look beyond 
 the syntax. Dart is completely unexciting, but I also find it 
 very productive when used with the IDE.
Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case).
I don't know the future of Dart, but if you have time to wait for it you might consider atscript/Angular 2.0.
 Knuth is also right that people think in different ways, and 
 it's an entirely natural thing to see a multiplicity of 
 languages emerging that are adapted to these different ways 
 (and of course the particular challenges people face are also 
 different).  That's why religious wars about these things have
I think most imperative languages are just variations over the same theme. I pick them based on what they+ecosystem is good at, not the language by itself. So basically, you have to be best at one particular application area to do well. Go is aiming to have a good runtime for building smaller web-services, and they are getting there. Because they focus.
Mar 30 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 30 March 2015 at 08:53:15 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 29 March 2015 at 19:03:06 UTC, Laeeth Isharc wrote:
 On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad 
 wrote:
 Actually, there is quite a large overlap if you look beyond 
 the syntax. Dart is completely unexciting, but I also find it 
 very productive when used with the IDE.
Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case).
I don't know the future of Dart, but if you have time to wait for it you might consider atscript/Angular 2.0.
Very dark as Angular team decided to look for Typescript instead[0]. http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx Now with Dart team giving up on their VM, Dart becomes just yet another language that transpiles to JavaScript. http://news.dartlang.org/2015/03/dart-for-entire-web.html So, it will just fade way in the sea of JavaScript wannabe replacements. -- Paulo
Mar 30 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 30 March 2015 at 10:04:11 UTC, Paulo  Pinto wrote:
 Very dark as Angular team decided to look for Typescript 
 instead[0].
It isn't very dark though, they cooperate with MS to build atscript features into Typescript instead. The two dialect were always meant to be merged at some point. So they decided to merge early. A good idea, actually.
 http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx

 Now with Dart team giving up on their VM, Dart becomes just yet 
 another language that transpiles to JavaScript.
Yes, although you can run the dartvm outside the browser, not sure how much love it will receive though.
 So, it will just fade way in the sea of JavaScript wannabe 
 replacements.
Maybe, but Google is using it for Google Ads. Which is their primary business? Still, a bit early to say what happens next.
Mar 30 2015
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ola Fosheim Grøstad:

 So, it will just fade way in the sea of JavaScript wannabe 
 replacements.
Maybe, but Google is using it for Google Ads. Which is their primary business? Still, a bit early to say what happens next.
Perhaps next some kind of blend of Typescript and Dart will become part of a next JavaScript update :-) Bye, bearophile
Mar 30 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 30 March 2015 at 10:45:50 UTC, bearophile wrote:
 Ola Fosheim Grøstad:

 So, it will just fade way in the sea of JavaScript wannabe 
 replacements.
Maybe, but Google is using it for Google Ads. Which is their primary business? Still, a bit early to say what happens next.
Perhaps next some kind of blend of Typescript and Dart will become part of a next JavaScript update :-)
Yeah, I think both Microsoft and Google see this as an effort to prototype what Ecmascript6+ should be like.
Mar 30 2015
prev sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Monday, 30 March 2015 at 08:53:15 UTC, Ola Fosheim Grøstad 
wrote:

 same theme. I pick them based on what they+ecosystem is good 
 at, not the language by itself. So basically, you have to be 
 best at one particular application area to do well. Go is 
 aiming to have a good runtime for building smaller 
 web-services, and they are getting there. Because they focus.
It is necessary to be appealing to Ola by Ola's standards for a language to appeal to other people? I think how it actually works is that you have to find a small but focused group of people to love you lots. Then they tell other people and over time you get better at appealing to those for whom you weren't ready before. So that's similar to what you suggest in one sense, except that the chicken and egg problem is smaller. Sociomantic didn't consider the ecosystem when selecting D (or at least were not put off by its immaturity). But if in five years time their competitors realize the possibilities for doing things better, they will certainly benefit from the work Sociomantic has done on improving D (even purely as a demanding use case, but it's more than that). [And Sociomantic won't lose, in my uninformed estimation, because edge is dynamic]. Similarly in the tiniest of ways, I didn't weight the library situation very heavily in picking D. I have written a couple of bindings (painfully, before I got Dstep to work or knew the language very well!) and wrappers and if anyone like me arrives subsequently then it will be that little bit easier. So that's one more reason why it can take a couple of decades for something to be an overnight success - it takes time for paths and habits to be formed, and there are threshold effects, beyond which there is a phase change. So D's long-term prospects will be shaped by how it responds to the challenges of growth. Looks good to me right now. Laeeth.
Mar 30 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 30 March 2015 at 12:20:11 UTC, Laeeth Isharc wrote:
 It is necessary to be appealing to Ola by Ola's standards for a 
 language to appeal to other people?
Not sure what point you are trying to make. Project managers pick tools that they think will solve the issues they have in the current project. When you make a plan you have to look at what is there, not what could be. You aim to reduce risk, not increase risk.
Mar 30 2015
prev sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:

 Urr.... As an active Python developer, I find that one pretty 
 harsh. It's not that we need to enforce good style, it's that 
 we take good style as granted and choose to lighten it 
 consequently.

 On the contrary I think that D has everything to attract a 
 pythonista. Most new, trendy languages like Go or Rust are to 
 down a level to easily suit a python's formated mind, and I 
 guess that if most python developers come to switch language 
 for performance issues (like myself) D's code safety system is 
 definitely very appealing because python's safety is... well... 
 ^^"

 Moreover, it is possible to reach a good expressiveness (maybe 
 not as good as python, but that's the whole goal of python so 
 there's no shame in not matching it).

 UFCS FTW!
As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html
Mar 29 2015
next sibling parent reply "cym13" <cpicard openmailbox.org> writes:
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote:
 As an active Python developer, what would you add to or change 
 about the following:
 http://bitbashing.io/2015/01/26/d-is-like-native-python.html
I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like "or web server developments with vibe.d" thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal "Writting Python in D". Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :)
Mar 29 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Sunday, 29 March 2015 at 19:44:01 UTC, cym13 wrote:
 On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote:
 As an active Python developer, what would you add to or change 
 about the following:
 http://bitbashing.io/2015/01/26/d-is-like-native-python.html
I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like "or web server developments with vibe.d" thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal "Writting Python in D". Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :)
should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python
Mar 29 2015
parent reply "cym13" <cpicard openmailbox.org> writes:
On Sunday, 29 March 2015 at 21:06:28 UTC, Laeeth Isharc wrote:
 On Sunday, 29 March 2015 at 19:44:01 UTC, cym13 wrote:
 On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote:
 As an active Python developer, what would you add to or 
 change about the following:
 http://bitbashing.io/2015/01/26/d-is-like-native-python.html
I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like "or web server developments with vibe.d" thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal "Writting Python in D". Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :)
should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python
I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two.
Mar 29 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
 should we add a link to the wiki and ask author if we could 
 mirror there ?

 This section on wiki looks like it could with a bit of 
 fleshing out!

 http://wiki.dlang.org/Coming_From/Python
I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two.
Thank you for noticing. It's not very inspired, but I don't have much energy at the moment, and it is the best I can do with what I have. Better an acceptable start than trying to be perfect. The Ruby / Java / Eiffel / C# / and Basic sections also need starting.
Mar 29 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 29 March 2015 at 22:07:40 UTC, Laeeth Isharc wrote:
 should we add a link to the wiki and ask author if we could 
 mirror there ?

 This section on wiki looks like it could with a bit of 
 fleshing out!

 http://wiki.dlang.org/Coming_From/Python
I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two.
Thank you for noticing. It's not very inspired, but I don't have much energy at the moment, and it is the best I can do with what I have. Better an acceptable start than trying to be perfect. The Ruby / Java / Eiffel / C# / and Basic sections also need starting.
While not forgetting that Java, Eiffel, C#, Basic have options to compile straight to native code, just like D, so the focus should be on other features and not on native vs VM. -- Paulo
Mar 30 2015
prev sibling next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote:
 On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote:

 Urr.... As an active Python developer, I find that one pretty 
 harsh. It's not that we need to enforce good style, it's that 
 we take good style as granted and choose to lighten it 
 consequently.

 On the contrary I think that D has everything to attract a 
 pythonista. Most new, trendy languages like Go or Rust are to 
 down a level to easily suit a python's formated mind, and I 
 guess that if most python developers come to switch language 
 for performance issues (like myself) D's code safety system is 
 definitely very appealing because python's safety is... 
 well... ^^"

 Moreover, it is possible to reach a good expressiveness (maybe 
 not as good as python, but that's the whole goal of python so 
 there's no shame in not matching it).

 UFCS FTW!
As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html
while it mentions concurrency/parallel, a quick example of showing how easy it is to do parallel operations in D would probably benefit considering python's current state of parallelism.
Mar 29 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2015 12:09 PM, Laeeth Isharc wrote:
 As an active Python developer, what would you add to or change about the
following:
 http://bitbashing.io/2015/01/26/d-is-like-native-python.html
Has someone reddit-ized it?
Mar 29 2015
parent reply "cym13" <cpicard openmailbox.org> writes:
On Sunday, 29 March 2015 at 21:45:23 UTC, Walter Bright wrote:
 On 3/29/2015 12:09 PM, Laeeth Isharc wrote:
 As an active Python developer, what would you add to or change 
 about the following:
 http://bitbashing.io/2015/01/26/d-is-like-native-python.html
Has someone reddit-ized it?
It seems so: http://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?submit_url=http%3A%2F%2Fbitbashing.io%2F2015%2F01%2F26%2Fd-is-like-native-python.html&already_submitted=true
Mar 29 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2015 2:46 PM, cym13 wrote:
 On Sunday, 29 March 2015 at 21:45:23 UTC, Walter Bright wrote:
 On 3/29/2015 12:09 PM, Laeeth Isharc wrote:
 As an active Python developer, what would you add to or change about the
 following:
 http://bitbashing.io/2015/01/26/d-is-like-native-python.html
Has someone reddit-ized it?
It seems so: http://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?submit_url=http%3A%2F%2Fbitbashing.io%2F2015%2F01%2F26%2Fd-is-like-native-python.html&already_submitted=true
Ah, thanks!
Mar 29 2015
prev sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
 On 3/28/2015 3:20 AM, Jonathan M Davis via 
 Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go 
 against D
 precisely because they're so different that they're likely to 
 appeal to
 completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")
Mar 29 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
 On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
 On 3/28/2015 3:20 AM, Jonathan M Davis via 
 Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go 
 against D
 precisely because they're so different that they're likely to 
 appeal to
 completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")
I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it.
Mar 29 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/29/15 4:43 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:
 On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
 On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
 On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go against D
 precisely because they're so different that they're likely to appeal to
 completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")
I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it.
... but efficiency. Ruby is 50 times slower than all languages, including itself. Andrei
Mar 29 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 29 March 2015 at 15:57:18 UTC, Andrei Alexandrescu 
wrote:
 On 3/29/15 4:43 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
 <schuetzm gmx.net>" wrote:
 On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
 On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright 
 wrote:
 On 3/28/2015 3:20 AM, Jonathan M Davis via 
 Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go 
 against D
 precisely because they're so different that they're likely 
 to appeal to
 completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")
I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it.
... but efficiency. Ruby is 50 times slower than all languages, including itself. Andrei
Not to mention orthogonal safety. Even for a dynamically typed scripting language Ruby sacrifices a lot of safety. Not memory-wise but orthogonality-wise - it's design is very hackish, and you can remove an import("require") to foo.rb from bar.rb thus causing a bug in baz.rb that was importing bar.rb and thus indirectly importing qux.rb because foo.rb was importing it, and qux.rb is monkey-patching class Qux to override some method to return a different value. Have fun trying to debug this! Computer science is all about tradeoffs. I used to love Ruby, but then a Rails project got out of hand... Nowadays I use it mainly as a bash replacement - Hundredfolds more expressive, only a tiny tiny bit syntax overhead, and for things that bash's safety would be enough Ruby's certainly suffices.
Mar 29 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 29 March 2015 at 16:32:32 UTC, Idan Arye wrote:
 Computer science is all about tradeoffs. I used to love Ruby, 
 but then a Rails project got out of hand... Nowadays I use it 
 mainly as a bash replacement - Hundredfolds more expressive, 
 only a tiny tiny bit syntax overhead, and for things that 
 bash's safety would be enough Ruby's certainly suffices.
This is pretty much the recurring story with ruby. The first 10 000 lines are a lot of fun, and then it gets out of hands.
Mar 29 2015
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 30 March 2015 at 03:26:14 UTC, deadalnix wrote:
 On Sunday, 29 March 2015 at 16:32:32 UTC, Idan Arye wrote:
 Computer science is all about tradeoffs. I used to love Ruby, 
 but then a Rails project got out of hand... Nowadays I use it 
 mainly as a bash replacement - Hundredfolds more expressive, 
 only a tiny tiny bit syntax overhead, and for things that 
 bash's safety would be enough Ruby's certainly suffices.
This is pretty much the recurring story with ruby. The first 10 000 lines are a lot of fun, and then it gets out of hands.
Just like any other language with dynamic typing.
Mar 30 2015
parent "Idan Arye" <GenericNPC gmail.com> writes:
On Monday, 30 March 2015 at 07:45:50 UTC, Paulo  Pinto wrote:
 On Monday, 30 March 2015 at 03:26:14 UTC, deadalnix wrote:
 On Sunday, 29 March 2015 at 16:32:32 UTC, Idan Arye wrote:
 Computer science is all about tradeoffs. I used to love Ruby, 
 but then a Rails project got out of hand... Nowadays I use it 
 mainly as a bash replacement - Hundredfolds more expressive, 
 only a tiny tiny bit syntax overhead, and for things that 
 bash's safety would be enough Ruby's certainly suffices.
This is pretty much the recurring story with ruby. The first 10 000 lines are a lot of fun, and then it gets out of hands.
Just like any other language with dynamic typing.
This has more to do with the module system than with the typing. In Ruby, the `require` function reads a source file and interprets it in the global namespace. This means that from that point on, all symbols declared in that source file(and the source files it `require`s) are now part of the global namespace and accessible from anywhere(even from places that didn't `require` it), and that all monkey-patching done in that source file from now on applies *everywhere*. Compare it to Python, that has a module system that handles namespacing and forces you to `import` a module in each scope you want to use it. This means that if foo.py uses stuff from bar.py it must `import` it directly and can't rely on some other baz.py that might dropt it's `import` to bar.py because it no longer needs it without knowing that foo.py was using it. Note that Ruby does has `module`s that can be used for namespacing(or for mixins...) but using them is a hassle, because you either have to always use fully qualified names or to `mixin` them into the current namespace(which propagates to other scopes that want to use stuff from YOUR namespace...) Also note that Python also has ways to mess with the gloabl context - but you have to actually dig in to do this, compared to Ruby where messing up the global context is the standard way of doing things.
Mar 30 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
 On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote:
 On 3/28/2015 3:20 AM, Jonathan M Davis via 
 Digitalmars-d-announce wrote:
 Personally, I'm not sure that much is gained in pitting Go 
 against D
 precisely because they're so different that they're likely to 
 appeal to
 completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")
They appeal to programmer that prefers fashionable technology rather than technologies that solve problems.
Mar 29 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 1:20 PM, Nick Sabalausky wrote:
 I'm no Go expert, but AIUI, Go seems to be one of those languages that
considers
 *lacking* certain features to *be* a feature. Ie the whole "minimalism"
approach
 to language design. For people who value that (not for me personally though),
 it's a feature D doesn't offer and deliberately doesn't try to.
That's right. What a minimal language does is transfer the work from the compiler to the programmer. Obviously, I prefer to transfer the work to the compiler. After all, if you're going to be spending 8 hours a day programming, investing a few more hours to learn the language is nothing compared with the time savings from using a more powerful one.
Mar 27 2015
prev sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Thursday, 26 March 2015 at 08:44:20 UTC, Gary Willoughby wrote:
 I wrote the article in a rush last night (girlfriend calling me 
 to bed) and as a result it has a few spelling/grammar errors 
 which I've hopefully corrected.

 The article is a total rant about Go after using it over the 
 last month or so for a project. I honestly was getting so bored 
 with Go and the article that I was literally falling asleep 
 writing it. lol! Is started liking Go but after a while I found 
 it increasing difficult trying to change me way of working to 
 shoehorn solutions into such a simple language.

 I know it's a bit unfair in places and it's got a click bait 
 title but who cares? I got my point across and I think people 
 understand where i'm coming from. It seems to have got really 
 popular and I've been swamped with mail, etc. I think it's the 
 most read article i've ever written. ha! :o)
https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang fwiw
Mar 29 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote:
 https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang

 fwiw
Nice, well-written answer, enjoyed reading it.
Mar 29 2015
parent "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Monday, 30 March 2015 at 03:47:45 UTC, Joakim wrote:
 On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote:
 https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang

 fwiw
Nice, well-written answer, enjoyed reading it.
Thank you.
Mar 29 2015
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote:
 https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang
Post this on reddit.
Mar 30 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu 
wrote:
 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/

 Andrei
Downplaying other languages makes the D crowd look desperate... Go has stability, is production ready and has an ecosystem with commercial value. D lacks all of these atm...
Mar 25 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ola Fosheim Grøstad:

 Downplaying other languages makes the D crowd look desperate...
That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile
Mar 25 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote:
 Ola Fosheim Grøstad:

 Downplaying other languages makes the D crowd look desperate...
That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile
+1 but his points about go really are right.
Mar 25 2015
prev sibling next sibling parent "cym13" <cpicard openmailbox.org> writes:
On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote:
 Ola Fosheim Grøstad:

 Downplaying other languages makes the D crowd look desperate...
That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile
I don't know about that... I too think that maybe it was a clumsy way of doing it but I'm not sure that we would have had such critics if Python (eg.) had been choosen to write the examples, even with not very pythonic code. Maybe it should have been backed up with another language not to put the comparison on D alone. Bad publicity is better than no publicity in many cases. There's no reason why this couldn't play out right in the end.
Mar 25 2015
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote:
 Ola Fosheim Grøstad:

 Downplaying other languages makes the D crowd look desperate...
That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile
I don't think it's that bad. The general sentiment in the comments seems to agree with the article despite (or because of) its strong opinionation, and apparently this is the most popular article Gary has ever written, which is good publicity for D.
Mar 26 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/25/2015 07:00 PM, bearophile wrote:
 Ola Fosheim Grøstad:

 Downplaying other languages makes the D crowd look desperate...
That kind of articles are bad for the image of the D community
No. Just...no. I'm honestly *really* tired of general society's (seemingly?) increasing intolerance FOR intolerance. Some things ARE bad. Some ideas are dumb ideas (ie without merit). Some features are bad features. Some products really are crappy products. Calling it out when you see it, using a frank explanation of your reasoning, isn't bad, it's productive. To discourage dissent, objections, or complaints is to rob ourselves of potential improvement. *That's* what critique and complaints and objections ARE: Recognition of the potential for improvement. There *cannot* be progress and improvement without first identifying existing faults. If nobody ever identified and voiced criticism of punchcards, for example, we'd all still be stuck in the world of 1950's computing. It's not as if "the D crowd" doesn't critique itself and it's own language just plenty, so it's not like there's any hypocrisy here. And I'm certainly not willing to accept that programmers should be viewed as being part of distinct mutually-exclusive factions based on some single-language allegiance. I'm a D guy. I also happen to be a fan of Nemerle. And both languages have things I hate. So scratch the "it's the D crowd" idea. And seriously, the article in question barely mentions D at all. So no, this is NOT some sort of "D community piece attacking another language" as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. So he happens to also use D? So what? A lot of people use a lot of langauges. I'm sure the author's used more than just Go and D, too. That certainly doesn't make it one language attacking another. Maybe he's a fan of burritos, too. Maybe then we could take it as a "ZOMG! The burrito enthusiasts are attacking golang!"
Mar 26 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 18:00:29 UTC, Nick Sabalausky wrote:
 So no, this is NOT some sort of "D community piece attacking 
 another language" as some comments seem to imply. It is merely 
 an isolated critique of one language by someone who happens to 
 be *using* the given language.
==> digitalmars.D.announce
Mar 26 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/26/2015 02:04 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Thursday, 26 March 2015 at 18:00:29 UTC, Nick Sabalausky wrote:
 So no, this is NOT some sort of "D community piece attacking another
 language" as some comments seem to imply. It is merely an isolated
 critique of one language by someone who happens to be *using* the
 given language.
==> digitalmars.D.announce
Oh, so you were merely objecting to it being posted on D.announce rather than objecting to the article itself? Nevermind then.
Mar 26 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 18:07:39 UTC, Nick Sabalausky wrote:
 On 03/26/2015 02:04 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Thursday, 26 March 2015 at 18:00:29 UTC, Nick Sabalausky 
 wrote:
 So no, this is NOT some sort of "D community piece attacking 
 another
 language" as some comments seem to imply. It is merely an 
 isolated
 critique of one language by someone who happens to be *using* 
 the
 given language.
==> digitalmars.D.announce
Oh, so you were merely objecting to it being posted on D.announce rather than objecting to the article itself? Nevermind then.
I was merely pointing out that the D community comes through as desperate. Whether that is objectionable depends on how one wants to be perceived? Maybe it is the truth? In that case it is a good thing that it comes through as desperate!! ;^) And yes, when it is posted to the announcement list by one of the D language designers it is given a different status than merely being a random rant using toy examples. Obvious ranting is okish if it doesn't pretend to be more than that, but then it isn't something to be announced... is it? http://en.wiktionary.org/wiki/people_who_live_in_glass_houses_shouldn%27t_throw_stones
Mar 26 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Btw, I have nothing against people complaining about Go's lack of 
productivity features and pointing out that they have competition 
from  D. After all, I too did some ranting on the topic back in 
2009:

https://groups.google.com/forum/#!topic/golang-nuts/TTCaIpSxn2U%5B1-25%5D

«I think Go has set off onto a very nice track, but it doesn't 
seem
like you guys have really managed to communicate in which 
direction
you are heading. I expect Go to improve, but if it isn't going to
provide for more error-catching facilities then it probably isn't
worth the trouble. Go has more competition than C and C++: D 
comes to
mind along with other smaller competitors.»

Nothing is new under the sun etc...
Mar 26 2015
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/26/2015 02:00 PM, Nick Sabalausky wrote:
 And seriously, the article in question barely mentions D at all.
Sorry, what I meant is it doesn't rely on D, and "D > Go" is very clearly NOT the point the article is trying to make. It's just used for contrast, to illustrate the points. It could've been other languages as well.
Mar 26 2015
prev sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
 That kind of articles are bad for the image of the D community
Nick S:
 No. Just...no.

 I'm honestly *really* tired of general society's (seemingly?) 
 increasing intolerance FOR intolerance.

 Some things ARE bad. Some ideas are dumb ideas (ie without 
 merit). Some features are bad features. Some products really 
 are crappy products. Calling it out when you see it, using a 
 frank explanation of your reasoning, isn't bad, it's productive.
Excellence is incompatible with tolerating mediocrity or what is appalling, and what I have seen is that there are aesthetic aspects to creative endeavours not conventionally thought of as having an aesthetic element, and it is in the nature of such things that one cannot and should not tolerate what one perceives to be ugly in a creative endeavour. If one is driven mostly by ROI rather than high feelings, one doesn't get to excellence. So it is my belief that dealing with creative people means dealing with a certain ... intensity. That (on the aesthetic aspects of technical fields) is not just my opinion, but also (I think) that of a certain Mr W Bright, judging by his comments on how good code should look and on good aircraft design, although he presented this in his usual low-key manner. I was looking for a language that was beautiful, as well as powerful, and for whatever it is worth, this was a factor of high appeal with D. It's also the view of Feynman, not to mention many great minds of the past. Ie it is limiting to insist on data before forming a strong opinion about something (which is not to say that one may not change one's mind in the face of contrary data). "You can recognize truth by its beauty and simplicity. When you get it right, it is obvious that it is right—at least if you have any experience—because usually what happens is that more comes out than goes in. ...The inexperienced, the crackpots, and people like that, make guesses that are simple, but you can immediately see that they are wrong, so that does not count. Others, the inexperienced students, make guesses that are very complicated, and it sort of looks as if it is all right, but I know it is not true because the truth always turns out to be simpler than you thought." - Feynman via Wikiquote (but the same idea comes across in his books).
 To discourage dissent, objections, or complaints is to rob 
 ourselves of potential improvement. *That's* what critique and 
 complaints and objections ARE: Recognition of the potential for 
 improvement. There *cannot* be progress and improvement without 
 first identifying existing faults. If nobody ever identified 
 and voiced criticism of punchcards, for example, we'd all still 
 be stuck in the world of 1950's computing.
Excellently put. (And, I would add, a constructive draw towards what is generative - not just fault-finding).
 It's not as if "the D crowd" doesn't critique itself and it's 
 own language just plenty, so it's not like there's any 
 hypocrisy here. And I'm certainly not willing to accept that 
 programmers should be viewed as being part of distinct 
 mutually-exclusive factions based on some single-language 
 allegiance. I'm a D guy. I also happen to be a fan of Nemerle. 
 And both languages have things I hate. So scratch the "it's the 
 D crowd" idea.
Interesting - what should I read about Nemerle, and what is it best at ?
 And seriously, the article in question barely mentions D at all.

 So no, this is NOT some sort of "D community piece attacking 
 another language" as some comments seem to imply. It is merely 
 an isolated critique of one language by someone who happens to 
 be *using* the given language.
There are some very interesting psychological dynamics in the reaction to this kind of piece. For me it was key that although it was clearly written in a humorous tone, and hurriedly, he seemed to speak from the heart - it is refreshing to see such work even when one doesn't agree with it. BTW since when has linking to something been an endorsement of it?
Mar 26 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2015 8:53 PM, Laeeth Isharc wrote:
 It's also the view of Feynman, not to mention many great minds of the past.  Ie
 it is limiting to insist on data before forming a strong opinion about
something
 (which is not to say that one may not change one's mind in the face of contrary
 data).
Feynman's books are all worth reading, even if you have no interest in physics. His attitude about things is just a marvel. I once had a roundtable discussion with the question "if you could resurrect any historical figure, who would it be?" I nominated Feynman, and that pretty much ended the discussion :-) nobody could think of anyone more appropriate. So yeah, I definitely take inspiration from him.
Mar 26 2015
parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Friday, 27 March 2015 at 04:35:17 UTC, Walter Bright wrote:
 On 3/26/2015 8:53 PM, Laeeth Isharc wrote:
 It's also the view of Feynman, not to mention many great minds 
 of the past.  Ie
 it is limiting to insist on data before forming a strong 
 opinion about something
 (which is not to say that one may not change one's mind in the 
 face of contrary
 data).
Feynman's books are all worth reading, even if you have no interest in physics. His attitude about things is just a marvel. I once had a roundtable discussion with the question "if you could resurrect any historical figure, who would it be?" I nominated Feynman, and that pretty much ended the discussion :-) nobody could think of anyone more appropriate. So yeah, I definitely take inspiration from him.
Richard P. Feynman “Well, Mr. Frankel, who started this program, began to suffer from the computer disease that anybody who works with computers now knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is you *play* with them. They are so wonderful. You have these switches - if it's an even number you do this, if it's an odd number you do that - and pretty soon you can do more and more elaborate things if you are clever enough, on one machine. After a while the whole system broke down. Frankel wasn't paying any attention; he wasn't supervising anybody. The system was going very, very slowly - while he was sitting in a room figuring out how to make one tabulator automatically print arc-tangent X, and then it would start and it would print columns and then bitsi, bitsi, bitsi, and calculate the arc-tangent automatically by integrating as it went along and make a whole table in one operation. Absolutely useless. We *had* tables of arc-tangents. But if you've ever worked with computers, you understand the disease - the *delight* in being able to see how much you can do. But he got the disease for the first time, the poor fellow who invented the thing.” ― Richard P. Feynman, Surely You're Joking, Mr. Feynman!: Adventures of a Curious Character tags: computers, humor, programming ;)
Mar 26 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 27 March 2015 at 03:53:36 UTC, Laeeth Isharc wrote:
 That kind of articles are bad for the image of the D community
Nick S:
 No. Just...no.

 I'm honestly *really* tired of general society's (seemingly?) 
 increasing intolerance FOR intolerance.

 Some things ARE bad. Some ideas are dumb ideas (ie without 
 merit). Some features are bad features. Some products really 
 are crappy products. Calling it out when you see it, using a 
 frank explanation of your reasoning, isn't bad, it's 
 productive.
Excellence is incompatible with tolerating mediocrity or what is appalling, and what I have seen is that there are aesthetic aspects to creative endeavours not conventionally thought of as having an aesthetic element, and it is in the nature of such things that one cannot and should not tolerate what one perceives to be ugly in a creative endeavour. If one is driven mostly by ROI rather than high feelings, one doesn't get to excellence. So it is my belief that dealing with creative people means dealing with a certain ... intensity. That (on the aesthetic aspects of technical fields) is not just my opinion, but also (I think) that of a certain Mr W Bright, judging by his comments on how good code should look and on good aircraft design, although he presented this in his usual low-key manner. I was looking for a language that was beautiful, as well as powerful, and for whatever it is worth, this was a factor of high appeal with D. It's also the view of Feynman, not to mention many great minds of the past. Ie it is limiting to insist on data before forming a strong opinion about something (which is not to say that one may not change one's mind in the face of contrary data). "You can recognize truth by its beauty and simplicity. When you get it right, it is obvious that it is right—at least if you have any experience—because usually what happens is that more comes out than goes in. ...The inexperienced, the crackpots, and people like that, make guesses that are simple, but you can immediately see that they are wrong, so that does not count. Others, the inexperienced students, make guesses that are very complicated, and it sort of looks as if it is all right, but I know it is not true because the truth always turns out to be simpler than you thought." - Feynman via Wikiquote (but the same idea comes across in his books).
 To discourage dissent, objections, or complaints is to rob 
 ourselves of potential improvement. *That's* what critique and 
 complaints and objections ARE: Recognition of the potential 
 for improvement. There *cannot* be progress and improvement 
 without first identifying existing faults. If nobody ever 
 identified and voiced criticism of punchcards, for example, 
 we'd all still be stuck in the world of 1950's computing.
Excellently put. (And, I would add, a constructive draw towards what is generative - not just fault-finding).
 It's not as if "the D crowd" doesn't critique itself and it's 
 own language just plenty, so it's not like there's any 
 hypocrisy here. And I'm certainly not willing to accept that 
 programmers should be viewed as being part of distinct 
 mutually-exclusive factions based on some single-language 
 allegiance. I'm a D guy. I also happen to be a fan of Nemerle. 
 And both languages have things I hate. So scratch the "it's 
 the D crowd" idea.
Interesting - what should I read about Nemerle, and what is it best at ?
 And seriously, the article in question barely mentions D at 
 all.

 So no, this is NOT some sort of "D community piece attacking 
 another language" as some comments seem to imply. It is merely 
 an isolated critique of one language by someone who happens to 
 be *using* the given language.
There are some very interesting psychological dynamics in the reaction to this kind of piece. For me it was key that although it was clearly written in a humorous tone, and hurriedly, he seemed to speak from the heart - it is refreshing to see such work even when one doesn't agree with it. BTW since when has linking to something been an endorsement of it?
Interesting. Have you read Oscar Wilde? Your comments remind me of him somehow. I was just thinking yesterday how working with D makes me happy whereas working with other (lower) languages makes me grumpy. Going down to the punchcard level (PHP, JS etc.) is boring and doesn't do justice to the human mind. Whenever I use D, I am confident that I can map a complicated reality onto a machine, it inspires me and it challenges me. Primitive languages discourage me. So there's more to productivity than meets the eye when looking at numbers. Numbers are insignificant, they can prove anything you want, and you can tweak them any way you want. "Eat shit, a million flies can't be wrong!", as they say. It's one thing to be productive in terms of maintaining and selling apps and another in terms of being innovative. You can sell a million records by sticking to well-trodden paths (dum-dum-dum-di-dum) or you can be a Mozart, a Beethoven, a Miles Davis or a Hendrix and just say "I'm gonna do my own thing!". Sure, it involves what is commonly perceived as "arrogance", but it's not.
Mar 27 2015
parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
 There are some very interesting psychological dynamics in the 
 reaction to this kind of piece.  For me it was key that 
 although it was clearly written in a humorous tone, and 
 hurriedly, he seemed to speak from the heart - it is 
 refreshing to see such work even when one doesn't agree with 
 it.

 BTW since when has linking to something been an endorsement of 
 it?
Interesting. Have you read Oscar Wilde? Your comments remind me of him somehow.
Only a few things, and not his writings on aesthetics - but I do think truth, beauty and virtue need to balance each other. Concentrating on prettiness alone leads to a shallow kind of thing becomes it becomes disconnected from the underlying generative spirit and eventually the life goes out of it. So I suspect his perspective was rather different.
 I was just thinking yesterday how working with D makes me happy 
 whereas working with other (lower) languages makes me grumpy.
Yes - and this matters so much more than as technical people we give ourselves permission to realize because willpower is a limited resource and modern life often appears as if it is a conspiracy to exhaust it. When one actually look forward to writing a boring script because "I can do it in D", I take notice. Moving towards what is generative and away from the wrong kind of pain is a strategy that seems to pay off in life.
 Going down to the punchcard level (PHP, JS etc.) is boring and 
 doesn't do justice to the human mind. Whenever I use D, I am 
 confident that I can map a complicated reality onto a machine, 
 it inspires me and it challenges me. Primitive languages 
 discourage me.
Yes, although I must say I still prefer programming in C to VBA. Provided the aim is not actually to accomplish something quickly !
 So there's more to productivity than meets the eye when looking 
 at numbers. Numbers are insignificant, they can prove anything 
 you want, and you can tweak them any way you want. "Eat shit, a 
 million flies can't be wrong!", as they say.
Yes. And worst of all is the self deception from believing analytical objectivity to be something real rather than something that results from unexamined implicit assumptions. Dr Iain Mcgilchrist at Oxford is excellent on this topic. That doesn't mean one should throw away the profiler, of course...
 It's one thing to be productive in terms of maintaining and 
 selling apps and another in terms of being innovative. You can 
 sell a million records by sticking to well-trodden paths 
 (dum-dum-dum-di-dum) or you can be a Mozart, a Beethoven, a 
 Miles Davis or a Hendrix and just say "I'm gonna do my own 
 thing!". Sure, it involves what is commonly perceived as 
 "arrogance", but it's not.
Fully agree, although humbler initial aspirations and self conceptions are also compatible with a creative path. Viz. "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. "
Mar 27 2015
prev sibling next sibling parent reply "bachmeier" <no spam.net> writes:
On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad 
wrote:
 Go has stability, is production ready and has an ecosystem with 
 commercial value.
You could say the same things about Cobol or PHP, but that doesn't mean the languages themselves should be free from criticism. My opinion of Go was very much consistent with the article. It doesn't mean much to me to have a stable language that I don't want to use. His points are valid.
Mar 25 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 00:08:28 UTC, bachmeier wrote:
 On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim 
 Grøstad wrote:
 Go has stability, is production ready and has an ecosystem 
 with commercial value.
You could say the same things about Cobol or PHP, but that doesn't mean the languages themselves should be free from criticism.
There is a difference between claiming that language A makes this and that difficult and claiming that language B is better than A. To claim the latter you need to look at comparable larger real world programs and how it fares regarding scaling and maintainability issues.
 My opinion of Go was very much consistent with the article. It 
 doesn't mean much to me to have a stable language that I don't 
 want to use. His points are valid.
I could easily make similar points about D and it's somewhat messed up type system, syntax and libraries. It would be quite easy to convincingly claim that C++/Go/Python are a better languages than D. The Go designers keep the language small and polish it to production quality before moving on with new features. Some of the Go designers also have acknowledged that exceptions and generics can be useful, but that they don't want to add features until they know it is the right thing to do and how to go about it. If you aren't making a research language (and D most certainly would fail in that arena) the only thing that matters is how it fares in a production setting by programmers who do full time programming in the language.
Mar 26 2015
parent reply "bachmeier" <no spam.com> writes:
On Thursday, 26 March 2015 at 08:53:31 UTC, Ola Fosheim Grøstad 
wrote:

 There is a difference between claiming that language A makes 
 this and that difficult and claiming that language B is better 
 than A.
We have different interpretations of the article. My reading was "I hate these properties of Go."
 If you aren't making a research language (and D most certainly 
 would fail in that arena) the only thing that matters is how it 
 fares in a production setting by programmers who do full time 
 programming in the language.
You're making a big assumption about which programmers and projects count and which don't. I wonder if outside of Google if there are even 100 programmers working full time exclusively with Go. I don't work full time with D, but I work with it a lot, and I don't see why my experience shouldn't count.
Mar 26 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 19:16:54 UTC, bachmeier wrote:
 You're making a big assumption about which programmers and 
 projects count and which don't. I wonder if outside of Google
It doesn't matter what the programmers think, what matters is how the development environment affects the project in measurable terms. Having all kinds of features does not necessarily benefit projects. That's the difference between a fun toy language and one aiming for production and maintenance.
Mar 26 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Thursday, 26 March 2015 at 19:37:30 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 26 March 2015 at 19:16:54 UTC, bachmeier wrote:
 You're making a big assumption about which programmers and 
 projects count and which don't. I wonder if outside of Google
It doesn't matter what the programmers think, what matters is how the development environment affects the project in measurable terms. Having all kinds of features does not necessarily benefit projects. That's the difference between a fun toy language and one aiming for production and maintenance.
Programming is - for now - still a human activity, and what is important in human activities may not always be measured, and what may be easily measured is not always important. That doesn't mean one should throw away the profiler and go back to guessing, but it does suggest caution about adopting the prestigious techniques of the natural sciences and applying them to a domain where they don't necessarily fully belong. I say this as someone coming from the financial markets, where we have all experienced quite recently the effects of mistaking being quantitative for thinking soundly - what happened ought not to have been a surprise, and of those who saw 2008 coming and spoke publicly about it, I don't think a single one based their view on the quant especially. Yet the field of macroeconomics is much more fully developed than that of assessing programmer productivity and quality of output. It is not scientific to depend on an approach that has not yet proven itself in practical terms over the course of time and in different environments. http://en.wikipedia.org/wiki/Scientism http://plato.stanford.edu/entries/feyerabend/ Laeeth.
Mar 26 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 04:05:30 UTC, Laeeth Isharc wrote:
 Programming is - for now - still a human activity, and what is 
 important in human activities may not always be measured, and 
 what may be easily measured is not always important.  That 
 doesn't mean one should throw away the profiler and go back to 
 guessing, but it does suggest caution about adopting the 
 prestigious techniques of the natural sciences and applying 
 them to a domain where they don't necessarily fully belong.
What is almost always important is: 1. to be able to ship the product in a predictable fashion 2. not go 300-400% over budget 3. being able to train new people to maintain it in reasonable time 4. being able to add new unexpected features to the code base on request Perl is a very expressive and productive language. And you can write maintainable software in it if you have discipline. In the real world Perl tends to lead to an unmaintainable mess with the average programmer.
Mar 26 2015
parent reply "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Friday, 27 March 2015 at 06:49:05 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 27 March 2015 at 04:05:30 UTC, Laeeth Isharc wrote:
 Programming is - for now - still a human activity, and what is 
 important in human activities may not always be measured, and 
 what may be easily measured is not always important.  That 
 doesn't mean one should throw away the profiler and go back to 
 guessing, but it does suggest caution about adopting the 
 prestigious techniques of the natural sciences and applying 
 them to a domain where they don't necessarily fully belong.
What is almost always important is: 1. to be able to ship the product in a predictable fashion 2. not go 300-400% over budget 3. being able to train new people to maintain it in reasonable time 4. being able to add new unexpected features to the code base on request Perl is a very expressive and productive language. And you can write maintainable software in it if you have discipline. In the real world Perl tends to lead to an unmaintainable mess with the average programmer.
Fair points that I wouldn't argue with (although I think predicting when one will finish something entirely new is a mugs game - another reason to favour prototyping and rapid iteration when possible). But those strike me as practical questions of commercial experience, judgement, and tradecraft, and I don't see what it has to do with D or with a scientific approach, except that D may have some advantages in some cases in these areas. I don't see any essential resemblance whatsoever between D and Perl - on the contrary. The data points we have suggest that the scarcity of D programmers is an imaginary problem, because enterprises just hire good people and they pick it up (ask Don at Sociomantic or Dicebot for example). Modern business has a misplaced emphasis on credentials. And if you have a large code base it is not like a new guy can just dive in, anyway. There is a signalling effect at work also, at least for the time being. I am curious about something, if I might ask. You seem like you feel let down by something about D. Ie you give various reasons but I am not sure that's the motivating factor. What's behind that ? No need to answer if you prefer not to, of course. Laeeth.
Mar 27 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 March 2015 at 02:31:37 UTC, Laeeth Isharc wrote:
 Fair points that I wouldn't argue with (although I think 
 predicting when one will finish something entirely new is a 
 mugs game - another reason to favour prototyping and rapid 
 iteration when possible).
Yet you have to if you are to get a fixed price contract.
 on credentials.  And if you have a large code base it is not 
 like a new guy can just dive in, anyway.  There is a signalling 
 effect at work also, at least for the time being.
But that is what the Go authors claim that they are aiming for. To judge it you will have to look at real projects and how they fare. Some teams claim that they are getting good results with Go, whether that is a result of enthusiasm or language qualities is another issue. But they do appear. If you are to evaluate a project you have to look at the project goals. To evaluate Go you have to look at what their design goals are.
 I am curious about something, if I might ask.  You seem like 
 you feel let down by something about D.  Ie you give various
D is going too wide, and therefore does not move. ~9 years ago it was announced as a production level language that could be used to replace C++. Last year there was a move to support better memory management, but it has since halted because there is an unwillingness to change the language. Which is ok, if you just say D2 is all about GC. If you want to excel as a programming language you need to focus on a few areas and be really good in those before you expand into the next one. It is a fairly deep rooted development process issue that needs addressing if D is to reach a wide audience.
Mar 28 2015
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Saturday, 28 March 2015 at 02:31:37 UTC, Laeeth Isharc wrote:

 The data points we have suggest that the scarcity of D 
 programmers is an imaginary problem, because enterprises just 
 hire good people and they pick it up (ask Don at Sociomantic or 
 Dicebot for example).  Modern business has a misplaced emphasis 
 on credentials.  And if you have a large code base it is not 
 like a new guy can just dive in, anyway.  There is a signalling 
 effect at work also, at least for the time being.
+1 /P
Mar 28 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 25 Mar 2015 22:30:10 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 Downplaying other languages makes the D crowd look desperate...
and we are. see for example bug#14035. "typesystem? lolwut, never heard=20 about that thing!" that's why i'd better report bugs directly to Kenji:=20 he is a sane person.=
Mar 25 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 06:05:25 UTC, ketmar wrote:
 On Wed, 25 Mar 2015 22:30:10 +0000, Ola Fosheim Grøstad wrote:

 Downplaying other languages makes the D crowd look desperate...
and we are. see for example bug#14035. "typesystem? lolwut, never heard about that thing!" that's why i'd better report bugs directly to Kenji: he is a sane person.
D most certainly needs stronger typing, not sure why it tries to propagate the weak typing of C. I find myself adding extra template parameters and "explicit" in my C++ code just to get stronger typing. New AoT languages ought to do better than C++. What Go really got right was to have untyped literals. If you combine that with a orthogonal weak-cast operator with pleasant syntax then you have something. Strong explicit typing also makes it possible to overload on return values... Something I really want to see in a C++ replacement language.
Mar 26 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad 
wrote:
 Downplaying other languages makes the D crowd look desperate...
Heh, there were whole sites like phpain (can't find it now) and something similar for C++.
Mar 26 2015
next sibling parent "amber" <swamberan gmail.com> writes:
On Thursday, 26 March 2015 at 10:17:42 UTC, Kagamin wrote:
 On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim 
 Grøstad wrote:
 Downplaying other languages makes the D crowd look desperate...
Heh, there were whole sites like phpain (can't find it now) and something similar for C++.
It happens in the IDE world too. http://www.ihateeclipse.com/ As physics student new to programming I agree with most of the Go comments in the blog. bye, Amber
Mar 26 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 10:17:42 UTC, Kagamin wrote:
 On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim 
 Grøstad wrote:
 Downplaying other languages makes the D crowd look desperate...
Heh, there were whole sites like phpain (can't find it now) and something similar for C++.
The feature set of C++ does cause maintenance issues in real world codebases if you let programmers roam about freely and "redefine" the syntax/semantics. More so than C with it's limited feature set. Are you sure that D does not have similar issues? I have no idea how Go fares, but orthogonal simplicity could be an advantage in real world code bases where you read code other people have written/mutated. What I find interesting is that Python also has a feature set for redefining semantics that should cause C++ like issues. Still, I find most Python libraries I use to be fairly clean and intuitive. Maybe the fact that Python is untyped and non-performance-oriented makes programmers constrain themselves more from producing spaghetti libraries...?
Mar 26 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 26 March 2015 at 11:29:20 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 26 March 2015 at 10:17:42 UTC, Kagamin wrote:
 On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim 
 Grøstad wrote:
 Downplaying other languages makes the D crowd look 
 desperate...
Heh, there were whole sites like phpain (can't find it now) and something similar for C++.
The feature set of C++ does cause maintenance issues in real world codebases if you let programmers roam about freely and "redefine" the syntax/semantics. More so than C with it's limited feature set. Are you sure that D does not have similar issues? I have no idea how Go fares, but orthogonal simplicity could be an advantage in real world code bases where you read code other people have written/mutated. What I find interesting is that Python also has a feature set for redefining semantics that should cause C++ like issues. Still, I find most Python libraries I use to be fairly clean and intuitive. Maybe the fact that Python is untyped and non-performance-oriented makes programmers constrain themselves more from producing spaghetti libraries...?
Further down the road, people will ask for more features in Go, and there will be patches and more patches, until we'll have Go++. This, or they won't get the features and move on to other language. Of course, Google is trying to prevent this by binding as many users as possible right now, so it will be hard to leave. The oldest trick in the IT hat. ... or Google abandons Go! Ha ha ha.
Mar 26 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 12:27:14 UTC, Chris wrote:
 Further down the road, people will ask for more features in Go, 
 and there will be patches and more patches, until we'll have 
 Go++.
Quite possible. Being open source it is quite likely that some outsiders create a go++. I can see that coming when/if they get their runtime up to snuff, it could be a promising starting point for new concurrent GC-based languages. Maybe even a starting point for a D3 language?
 This, or they won't get the features and move on to other 
 language. Of course, Google is trying to prevent this by 
 binding as many users as possible right now, so it will be hard 
 to leave. The oldest trick in the IT hat.

 ... or Google abandons Go! Ha ha ha.
Yeah, I doubt Google care about people leaving Go, or that they have invested all that much in Go. We'll have to keep in mind that they hire 1000s of programmers, spending a few on some experimental programming projects like Go and Dart is probably just reasonable R&D. They also spend R&D on Angular, Polymer, AtScript, the Closure-compiler, and a slew of other projects. As far as I am concerned Google don't back Go until it is fully supported on App Engine.
Mar 26 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 26 March 2015 at 12:37:31 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 26 March 2015 at 12:27:14 UTC, Chris wrote:
 Further down the road, people will ask for more features in 
 Go, and there will be patches and more patches, until we'll 
 have Go++.
Quite possible. Being open source it is quite likely that some outsiders create a go++. I can see that coming when/if they get their runtime up to snuff, it could be a promising starting point for new concurrent GC-based languages. Maybe even a starting point for a D3 language?
 This, or they won't get the features and move on to other 
 language. Of course, Google is trying to prevent this by 
 binding as many users as possible right now, so it will be 
 hard to leave. The oldest trick in the IT hat.

 ... or Google abandons Go! Ha ha ha.
Yeah, I doubt Google care about people leaving Go, or that they have invested all that much in Go. We'll have to keep in mind that they hire 1000s of programmers, spending a few on some experimental programming projects like Go and Dart is probably just reasonable R&D. They also spend R&D on Angular, Polymer, AtScript, the Closure-compiler, and a slew of other projects. As far as I am concerned Google don't back Go until it is fully supported on App Engine.
The Go language aside, I don't trust Google projects. Too many corpses. I have more confidence in community driven things.
Mar 26 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 13:51:32 UTC, Chris wrote:
 The Go language aside, I don't trust Google projects. Too many 
 corpses. I have more confidence in community driven things.
If you can make do with a conglomerate of small things, yes. Python is well suited for that, many small independent bits. I'm ok with Google projects as long as there is a fallback. And there is a fallback for most of the tech they push. (e.g. you can host your own App Engine compatible setup, compile your own Go compiler, etc)
Mar 26 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 26 Mar 2015 12:27:13 +0000, Chris wrote:

 ... or Google abandons Go! Ha ha ha.
they almost did that with Dart, so they have no language to replace Go=20 right now. i think that Go programmers are safe for three or five years.=
Mar 26 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 26 March 2015 at 22:43:06 UTC, ketmar wrote:
 On Thu, 26 Mar 2015 12:27:13 +0000, Chris wrote:

 ... or Google abandons Go! Ha ha ha.
they almost did that with Dart, so they have no language to replace Go right now. i think that Go programmers are safe for three or five years.
average Google product lifespan is something like 4 years.
Mar 26 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 26 March 2015 at 10:17:42 UTC, Kagamin wrote:
 On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim 
 Grøstad wrote:
 Downplaying other languages makes the D crowd look desperate...
Heh, there were whole sites like phpain (can't find it now) and something similar for C++.
Actually http://www.phpsadness.com/
Mar 26 2015
prev sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei 
 Alexandrescu wrote:
 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/

 Andrei
Downplaying other languages makes the D crowd look desperate... Go has stability, is production ready and has an ecosystem with commercial value. D lacks all of these atm...
Not to mention that Go is in GCC for a very long time already... :) I never liked the language much (I think Erlang or Scala are definitely better choices than Go), but it is in a much better shape than D (unless you want to use stable D1).
Mar 27 2015
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu 
wrote:
 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/

 Andrei
As I know Gary is sometimes (often?) on these forums I'll post some critique here. Misrepresenting Go in a comparison with D doesn't reflect well on the D community, so please have a look at the following issues: In the first code example, the Go version returns 1 on failure and 0 on success, while the D version always returns 0. Also, the Go version correctly uses stderr for error messages while the D version uses stdout for everything. In the second example maybe you should print four lists to be equivalent of the Go code. I think it's misrepresentative to shorten the D example by making it do less work.
 auto text   = source.byLine.join.to!(string);
This is not safe as byLine reuses the same buffer for every line. It may or may not work depending on join's implementation. Also, it's idiomatic to omit parantheses when a template argument list consists of a single token: source.byLine.join.to!string;
 With all that said, I honestly think Go’s design a disservice 
 to intelligent programmers.
s/design a disservice/design is a disservice/
 From my experience of using Go it’s just too simple to create 
 useful abstractions.
This sentence is ambiguous and could be taken to mean it's really simple to create useful abstractions in Go. The intended meaning is obvious with context, but it threw me off for a second...
 I guess by now Go programmers reading this will be frothing at 
 the mouth shouting “Your doing it wrong!”.
s/your/you're/ That could be misconstrued as a jab at the intelligence of Go programmers, which I don't think serves your cause.
 Well, there is another way of implementing generic functions 
 and data types, and that is to completely break the type system!
Didn't you just say there was simply no way around it?
 I know object-oriented programming is no silver bullet but it 
 would of been nice to be able to abstract details away into 
 types and provide better encapsulation.
s/would of/would have/ Also, this statement just begs for responses pointing to Go's OOP features. It has both user-defined types and encapsulation features.
Mar 25 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Thursday, 26 March 2015 at 00:19:44 UTC, Jakob Ovrum wrote:
 As I know Gary is sometimes (often?) on these forums I'll post 
 some critique here. Misrepresenting Go in a comparison with D 
 doesn't reflect well on the D community, so please have a look 
 at the following issues:
You describe these as issues forming part of a critique and suggesting the substance of what he wrote is wrong, but are these substantive in the context of a quick blog post (where it is more important to say something generative than to be perfect in its expression). I don't claim to know Go, but is his basic point off the mark?
 In the first code example, the Go version returns 1 on failure 
 and 0 on success, while the D version always returns 0. Also, 
 the Go version correctly uses stderr for error messages while 
 the D version uses stdout for everything.
stderr.writeln(text); return 1; correctness is important, but does this change much?
 In the second example maybe you should print four lists to be 
 equivalent of the Go code. I think it's misrepresentative to 
 shorten the D example by making it do less work.
surely people can see beyond a difference of three lines ? would this change his point?
 auto text   = source.byLine.join.to!(string);
This is not safe as byLine reuses the same buffer for every line. It may or may not work depending on join's implementation. Also, it's idiomatic to omit parantheses when a template argument list consists of a single token: source.byLine.join.to!string;
fair point if true (I will let others who know better say whether .array. or something is needed).
 With all that said, I honestly think Go’s design a disservice 
 to intelligent programmers.
s/design a disservice/design is a disservice/
What he wrote is correct English, and he is an Englishman living in England.
I guess by now Go programmers reading this will be frothing at 
the mouth >>shouting “Your doing it wrong!”.
That could be misconstrued as a jab at the intelligence of Go programmers, which I don't think serves your cause.
Again, nobody English would think this was more than mildly humorous (and by no means insulting). To suggest somebody is rabid is not to insult their intelligence, but merely to tease them about their likely strong emotional reaction. But what is one to do when making the trade-off between being blandly corporate and acceptable to everyone, versus writing with some character and spirit and offending the sensitive. It's a personal choice, but not easy to criticize another for theirs. I personally find the world too bland these days. One cannot police the forms of expression of people who do not speak for a community or claim to be acting as such (apologies if I am mistaken and he does have an official position within D). And perhaps one ought not to try. Laeeth.
Mar 25 2015
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 26 March 2015 at 02:04:26 UTC, Laeeth Isharc wrote:
 You describe these as issues forming part of a critique and 
 suggesting the substance of what he wrote is wrong, but are 
 these substantive in the context of a quick blog post (where it 
 is more important to say something generative than to be 
 perfect in its expression).
The comparison, as-is, is unfair. He writes a long-winded Go snippet (which it turns out is completely unrepresentative of an idiomatic Go solution[1]) then counters it with a short D solution that deceptively does less work. I did not mean to suggest his overall claims are wrong; I strongly agree with him on his main points. The problem is that he's using faulty data to reach that conclusion.
 I don't claim to know Go, but is his basic point off the mark?
At the very least, he's completely misrepresented the difference with the unnaturally long Go snippet[1] and the incomplete D snippet.
    stderr.writeln(text);
    return 1;
 correctness is important, but does this change much?
The size of the code is an essential point in this post. It's probably safe to say most readers can't spot the difference in semantics, which makes Go look disproportionally verbose.
 In the second example maybe you should print four lists to be 
 equivalent of the Go code. I think it's misrepresentative to 
 shorten the D example by making it do less work.
surely people can see beyond a difference of three lines ? would this change his point?
I think it makes a big difference visually.
 fair point if true (I will let others who know better say 
 whether .array. or something is needed).
join and array on byLine both suffer the same problem. Using joiner instead of join would fix it and still allow it to forego copying each line.
 What he wrote is correct English, and he is an Englishman 
 living in England.
Great.
 Again, nobody English would think this was more than mildly 
 humorous (and by no means insulting).  To suggest somebody is 
 rabid is not to insult their intelligence, but merely to tease 
 them about their likely strong emotional reaction.
I wasn't referring to that, I was referring to the grammatical error in the quote.
 But what is one to do when making the trade-off between being 
 blandly corporate and acceptable to everyone, versus writing 
 with some character and spirit and offending the sensitive.  
 It's a personal choice, but not easy to criticize another for 
 theirs.

 I personally find the world too bland these days.  One cannot 
 police the forms of expression of people who do not speak for a 
 community or claim to be acting as such (apologies if I am 
 mistaken and he does have an official position within D).  And 
 perhaps one ought not to try.
I intentionally did not want to criticize his post as a whole, just the methodology employed. The post has been met with a lot of scorn on Reddit, and I think it would help D's case to get the facts right. [1] https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/cpqpfjx
Mar 25 2015
parent reply "lobo" <swamplobo gmail.com> writes:
On Thursday, 26 March 2015 at 02:34:04 UTC, Jakob Ovrum wrote:
 On Thursday, 26 March 2015 at 02:04:26 UTC, Laeeth Isharc wrote:
[snip] It would have been better if several languages were used in comparison to Go. Overall the blog post is a bit immature with little rigor and too much emotion. The code comparisons that aren't idiomatic for either language nor behaviorally equivalent. It reads like a D-zealot had decided to write this blog before they even clicked the download link for the Go compiler. And so, their experience was never going to be anything but negative. That said, Go is unpleasant and probably the most boring language I've had to write code in. bye, lobo
Mar 25 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/25/2015 11:11 PM, lobo wrote:
 Overall the blog post is a bit immature with little rigor and too much
 emotion.
I can't comment on the accuracy of the comparisons, but FWIW, I'd take "immature and emotional" over "dry, corporate and PC" any day. :) Life's too short to be bland.
Mar 26 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Wed, 2015-03-25 at 14:00 -0700, Andrei Alexandrescu via Digitalmars-d-an=
nounce wrote:
 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_=
disservice_to_intelligent/
=20
 Andrei
The reaction in the Go community to this article has been exactly as=20 one would have anticipated. I paraphrase the common theme thus: Go is=20 successful in the market, D isn't, therefore Go is a better language=20 than D. Go does indeed have much greater market penetration, but I=20 leave it as an exercise for the reader to deduce the sophistry, and=20 indeed casuistry, in most of the argumentation. Interestingly, or not, Erlang and Go are bringing better concurrency=20 and parallelism to Java. If there was some design/programming=20 resource, is would be good to revisit D's std.concurrency and=20 std.parallelism, in the light of the fibres stuff, to do something not=20 dissimilar to the Quasar framework so as to provide an integrated=20 actor/dataflow/CSP/data parallelism framework for D. As GPars has=20 shown, trying to do this stuff on volunteer labour alone just doesn't=20 work.=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 26 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 03/26/2015 04:38 AM, Russel Winder via Digitalmars-d-announce wrote:
 I paraphrase the common theme thus:  Go is
 successful in the market, D isn't, therefore Go is a better language
 than D.
I love how Go's very own reasoning there naturally suggests that PHP, C++, and Java must all be vastly superior to Go.
Mar 26 2015
parent Russel Winder via Digitalmars-d-announce writes:
On Thu, 2015-03-26 at 14:37 -0400, Nick Sabalausky via Digitalmars-d-announ=
ce wrote:
 On 03/26/2015 04:38 AM, Russel Winder via Digitalmars-d-announce=20
 wrote:
=20
 I paraphrase the common theme thus:  Go is
 successful in the market, D isn't, therefore Go is a better=20
 language
 than D.
=20 I love how Go's very own reasoning there naturally suggests that=20 PHP,=20 C++, and Java must all be vastly superior to Go.
Did I mention sophistry and casuistry? --=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 26 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 March 2015 at 08:39:14 UTC, Russel Winder wrote:
 On Wed, 2015-03-25 at 14:00 -0700, Andrei Alexandrescu via 
 Digitalmars-d-announce wrote:
 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/
 
 Andrei
The reaction in the Go community to this article has been exactly as one would have anticipated. I paraphrase the common theme thus: Go is successful in the market, D isn't, therefore Go is a better language than D. Go does indeed have much greater market penetration, but I leave it as an exercise for the reader to deduce the sophistry, and indeed casuistry, in most of the argumentation.
By this standard, Go is much worse than C++, Java, or even C, which they pretend to be a better version of.
Mar 27 2015
prev sibling next sibling parent "Israel" <tl12000 live.com> writes:
On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu
wrote:
 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/

 Andrei
Wow this bad, almost like "Shots Fired". Although you can tell hes trying to say something by using a vertical line of imports on go and a horizontal line of imports on D to make it look shorter...
Mar 26 2015
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu 
wrote:
 https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/

 Andrei
If Go community is what they believe they are - intelligent. They would not blame D community for this article, but the person who wrote it. - It is not tagged "Opinion" for no reason !! My personal opinion about the article - people may hate D equally for being "too pragmatic". That `source.byLine.join.to!(string);` line for example, takes much longer time to understand than 20 lines of Go code. Any D newbie with knowledge of some modern language will struggle understanding (and being 100% sure that he/she understands!) that line of D code. I could give a big list of things where Go has advantage over D. What I found pathetic is that Go community used list of established open-source projects done in Go. :) But OK, we expected that, did we?
Mar 27 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 12:48:04 UTC, Dejan Lekic wrote:
 My personal opinion about the article - people may hate D 
 equally for being "too pragmatic". That
Yeah, well, both the D/Go communities use the term "pragmatic" to gloss over underwhelming design issues in D/Go, and makes a point of how D/Go is deliberately not being a research language, yet still claim that D/Go bring novel features... although neither D or Go bring anything new to the table. I.e.just about all the major concepts in D/Go are 30-50 years old... It is mostly a case of inexperienced programmers not knowing PL history becoming fanbois of new languages. Kind of like the OS wars of the 1990s.
Mar 27 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 27 March 2015 at 15:54:31 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 27 March 2015 at 12:48:04 UTC, Dejan Lekic wrote:
 My personal opinion about the article - people may hate D 
 equally for being "too pragmatic". That
Yeah, well, both the D/Go communities use the term "pragmatic" to gloss over underwhelming design issues in D/Go, and makes a point of how D/Go is deliberately not being a research language, yet still claim that D/Go bring novel features... although neither D or Go bring anything new to the table. I.e.just about all the major concepts in D/Go are 30-50 years old...
It need not be new, it needs to be good. That's all. I don't understand this obsession people have with new things, as if they were automatically good only because they are new. Why not try square wheels? Uh, it's new, you know.
 It is mostly a case of inexperienced programmers not knowing PL 
 history becoming fanbois of new languages. Kind of like the OS 
 wars of the 1990s.
Mar 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 16:09:08 UTC, Chris wrote:
 It need not be new, it needs to be good. That's all. I don't 
 understand this obsession people have with new things, as if 
 they were automatically good only because they are new. Why not 
 try square wheels? Uh, it's new, you know.
New things can be cool for a toy language, but not for a production language. The latter needs polish and support (IDE etc). Just pointed out the social dynamics where Go/D communities are not all that different. There's probably a difference between programmers that juggle 5-7 languages and programmers that stick to 1 language: «it is just A tool among many» vs «it is THE tool». I think you see this expressed in both Go and D communities.
Mar 27 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 27 March 2015 at 16:20:28 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 27 March 2015 at 16:09:08 UTC, Chris wrote:
 It need not be new, it needs to be good. That's all. I don't 
 understand this obsession people have with new things, as if 
 they were automatically good only because they are new. Why 
 not try square wheels? Uh, it's new, you know.
New things can be cool for a toy language, but not for a production language. The latter needs polish and support (IDE etc). Just pointed out the social dynamics where Go/D communities are not all that different. There's probably a difference between programmers that juggle 5-7 languages and programmers that stick to 1 language: «it is just A tool among many» vs «it is THE tool». I think you see this expressed in both Go and D communities.
I'd say Go fans are worse in this respect (yes, I know, probably not all of them). People in the D community are here, because they have tried at least 5-7 other languages. Go programmers, if Pike's remarks are anything to go by, are probably less experienced (just left school or college) and are more susceptible to Google's propaganda. I'd say they know not better.
Mar 27 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 27 March 2015 at 16:44:50 UTC, Chris wrote:
 I'd say Go fans are worse in this respect (yes, I know, 
 probably not all of them). People in the D community are here,
But that is just because there is more Go fans... ;)
Mar 28 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 5:48 AM, Dejan Lekic wrote:
 That `source.byLine.join.to!(string);` line for example, takes much
 longer time to understand than 20 lines of Go code. Any D newbie with knowledge
 of some modern language will struggle understanding (and being 100% sure that
 he/she understands!) that line of D code.
This style of programming does take some getting used to for one that is used to traditional loop programming (like me). But it is like learning a new language - once you learn what byLine, join, etc., do, it is pretty simple to see what is happening.
Mar 27 2015
parent reply "w0rp" <devw0rp gmail.com> writes:
On Friday, 27 March 2015 at 19:11:58 UTC, Walter Bright wrote:
 On 3/27/2015 5:48 AM, Dejan Lekic wrote:
 That `source.byLine.join.to!(string);` line for example, takes 
 much
 longer time to understand than 20 lines of Go code. Any D 
 newbie with knowledge
 of some modern language will struggle understanding (and being 
 100% sure that
 he/she understands!) that line of D code.
This style of programming does take some getting used to for one that is used to traditional loop programming (like me). But it is like learning a new language - once you learn what byLine, join, etc., do, it is pretty simple to see what is happening.
Sean Parent's advice for "no raw loops" comes to mind. https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule, basically a one-line body for foreach becomes acceptable. Your own description of component programming was also very good. Also Andrei's description of generic algorithms as being something like the final destination of programming, etc. You start with the same old code you might be used to from other languages, and then slowly learn to write generic code and propose new algorithms.
Mar 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2015 12:34 PM, w0rp wrote:
 Sean Parent's advice for "no raw loops" comes to mind.
 https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule,
 basically a one-line body for foreach becomes acceptable.
This really is a great video. Which leads me to wonder why std.algorithm doesn't have a 'rotate'.
Mar 28 2015
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 28 March 2015 at 20:35:07 UTC, Walter Bright wrote:
 On 3/27/2015 12:34 PM, w0rp wrote:
 Sean Parent's advice for "no raw loops" comes to mind.
 https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning 
 With that rule,
 basically a one-line body for foreach becomes acceptable.
This really is a great video. Which leads me to wonder why std.algorithm doesn't have a 'rotate'.
Three iterator algorithms don't really work well with ranges. We have bringToFront instead, which is more general. http://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront
Mar 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2015 2:01 PM, Peter Alexander wrote:
 On Saturday, 28 March 2015 at 20:35:07 UTC, Walter Bright wrote:
 On 3/27/2015 12:34 PM, w0rp wrote:
 Sean Parent's advice for "no raw loops" comes to mind.
 https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule,
 basically a one-line body for foreach becomes acceptable.
This really is a great video. Which leads me to wonder why std.algorithm doesn't have a 'rotate'.
Three iterator algorithms don't really work well with ranges. We have bringToFront instead, which is more general. http://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront
Thank you. I need to learn std.algorithm better.
Mar 28 2015
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce
wrote:
 Thank you. I need to learn std.algorithm better.
Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. - Jonathan M Davis
Mar 30 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 30 Mar 2015 00:29:46 -0700, Jonathan M Davis via
Digitalmars-d-announce wrote:

 On Saturday, March 28, 2015 14:19:46 Walter Bright via
 Digitalmars-d-announce wrote:
 Thank you. I need to learn std.algorithm better.
=20 Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time.
and those who doesn't (like me) keep finding various gems there. ;-)=
Mar 30 2015
prev sibling next sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Monday, 30 March 2015 at 07:29:56 UTC, Jonathan M Davis wrote:
 On Saturday, March 28, 2015 14:19:46 Walter Bright via 
 Digitalmars-d-announce wrote:
 Thank you. I need to learn std.algorithm better.
Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. - Jonathan M Davis
when this happens, it would be great if the person could post to the group a few lines about it so someone (possibly someone else) can collate into a future series on gems in phobos. maybe give subject some consistent name so it is easy to find them later.
Mar 30 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2015 5:04 AM, Laeeth Isharc wrote:
 when this happens, it would be great if the person could post to the group a
few
 lines about it so someone (possibly someone else) can collate into a future
 series on gems in phobos.  maybe give subject some consistent name so it is
easy
 to find them later.
Even Andrei, who wrote most of std.algorithm, posted here recently how he was surprised at how powerful it was.
Mar 30 2015
parent Russel Winder via Digitalmars-d-announce writes:
On Mon, 2015-03-30 at 11:20 -0700, Walter Bright via Digitalmars-d-announce=
 wrote:
=20
[=E2=80=A6]
 Even Andrei, who wrote most of std.algorithm, posted here recently=20
 how he was=20
 surprised at how powerful it was.
An indicator of plagiarism? ;-) --=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 30 2015
prev sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Monday, 30 March 2015 at 12:04:22 UTC, Laeeth Isharc wrote:
 On Monday, 30 March 2015 at 07:29:56 UTC, Jonathan M Davis 
 wrote:
 On Saturday, March 28, 2015 14:19:46 Walter Bright via 
 Digitalmars-d-announce wrote:
 Thank you. I need to learn std.algorithm better.
Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. - Jonathan M Davis
when this happens, it would be great if the person could post to the group a few lines about it so someone (possibly someone else) can collate into a future series on gems in phobos. maybe give subject some consistent name so it is easy to find them later.
I regularly review std.algorithm just because I'm not used to functional programming, it has so many useful things.
Mar 30 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2015 12:29 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
 On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce
wrote:
 Thank you. I need to learn std.algorithm better.
Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time.
Well put. My brain still thinks in terms of loops.
Mar 30 2015
next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2015-03-30 at 11:19 -0700, Walter Bright via Digitalmars-d-announce=
 wrote:
 [=E2=80=A6]
=20
 My brain still thinks in terms of loops.
The excellent influence of functional programming on imperative=20 programming is implicit iteration and higher-order functions. Any explicit for/while loop in a modern imperative language code=20 should *necessarily* involve a side-effect or it is coded wrongly.=20 Even then it can almost certainly be recast to preserve the side- effect and remove the loop =E2=80=93 unless you are implementing the implic= it=20 iteration function. This has nothing to do with tail recursion optimization and all that=20 Lambda Calculus stuff, this is to do with correct levels of=20 abstraction that allow the tool chain to maximize support for the=20 programmer. Java programmers are having to come to terms with this. Python=20 programmers sort of have, except that BDFL has failed to accept the=20 correct end point and still likes loops. Scala has done it all wrong.=20 (Further opinions available on request :-) --=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 30 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 30 March 2015 at 18:41:17 UTC, Russel Winder wrote:
 On Mon, 2015-03-30 at 11:19 -0700, Walter Bright via 
 Digitalmars-d-announce wrote:
 […]
 
 My brain still thinks in terms of loops.
The excellent influence of functional programming on imperative programming is implicit iteration and higher-order functions. Any explicit for/while loop in a modern imperative language code should *necessarily* involve a side-effect or it is coded wrongly. Even then it can almost certainly be recast to preserve the side- effect and remove the loop – unless you are implementing the implicit iteration function. This has nothing to do with tail recursion optimization and all that Lambda Calculus stuff, this is to do with correct levels of abstraction that allow the tool chain to maximize support for the programmer. Java programmers are having to come to terms with this. Python programmers sort of have, except that BDFL has failed to accept the correct end point and still likes loops. Scala has done it all wrong. (Further opinions available on request :-)
speaking of optimization, are there any guarantees(documented?) on the kind of optimizations you should expect from range programming in D(i.e, function chaining) similar to Haskell's stream fusion?
Mar 30 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2015 11:53 AM, weaselcat wrote:
 speaking of optimization, are there any guarantees(documented?) on the kind of
 optimizations you should expect from range programming in D(i.e, function
 chaining) similar to Haskell's stream fusion?
No. It's a QoI issue.
Mar 30 2015
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2015 11:41 AM, Russel Winder via Digitalmars-d-announce wrote:
 Java programmers are having to come to terms with this. Python
 programmers sort of have, except that BDFL has failed to accept the
 correct end point and still likes loops. Scala has done it all wrong.
 (Further opinions available on request :-)
I always enjoy your posts, Russel! ... opinionated posts backed by experience.
Mar 30 2015
prev sibling parent "Bienlein" <jeti789 web.de> writes:
Java programmers are having to come to terms with this. Python 
programmers sort of have, except that BDFL has failed to accept 
the correct end point and still likes loops. Scala has done it 
all wrong. (Further opinions available on request :-)
Could you provide some sample Scala code to demonstrate what you mean? Just because it is not clear to me what this is about. Thanks.
Mar 31 2015
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Monday, 30 March 2015 at 18:20:39 UTC, Walter Bright wrote:
 Well put.

 My brain still thinks in terms of loops.
Sadly, mine also... ;-P
Mar 31 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/30/15 12:29 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
 On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce
wrote:
 Thank you. I need to learn std.algorithm better.
Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time.
Then we need more examples and tutorials. -- Andrei
Mar 30 2015
parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Tuesday, 31 March 2015 at 02:05:05 UTC, Andrei Alexandrescu 
wrote:
 On 3/30/15 12:29 AM, Jonathan M Davis via 
 Digitalmars-d-announce wrote:
 On Saturday, March 28, 2015 14:19:46 Walter Bright via 
 Digitalmars-d-announce wrote:
 Thank you. I need to learn std.algorithm better.
Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time.
Then we need more examples and tutorials. -- Andrei
how are these to appear?
Mar 31 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/31/15 1:19 AM, Laeeth Isharc wrote:
 On Tuesday, 31 March 2015 at 02:05:05 UTC, Andrei Alexandrescu wrote:
 On 3/30/15 12:29 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
 On Saturday, March 28, 2015 14:19:46 Walter Bright via
 Digitalmars-d-announce wrote:
 Thank you. I need to learn std.algorithm better.
Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time.
Then we need more examples and tutorials. -- Andrei
how are these to appear?
I've offered a number of times to write a slides-like tutorial if anyone wants to do the slides logic. Nobody came about. Probably nobody will, so I'll have to do it myself. It's also disheartening that people in our community say "Except for one function, std.algorithm does not allocate memory", or "RefCounted works with classes, it just hasn't been implemented yet", however nobody actually fixes these things (not to mention "file reading by line is slow" which has been fixed after having been wrongly characterized as a fundamental cstdlib issue). This has been going on for YEARS. Only a handful of contributors actually do such work, a lot of which is trivial; everybody else seems content to just talk about it and wait for handouts. We need to do better at empowering people. Andrei
Mar 31 2015
next sibling parent "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> writes:
On Tuesday, 31 March 2015 at 08:35:47 UTC, Andrei Alexandrescu 
wrote:
 I've offered a number of times to write a slides-like tutorial 
 if anyone wants to do the slides logic. Nobody came about. 
 Probably nobody will, so I'll have to do it myself.
What do you mean by "slides logic"? What are you aiming for? (I missed your earlier posts on that, sorry.) In any case, if this is a "you do the content, someone else does the mundane" kind of offer, I am all ears. I'd like to help, I'd like to learn and I am not able to do the content myself.
Mar 31 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 31 Mar 2015 01:35:47 -0700, Andrei Alexandrescu wrote:

 We need to do better at empowering people.
it's fairly easy: just pay them for the tasks. most people using D to solve *their* task at hand, and if they see=20 something wrong, they report it as an issue (sometimes) and go on with=20 their task, designing workarounds. there is no way you can force people=20 to drop their tasks and do something different. only sometimes, when they=20 continuously hit by something in Phobos, they writing patches. yet that=20 patches will not be widely available until the next compiler release,=20 which means that if people plan to publish their code, they *have* to=20 write workarounds anyway. and if there is workaround written, there is=20 less motivation to write a patch that fixes the thing. for GNU/Linux everything is even worse, as DMD cannot be included in=20 repositories as free software (it isn't), so we have GDC/LDC, which are=20 much slower with releases, and much slower with repo updates. what *can* help here is free DMD (in FSF definition) and monthly=20 releases. this is not a silver bullet, but it's easier to convince=20 maintainers of various distributives to work on free compiler.=
Mar 31 2015
prev sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
 Then we need more examples and tutorials. -- Andrei
how are these to appear?
I've offered a number of times to write a slides-like tutorial if anyone wants to do the slides logic. Nobody came about. Probably nobody will, so I'll have to do it myself.
Sorry for my denseness, but what is 'slides logic'? What I had in mind was that big projects that are not intrinsically gratifying can be too much to undertake in one bite. So how about we just agree something like 'email p0nce' (if he is willing - he seems to be good at it) when one comes across something cool - like a way to make use of std.algorithm (as several people have mentioned keeps happening) so he can collect them and write them up when there is time. Or someone else, if p0nce cannot or does not wish to do it. I bet that one could find quite a few useful examples just grepping thru one's own code/searching on github.
 It's also disheartening that people in our community say 
 "Except for one function, std.algorithm does not allocate 
 memory"
Umm that was me... I don't feel confident enough to write at a Phobos standard yet and might be a little while before I am experienced enough. But I see your point. I reckon people do want to help, but don't know how. If I do a search for priorities on the wiki, only the roadmap comes up. I started this page as a placeholder: http://wiki.dlang.org/How_You_Can_Help Laeeth.
Mar 31 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/31/15 3:40 AM, Laeeth Isharc wrote:
 Then we need more examples and tutorials. -- Andrei
how are these to appear?
I've offered a number of times to write a slides-like tutorial if anyone wants to do the slides logic. Nobody came about. Probably nobody will, so I'll have to do it myself.
Sorry for my denseness, but what is 'slides logic'?
E.g. http://tour.golang.org/welcome/1
 What I had in mind was that big projects that are not
 intrinsically gratifying can be too much to undertake in one
 bite.  So how about we just agree something like 'email p0nce'
 (if he is willing - he seems to be good at it) when one comes
 across something cool - like a way to make use of std.algorithm
 (as several people have mentioned keeps happening) so he can
 collect them and write them up when there is time.  Or someone
 else, if p0nce cannot or does not wish to do it.

 I bet that one could find quite a few useful examples just
 grepping thru one's own code/searching on github.

 It's also disheartening that people in our community say "Except for
 one function, std.algorithm does not allocate memory"
Umm that was me... I don't feel confident enough to write at a Phobos standard yet and might be a little while before I am experienced enough. But I see your point.
No worries, it's the pattern not the person. Walter mentioned that as well. It gets mentioned often.
 I reckon people do want to help, but don't know how.  If I do a
 search for priorities on the wiki, only the roadmap comes up.

 I started this page as a placeholder:
 http://wiki.dlang.org/How_You_Can_Help
Great, thanks! Andrei
Mar 31 2015
prev sibling parent "Panke" <tobias pankrath.net> writes:
 Umm that was me...  I don't feel confident enough to write at a
 Phobos standard yet and might be a little while before I am
 experienced enough.  But I see your point.
Fastest way to get better is to submit PRs and get reviewed.
Mar 31 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 27 Mar 2015 12:48:03 +0000, Dejan Lekic wrote:

 That `source.byLine.join.to!(string);`
 line for example, takes...
...almost no time to understand. it's a simple composition, the thing=20 they should learn on their CS courses, along with lambda calculus (or=20 "functional programming", if you want).=
Mar 27 2015