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