View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2013
Re: D popularity
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?
January 21, 2013
Re: D popularity
>> 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.
January 21, 2013
Re: D popularity
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.
January 21, 2013
Re: D popularity
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
January 21, 2013
Re: D popularity
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
January 21, 2013
Re: D popularity
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,
> > 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.
> 

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.
January 21, 2013
Re: D popularity
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 ;)
January 21, 2013
Re: D popularity
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.
January 21, 2013
Re: D popularity
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:
> […]
> > 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.
> 

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".
January 21, 2013
Re: D popularity
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.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home