Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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. > > 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. ;-) signature.asc Description: PGP signature
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: dsq-1: open-source software synthesizer
On Monday, 30 March 2015 at 06:26:00 UTC, ketmar wrote: On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote: On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. O_O Hey hey hey, context matters! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see "std.license.compare" in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have. what i really want to have is "libdub". i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) +1 E.g. using libdub in my project DlangIDE would be much easy than command line interface.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: DDT 0.11.0 released
Is there an easy trick to run/debug unittests? I found the dialog to add additional options for dub, but it always executes "dub build" Copying the failing unittest into main() works, but I'd prefer another solution :) My current workaround is to run "dub --test" from the Linux terminal. Dub compiles the tests and runs them (the second is unnecessary but does not matter because tests are fast enough). After that I can click debug in Eclipse and use the nice debug support.
Re: This Week in D #11: new release, undocumented feature exposed, FAQ answered, DConf schedule posted.
On 3/29/15 10:35 PM, weaselcat wrote: On Monday, 30 March 2015 at 01:14:59 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/mar-29.html The big pieces have already been posted to Reddit, so idk if we want to post again, but if you want to, go ahead and just post the reddit link here too as this is a nice little roundup. I also took the opportunity to document the new ddoc `code` feature! I think reddit is starting to act unfriendly to frequent D posts now, this week in D maybe shouldn't be cross-posted there so much. Really? Please, let's drop the dependency on reddit for street cred or affirmation. I'm sick of it. If a user on reddit doesn't like D, then that is their problem. Besides, nobody here is in charge of whether reddit can have posts on D or not. -Steve
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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 :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Mon, 2015-03-30 at 11:20 -0700, Walter Bright via Digitalmars-d-announce wrote: > […] > Even Andrei, who wrote most of std.algorithm, posted here recently > how he was > surprised at how powerful it was. An indicator of plagiarism? ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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?
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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