Index » General » D popularity (page 5)

January 21, 2013
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
>> 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
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
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
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
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
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
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
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
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 10
Top | Discussion index | About this forum | D home