January 21, 2013
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

January 21, 2013
On Mon, 2013-01-21 at 11:22 -0800, 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!

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, ===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.)

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.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 21, 2013
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
January 21, 2013
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
January 21, 2013
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,
> you can make your source file executable, put #!/bin/dmd at the 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
January 21, 2013
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
January 21, 2013
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!)
January 21, 2013
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.
January 21, 2013
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
January 21, 2013
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