www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D popularity

reply "SaltySugar" <Butkustomas777 gmail.com> writes:
Why it isn't popular?  We must popularize it. There aren't any 
tutorials with D, books and other stuff. How about writing a D 
programming forum?
Jan 20 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any 
 tutorials with D, books and other stuff.
http://www.amazon.com/exec/obidos/ASIN/0321635361/classicempire http://ddili.org/ders/d.en/index.html
 How about writing a D programming forum?
http://forum.dlang.org/
Jan 20 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 20 January 2013 at 10:01:36 UTC, deadalnix wrote:
 On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:

 How about writing a D programming forum?
http://forum.dlang.org/
I think he is aware of this forum because he appears to post the message via it.
Jan 20 2013
parent reply David <d dav1d.de> writes:
Am 20.01.2013 12:10, schrieb Maxim Fomin:
 On Sunday, 20 January 2013 at 10:01:36 UTC, deadalnix wrote:
 On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:

 How about writing a D programming forum?
http://forum.dlang.org/
I think he is aware of this forum because he appears to post the message via it.
I am not using the forum, but still sending messages. You can send messages directly via a NNTP client, you don't have to use the forum, so it's definitly possible he doesn't know of it.
Jan 20 2013
parent d coder <dlang.coder gmail.com> writes:
On Sun, Jan 20, 2013 at 6:21 PM, David <d dav1d.de> wrote:

 I am not using the forum, but still sending messages. You can send
 messages directly via a NNTP client, you don't have to use the forum, so
 it's definitly possible he doesn't know of it.
David, that can be guessed on basis of the email headers. And the OP does appear to have used dlang forum. Regards - Puneet
Jan 20 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any 
 tutorials with D, books and other stuff. How about writing a D 
 programming forum?
It is unpopular because some problems are still not solved (linking, dynamic libraries, IDEs, some compiler internals - 64 ABI, corrupting memory lambdas, nested struct crashes, debugging, win32 COFF, third-party libraries, etc.) and because many are satisfied with languages they are using.
Jan 20 2013
prev sibling next sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any 
 tutorials with D, books and other stuff. How about writing a D 
 programming forum?
I think it is on its way there though. There is the excellent book that Andrei wrote which will give a most useful insight on the language. I have heard of D from a coworker but was uninterested in learning a new language at the time (and there might be many others in that situation). I use D now because I started a new project and D fitted my needs perfectly. I think D shines when people start looking for a new language, especially as a C/C++ (IMHO) replacement. As more and more will, the more popular D will become. As you know, those languages C/C++ are probably the most used languages worldwide (I am not saying not other rivals them) and in companies. Therefore, people who use it tend to use it for good reasons (legacy code compatibility, maturity of tools/compilers, efficient code generation, low memory consumption, etc...), and their minds will be hard to change, unless a smooth transition is guaranteed. I think that new projects/research are the bread and butter of D at that time. One of its most attracting advantage for someone working with legacy code is that it easily binds to C (so a HUGE code base and native os APIs), so I believe D really has a chance at becoming widely used. It is true however that, as you learn to love your new language (D), you will also find out that some issues haven't been ironed out yet (for the reference compiler for example, as someone mentioned), and that can be a deal breaker for some. Those of us that still uses it must find that its goodies outweighs its drawbacks: drawbacks which I think are for the most part UNRELATED to the language itself. Personally, I believe that D is slowly but surely making its place as a viable, more powerful alternative to C++( ( ++C)++ ).
Jan 20 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 20 January 2013 at 14:31:25 UTC, Phil Lavoie wrote:
 On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any 
 tutorials with D, books and other stuff. How about writing a D 
 programming forum?
 I have heard of D from a coworker but was uninterested in 
 learning a new language at the time (and there might be many 
 others in that situation). I use D now because I started a new 
 project and D fitted my needs perfectly.

 I think D shines when people start looking for a new language, 
 especially as a C/C++ (IMHO) replacement. As more and more 
 will, the more popular D will become.

 As you know, those languages C/C++ are probably the most used 
 languages worldwide (I am not saying not other rivals them) and 
 in companies. Therefore, people who use it tend to use it for 
 good reasons (legacy code compatibility, maturity of 
 tools/compilers, efficient code generation, low memory 
 consumption, etc...), and their minds will be hard to change, 
 unless a smooth transition is guaranteed.
The standard library needs to be complete/reliable as well along with everything needed for parallel processing. An obvious need and interest is also present to have libraries/features not rely on the GC (in places where there is no GC); Meaning likely only the replaced functions (that needed the GC) need be re-written. Perhaps naming it like std.nogc.stdio for clarity; Naturally anything in std.stdio will be forwarded through the nogc so transition is invisible API-wise. I'm sure once the library & compiler & language are fully fixed and ready that D will become very very popular. C++ will never stop being used (embedded systems, games that they need every cycle and can't risk switching languages), but it's ugliness and issues can be reduced, maybe even replaced as the standard language some day.
Jan 20 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any 
 tutorials with D, books and other stuff. How about writing a D 
 programming forum?
I don't think the problem is purely a technical one as some may be suggesting. For example, even if all the technical issues were resolved, I doubt usage will increase much faster than they currently are. It won't hurt to make things 100% production ready, but I doubt that's the biggest hurdle to overcome. With mountains of investment in existing C/C++ infrastructure, who is going to make the leap to D? The cost of switching must be far less than the cost of not switching. I also figure a lot of people remain perfectly content with C/C++, and will never consider changing to something else simply because they don't have a significant enough reason to look for a better alternative. Even if there are a lot of dissatisfied C/C++ programmers, I bet most of them don't even know that there's a viable alternative. As far as I know, aside from D, there's nothing else that can replace C/C++, except maybe Rust, but it's still an experiment not suitable for production use, so the perception may be that using C/C++ is the only choice you have. One possible way to get programmers to at least begin considering D, is to expose them to D through useful applications that are written in D that can be interfaced directly to C/C++. D has a compatible ABI, but in this case there is a technical problem to overcome, and it's with D's inability to support dynamic linking fully. If we're to develop tactics for popularizing D, we have to consider more than technical issues, and when considering technical issues, we have to carefully choose the problem areas that are likely to matter the most. Unfortunately, we don't have a coordinated action plan, and everything proceeds in a more or less random way. So I'd say improving the way D is developed through better coordination is the best way to achieve more rapid progress. For those who prefer random chaos to guide the way, nothing stops that from continuing, you can have both an organized system in place, and a chaotic one at the same time. --rt
Jan 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 02:00:12 +0100
"Rob T" <alanb ucora.com> wrote:

 On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any 
 tutorials with D, books and other stuff. How about writing a D 
 programming forum?
I don't think the problem is purely a technical one as some may be suggesting. For example, even if all the technical issues were resolved, I doubt usage will increase much faster than they currently are. It won't hurt to make things 100% production ready, but I doubt that's the biggest hurdle to overcome. With mountains of investment in existing C/C++ infrastructure, who is going to make the leap to D? The cost of switching must be far less than the cost of not switching.
D does continue to face an uphill battle for mindshare: These days, most people who write code prefer to use languages that accept ANY grammatically-correct code and deliberately remain silent about all mechanically-checkable problems they can possibly ignore. Apparently this is because they prefer to manually write extra unittests so that only a subset of these errors are actually guaranteed to get caught (if there's any guarantee at all). I'm not joking: I genuinely wouldn't be surprised if the next popular "advancement" in computer languages involves a way for compilers to stay silent about all grammatical errors as well as the semantic errors they already ignore *by design*. As bizarre and tongue-in-cheek as all that sounds, most programmers these days actually *DO* consider that to be vastly superior. (The thought that large numbers programmers can be that stupid is something I genuinely find disturbing.) If I were a savvy businessman (read: no ethical fiber), I would manufacture a line of fire alarms advertised as being 100% silent, and therefore less bothersome and less inconvenient than the "old" kind, and sell them exclusively to programmers. As long as I remember to refer to the non-silent alarms as "old", and point out how convenient and productive it is to not be bothered by pesky fire-alarm sirens, I'd be guaranteed to make millions off of these short-sighted suckers^H^H^H^H^H^H^Hprogrammers. (I just threw up a little in my mouth at calling them "programmers", but well, *technically* that's what they...sort of...are.) A roundabout way to say it, but I guess the point I started out trying to make is this: The popularity of dynamic/interpreted/sandboxed/etc languages *is* IMO one of the more significant roadblocks in the way of D popularity. Silent fire alarms are what's hip, and here we are peddling an old-fashioned sounds-and-lights fire alarm. We're pragmatic instead of cool.
Jan 20 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
 D does continue to face an uphill battle for mindshare: These days,
 most people who write code prefer to use languages that accept ANY
 grammatically-correct code and deliberately remain silent about all
 mechanically-checkable problems they can possibly ignore. Apparently
 this is because they prefer to manually write extra unittests so that
 only a subset of these errors are actually guaranteed to get caught
 (if there's any guarantee at all).
In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are. I suspect that the main problem with folks wanting the compiler to just accept stuff is that too many of those folks started with scripting languages where you don't have compilation errors, because you don't compile anything. - Jonathan M Davis
Jan 20 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Monday, 21 January 2013 at 07:20:59 UTC, Jonathan M Davis 
wrote:
 On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
 D does continue to face an uphill battle for mindshare: These 
 days,
 most people who write code prefer to use languages that accept 
 ANY
 grammatically-correct code and deliberately remain silent 
 about all
 mechanically-checkable problems they can possibly ignore. 
 Apparently
 this is because they prefer to manually write extra unittests 
 so that
 only a subset of these errors are actually guaranteed to get 
 caught
 (if there's any guarantee at all).
In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are. I suspect that the main problem with folks wanting the compiler to just accept stuff is that too many of those folks started with scripting languages where you don't have compilation errors, because you don't compile anything. - Jonathan M Davis
If the goal is to increase the popularity of D, and if people prefer scripted languages over compiled, then a good place to start is to create an interpreter for D, thus allowing it to be used as a scripted language, and also retain the ability to be compiled for optimal performance. This will _not_ cheapen D, it will strengthen it, because I can see plenty of serious programmers using the interpreter for faster coding. Later the code can be compiled once the job is done or needs to be tested in compiled form. There are also perfectly sane use cases for having the ability to embed an interpreter directly into an application. If we can determine what will help move D towards greater adoption, and then prioritize what needs to be done to make it happen, then we'll move forward faster than just randomly bumping around. --rt
Jan 20 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 21, 2013 08:52:23 Rob T wrote:
 If the goal is to increase the popularity of D, and if people
 prefer scripted languages over compiled, then a good place to
 start is to create an interpreter for D, thus allowing it to be
 used as a scripted language, and also retain the ability to be
 compiled for optimal performance.
You can already do that. Assuming that dmd is installed in the right place, then run it. It'll be compiled and run. It's not interpreted, strictly speaking, but given how fast D compiles and how fast D code runs once it's been compiled, it'll be plenty fast. - Jonathan M Davis
Jan 21 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 08:09:45 UTC, Jonathan M Davis 
wrote:
 On Monday, January 21, 2013 08:52:23 Rob T wrote:
 You can already do that. Assuming that dmd is installed in the 
 right place,

 top of it, and
 then run it. It'll be compiled and run. It's not interpreted, 
 strictly
 speaking, but given how fast D compiles and how fast D code 
 runs once it's
 been compiled, it'll be plenty fast.
I have been always curious how the debugging occurs in that case? You need to go through gdb? Then, this is a real difference wrt an interpreted language, where the interpreter can be used interactively to examine variables in a given state. D "script" seems to not allow that.
Jan 21 2013
parent "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 14:12:30 UTC, eles wrote:
 On Monday, 21 January 2013 at 08:09:45 UTC, Jonathan M Davis 
 wrote:
 On Monday, January 21, 2013 08:52:23 Rob T wrote:
I have been always curious how the debugging occurs in that case? You need to go through gdb? Then, this is a real difference wrt an interpreted language, where the interpreter can be used interactively to examine variables in a given state.
And step-by-step execution.
Jan 21 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
On Monday, 21 January 2013 at 08:09:45 UTC, Jonathan M Davis 
wrote:
 On Monday, January 21, 2013 08:52:23 Rob T wrote:
 If the goal is to increase the popularity of D, and if people
 prefer scripted languages over compiled, then a good place to
 start is to create an interpreter for D, thus allowing it to be
 used as a scripted language, and also retain the ability to be
 compiled for optimal performance.
You can already do that. Assuming that dmd is installed in the right place, top of it, and then run it. It'll be compiled and run. It's not interpreted, strictly speaking, but given how fast D compiles and how fast D code runs once it's been compiled, it'll be plenty fast. - Jonathan M Davis
Yes that kind of thing works well in some situations, but there's more required than that. For example, there are situations where you want to make a change to a component of a large application without stopping the entire application. Also there are situations where an embedded interpreter is critical to the success of the application. I think that D almost gets it right, it's close and it does many things very well, but it still falls short in terms of meeting all of the major advantages of a scripted language. --rt
Jan 21 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 21:02:49 +0100
"Rob T" <alanb ucora.com> wrote:

 On Monday, 21 January 2013 at 08:09:45 UTC, Jonathan M Davis 
 wrote:
 On Monday, January 21, 2013 08:52:23 Rob T wrote:
 If the goal is to increase the popularity of D, and if people
 prefer scripted languages over compiled, then a good place to
 start is to create an interpreter for D, thus allowing it to be
 used as a scripted language, and also retain the ability to be
 compiled for optimal performance.
You can already do that. Assuming that dmd is installed in the right place, top of it, and then run it. It'll be compiled and run. It's not interpreted, strictly speaking, but given how fast D compiles and how fast D code runs once it's been compiled, it'll be plenty fast. - Jonathan M Davis
Yes that kind of thing works well in some situations, but there's more required than that. For example, there are situations where you want to make a change to a component of a large application without stopping the entire application. Also there are situations where an embedded interpreter is critical to the success of the application.
That's what will be great about having good dynamic lib support - once we get good dynamic lib support: void reloadScriptD() { if(system("rdmd -make-dll myScript.d") == Success!) { auto persistentState = myScriptModule.getPersistentState(); myScriptModule.unload(); myScriptModule = load("myScript.(dll|s)"); myScriptModule.init(persistentState); } } Fucking awesome :) I look forward to being able to do that (without worrying about whatever shared lib issues I know exist but don't really understand). In fact, didn't Quake 2 do something like that, just without actually invoking the compiler? (Or using a language that compiles fast.) Having a service-based D compiler would be even more awesome: Ie, Kinda like how the fancier IDE's do incremental compilation, but generalized out for more than just IDEs to use.
 I think that D almost gets it right, it's close and it does many 
 things very well, but it still falls short in terms of meeting 
 all of the major advantages of a scripted language.
 
I, reluctantly, have to agree. For shell-scripting sorts of things, I think D's already a very nice alternative to bash/batch/etc despite some rough edges (Knowing that a D compiler, of the right version, is properly set up in a standard way on the target machine, and actually getting the new std.process...eventually), but for individual programs that include scriptability features I wouldn't feel comfortable trying it until D dynamic libs are considered much more mature. But note that these are all basically toolchain issues, and not actual language issues. They're *certainly* not issues with D being static-typed or native-compiled.
Jan 21 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 07:20:59 UTC, Jonathan M Davis 
wrote:
 On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
 D does continue to face an uphill battle for mindshare: These 
 days,
 most people who write code prefer to use languages that accept 
 ANY
 grammatically-correct code and deliberately remain silent 
 about all
 mechanically-checkable problems they can possibly ignore. 
 Apparently
 this is because they prefer to manually write extra unittests 
 so that
 only a subset of these errors are actually guaranteed to get 
 caught
 (if there's any guarantee at all).
In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are. I suspect that the main problem with folks wanting the compiler to just accept stuff is that too many of those folks started with scripting languages where you don't have compilation errors, because you don't compile anything. - Jonathan M Davis
We move from ruby on rail to Node.js for scalability reasons !!!!!!
Jan 21 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 21 January 2013 at 08:55:00 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 07:20:59 UTC, Jonathan M Davis 
 wrote:
 On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
 D does continue to face an uphill battle for mindshare: These 
 days,
 most people who write code prefer to use languages that 
 accept ANY
 grammatically-correct code and deliberately remain silent 
 about all
 mechanically-checkable problems they can possibly ignore. 
 Apparently
 this is because they prefer to manually write extra unittests 
 so that
 only a subset of these errors are actually guaranteed to get 
 caught
 (if there's any guarantee at all).
In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are. I suspect that the main problem with folks wanting the compiler to just accept stuff is that too many of those folks started with scripting languages where you don't have compilation errors, because you don't compile anything. - Jonathan M Davis
We move from ruby on rail to Node.js for scalability reasons !!!!!!
I always laugh when I read such things. Back in 1999, I was doing web development in our own TCL Apache module, with a developed in-house framework (C/TCL), which was quite similar to Rails 1.0. Around 2002, we started to migrate to C++/.NET (at the time only available to Microsoft partner companies like ours), because of scalability issues. What this taught us is that if you want to really scale, only compiled languages will do a proper job. Yet people seem not to learn from history. -- Paulo
Jan 21 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 09:48:46 UTC, Paulo Pinto wrote:
 On Monday, 21 January 2013 at 08:55:00 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 07:20:59 UTC, Jonathan M Davis 
 wrote:
 On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
 D does continue to face an uphill battle for mindshare: 
 These days,
 most people who write code prefer to use languages that 
 accept ANY
 grammatically-correct code and deliberately remain silent 
 about all
 mechanically-checkable problems they can possibly ignore. 
 Apparently
 this is because they prefer to manually write extra 
 unittests so that
 only a subset of these errors are actually guaranteed to get 
 caught
 (if there's any guarantee at all).
In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are. I suspect that the main problem with folks wanting the compiler to just accept stuff is that too many of those folks started with scripting languages where you don't have compilation errors, because you don't compile anything. - Jonathan M Davis
We move from ruby on rail to Node.js for scalability reasons !!!!!!
I always laugh when I read such things. Back in 1999, I was doing web development in our own TCL Apache module, with a developed in-house framework (C/TCL), which was quite similar to Rails 1.0. Around 2002, we started to migrate to C++/.NET (at the time only available to Microsoft partner companies like ours), because of scalability issues. What this taught us is that if you want to really scale, only compiled languages will do a proper job. Yet people seem not to learn from history.
So I tested tweeting that with a #facepalm hashtag. I got some ruby on rail people following me now. That makes me really sad.
Jan 21 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 09:54:59 +0100
"deadalnix" <deadalnix gmail.com> wrote:
 
 We move from ruby on rail to Node.js for scalability reasons 
 !!!!!!
I take it this "scalability reason" is to avoid scalability? You should to read Ted Dziuba's "Node.js is Cancer", he explains it better than I can: (He's destroyed all his good older posts, but I managed to save this one from a cache:) https://semitwist.com/mirror/node-js-is-cancer.html
Jan 21 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 13:27:48 -0500
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Mon, 21 Jan 2013 09:54:59 +0100
 "deadalnix" <deadalnix gmail.com> wrote:
 
 We move from ruby on rail to Node.js for scalability reasons 
 !!!!!!
I take it this "scalability reason" is to avoid scalability? You should to read Ted Dziuba's "Node.js is Cancer", he explains it better than I can: (He's destroyed all his good older posts, but I managed to save this one from a cache:) https://semitwist.com/mirror/node-js-is-cancer.html
Also, FWIW, while most of that sounds like it would also apply to Vibe.d, it's drastically mitigated in Vibe.d's case because: A. Unlike Node.js, Vibe.d I/O will automatically trigger a fiber switch to a different request while the I/O, purely behind the scenes, completes asynchronously. B. Vibe.d uses a real language instead of requiring your server to be written in a toy language that thinks it's ok to force every f* ^ing variable in a "scalable" program to be an associative array of Variants, whether they need to be or not. The *one* thing in that guy's article that I admit I don't really buy is the complaint about it being non-Unixy. Yea, "The Unix Way" is certainly very good, but when it means shuffling every damn request on a highly "scalable" server between separate processes, I think it's perfectly reasonable to bend the rules a bit and not be religious about the Unix Scripture.
Jan 21 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 01:47:44PM -0500, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 13:27:48 -0500
 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
[...]
 You should to read Ted Dziuba's "Node.js is Cancer", he explains it
 better than I can: (He's destroyed all his good older posts, but I
 managed to save this one from a cache:)
 https://semitwist.com/mirror/node-js-is-cancer.html
 
Also, FWIW, while most of that sounds like it would also apply to Vibe.d, it's drastically mitigated in Vibe.d's case because: A. Unlike Node.js, Vibe.d I/O will automatically trigger a fiber switch to a different request while the I/O, purely behind the scenes, completes asynchronously. B. Vibe.d uses a real language instead of requiring your server to be written in a toy language that thinks it's ok to force every f* ^ing variable in a "scalable" program to be an associative array of Variants, whether they need to be or not.
[...] Yeah, I remember when I was young and foolish, and believed for a short moment the hype about "dynamic typing" languages. I quickly discovered that dynamic typing is about the worst plague ever to befall the programming world as soon as you do anything more than trivial textbook examples. You have to be constantly vigilant of what types are being passed around in those variables, because they *might* just happen to be a string where you expected an int, or an int where you expected an object! So much code comes crashing down as soon as you hand it a variable of the wrong type -- which the language explicitly allows you to, and in fact, which is the language's selling point in the first place! So as soon as you move beyond trivial toy programs into real-world applications, you start feeling the need -- the desperate need -- to vet each and every single variable passed into your code for their type, and worse, the exact fields present in an object type, because so much code depends on variables being, uh, of specific, non-varying types? It's either that, or constantly checking if something is equal to NULL, or sorry, I mean, ===NULL (as opposed to ==NULL or =NULL or <>NULL or ====NULL or whatever stupid UFO operator it is nowadays that they use to patch a type system on top of a broken language). And you quickly find yourself reimplementing a type system on top of the language, which *should have provided one in the first place*. This article cinched it for me: http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ (Summary for the tl;dr people: dynamic languages == static languages straitjacketed with only a single type.) To conclude, I have to say that so far, the number of times I've actually *needed* to use a Variant type in my entire career is 1 (out of the hundreds if not thousands of programs I've written). And that one time was when I was writing an interpreter for a DSL. How many interpreters are written in Javascript? I rest my case. :) T -- Let's eat some disquits while we format the biskettes.
Jan 21 2013
next sibling parent "Rob T" <alanb ucora.com> writes:
On Monday, 21 January 2013 at 19:24:10 UTC, H. S. Teoh wrote:
 Yeah, I remember when I was young and foolish, and believed for 
 a short
 moment the hype about "dynamic typing" languages. I quickly 
 discovered
 that dynamic typing is about the worst plague ever to befall the
 programming world as soon as you do anything more than trivial 
 textbook
 examples. You have to be constantly vigilant of what types are 
 being
 passed around in those variables, because they *might* just 
 happen to be
 a string where you expected an int, or an int where you 
 expected an
 object! So much code comes crashing down as soon as you hand it 
 a
 variable of the wrong type -- which the language explicitly 
 allows you
 to, and in fact, which is the language's selling point in the 
 first
 place!
True, however there are legitimate situations where dynamic types are essential. Fortunately in D, you can use std.variant or write your own improved version which is relatively easy to do in D (easier than most static typed languages). What I see going on in here, is we're being far too quick to bash scripted languages without understanding why so many people enjoy using them. You can point out all of the problems, but there are also plenty of good points. D can be made to operate with all of the advantages of a scripted language, and simultaneously be a compiled language. It almost does get it already, it's just missing a few key items, and those items won't ever materialize unless we change our attitudes. --rt
Jan 21 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 11:22:19 -0800
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Mon, Jan 21, 2013 at 01:47:44PM -0500, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 13:27:48 -0500
 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
[...]
 You should to read Ted Dziuba's "Node.js is Cancer", he explains
 it better than I can: (He's destroyed all his good older posts,
 but I managed to save this one from a cache:)
 https://semitwist.com/mirror/node-js-is-cancer.html
 
Also, FWIW, while most of that sounds like it would also apply to Vibe.d, it's drastically mitigated in Vibe.d's case because: A. Unlike Node.js, Vibe.d I/O will automatically trigger a fiber switch to a different request while the I/O, purely behind the scenes, completes asynchronously. B. Vibe.d uses a real language instead of requiring your server to be written in a toy language that thinks it's ok to force every f* ^ing variable in a "scalable" program to be an associative array of Variants, whether they need to be or not.
[...] Yeah, I remember when I was young and foolish, and believed for a short moment the hype about "dynamic typing" languages.
Yup. It's *inherently* slow and resource-intensive to execute no matter how well optimized[1], and (contrary to popular belief) it's ALSO slow to write since you spend half the time debugging the "bugs" that a grown-ups language would have caught and pointed out instantly[2]. And it's inherently bug-prone. [1] https://semitwist.com/articles/article/view/quake-shows-javascript-is-slow-not-fast [2] https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really Granted, there are many dynamic coders who *don't* spend half their time debugging statically-checkable things, but I guarantee those are the same people writing all those Python scripts that blow up immediately with a Traceback (ie Literally at least half of the Python-written software I've ever tried to use). So, it's slower and more bloated to execute, slower to write, and bug-riddled. So there's literally no benefit. The *claim* is that the benefits of dynamic are: A. Faster development: But this is a load of crap because the only non-superhuman way to prevent it from being riddled with bugs is to (remember to) manually perform or otherwise reimplement the work that a real compiler would have done automatically. B. Easier for non-programmers to use: But non-programmers should NEVER be writing production code, PERIOD. That's like a car manufacturer having their accountants and graphic designers designing the mechanical parts: Yea great f&^ ing idea... C. More powerful features, more safety, and simpler code: D proves this is bullshit. Heck, damn near any static language that isn't C++ or Java proves this is bullshit. But people think "non-dynamic" and they think "C++ and Java" - the two worst possible examples. I can't even tell you how many *programmers* I've come across that actually believe runtime reflection and hotspot optimizations are theoretically impossible without a VM.
 I quickly
 discovered that dynamic typing is about the worst plague ever to
 befall the programming world as soon as you do anything more than
 trivial textbook examples. You have to be constantly vigilant of what
 types are being passed around in those variables, because they
 *might* just happen to be a string where you expected an int, or an
 int where you expected an object! So much code comes crashing down as
 soon as you hand it a variable of the wrong type -- which the
 language explicitly allows you to, and in fact, which is the
 language's selling point in the first place!
 
And then all that careful manual checking becomes completely useless the moment you accidentally do something on the wrong variable. "Huh? He's setting the content type, but the GET request doesn't have a content type. I guess he wants me to make one! Yea, that must be it!" Me: D and Python, shoot the tin can. D: Ok, shooting the tin can. Python: Ok, shooting the tin can. Me: D and Python, shoot the glass bortle. D: Wait...what? Do what now? Python: I don't know what a bortle is so I'm just gonna spray bullets everywhere and hope I hit it.
 So as soon as you move beyond trivial toy programs into real-world
 applications, you start feeling the need -- the desperate need -- to
 vet each and every single variable passed into your code for their
 type, and worse, the exact fields present in an object type, because
 so much code depends on variables being, uh, of specific, non-varying
 types? It's either that, or constantly checking if something is equal
 to NULL, or sorry, I mean, ===NULL (as opposed to ==NULL or =NULL or
 <>NULL or ====NULL or whatever stupid UFO operator it is nowadays
 that they use to patch a type system on top of a broken language).
 And you quickly find yourself reimplementing a type system on top of
 the language, which *should have provided one in the first place*.
 
Exactly. I suspect the root of the problem (or at least one root) is this: 1. Joe Dumbass decides "Hey, we should have people OTHER than programmers do some programming!" (A clearly bad idea in the first place. It's like "Hey, let's have our receptionists assist in open-heart surgery! That'll save us lots of time and money!") 2. Joe Dumbass (alias "Rasmus Lerdorf") either creates, or hires someone else to create, a language specifically for non-programmers. 3. The language, due to the requirement of being usable *specifically* by those who don't know what they're doing, is *by necessity* guaranteed to be garbage. 4. Those non-programmers start writing code, and therefore start believing they're real programmers who know what they're doing. They *could become* real programmers of course, but not before shedding the training-wheels language. That only happens in a minority of the cases, though. That is *known* to literally be how PHP was created. I think there's very compelling reason to believe the same is also true of JavaScript and Flash's ActionScript as well.
 This article cinched it for me:
 
 http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
 
 (Summary for the tl;dr people: dynamic languages == static languages
 straitjacketed with only a single type.)
 
Yea, I always liked that explanation of it. It really is absolutely true.
 To conclude, I have to say that so far, the number of times I've
 actually *needed* to use a Variant type in my entire career is 1 (out
 of the hundreds if not thousands of programs I've written). And that
 one time was when I was writing an interpreter for a DSL.
Much the same here, only times I've *ever* felt any need for a Variant is when interfacing with something that's already variant or nearly-variant. Or as a bloated workaround when I'm using a language with really shitty (or no) template support. Algebraic types are another matter, though. Those can be useful, although D's Algebraic still needs some work.
 How many
 interpreters are written in Javascript? I rest my case. :)
 
Don't worry, no doubt it'll happen soon enough. Half the web devs out there are already convinced that JS is a valid "asm of the web" and that V8 is "fast" (it's only fast compared to some other JS engines, not to real languages - it *can't* be fast when literally everything is guaranteed to be a Variant[string]). If text editors written in JavaScript have become commonplace (<sarcasm>Thanks, Google!</sarcasm>), I'm sure JS-based interpreters, JS-based codecs and "F"FTs (rather SFTs), and other such nonsense aren't far behind. Just like Google already did with Quake, some jackass will write an MP3 decoder in JS and use it to claim that JS is fast (yea, as fast as a 486 which could decode MP3s just fine, too). "But if it can play quake and decode mp3s, that's all the power you need!" Then why the fuck did I just pay hundreds of dollars for what amounts to a brand-new Pentium 1?
Jan 21 2013
next sibling parent reply "Thiez" <thiezz gmail.com> writes:
Nick, Teoh, what exactly do you guys hope to accomplish with your 
current discussion? What if someone who comes from a dynamically 
typed language wants to check out D and reads that vitriolic crap 
the two of you are spewing? I'm sure they'll feel very welcome 
knowing that what appears to be the D community thinks their 
current language of choice (which may simply be because it is the 
only language they have gotten a chance to learn) is cancer and a 
plague, that they are a fool, a dumbass, not a real programmer, 
and are guaranteed to write garbage. They will turn around and 
never return. And they'd be right. Why would they want to become 
part of a community that actively hates and despises them?

Look, I get it, the two of you don't like dynamic typing. Neither 
do I. That is no absolutely excuse to bash dynamically typed 
languages and the people who use them. I expect D users can be 
divided into two groups: one with people that already prefer 
statically typed languages (in which case you are preaching to 
the choir), and one that consists of people who think both 
static- and dynamically typed languages have their uses (in which 
case they are probably well aware of the pros and cons and you 
are not going to convince them, but you will manage to leave the 
impression that they are not *really* welcome).

Take a moment to think about on the impression you are creating. 
If you really need a dynamic-typing-circlejerk every now and 
then, consider having it in private or in a context where it will 
not reflect badly on the D community.
Jan 21 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 23:20:44 +0100
"Thiez" <thiezz gmail.com> wrote:

 Nick, Teoh, what exactly do you guys hope to accomplish with your 
 current discussion? 
Venting ;)
Jan 21 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 11:20:44PM +0100, Thiez wrote:
 Nick, Teoh, what exactly do you guys hope to accomplish with your
 current discussion? What if someone who comes from a dynamically
 typed language wants to check out D and reads that vitriolic crap
 the two of you are spewing? I'm sure they'll feel very welcome
 knowing that what appears to be the D community thinks their current
 language of choice (which may simply be because it is the only
 language they have gotten a chance to learn) is cancer and a plague,
 that they are a fool, a dumbass, not a real programmer, and are
 guaranteed to write garbage. They will turn around and never return.
 And they'd be right. Why would they want to become part of a
 community that actively hates and despises them?
[...] Let me set the record straight. I was merely writing my evaluation of languages that I have tried before, and I never intended to attack anyone personally. If I did, then I apologize. Criticizing a language does not equal attacking the people associated with it. But avoiding personal attacks does not exclude criticizing a language for what I perceive as its flaws. T -- Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.
Jan 21 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 19:14:16 -0800
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Mon, Jan 21, 2013 at 11:20:44PM +0100, Thiez wrote:
 Nick, Teoh, what exactly do you guys hope to accomplish with your
 current discussion? What if someone who comes from a dynamically
 typed language wants to check out D and reads that vitriolic crap
 the two of you are spewing? I'm sure they'll feel very welcome
 knowing that what appears to be the D community thinks their current
 language of choice (which may simply be because it is the only
 language they have gotten a chance to learn) is cancer and a plague,
 that they are a fool, a dumbass, not a real programmer, and are
 guaranteed to write garbage. They will turn around and never return.
 And they'd be right. Why would they want to become part of a
 community that actively hates and despises them?
[...] Let me set the record straight. I was merely writing my evaluation of languages that I have tried before, and I never intended to attack anyone personally. If I did, then I apologize. Criticizing a language does not equal attacking the people associated with it. But avoiding personal attacks does not exclude criticizing a language for what I perceive as its flaws.
Same goes for me, too, but I wouldn't have been able to express it quite so clearly. Related note: If I go to a Python forum, I'm going to expect that I might see anti-static-typing sentiment from some people. Just like if you go to a Paul Greengrass fan forum, you kinda have to expect you might see "What's wrong with shaking the camera all around?" ;) If I then choose to get in a huf over it, *I'd* be the unreasonable one for expecting...well, for expecting not to see a leaf in the middle of a forest.
Jan 21 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 22:20:45 UTC, Thiez wrote:
 Nick, Teoh, what exactly do you guys hope to accomplish with 
 your current discussion? What if someone who comes from a 
 dynamically typed language wants to check out D and reads that 
 vitriolic crap the two of you are spewing? I'm sure they'll 
 feel very welcome knowing that what appears to be the D 
 community thinks their current language of choice (which may 
 simply be because it is the only language they have gotten a 
 chance to learn) is cancer and a plague, that they are a fool, 
 a dumbass, not a real programmer, and are guaranteed to write 
 garbage. They will turn around and never return. And they'd be 
 right. Why would they want to become part of a community that 
 actively hates and despises them?
Well, if people can't make a difference between themselve and a programming language, they have really bad psychological issues.
 Look, I get it, the two of you don't like dynamic typing. 
 Neither do I. That is no absolutely excuse to bash dynamically 
 typed languages and the people who use them. I expect D users 
 can be divided into two groups: one with people that already 
 prefer statically typed languages (in which case you are 
 preaching to the choir), and one that consists of people who 
 think both static- and dynamically typed languages have their 
 uses (in which case they are probably well aware of the pros 
 and cons and you are not going to convince them, but you will 
 manage to leave the impression that they are not *really* 
 welcome).
I use dynamically typed language on a daily basis at work. It doesn't prevent me to acknowledge it is complete crap. I also understand that I am not the programming language, so I don't feel bad about it.
 Take a moment to think about on the impression you are 
 creating. If you really need a dynamic-typing-circlejerk every 
 now and then, consider having it in private or in a context 
 where it will not reflect badly on the D community.
OK, let's start the politically correct game. dynamically typed language are great, but they have issue X and Y sounds much better.
Jan 21 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 22 Jan 2013 04:21:41 +0100
"deadalnix" <deadalnix gmail.com> wrote:

 On Monday, 21 January 2013 at 22:20:45 UTC, Thiez wrote:
 
 Take a moment to think about on the impression you are 
 creating. If you really need a dynamic-typing-circlejerk every 
 now and then, consider having it in private or in a context 
 where it will not reflect badly on the D community.
OK, let's start the politically correct game. dynamically typed language are great, but they have issue X and Y sounds much better.
I like this game! My turn: Dynamic languages are great, but I hate them, they're total junk, and I want them all to go away. Did I win? :) Oh well, back to Disgaea...Erm...I mean "work"...
Jan 21 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Monday, 21 January 2013 at 21:27:54 UTC, Nick Sabalausky wrote:
 Much the same here, only times I've *ever* felt any need for a 
 Variant
 is when interfacing with something that's already variant or
 nearly-variant. Or as a bloated workaround when I'm using a 
 language
 with really shitty (or no) template support.
I bet you use variants a lot more than you think. Often the variants are not noticed, such as when using std.json, which implements a form of variant type. There are many uses of "hidden" variants, some are more generalized than others, but they are still variants. I think what you are pointing out as being bad, are the situations where variant types are used for no actual purpose, where you gain nothing, and loose performance and possibly type safety depending on the richness of the implementation. In addition, there are scripted languages that have no means to check even statically declared types to ensure they are being used correctly, and the only way to discover errors is during runtime. I think that's not really a language design issue, it's more of an implementation issue. The worse languages of all, are the ones that will automatically create instances of variables without the programmer having to explicitly declare them. In those languages, a simple typo can lead to disaster. The reasoning behind such a design can only be to purposefully make programming dangerous and error prone just for laughs. I always do my best to avoid using those kinds of languages. So in a general sense, I will argue that what you are complaining about is not the idea of the variant - it is a very useful concept - the problems you are pointing out are with poor design and implementation choices. --rt
Jan 21 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 22 Jan 2013 00:14:13 +0100
"Rob T" <alanb ucora.com> wrote:

 On Monday, 21 January 2013 at 21:27:54 UTC, Nick Sabalausky wrote:
 Much the same here, only times I've *ever* felt any need for a 
 Variant
 is when interfacing with something that's already variant or
 nearly-variant. Or as a bloated workaround when I'm using a 
 language
 with really shitty (or no) template support.
I bet you use variants a lot more than you think. Often the variants are not noticed, such as when using std.json, which implements a form of variant type. There are many uses of "hidden" variants, some are more generalized than others, but they are still variants. I think what you are pointing out as being bad, are the situations where variant types are used for no actual purpose, where you gain nothing, and loose performance and possibly type safety depending on the richness of the implementation.
But under dynamic typing, those "bad" situations are the vast majority of cases.
 In addition, there are scripted languages that have no means to 
 check even statically declared types to ensure they are being 
 used correctly, and the only way to discover errors is during 
 runtime. I think that's not really a language design issue, it's 
 more of an implementation issue.
 
 The worse languages of all, are the ones that will automatically 
 create instances of variables without the programmer having to 
 explicitly declare them. In those languages, a simple typo can 
 lead to disaster. The reasoning behind such a design can only be 
 to purposefully make programming dangerous and error prone just 
 for laughs. I always do my best to avoid using those kinds of 
 languages.
 
Totally agree. That's one of the biggest reasons I can't stand Python.
 So in a general sense, I will argue that what you are complaining 
 about is not the idea of the variant - it is a very useful 
 concept - the problems you are pointing out are with poor design 
 and implementation choices.
 
Right. Having a variant available is certainly fine. I'd never argue against that. But designing a language specifically around variants - that's a misguided design mistake.
Jan 21 2013
prev sibling parent "Joakim" <joakim airpost.net> writes:
On Monday, 21 January 2013 at 21:27:54 UTC, Nick Sabalausky wrote:
 If text editors written in JavaScript have become
 commonplace (<sarcasm>Thanks, Google!</sarcasm>), I'm sure 
 JS-based
 interpreters, JS-based codecs and "F"FTs (rather SFTs), and 
 other
 such nonsense aren't far behind.
You probably already saw these, but an x86 emulator that runs linux, written in javascript: http://www.geek.com/articles/chips/javascript-emulator-lets-linux-run-in-a-browser-tab-20110517/ Forge, a Transport Layer Security implementation written in javascript: http://digitalbazaar.com/2010/07/20/javascript-tls-1/ Not quite FFTs or codecs, but not far off. :) I think these are horribly dumb ideas, just pointing out that they exist.
 A roundabout way to say it, but I guess the point I started out 
 trying to make is this: The popularity of 
 dynamic/interpreted/sandboxed/etc
 languages *is* IMO one of the more significant roadblocks in 
 the way of D popularity. Silent fire alarms are what's hip, and 
 here we are
 peddling an old-fashioned sounds-and-lights fire alarm. We're 
 pragmatic instead of cool.
I agree with this generally, but I'll note that those dynamic languages really aren't that popular. Using TIOBE data, (yes, yes, I know it's not good data, but I'm going to keep looking under the streetlight, dammit ;) ) http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Three out of the top four languages are now native compiled, with C even beating back Java for the top spot recently. D is probably in the top 7 for compiled languages and the only one to be designed in the last decade or so (I don't think Pascal and Ada are coming back ;) ). So I think D is well-positioned to hit that top spot, or at least that's what I told a friend recently when I explained why I'm trying to use D. :)
Jan 22 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-01-21 at 11:22 -0800, H. S. Teoh wrote:
[=E2=80=A6]
 Yeah, I remember when I was young and foolish, and believed for a short
 moment the hype about "dynamic typing" languages. I quickly discovered
 that dynamic typing is about the worst plague ever to befall the
 programming world as soon as you do anything more than trivial textbook
 examples. You have to be constantly vigilant of what types are being
 passed around in those variables, because they *might* just happen to be
 a string where you expected an int, or an int where you expected an
 object! So much code comes crashing down as soon as you hand it a
 variable of the wrong type -- which the language explicitly allows you
 to, and in fact, which is the language's selling point in the first
 place!
Speaking from the perspective of Groovy and Python, bollocks! Static typing programming is different from dynamic typing programming. Approaches and idioms from one do not transfer to the other. Phrases such as "You have to be constantly vigilant of what types are being passed around in those variables" is indicative of trying to program in static typing mode when using a dynamic programming language. "Ain't gonna work."
 So as soon as you move beyond trivial toy programs into real-world
 applications, you start feeling the need -- the desperate need -- to vet
 each and every single variable passed into your code for their type, and
 worse, the exact fields present in an object type, because so much code
 depends on variables being, uh, of specific, non-varying types? It's
 either that, or constantly checking if something is equal to NULL, or
 sorry, I mean, =3D=3D=3DNULL (as opposed to =3D=3DNULL or =3DNULL or <>NU=
LL or
 =3D=3D=3D=3DNULL or whatever stupid UFO operator it is nowadays that they=
use to
 patch a type system on top of a broken language). And you quickly find
 yourself reimplementing a type system on top of the language, which
 *should have provided one in the first place*.
=20
 This article cinched it for me:
=20
 http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-sta=
tic-languages/
=20
 (Summary for the tl;dr people: dynamic languages =3D=3D static languages
 straitjacketed with only a single type.)
This article and the tl;dr is so founded in complete misunderstanding of dynamic typing and object-oriented programming, that it cannot be taken seriously. Dynamically typed languages do have problems, but this level of hate is so profoundly wrong there should be laws against it.
 To conclude, I have to say that so far, the number of times I've
 actually *needed* to use a Variant type in my entire career is 1 (out of
 the hundreds if not thousands of programs I've written). And that one
 time was when I was writing an interpreter for a DSL. How many
 interpreters are written in Javascript? I rest my case. :)
Using a static typing mindset requires using a statically typed language. This is fine. Using a dynamically typed language requires a dynamic type mindset. They are different. There are a number of interpreters written in JavaScript. It is interesting that Groovy, the epitome of a dynamic language is pushing static typing and compilation as a partner mode of working, and Scala the epitome of statically typed systems now has a dynamic mode of working. These languages with both statically typed and dynamically typed parts are the way forward. Programmers coming to terms with the two modes of thinking is a professional responsibility. --=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
Jan 21 2013
next sibling parent "Araq" <rumpf_a gmx.de> writes:
 This article cinched it for me:
 
 http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
 
 (Summary for the tl;dr people: dynamic languages == static 
 languages
 straitjacketed with only a single type.)
This article and the tl;dr is so founded in complete misunderstanding of dynamic typing and object-oriented programming, that it cannot be taken seriously. Dynamically typed languages do have problems, but this level of hate is so profoundly wrong there should be laws against it.
What? As much as I dislike arguments by authority: Do you even know who Robert Harper is? Claiming that he misunderstands OO or dynamic typing is absurd.
Jan 21 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 19:48:55 +0000
Russel Winder <russel winder.org.uk> wrote:

 On Mon, 2013-01-21 at 11:22 -0800, H. S. Teoh wrote:
 [=E2=80=A6]
 Yeah, I remember when I was young and foolish, and believed for a
 short moment the hype about "dynamic typing" languages. I quickly
 discovered that dynamic typing is about the worst plague ever to
 befall the programming world as soon as you do anything more than
 trivial textbook examples. You have to be constantly vigilant of
 what types are being passed around in those variables, because they
 *might* just happen to be a string where you expected an int, or an
 int where you expected an object! So much code comes crashing down
 as soon as you hand it a variable of the wrong type -- which the
 language explicitly allows you to, and in fact, which is the
 language's selling point in the first place!
=20 Speaking from the perspective of Groovy and Python, bollocks! =20 Static typing programming is different from dynamic typing programming. Approaches and idioms from one do not transfer to the other. Phrases such as "You have to be constantly vigilant of what types are being passed around in those variables" is indicative of trying to program in static typing mode when using a dynamic programming language. "Ain't gonna work." =20
 So as soon as you move beyond trivial toy programs into real-world
 applications, you start feeling the need -- the desperate need --
 to vet each and every single variable passed into your code for
 their type, and worse, the exact fields present in an object type,
 because so much code depends on variables being, uh, of specific,
 non-varying types? It's either that, or constantly checking if
 something is equal to NULL, or sorry, I mean, =3D=3D=3DNULL (as opposed
 to =3D=3DNULL or =3DNULL or <>NULL or =3D=3D=3D=3DNULL or whatever stup=
id UFO
 operator it is nowadays that they use to patch a type system on top
 of a broken language). And you quickly find yourself reimplementing
 a type system on top of the language, which *should have provided
 one in the first place*.
=20
 This article cinched it for me:
=20
 http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-s=
tatic-languages/
=20
 (Summary for the tl;dr people: dynamic languages =3D=3D static languages
 straitjacketed with only a single type.)
=20 This article and the tl;dr is so founded in complete misunderstanding of dynamic typing and object-oriented programming, that it cannot be taken seriously. Dynamically typed languages do have problems, but this level of hate is so profoundly wrong there should be laws against it. =20
 To conclude, I have to say that so far, the number of times I've
 actually *needed* to use a Variant type in my entire career is 1
 (out of the hundreds if not thousands of programs I've written).
 And that one time was when I was writing an interpreter for a DSL.
 How many interpreters are written in Javascript? I rest my case. :)
=20 Using a static typing mindset requires using a statically typed language. This is fine. Using a dynamically typed language requires a dynamic type mindset. They are different. =20
I've heard that argument before, but I've yet to come across a good explanation of how this "dynamic mindset" different from the static one. Just that "it exists" and "it's different". Far as I can tell so far, the "dynamic mindset" is just "Bugs? Efficiency? Meh, I don't care as long as I'm piling on and shipping (easily broken) code". So what is this "dynamic mindset" that makes using dynamic typing productive and non-bug-prone? How does it work, if it's not as I described above?
 It is interesting that Groovy, the epitome of a dynamic language is
 pushing static typing and compilation as a partner mode of working,
It doesn't sound at all like it's an epitome of dynamic language, then. The *core* of it might be, but if it both provides *and* encourages you to use static typing, then if you choose to do so, you're clearly NOT doing dynamic programming - you're doing static programming. I don't see how using a static type system can ever be accurately called "dynamic programming".
Jan 21 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 21 January 2013 at 23:42:49 UTC, Nick Sabalausky wrote:

 I've heard that argument before, but I've yet to come across a 
 good
 explanation of how this "dynamic mindset" different from the 
 static
 one. Just that "it exists" and "it's different". Far as I can 
 tell so
 far, the "dynamic mindset" is just "Bugs? Efficiency? Meh, I 
 don't care
 as long as I'm piling on and shipping (easily broken) code".

 So what is this "dynamic mindset" that makes using dynamic 
 typing
 productive and non-bug-prone? How does it work, if it's not as I
 described above?
Take a look at this project: https://github.com/pydata/pandas It's a very effective library, that's easy to use in a flexible, interactive fashion. It's fast due to judicious use of C and cython where absolutely necessary and numpy elsewhere. One of the strengths of the library is it's ability to make a "best guess" as to what to do with information it's passed, irrelevant of what type that information is. It's not the sort of behaviour you'd want in a large production codebase, but for an interactive toolbox it speeds things up by orders of magnitude. Whatever you throw at it, it just works, which for a high-pressure financial analyst (the primary target audience) is absolutely invaluable. This is all stuff that (with better shared library support) D could do, making it the awesome king of all languages, but at the moment i'll still to drafting my data analysis in python and then writing it up in D when it's settled. P.S. dmd 32bit on linux produces functional shared libraries, which can be happily called by IDL (http://www.exelisvis.com/ProductsServices/IDL.aspx). IDL rules the roost in several data heavy scientific arenas (fusion physics, medical imaging, solar physics, astophysics etc) so this could be a potential jackpot for D. By and large people don't write their own extensions for IDL as they don't want to get their hands dirty with C. D could be the perfect tool for the job. I've recently started collaborating with some people from MAST and JET (http://www.ccfe.ac.uk/), working on some better data analysis tools for some of the fusion diagnostics, to be run online during "shots" (running the reactor) and retrospectively. They all use matlab (yuck) and/or IDL so naturally i'll be writing my code as extensions to IDL, written in D!
Jan 21 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 22 January 2013 at 00:24:04 UTC, John Colvin wrote:

 P.S.
 dmd 32bit on linux produces functional shared libraries, which 
 can be happily called by IDL
to clarify: extern(C) is required, there's nothing clever going on.
Jan 21 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 22 January 2013 at 00:32:03 UTC, John Colvin wrote:
 On Tuesday, 22 January 2013 at 00:24:04 UTC, John Colvin wrote:

 P.S.
 dmd 32bit on linux produces functional shared libraries, which 
 can be happily called by IDL
to clarify: extern(C) is required, there's nothing clever going on.
Another correction: dmd can't make the runtime work. Ldc does work however.
Jan 22 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/22/2013 12:42 AM, Nick Sabalausky wrote:
 ...

 It doesn't sound at all like it's an epitome of dynamic language,
 then. The *core* of it might be, but if it both provides *and*
 encourages you to use static typing, then if you choose to do so,
 you're clearly NOT doing dynamic programming - you're doing
 static programming. I don't see how using a static type system can ever
 be accurately called "dynamic programming".
I'm doing it all the time. :P http://en.wikipedia.org/wiki/Dynamic_programming
Jan 21 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 22, 2013 at 07:02:59AM +0100, Timon Gehr wrote:
 On 01/22/2013 12:42 AM, Nick Sabalausky wrote:
...

It doesn't sound at all like it's an epitome of dynamic language,
then. The *core* of it might be, but if it both provides *and*
encourages you to use static typing, then if you choose to do so,
you're clearly NOT doing dynamic programming - you're doing static
programming. I don't see how using a static type system can ever be
accurately called "dynamic programming".
I'm doing it all the time. :P http://en.wikipedia.org/wiki/Dynamic_programming
Yeah, that one always cracks me up. Funny how the same terms get applied in completely unrelated ways in different places, often in conflicting ways. Reminds me of how "French horn" refers to an instrument that neither originated nor developed in France (it was in Germany that where most of its modern development took place), or "English horn", which isn't even a "horn" to begin with, but a reed instrument, and neither did it develop in England. (Now just don't get me started on "Liberty Horn"...) T -- Gone Chopin. Bach in a minuet.
Jan 21 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 01:27:48PM -0500, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 09:54:59 +0100
 "deadalnix" <deadalnix gmail.com> wrote:
 
 We move from ruby on rail to Node.js for scalability reasons 
 !!!!!!
I take it this "scalability reason" is to avoid scalability? You should to read Ted Dziuba's "Node.js is Cancer", he explains it better than I can: (He's destroyed all his good older posts, but I managed to save this one from a cache:) https://semitwist.com/mirror/node-js-is-cancer.html
Anything that involves running javascript on a *server* cannot possibly be a good idea. (I mean, I have hesitations about running javascript on the *client*, needless to say a server...) T -- The best compiler is between your ears. -- Michael Abrash
Jan 21 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 10:49:30 -0800
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Mon, Jan 21, 2013 at 01:27:48PM -0500, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 09:54:59 +0100
 "deadalnix" <deadalnix gmail.com> wrote:
 
 We move from ruby on rail to Node.js for scalability reasons 
 !!!!!!
I take it this "scalability reason" is to avoid scalability? You should to read Ted Dziuba's "Node.js is Cancer", he explains it better than I can: (He's destroyed all his good older posts, but I managed to save this one from a cache:) https://semitwist.com/mirror/node-js-is-cancer.html
Anything that involves running javascript on a *server* cannot possibly be a good idea. (I mean, I have hesitations about running javascript on the *client*, needless to say a server...)
Exactly. Although, I'd be willing to entertain the idea that it's better than running PHP on a server. Not that that's saying much. Case in point: https://semitwist.com/articles/
Jan 21 2013
parent Matt Soucy <msoucy csh.rit.edu> writes:
On 01/21/2013 02:04 PM, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 10:49:30 -0800
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 On Mon, Jan 21, 2013 at 01:27:48PM -0500, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 09:54:59 +0100
 "deadalnix" <deadalnix gmail.com> wrote:
 We move from ruby on rail to Node.js for scalability reasons
 !!!!!!
I take it this "scalability reason" is to avoid scalability? You should to read Ted Dziuba's "Node.js is Cancer", he explains it better than I can: (He's destroyed all his good older posts, but I managed to save this one from a cache:) https://semitwist.com/mirror/node-js-is-cancer.html
Anything that involves running javascript on a *server* cannot possibly be a good idea. (I mean, I have hesitations about running javascript on the *client*, needless to say a server...)
Exactly. Although, I'd be willing to entertain the idea that it's better than running PHP on a server. Not that that's saying much. Case in point: https://semitwist.com/articles/
The scariest thing I've ever seen involving Node.JS is, and I kid you not, a Coke machine. Drink.JS is the latest iteration of the project, and the author loves using technologies that aren't really there yet. (For a while, nobody could use it because it limited itself to WebSocket output when it only existed in Chromium Canary. He started it when Node wasn't even really out yet) He absolutely refuses to believe that JS is not a sane choice. I'm still hoping that the constant downtime and bugs (my favorite: NMAPping the server would crash it) is more of a programmer error, but I feel like Node was a horrible choice for the maintainability alone. (Sadly, the same reason why I wouldn't use D for a rewrite of it...yet) tl;dr: Bad experience with Node in places where Node should never be
Jan 21 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 20, 2013 at 11:19:58PM -0800, Jonathan M Davis wrote:
 On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
 D does continue to face an uphill battle for mindshare: These days,
 most people who write code prefer to use languages that accept ANY
 grammatically-correct code and deliberately remain silent about all
 mechanically-checkable problems they can possibly ignore. Apparently
 this is because they prefer to manually write extra unittests so
 that only a subset of these errors are actually guaranteed to get
 caught (if there's any guarantee at all).
In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are.
[...] Before D, I never wanted to write unittests. They were cumbersome, required diversion from the task at hand, consumed extra effort, and were troublesome to remember to run separately every time you make some changes. D's unittest blocks singlehandedly converted me. :) T -- Two wrongs don't make a right; but three rights do make a left...
Jan 21 2013
next sibling parent "mist" <none none.none> writes:
What is best in my opinion - you can start to add tests even to 
projects that do not yet have them, without any build system 
tweaks or arguments about what unit test library to use. This 
makes it a habit - a good habit.
 Before D, I never wanted to write unittests. They were 
 cumbersome,
 required diversion from the task at hand, consumed extra 
 effort, and
 were troublesome to remember to run separately every time you 
 make some
 changes.

 D's unittest blocks singlehandedly converted me. :)


 T
Jan 21 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 21 January 2013 at 16:14:45 UTC, H. S. Teoh wrote:

The only thing holding me back from D is that it is unreliable. 
I'm not just talking about bugs in Phobos (which can easilly 
found and/or fixed).

I'm talking about all the unreliable voldemort structs, the 
context pointers, the delegates, the destructor sequences, memory 
management and whatnot.

I can see that these issues are being fixed and worked on, but 
today, I would NEVER even dream of using D in a professional 
project.

The only way for that to work would be to use a "restricted D": 
No non-static structs, no allocating delegates etc. It's a hard 
sell to management.

I use it at work to quickly deploy helper scripts, because it is 
so easy, and I know what I'm doing, but it stops there. It HAS to 
stop there :( ...
Jan 21 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
 The only thing holding me back from D is that it is unreliable. I'm
 not just talking about bugs in Phobos (which can easilly found and/or
 fixed).
 
 I'm talking about all the unreliable voldemort structs, the context
 pointers, the delegates, the destructor sequences, memory management
 and whatnot.
Oh? What's so unreliable about delegates? I find that they work quite well in general. But yeah, anything involving dtors is treading on a minefield. As is structs with hidden context pointers. It was presented in a very attractive way in TDPL, but given the treatment of structs as value types ("glorified ints" as TDPL puts it), having hidden context pointers involving them is a dangerous game.
 I can see that these issues are being fixed and worked on, but today,
 I would NEVER even dream of using D in a professional project.
 
 The only way for that to work would be to use a "restricted D": No
 non-static structs, no allocating delegates etc. It's a hard sell to
 management.
I don't find the need to use non-static structs that often, actually. Delegates, yes, but I haven't found any showstopper issues with them yet.
 I use it at work to quickly deploy helper scripts, because it is so
 easy, and I know what I'm doing, but it stops there. It HAS to stop
 there :( ...
What I find frustrating with D is that most features work extremely well when used in isolation, but put them together with each other, and suddenly you're in untested territory filled with bugs and obscure corner cases with buggy behaviours. T -- Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
Jan 21 2013
next sibling parent reply "Zhenya" <zheny list.ru> writes:
 Oh? What's so unreliable about delegates? I find that they work 
 quite
 well in general.
This for example: http://d.puremagic.com/issues/show_bug.cgi?id=5710
Jan 21 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 07:01:29PM +0100, Zhenya wrote:
Oh? What's so unreliable about delegates? I find that they work quite
well in general.
This for example: http://d.puremagic.com/issues/show_bug.cgi?id=5710
Yeah, that one falls under my category of "put two features together and get into unexplored buggy territory". Unfortunately, D's current implementation seems to have a lot of problems in this category. :-( T -- People tell me that I'm skeptical, but I don't believe it.
Jan 21 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 21 January 2013 at 17:56:05 UTC, H. S. Teoh wrote:
 On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
 The only thing holding me back from D is that it is 
 unreliable. I'm
 not just talking about bugs in Phobos (which can easilly found 
 and/or
 fixed).
 
 I'm talking about all the unreliable voldemort structs, the 
 context
 pointers, the delegates, the destructor sequences, memory 
 management
 and whatnot.
Oh? What's so unreliable about delegates? I find that they work quite well in general. [SNIP] T
I've stayed away from them mostly, so I may be unfair, but I'm mostly thinking about delegates that reference external data via context pointers. Come to think about it, everything I dislike about about D always boils down to "context pointer". That thing is so scary unsafe, and can so easily back fire on you :( I don't have the hindsight yet to be allowed to declare it was a terrible idea, but that's what I'm thinking right now. Heck, I'm kind of wishing we had a compiler switch to ban and/or warn on such usage. Or at least, make them explicit opt-ins for crying out loud.
Jan 21 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/21/2013 07:09 PM, monarch_dodra wrote:
 On Monday, 21 January 2013 at 17:56:05 UTC, H. S. Teoh wrote:
 On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
 The only thing holding me back from D is that it is unreliable. I'm
 not just talking about bugs in Phobos (which can easilly found and/or
 fixed).

 I'm talking about all the unreliable voldemort structs, the context
 pointers, the delegates, the destructor sequences, memory management
 and whatnot.
Oh? What's so unreliable about delegates? I find that they work quite well in general. [SNIP] T
I've stayed away from them mostly, so I may be unfair, but I'm mostly thinking about delegates that reference external data via context pointers. Come to think about it, everything I dislike about about D always boils down to "context pointer". That thing is so scary unsafe, and can so easily back fire on you :( I don't have the hindsight yet to be allowed to declare it was a terrible idea, but that's what I'm thinking right now. Heck, I'm kind of wishing we had a compiler switch to ban and/or warn on such usage. Or at least, make them explicit opt-ins for crying out loud.
That does not answer the question.
Jan 21 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 07:09:50PM +0100, monarch_dodra wrote:
 On Monday, 21 January 2013 at 17:56:05 UTC, H. S. Teoh wrote:
On Mon, Jan 21, 2013 at 05:32:12PM +0100, monarch_dodra wrote:
The only thing holding me back from D is that it is unreliable.  I'm
not just talking about bugs in Phobos (which can easilly found
and/or fixed).

I'm talking about all the unreliable voldemort structs, the context
pointers, the delegates, the destructor sequences, memory management
and whatnot.
Oh? What's so unreliable about delegates? I find that they work quite well in general.
[...]
 I've stayed away from them mostly, so I may be unfair, but I'm
 mostly thinking about delegates that reference external data via
 context pointers.
 
 Come to think about it, everything I dislike about about D always
 boils down to "context pointer". That thing is so scary unsafe, and
 can so easily back fire on you :(
Actually, I find delegates to be a big plus in my choosing to adopt D. They make it a lot of very complex, tedious code very easy to write. Non-trivial event-driven code is basically unwritable and unreadable (without lots of hair-pulling and all-nighters, that is) without delegates. A lot of generic code is impossible without delegates. I disagree that context pointers are the problem. I think the root of the problem is that many features in D work very well by themselves, but their interactions with each other are not well explored, and as a result there are a lot of bugs when you start leveraging more than one feature at the same time. For example, returning delegates that reference local variables works wonderfully. But if you reference member variables in a struct instead, then you start getting into trouble -- because the context pointer is now pointing to an on-stack struct, which risks becoming invalid once the scope exits. Another example. Array slicing works wonders; it makes arrays and strings wonderfully easy -- and I would even say, a pleasure -- to use. But slice a static array, and suddenly you're treading dangerous ground. Static arrays can be passed by value on the stack, and return a slice far enough up the call stack, and you're referencing invalid memory. Yet another delegate-related example. Declare a delegate directly inside a function, and everything works just fine. Declare it in a template alias argument, and suddenly you're treading on incomplete compiler support -- sometimes the compiler fails to notice that a delegate is involved, and fails to allocate local variables on the heap instead of the stack. Or fails to instantiate certain things, and you get a linker error. A Phobos example. Most range-based functions assume (at least unconciously) that ranges are structs, because, well, that's how most Phobos ranges are built. So passing a range to a function makes a copy of the range, and the original function can happily go on using the range, expecting that it hasn't changed. But pass in a class range, and suddenly you run into problems, because classes are passed by reference. More examples. Structs by themselves work pretty well, but once you start nesting the things, or nest classes inside structs or vice versa, you start getting into uncharted territory and "here be dragons" areas. Most trivial usages of such combinations tend to have no problems, because the basic use cases probably have been thought of before. But travel far enough away from the most trivial cases, and you're in uncharted territory full of pitfalls. Enums are another example. Most trivial cases of enums work flawlessly. But nest them inside a function and sprinkle initializers, and you start running into compiler bugs that cause linker errors. This is just an isolated case, of course -- most such cases are easily fixed, but that begs the question, if they're simple to fix, why weren't they caught earlier? It seems that D has too many features, and therefore an exponentially huge number of possible combinations of features, and therefore a large part of said combinations have not been tested (or well-tested). So there still lurks many probably trivial bugs that haven't been found, just because nobody has happened to use that particular combination of features yet. T -- "Maybe" is a strange word. When mom or dad says it it means "yes", but when my big brothers say it it means "no"! -- PJ jr.
Jan 21 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Monday, 21 January 2013 at 18:40:15 UTC, H. S. Teoh wrote:
 It seems that D has too many features, and therefore an 
 exponentially
 huge number of possible combinations of features, and therefore 
 a large
 part of said combinations have not been tested (or 
 well-tested). So
 there still lurks many probably trivial bugs that haven't been 
 found,
 just because nobody has happened to use that particular 
 combination of
 features yet.
I have to wonder if many of the features can be generalized down into less features without sacrificing anything. To solve the problem of instability, we need to stabilize the language, which is easy to do, and can be done in a way that does not prevent progress. All you need is to release a "stable" language specification along with a corresponding stable reference compiler that only implements the associated stable language release. The stable release is then fine tuned as bug reports come in over the course of a year (or whatever is required). The language development can proceed normally through an unstable branch. The next release can be tested through a semi-stable beta branch. We're trying to develop a process to achieve this sort of thing, but unfortunately the language specification has not yet been integrated into the process. Hopeful the development process will be expanded to include the language spec in the near future, as it is a critical component that cannot be left out. --rt
Jan 21 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2013 12:31 PM, Rob T wrote:
 I have to wonder if many of the features can be generalized down into less
 features without sacrificing anything.
Yeah, well, that's the major thing about any language design!
Jan 21 2013
parent reply "F i L" <witte2008 gmail.com> writes:
On Monday, 21 January 2013 at 20:48:22 UTC, Walter Bright wrote:
 On 1/21/2013 12:31 PM, Rob T wrote:
 I have to wonder if many of the features can be generalized 
 down into less
 features without sacrificing anything.
Yeah, well, that's the major thing about any language design!
and on that note I hear the C++ community (at least one key member) is proposing a: auto add(auto a, auto b) { return a + b; } pretty-template syntax! I wouldn't feel right if C++ had something that elegant and D did not *wink* *wink* :-)
Jan 21 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 and on that note I hear the C++ community (at least one key 
 member) is proposing a:

     auto add(auto a, auto b) {
         return a + b;
     }

 pretty-template syntax! I wouldn't feel right if C++ had 
 something that elegant and D did not *wink* *wink* :-)
Could you explain why this is necessary? D templates are far better than C++ templates and accomplish these task already.
Jan 21 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 09:53:35PM +0100, F i L wrote:
 On Monday, 21 January 2013 at 20:48:22 UTC, Walter Bright wrote:
On 1/21/2013 12:31 PM, Rob T wrote:
I have to wonder if many of the features can be generalized down
into less
features without sacrificing anything.
Yeah, well, that's the major thing about any language design!
and on that note I hear the C++ community (at least one key member) is proposing a: auto add(auto a, auto b) { return a + b; } pretty-template syntax! I wouldn't feel right if C++ had something that elegant and D did not *wink* *wink* :-)
D already has that: auto add(T,U)(T a, U b) { return a + b; } In fact, D does it one step better with signature constraints: auto add(T,U)(T a, U b) if (is(typeof(a+b))) { return a + b; } That way, the compiler won't even bother to instantiate the template if the two types can't be added in the first place. T -- Life would be easier if I had the source code. -- YHL
Jan 21 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, January 21, 2013 21:53:35 F i L wrote:
 and on that note I hear the C++ community (at least one key
 member) is proposing a:
 
 auto add(auto a, auto b) {
 return a + b;
 }
 
 pretty-template syntax! I wouldn't feel right if C++ had
 something that elegant and D did not *wink* *wink* :-)
It's been discussed before and rejected. - Jonathan M Davis
Jan 21 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2013 8:12 AM, H. S. Teoh wrote:
 Before D, I never wanted to write unittests. They were cumbersome,
 required diversion from the task at hand, consumed extra effort, and
 were troublesome to remember to run separately every time you make some
 changes.

 D's unittest blocks singlehandedly converted me. :)
One of the fascinating things I learned with D are that making things even slightly easier to use can have large, transformative consequences. 3 cases: 1. unittests (as you mentioned) 2. ddoc 3. new lambda syntax
Jan 21 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 11:28:21AM -0800, Walter Bright wrote:
 On 1/21/2013 8:12 AM, H. S. Teoh wrote:
Before D, I never wanted to write unittests. They were cumbersome,
required diversion from the task at hand, consumed extra effort, and
were troublesome to remember to run separately every time you make
some changes.

D's unittest blocks singlehandedly converted me. :)
One of the fascinating things I learned with D are that making things even slightly easier to use can have large, transformative consequences.
It's the butterfly effect in programming.
 3 cases:
 
 1. unittests (as you mentioned)
 2. ddoc
 3. new lambda syntax
I have to admit that ddoc hasn't really done it for me (yet). I think the impediment is that the default output needs some work (mainly in CSS and indexing) before it is useful as actual documentation. But yes, the new lambda syntax makes them a joy to work with. Ultimately, delegates are just syntactic sugar for defining, declaring, and using a functor class containing some context variables (which is what one has to do in C++), but being able to omit most of that boilerplate makes a huge difference in their usability (and readability!). T -- Ph.D. = Permanent head Damage
Jan 21 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2013 12:06 PM, H. S. Teoh wrote:
 I have to admit that ddoc hasn't really done it for me (yet). I think
 the impediment is that the default output needs some work (mainly in CSS
 and indexing) before it is useful as actual documentation.
The transformative effect of Ddoc is most obvious in the Phobos documentation before and immediately after Ddoc was introduced. There's just no comparison. The default Ddoc output is deliberately designed to not need CSS. It's supposed to be usable (in a rudimentary way) out of the box, and it is.
Jan 21 2013
parent "Peter Sommerfeld" <noreply rubrica.at> writes:
Am 21.01.2013, 21:47 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:

 The default Ddoc output is deliberately designed to not need CSS. It's  
 supposed to be usable (in a rudimentary way) out of the box, and it is.
Of course, it does! But how about to add the doc output to -X automatically. This currently happens with -D -X only. And JSON is a good base for more advanced documentations. Peter
Jan 21 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 3:06 PM, H. S. Teoh wrote:
 I have to admit that ddoc hasn't really done it for me (yet). I think
 the impediment is that the default output needs some work (mainly in CSS
 and indexing) before it is useful as actual documentation.
We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/. Andrei
Jan 21 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 09:03:55PM -0500, Andrei Alexandrescu wrote:
 On 1/21/13 3:06 PM, H. S. Teoh wrote:
I have to admit that ddoc hasn't really done it for me (yet). I think
the impediment is that the default output needs some work (mainly in
CSS and indexing) before it is useful as actual documentation.
We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/.
[...] +1. That would lower the "barrier to entry" and make it more likely for people to adopt ddoc. T -- Famous last words: I wonder what will happen if I do *this*...
Jan 21 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 10:06 PM, H. S. Teoh wrote:
 On Mon, Jan 21, 2013 at 09:03:55PM -0500, Andrei Alexandrescu wrote:
 On 1/21/13 3:06 PM, H. S. Teoh wrote:
 I have to admit that ddoc hasn't really done it for me (yet). I think
 the impediment is that the default output needs some work (mainly in
 CSS and indexing) before it is useful as actual documentation.
We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/.
[...] +1. That would lower the "barrier to entry" and make it more likely for people to adopt ddoc.
http://d.puremagic.com/issues/show_bug.cgi?id=9379 Preapproved, too! This may be an awesome website project. Andrei
Jan 23 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 21:03:55 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/21/13 3:06 PM, H. S. Teoh wrote:
 I have to admit that ddoc hasn't really done it for me (yet). I
 think the impediment is that the default output needs some work
 (mainly in CSS and indexing) before it is useful as actual
 documentation.
We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/.
Is that possible? PDF is binary, but I thought DDoc only did text output? Come to think of it, how *do* the non-html versions of the docs currently get generated?
Jan 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 10:32 PM, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 21:03:55 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

 On 1/21/13 3:06 PM, H. S. Teoh wrote:
 I have to admit that ddoc hasn't really done it for me (yet). I
 think the impediment is that the default output needs some work
 (mainly in CSS and indexing) before it is useful as actual
 documentation.
We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/.
Is that possible? PDF is binary, but I thought DDoc only did text output? Come to think of it, how *do* the non-html versions of the docs currently get generated?
LaTeX. Andrei
Jan 21 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 21, 2013 at 10:57:39PM -0500, Andrei Alexandrescu wrote:
 On 1/21/13 10:32 PM, Nick Sabalausky wrote:
On Mon, 21 Jan 2013 21:03:55 -0500
Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:

On 1/21/13 3:06 PM, H. S. Teoh wrote:
I have to admit that ddoc hasn't really done it for me (yet). I
think the impediment is that the default output needs some work
(mainly in CSS and indexing) before it is useful as actual
documentation.
We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/.
Is that possible? PDF is binary, but I thought DDoc only did text output? Come to think of it, how *do* the non-html versions of the docs currently get generated?
LaTeX.
[...] Speaking of which, did you manage to polish up the LaTeX macros to produce decent output? I'd love to take a look if you did -- I'm a LaTeX fan. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Jan 21 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 21:19:36 -0800
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 
 Speaking of which, did you manage to polish up the LaTeX macros to
 produce decent output? I'd love to take a look if you did -- I'm a
 LaTeX fan.
 
 T
 
 -- 
 Those who've learned LaTeX swear by it. Those who are learning LaTeX
 swear at it. -- Pete Bleackley
Your signature randomizer is becoming sentient...
Jan 21 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 22, 2013 at 12:30:42AM -0500, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 21:19:36 -0800
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 
 Speaking of which, did you manage to polish up the LaTeX macros to
 produce decent output? I'd love to take a look if you did -- I'm a
 LaTeX fan.
 
 T
 
 -- 
 Those who've learned LaTeX swear by it. Those who are learning LaTeX
 swear at it. -- Pete Bleackley
Your signature randomizer is becoming sentient...
Actually, this time I cheated. I manually picked that line for this particular post. ;-) Though I have to say, there were times in the past when the Perl script picked a quote that is eeriely relevant to the discussion at hand. The thought *did* cross my mind that it's starting to exhibit sentience. :-P On the other hand, I used to know someone whose signature script actually scanned the message body for keywords, and used some kind of Markov chain algo or some-such to pick the most appropriate quote for the occasion given those keywords. Alas, my understanding of Markov chains (or whatever it is they used) is practically nil, so I wouldn't know how to implement such a thing. T -- If you compete with slaves, you become a slave. -- Norbert Wiener
Jan 21 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/13 12:19 AM, H. S. Teoh wrote:
 On Mon, Jan 21, 2013 at 10:57:39PM -0500, Andrei Alexandrescu wrote:
 On 1/21/13 10:32 PM, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 21:03:55 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>   wrote:

 On 1/21/13 3:06 PM, H. S. Teoh wrote:
 I have to admit that ddoc hasn't really done it for me (yet). I
 think the impediment is that the default output needs some work
 (mainly in CSS and indexing) before it is useful as actual
 documentation.
We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/.
Is that possible? PDF is binary, but I thought DDoc only did text output? Come to think of it, how *do* the non-html versions of the docs currently get generated?
LaTeX.
[...] Speaking of which, did you manage to polish up the LaTeX macros to produce decent output? I'd love to take a look if you did -- I'm a LaTeX fan.
Yah, a start is already on github, run make VERSION=2.061 `pwd`/web/dlangspec.pdf from the d-programming-language.org repo. Andrei
Jan 22 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-22 04:57, Andrei Alexandrescu wrote:

 LaTeX.
Isn't that a failure of ddoc. Wasn't ddoc supposed to be independent of the output format. If we're only using ddoc to generate the HTML documentation it seems it's not good enough. This is not a big issue. I mostly care about the HTML docs. -- /Jacob Carlborg
Jan 22 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/22/2013 10:46 AM, Jacob Carlborg wrote:
 On 2013-01-22 04:57, Andrei Alexandrescu wrote:

 LaTeX.
Isn't that a failure of ddoc. Wasn't ddoc supposed to be independent of the output format. If we're only using ddoc to generate the HTML documentation it seems it's not good enough. This is not a big issue. I mostly care about the HTML docs.
It is ddoc -> LaTeX -> pdf.
Jan 22 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-22 11:04, Timon Gehr wrote:

 It is ddoc -> LaTeX -> pdf.
Ok, I guess it's easier to go through LaTeX than directly to PDF. -- /Jacob Carlborg
Jan 22 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/13 4:46 AM, Jacob Carlborg wrote:
 On 2013-01-22 04:57, Andrei Alexandrescu wrote:

 LaTeX.
Isn't that a failure of ddoc. Wasn't ddoc supposed to be independent of the output format. If we're only using ddoc to generate the HTML documentation it seems it's not good enough. This is not a big issue. I mostly care about the HTML docs.
Not sure I understand. We have working templates that produce passable PDF via LaTeX. Andrei
Jan 22 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-22 20:47, Andrei Alexandrescu wrote:

 Not sure I understand. We have working templates that produce passable
 PDF via LaTeX.
It's somewhat cheating to use an intermediate language like LaTeX, but in the end I guess it really doesn't matter. -- /Jacob Carlborg
Jan 22 2013
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 23 January 2013 at 07:18:37 UTC, Jacob Carlborg 
wrote:
 On 2013-01-22 20:47, Andrei Alexandrescu wrote:

 Not sure I understand. We have working templates that produce 
 passable
 PDF via LaTeX.
It's somewhat cheating to use an intermediate language like LaTeX, but in the end I guess it really doesn't matter.
yeah... in the end, it doesn't even matter. http://en.wikipedia.org/wiki/In_the_End
Jan 22 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/13 2:18 AM, Jacob Carlborg wrote:
 On 2013-01-22 20:47, Andrei Alexandrescu wrote:

 Not sure I understand. We have working templates that produce passable
 PDF via LaTeX.
It's somewhat cheating to use an intermediate language like LaTeX, but in the end I guess it really doesn't matter.
No, it's not cheating at all. You do realize the enormous effort that would be involved in producing good quality typesetting? Andrei
Jan 22 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2013 11:53 PM, Andrei Alexandrescu wrote:
 On 1/23/13 2:18 AM, Jacob Carlborg wrote:
 On 2013-01-22 20:47, Andrei Alexandrescu wrote:

 Not sure I understand. We have working templates that produce passable
 PDF via LaTeX.
It's somewhat cheating to use an intermediate language like LaTeX, but in the end I guess it really doesn't matter.
No, it's not cheating at all. You do realize the enormous effort that would be involved in producing good quality typesetting?
Also, Ddoc's charter is not to generate PDF files. It is to provide enough macro capability that Ddoc's output could be, given the right macro definitions, fed into a PDF generating tool or any other reasonable document format. The default set of macros will generate basic html.
Jan 23 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-23 08:53, Andrei Alexandrescu wrote:

 No, it's not cheating at all. You do realize the enormous effort that
 would be involved in producing good quality typesetting?
I'm not even arguing. -- /Jacob Carlborg
Jan 23 2013
prev sibling next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Mon, Jan 21, 2013 at 9:06 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Mon, Jan 21, 2013 at 11:28:21AM -0800, Walter Bright wrote:
 It's the butterfly effect in programming.


 3 cases:

 1. unittests (as you mentioned)
 2. ddoc
 3. new lambda syntax
4. Templates. I never (almost) used templates in C++. Certainly not to the level I'm using them in D right now (metaprogramming for the win!)
Jan 21 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 21 January 2013 at 20:46:22 UTC, Philippe Sigaud wrote:
 On Mon, Jan 21, 2013 at 9:06 PM, H. S. Teoh 
 <hsteoh quickfur.ath.cx> wrote:
 On Mon, Jan 21, 2013 at 11:28:21AM -0800, Walter Bright wrote:
 It's the butterfly effect in programming.


 3 cases:

 1. unittests (as you mentioned)
 2. ddoc
 3. new lambda syntax
4. Templates. I never (almost) used templates in C++. Certainly not to the level I'm using them in D right now (metaprogramming for the win!)
Same here. I couldn't stand using templates in C++, but in D I use them every day, extensively.
Jan 21 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 21 January 2013 at 19:28:21 UTC, Walter Bright wrote:
 3. new lambda syntax
I wish you have fixed it (from http://d.puremagic.com/issues/show_bug.cgi?id=8774) http://d.puremagic.com/issues/show_bug.cgi?id=8832 http://d.puremagic.com/issues/show_bug.cgi?id=7978
Jan 21 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2013 1:21 PM, Maxim Fomin wrote:
 On Monday, 21 January 2013 at 19:28:21 UTC, Walter Bright wrote:
 3. new lambda syntax
I wish you have fixed it (from http://d.puremagic.com/issues/show_bug.cgi?id=8774)
8774 was fixed.
 http://d.puremagic.com/issues/show_bug.cgi?id=8832

 http://d.puremagic.com/issues/show_bug.cgi?id=7978
Jan 21 2013
parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 21 January 2013 at 23:14:16 UTC, Walter Bright wrote:
 On 1/21/2013 1:21 PM, Maxim Fomin wrote:
 On Monday, 21 January 2013 at 19:28:21 UTC, Walter Bright 
 wrote:
 3. new lambda syntax
I wish you have fixed it (from http://d.puremagic.com/issues/show_bug.cgi?id=8774)
8774 was fixed.
 http://d.puremagic.com/issues/show_bug.cgi?id=8832

 http://d.puremagic.com/issues/show_bug.cgi?id=7978
Indeed you did (as well as bunch of other issues), but there are still some non-resolved.
Jan 21 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 2:01 AM, Nick Sabalausky wrote:
 If I were a savvy businessman (read: no ethical fiber)
Now that came out of left field. Andrei
Jan 21 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 20:17:26 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/21/13 2:01 AM, Nick Sabalausky wrote:
 If I were a savvy businessman (read: no ethical fiber)
Now that came out of left field.
I'm not sure what point you're trying to make by lifting that (arbitrary?) part of my sentence out of its full intended context: "[portion actually quoted here], I would manufacture a line of fire alarms advertised as being 100% silent[...etc...]and sell them exclusively to programmers." The point, of course, being that preferring to forgo the safety and static checks that a static language provides is comparable to preferring silent fire alarms (Ie because they're both good things to be explicitly warned about, and deliberately silencing them is shortsighted and ill-advised). You seem to have latched on to some insignificant detail there and misinterpreted it, though I'm not sure exactly what or how. You're not suggesting that trying to sell non-working fire alarms would be *ethical* are you? I wouldn't think so, but I'm not really sure what your point is.
Jan 21 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 21:16:07 -0500
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Mon, 21 Jan 2013 20:17:26 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 On 1/21/13 2:01 AM, Nick Sabalausky wrote:
 If I were a savvy businessman (read: no ethical fiber)
Now that came out of left field.
I'm not sure what point you're trying to make by lifting that (arbitrary?) part of my sentence out of its full intended context: "[portion actually quoted here], I would manufacture a line of fire alarms advertised as being 100% silent[...etc...]and sell them exclusively to programmers." The point, of course, being that preferring to forgo the safety and static checks that a static language provides is comparable to preferring silent fire alarms (Ie because they're both good things to be explicitly warned about, and deliberately silencing them is shortsighted and ill-advised). You seem to have latched on to some insignificant detail there and misinterpreted it, though I'm not sure exactly what or how. You're not suggesting that trying to sell non-working fire alarms would be *ethical* are you? I wouldn't think so, but I'm not really sure what your point is.
Is it just that my metaphor was too wild/obscure/unclear? Sometimes my metaphors do get a little obscure/silly/unclear, I do try to avoid that, though perhaps not always successfully.
Jan 21 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2013 6:16 PM, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 20:17:26 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/21/13 2:01 AM, Nick Sabalausky wrote:
 If I were a savvy businessman (read: no ethical fiber)
Now that came out of left field.
I'm not sure what point you're trying to make by lifting that (arbitrary?) part of my sentence out of its full intended context: "[portion actually quoted here], I would manufacture a line of fire alarms advertised as being 100% silent[...etc...]and sell them exclusively to programmers." The point, of course, being that preferring to forgo the safety and static checks that a static language provides is comparable to preferring silent fire alarms (Ie because they're both good things to be explicitly warned about, and deliberately silencing them is shortsighted and ill-advised). You seem to have latched on to some insignificant detail there and misinterpreted it, though I'm not sure exactly what or how. You're not suggesting that trying to sell non-working fire alarms would be *ethical* are you? I wouldn't think so, but I'm not really sure what your point is.
I think he suggested the quote equated being a savvy businessman with having no ethical fiber.
Jan 21 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 21 Jan 2013 18:27:10 -0800
Walter Bright <newshound2 digitalmars.com> wrote:

 On 1/21/2013 6:16 PM, Nick Sabalausky wrote:
 On Mon, 21 Jan 2013 20:17:26 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 1/21/13 2:01 AM, Nick Sabalausky wrote:
 If I were a savvy businessman (read: no ethical fiber)
Now that came out of left field.
I'm not sure what point you're trying to make by lifting that (arbitrary?) part of my sentence out of its full intended context: "[portion actually quoted here], I would manufacture a line of fire alarms advertised as being 100% silent[...etc...]and sell them exclusively to programmers." The point, of course, being that preferring to forgo the safety and static checks that a static language provides is comparable to preferring silent fire alarms (Ie because they're both good things to be explicitly warned about, and deliberately silencing them is shortsighted and ill-advised). You seem to have latched on to some insignificant detail there and misinterpreted it, though I'm not sure exactly what or how. You're not suggesting that trying to sell non-working fire alarms would be *ethical* are you? I wouldn't think so, but I'm not really sure what your point is.
I think he suggested the quote equated being a savvy businessman with having no ethical fiber.
Ok, it was a misunderstanding of a minor detail then. That's not what I was saying. The "selling silent fire alarms" would clearly require a lack of ethics (either that, or at the very least a major deficiency in one's understanding of the purpose and usage of fire alarms - but that's getting even more pedantic). Or, if you wanted to be very euphemistic about it, or if the ethics were beside the main point being made (as was the case above), you *could* refer to it as "savvy businessman" even though that would quite obviously be only *part* of the truth and therefore somewhat of a mischaracterization. Hence the sidenote of "read: no ethical fiber". IOW: If I mention a red ball, I'm not calling all balls red.
Jan 21 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2013 7:17 PM, Nick Sabalausky wrote:
 I think he suggested the quote equated being a savvy businessman with
 having no ethical fiber.
Ok, it was a misunderstanding of a minor detail then. That's not what I was saying.
No prob.
Jan 21 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any 
 tutorials with D, books and other stuff. How about writing a D 
 programming forum?
Because the implementation still has very fundamental problems, like structs being bitwise-copied when they shouldn't be. Even that single issue by _itself_ causes numerous problems.
Jan 20 2013
prev sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On 2013-01-20 10:52, SaltySugar wrote:
 Why it isn't popular?  We must popularize it. There aren't any tutorials
 with D, books and other stuff. How about writing a D programming forum?
Hi, I have just return to D after some years of absents, so I am sorry if some of what I write is incorrect. == Massive open online courses (MOOC's) == According to this study http://www.youtube.com/watch?v=v2ITaI4y7_0 Many people pick up a new language when taking a course/education. With the reason rise of MOOC's (see https://class-central.com/) I think that making an interesting MOOC where D is used extensive would be good way to make D popular. I have taken some MOOCs and been exposed different languages in the process. 1) Octave in Probabilistic Graphical Models. 2) R in Introduction to Computational Finance and Financial Econometrics. 3) Python in Web Intelligence and Big Data, Software Debugging, Computational Investing. For me it is important that the course is not about D but about an interesting subject where D fit perfect as a tool. I have given it some thoughts and I think robotics is a good subject for such a course. You both need code which is close to the hardware and a language where you can make abstract AI algorithms. I think a course like "nand to tetris" (http://www.nand2tetris.org/) for robotics is highly needed, because for robotics a good foundation in mechanical-, electronic- and software-engineering is need and I don't know any single MOOC's which provide this foundation. == online documentation == When I returned to D I felt very frustrated with D online documentation. After looking for root of the feeling i found that the reason was that I was used to the documentation of php. In php each function have a page of it own. (Closely resembling the unix man page) This means that if I search for "php strip" google send me to http://php.net/manual/en/function.trim.php Where the first line tells me: trim — Strip whitespace (or other characters) from the beginning and end of a string So It is very fast to see if I got the right page. If I search for "dlang strip" I am send to http://dlang.org/phobos/std_string.html. Then I have to look through the document to find the right function and to find that functions typical is missing examples and good descriptions of parameters and return values. (I think that the example part can be improved by automatic including unittest in the documentation, which would also insure that the examples is working.) (When documents is generated ddoc could test for if description for parameters and return values was present) Also another thing I like about the php documentation is the user notes at the bottom of the page, I know you are trying to make something simmilar with the "Improve this page" and "Page wiki" at the top, but I have to say that I don't think it works as well. == Geting the job done == All in all I think the language popularity comes down to one central thing. "Does it get the job done" !! and it also the reason I have returned to D after years of absent. It is because of vibe http://vibed.org/ in the world of today almost every company have to have a web-site. So, there is a lots of jobs building web-sites, but D hadn't had a dissent web framework until now AFAIK. Remember that ruby was a small language before ruby on rails. While vibe have some way to go it is a good start. == Thanks, for all == While somethings could be better, I think D is amazing ! Knud
Jan 21 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Tuesday, 22 January 2013 at 04:22:16 UTC, Knud Soerensen wrote:
[...]
 == online documentation ==
 When I returned to D I felt very frustrated with D online 
 documentation.
 After looking for root of the feeling i found that the reason 
 was that
 I was used to the documentation of php.
 In php each function have a page of it own. (Closely resembling 
 the unix
 man page)
 This means that if I search for "php strip" google send me to
 http://php.net/manual/en/function.trim.php
[...] Check out the new experimental on-line documentation. http://vibed.org/temp/d-programming-language.org/phobos/std/range.html You can put in user comments too. Still not as good as it can be, but it's a big improvement over the existing documentation. The important thing is that D seems to always be improving, and the community is very active. --rt
Jan 21 2013
next sibling parent Robert <jfanatiker gmx.at> writes:
Wow! :-)

Thanks for this link. This is so much better! :-)

Best regards,

Robert


 
 Check out the new experimental on-line documentation.
 http://vibed.org/temp/d-programming-language.org/phobos/std/range.html
 
 You can put in user comments too.
 
 Still not as good as it can be, but it's a big improvement over 
 the existing documentation.
 
 The important thing is that D seems to always be improving, and 
 the community is very active.
 
 --rt
Jan 22 2013
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 22 January 2013 at 06:38:01 UTC, Rob T wrote:
 Check out the new experimental on-line documentation.
 http://vibed.org/temp/d-programming-language.org/phobos/std/range.html

 You can put in user comments too.

 Still not as good as it can be, but it's a big improvement over 
 the existing documentation.

 The important thing is that D seems to always be improving, and 
 the community is very active.
A little different; feels more like a table of contents and a brief overview of each feature/function unless you want more detail. Two minor dislikes, and both are the menu half on the left side. First, it's listing core, etc and then std; Obviously that's not horrible but std is likely the more used and should be at the top, etc and core I am not sure about, so reversing the order I would think is preferred. Second, the first level is automatically expanded, that's not a bad thing but with the core on the top skimming more what I want takes a little more time and navigation. I would say only have std expanded by default, or the tree you are currently in.
Jan 22 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 11:22 PM, Knud Soerensen wrote:
 == online documentation ==
 When I returned to D I felt very frustrated with D online documentation.
 After looking for root of the feeling i found that the reason was that
 I was used to the documentation of php.
 In php each function have a page of it own.
We need to get on this, pronto. Unfortunately Sönke Ludwig, who had a working prototype, doesn't have the time to work on it at this time. Anyone would want to pick up the torch? Just created http://d.puremagic.com/issues/show_bug.cgi?id=9370 Andrei
Jan 22 2013