View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2013
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
Re: D popularity
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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home