Comments on Just a little Python: Dynamic Language Weenies?

I enjoy these debates, but part of me doesn't see ...

2007-11-08T22:46:00.000-05:00

I enjoy these debates, but part of me doesn't see the point. Is language X better than language Y? The language I happen to use at a given time is the one that--hopefully--will be best suited to the nature of the task at hand, and the constraints that will be imposed on me by the production environment.

It seems to me that the productivity gain one might experience with one language over another is dependent entirely on the nature of the problem. If I need to write to a socket, for instance, please don't make me use Java. Accessing memory directly is horribly painful in such a language.

Likewise, if I need to multithread, I need a language that doesn't mutex-protect the whole heap. That pretty much rules out all garbage collected languages.

Speaking of multithreading: in ten years' time, when there will be somewhere between 64 and 1024 cores on a chip that is tightly constrained by memory bandwidth, multithreading is going to be the only way to get performance out of it.

Surely linguists are not saying that all languages...

2007-04-02T21:37:00.000-04:00

Surely linguists are not saying that all languages express all ideas with identical concision and precision, right? I provide a simple counter-example in the French above (and yes, I know some French use the word for ninety). Of course all languages can express the same ideas, but one has only to look at the relative number of words in translations of various works to see that they do not express them all equally succinctly.

We are in agreement mostly, however ...

Put a little technically, linguists agree that all natural languages can be expressed with the exact same grammar. Hence, anything expressed in one language is equally easily expressed in other languages (a matter of words more at most).

Sapir-Whorf (and here we are in agreement) is probably valid for programming languages because the grammars of programming languages are different. And quite significantly. To take an extreme example, consider the Java grammar (which is at least Context-Free) and the instruction-set of some processor (which is not even a grammar but merely a collection of constant strings).

@andre:Thanks for your comment. Of course, you're...

2007-04-02T08:46:00.000-04:00

@andre:

Thanks for your comment. Of course, you're absolutely right. I was getting muddled myself when complaining about someone else's muddled thinking. ;-) My mental model was correct, but my vocabulary left much to be desired. Static typing is binding a variable name to a particular type, dynamic typing is tying the name only to the object (which likely has a "strong type"), and generally at runtime.

Late binding is kind of in-between, as you've tied a name to a hierarchy of types. I guess that's why the "safe" way to downcast in C++ is "dynamic_cast". But you're right that it falls into the static language camp.

Don't confuse static/dynamic typing with early/lat...

2007-04-01T21:42:00.000-04:00

Don't confuse static/dynamic typing with early/late binding. If you are defining static/dynamic typing to mean early and late binding, well, OK, I can't argue with that (although I will disagree the definition). C++ is statically typed, in the sense that the type of all variables are known at compile-time, but is late-bound via virtual methods, so that the method invoked is the one defined by the most derived subclass.

No virtual keyword: static typing, early binding. Virtual keyword: static typing, late binding.

I happened to see the last sentence first, you're ...

2007-04-01T20:57:00.000-04:00

I happened to see the last sentence first, you're tired of debating this - I'll bite my tongue.

Rick, I think it's telling that you didn't try to ...

2007-04-01T18:18:00.000-04:00

Rick, I think it's telling that you didn't try to answer these questions

Just getting tired of a discussion going nowhere, but here goes....

- "is it reasonable to say that Joe is more productive than you?"

It's reasonable to say that Joe is likely to be more productive than me (especially if the difference is consistently and strongly tilted in one direction), although I can't make a blanket statement that he is. It is more reasonable given that Joe was asked before completing the task to time himself (so we're not basing the results strictly on his memory). And without any objective evidence that refutes this iffy data, my bias is to accept it, at least in the general sense that scripting language programs tend to be shorter, slower to run, and faster to write than programs written in C, C++ and Java.

- "Does that really seem like a fair comparison to you?"

Fair comparison? No, there are a few things that are unfair. One major one is that the scripting languages had an unfair chance to advance in that time period. In fact, due to advances in all the languages studied (I know about some advances in Java and Python and assume there have also been improvements in C/C++, Rexx, and Tcl), the relevance today of the conclusions is questionable. It wasn't a paragon of scientific research, but then again, it's better than the zero studies that refute it. And from my perspective as someone who has achieved some level of mastery in both C++ and Python, and written similar applications in each, the productivity disparity between a competent C++ programmer and Python programmer, whether it be 2-3x improvement or 5-10x improvement (as it obviously would vary by programming task) does not seem extravagant to me.

In my opinion, take it or leave it, the improvement for dynamic languages will actually increase as projects get larger due to a) smaller team size (more done in less time means fewer coders are needed) leading to b) fewer interfaces, where interfaces between modules tend to increase development time and system complexity in a non-linear way. I would expect the "type safety" advantages of static languages to be mitigated by competently written unit tests which would, in the course of testing for functional bugs, automatically find most typing errors. It is, as I stated at the beginning of this paragraph, an opinion, but it is the opinion of a practitioner in both C++ and Python. Again, take it or leave it. And no, I don't think that this is "truthy," but I am tired of debating the point.

Rick, I think it's telling that you didn't try to ...

2007-04-01T16:51:00.000-04:00

Rick, I think it's telling that you didn't try to answer these questions
- "is it reasonable to say that Joe is more productive than you?"
- "Does that really seem like a fair comparison to you?"

rick wrote I think we understand each other here and just disagree on the value of the study.
It seems more than that.
It seems like you chose truthiness.

Re: isaacAs to the Prechelt study, I think that it...

2007-04-01T15:02:00.000-04:00

Re: isaac

As to the Prechelt study, I think that it contributes a data point that is not completely valueless (as in, equivalent in value to having never been performed, which is what the Hacknot article seems to believe.) It may have some methodological flaws, but without evidence to refute its conclusions, it's the best we've got. I think we understand each other here and just disagree on the value of the study. [Forrest Gump voice] And that's all I have to say about that. [/Forrest Gump voice]

As to the typing rants, I have put a disclaimer into the top of my article. The Hacknot author did indeed change his essay after I posted my response (at least once), and I don't particularly care to perform diffs every few days to let people know what he previously said. That's the danger to responding to something on the Internet, I suppose.

It seems a little strange that you both put forward higher-order functions as a strong advantage of dynamic languages and then characterize dynamic languages as "mainly imperative".

Higher-order functions are a feature of functional programming languages. Declarative programming is a style many or most functional programming languages use. This does not mean that HOFs are always declarative in nature (IMO).

rick wrote I think that the Prechelt study stands ...

2007-04-01T14:39:00.000-04:00

rick wrote I think that the Prechelt study stands as evidence. It may have some flaws which may or may not affect the conclusions of the study, but absent evidence presented from the C/C++/Java camp, it is at least something.
You are mistaken - if the Prechelt study has flaws which seriously undermine the conclusions then it's value as evidence disappears. (As-soon-as they discover your $100 bill is fake you lose $100.)

rick wrote If I remember it wrong, or if it's been corrected, you can throw out my typing rants.
If you want readers to pay attention to the other points you make, then maybe you should throw out those wrong or out-of-date typing rants.

rick wrote But my response (and the original article) was really more about comparing static languages of the C/C++/C#/Java type (imperative, no type inferencing, etc.) with dynamic languages of the Ruby/Python type (mainly imperative, no type inferencing, etc.)
It seems a little strange that you both put forward higher-order functions as a strong advantage of dynamic languages and then characterize dynamic languages as "mainly imperative".

(And there's a simple answer to this rhetoric - "I mean, come on -- do I really need to declare a pair class if I want a list of points? And a separate RGB class if I want color values? Give me a break" - if you don't need those classes, you can stick with a list of float arrays. But I'm digressing into details so I'll try and get back to a theme.)

rick wrote I think that the original author (on Hacknot) brushed off the Prechelt study much too quickly. ...
And dismisses it unfairly (IMO) without providing any evidence to counter his conclusions.
You are mistaken, the author did provide evidence, the author directed us to "read the paper [Prechelt's] carefully" - read section 3.6 "Validity: Are these programs comparable?" and you will find that Prechelt admits the very problems that the author complains about.

All the problems admitted by Prechelt gave advantage to the "script" programmers.

Let suspend disbelief for just a moment, take the results at face value, and use them as evidence for Stephen Deibel's comment "Python would use 10 to 20 percent of the amount of code that Java or C++ would use to write the same application."?
Prechelt wrote "We see that non-scripts are typically two to three times as long as scripts."
That's 30 to 50 percent not 10 to 20 percent.

rick wrote all studies of which I know (Prechelt's) support the dynamic language productivity hypothesis
Consider this -
a) we measure how long it takes you to satisfactorily complete a programming task
b) Joe satisfactorily completes the same task and we ask him how long he took
Joe says he took 2 hours and we measured that you took 5 hours - is it reasonable to say that Joe is more productive than you?

Prechelt measured how long the Java,C,C++ programmers took as part of a controlled experiment. He didn't measure how long the Perl,Python,Rexx,Tcl programmers took.

A year or two after the Java,C,C++ controlled experiment he did a newsgroup request for Perl,Python,Rexx,Tcl programs and asked the programmers how long they took to write the programs.

Does that really seem like a fair comparison to you?

Thanks for the quick reply. I believe you would us...

2007-04-01T09:47:00.000-04:00

Thanks for the quick reply. I believe you would use the '.' operator to do the operation you are talking about. There is no real ambiguity here, is it ?

Re: pierreI'm not a Perl expert, but I believe tha...

2007-04-01T09:21:00.000-04:00

Re: pierre

I'm not a Perl expert, but I believe that the following confusion can apply to Perl:

The deciding question here is whether the language implicitly converts unrelated types without warning, allowing you to add the integer 0 to the string "10" and arrive at the result "010" (or is it 11? I forget.).

But as a previous commenter pointed out, everyone has their own definition of strong/weak, so mine may not apply. IMO, any language that implicitly converts strings and integers is weakly typed because of ambiguities like the above.

In what way, Perl goes in the weak side of your fi...

2007-04-01T08:33:00.000-04:00

In what way, Perl goes in the weak side of your first strong/weak axis ?

Re: anonymous (on the linguistics issue)Good artic...

2007-03-31T23:19:00.000-04:00

Re: anonymous (on the linguistics issue)

Good article. I agree with you mostly but the following myth is Just Plain Wrong (TM)

"Language is a tool for expressing ideas. Some languages express different ideas more easily, or with greater difficulty, than others. Try saying ninety-nine in French, if you don't believe me (quatre-vingt-dix-neuf, literally four twenty ten nine)"

That is the Sapir-Whorf hypothesis which has been quite thoroughly debunked by linguists. See "Language Instinct" by Steven Pinker for details which are explained in lay-terms.

Surely linguists are not saying that all languages express all ideas with identical concision and precision, right? I provide a simple counter-example in the French above (and yes, I know some French use the word for ninety). Of course all languages can express the same ideas, but one has only to look at the relative number of words in translations of various works to see that they do not express them all equally succinctly.

Additionally, glancing over at the Wikipedia entry on Sapir-Whorf, it doesn't appear to be what I'm saying at all. Sapir-Whorf says that language affects the ability of the speaker to formulate ideas, not that it affects his efficiency in expressing them. So I don't think I'm supporting the Sapir-Whorf hypothesis at all with my natural language comment at all. (Though I may tend to agree with it when it comes to programming languages.)

Re: IsaacFirst off, thanks for your insightful com...

2007-03-31T23:11:00.000-04:00

Re: Isaac

First off, thanks for your insightful comment. I'll try to respond to each of your points, but due to my sleepiness I probably won't give them the attention they deserve ;-)

1) Show me the evidence!
afaict the big theme of "Invasion Of The Dynamic Language Weenies" is simply that extravagant claims are being made without evidence to back them up (aka BS aka Snake Oil). I don't think you addressed that at all.

I think that the Prechelt study stands as evidence. It may have some flaws which may or may not affect the conclusions of the study, but absent evidence presented from the C/C++/Java camp, it is at least something. And of course, there is the subjective "evidence" of the "converts" to dynamic languages. I think that the original author (on Hacknot) brushed off the Prechelt study much too quickly.

2A) Muddled thinking about typing
The terms we use to describe programming languages are somewhat muddled - different people have their own definitions.

The author of "Invasion Of The Dynamic Language Weenies" seems to acknowledge that - There is no canonical definition of a Dynamic Language, but some generalizations are possible.

afaict you don't actually address his description of dynamic languages at all but just list your own distinctions (axes).

Sorry if I wasn't as clear as I'd intended to be. I would describe most dynamic languages as strongly typed, where the Hacknot author would describe them as weakly typed.

[Actually, I just went back to the original article and it doesn't seem to have any reference to strong/weak typing at all. I could have sworn that the original had "weak" for the current "dynamic", and "strong" for the current "static." If I remember it wrong, or if it's been corrected, you can throw out my typing rants. ;-)]

That's what I was trying to get at. I also think he missed most of the productivity-enhancing features of dynamic languages over C/C++/C#/Java.

And then you write "The author ... conflates all three axes into strong versus weak".
No! - the author never mentions strong typing or weak typing.

You may be right. I either misread, or the article has changed.

2B) Muddled thinking about typing
Here's what one programming languages textbook says: 'So what is “strong typing”? This appears to be a meaningless phrase, and people often use it in a nonsensical fashion. To some it seems to mean “The language has a type checker”. To others it means “The language is sound” (that is, the type checker and run-time system are related). To most, it seems to just mean, “A language like Pascal, C or Java, related in a way I can’t quite make precise”.

Agreed. That's why I prefer to be a lot more explicit than say "strong/weak." And I may have misread the original article.

2C) Muddled thinking about typing
"The second axis is static versus dynamic typing, also known as early versus late binding."
Do you think when people say static typing and dynamic typing they might mean static checking and dynamic checking?

They might -- both as kinds of type safety, one check performed before runtime and one at runtime. In the case of Python, what I mean by dynamic typing is that objects have types, names (variables) do not. Names may be re-bound at runtime to objects of any type.

3) selective examples
"Ignorance of other strong advantages of dynamic languages ... built-in polymorphic containers and high-order functions"
You also accuse the author of ignoring other languages such as Haskell, ..., OCAML
Don't static languages like Haskell and OCaml and ... provide built-in polymorphic containers and higher-order functions?

Absolutely! I think that these static languages provide development environments that may be significantly more productive, produce higher-performing code, and provide greater assurance of correctness. But my response (and the original article) was really more about comparing static languages of the C/C++/C#/Java type (imperative, no type inferencing, etc.) with dynamic languages of the Ruby/Python type (mainly imperative, no type inferencing, etc.).

Isn't there an OCaml REPL?
Have you Googled for c repl? Tried cint or ch?

I haven't tried cint or ch, and have only fiddling-around experience with OCaml, so I can't comment on these. I know that my REPL in Python (IPython) has great introspection abilities, debugger integration, etc. While I'd expect that from OCaml (since so much of what they do impresses me already), I'd be surprised to find introspection in a C/C++ REPL, simply because the language support isn't there (RTTI doesn't even come close).

4) Show me the evidence! (Again)
The article's author doesn't need to take measurements to show that the extravagant claims made by others are not supported by evidence - he just needs to show that those others do not provide evidence for their claims. The burden is on the others to show their claims are true.

The author discusses Prechelt's study.

And dismisses it unfairly (IMO) without providing any evidence to counter his conclusions.

Writing "In fact, without exception, all studies ..." is another example of what the author is objecting to - it's an extravagant unsupported claim - show us the reference list of "all studies" so we can check that what you say is correct!

OK, that was probably overreaching on my part. What I meant was, "Here, we have this Prechelt study. What do you have? Nothing? Well, I guess that means all the studie(s) (however weak you may hold them or it to be) favor(s) our conclusion." I was basing my argument on the fact that all studies of which I know (Prechelt's) support the dynamic language productivity hypothesis, while I have seen none to refute it. I'll admit that's weak, but it's something.

Plus on a less persuasive, subjective note, it agrees with the experience of myself and the incredibly unscientific sampling of "people I know who have programmed professionally in both." ;-)

Another "best of both worlds" language like Groovy...

2007-03-31T22:01:00.000-04:00

Another "best of both worlds" language like Groovy is Boo (boo.codehaus.org). It's a CLI language with syntax copied from Python. Variables default to statically typed, but with type inference so you don't have to repeat yourself. You can explicitly declare variables as "duck" typed to get fully dynamic lookup.

So you get the speed and safety of static typing, with the convenience of type inference, and the convenience of fully dynamic types when that isn't enough, and nice clean Pythonish syntax (only better, because unlike Guido the Boo folks don't have a hate on for anonymous functions and higher-order-programming), and full interop with the enormous suite of .NET libraries.

Good article. I agree with you mostly but the fol...

2007-03-31T21:42:00.000-04:00

Good article. I agree with you mostly but the following myth is Just Plain Wrong (TM)

Language is a tool for expressing ideas. Some languages express different ideas more easily, or with greater difficulty, than others. Try saying ninety-nine in French, if you don't believe me (quatre-vingt-dix-neuf, literally four twenty ten nine)

That is the Sapir-Whorf hypothesis which has been quite thoroughly debunked by linguists. See "Language Instinct" by Steven Pinker for details which are explained in lay-terms.

However, the theory could be valid for programming languages. (A programmer who does not have functional programming is almost never going to think to use them.) But it has been proved that all natural languages are exactly equivalent to each other.

I think people get pissed off with the hype surrou...

2007-03-31T16:38:00.000-04:00

I think people get pissed off with the hype surrounding dynamic languages (I know I do) because sometimes it does seem to be driven by 'weenies' (ok, novices) that don't have the experience to evaluate it, and like it purely because its new, cool and allows them to work without discipline (thats not saying everyone uses them to work without discipline..). Of course its not new, e.g. ideas of functions as first class composable concepts is approx 100 years old.

I think you do Java (yes, its one of my favorites..) a disservice by saying it didn't introduce anything new. The delegating classloader model is something that the VM authors claim was novel for instance. As an aggregation of existing techniques, it also broke new ground - i.e. what they carefully discriminated what to put in, and what to put out, has turned out, even over a decade later, to have been quite astoundingly balanced and preciently cautious.

The current interest in languages that experiment with typing (python, ruby, kawa, javascript) feels to me like the mini explosion in imperative languages at the start of home computing. None of them seem to have got a good balance so far, they feel more driven by experiment - which is fine as no-one yet has the benefit of hindsight thats necessary.

I think in summary my message is, give it more time, and ignore the mudslinging.

Rick, great article. nice rebuttal, and very info...

2007-03-31T16:00:00.000-04:00

Rick, great article. nice rebuttal, and very informative.

thanks,
-Corey

----
www.goldb.org

Both "Invasion Of The Dynamic Language Weenies" an...

2007-03-31T15:54:00.000-04:00

Both "Invasion Of The Dynamic Language Weenies" and your response here are so long that it's difficult to comment without seeming to pick on small things so I'll try to stay with main themes.

1) Show me the evidence!
afaict the big theme of "Invasion Of The Dynamic Language Weenies" is simply that extravagant claims are being made without evidence to back them up (aka BS aka Snake Oil). I don't think you addressed that at all.

2A) Muddled thinking about typing
The terms we use to describe programming languages are somewhat muddled - different people have their own definitions.

The author of "Invasion Of The Dynamic Language Weenies" seems to acknowledge that - There is no canonical definition of a Dynamic Language, but some generalizations are possible.

afaict you don't actually address his description of dynamic languages at all but just list your own distinctions (axes).

And then you write "The author ... conflates all three axes into strong versus weak".
No! - the author never mentions strong typing or weak typing.

2B) Muddled thinking about typing
Here's what one programming languages textbook says: 'So what is “strong typing”? This appears to be a meaningless phrase, and people often use it in a nonsensical fashion. To some it seems to mean “The language has a type checker”. To others it means “The language is sound” (that is, the type checker and run-time system are related). To most, it seems to just mean, “A language like Pascal, C or Java, related in a way I can’t quite make precise”.

2C) Muddled thinking about typing
"The second axis is static versus dynamic typing, also known as early versus late binding."
Do you think when people say static typing and dynamic typing they might mean static checking and dynamic checking?

3) selective examples
"Ignorance of other strong advantages of dynamic languages ... built-in polymorphic containers and high-order functions"
You also accuse the author of ignoring other languages such as Haskell, ..., OCAML
Don't static languages like Haskell and OCaml and ... provide built-in polymorphic containers and higher-order functions?

not so much because compile time is prohibitive in static projects, but because the REPL (read-eval-print loop) is so freaking easy
Isn't there an OCaml REPL?
Have you Googled for c repl? Tried cint or ch?

4) Show me the evidence! (Again)
The article's author hasn't taken measurements, either. But Lutz Prechelt at least has some data, where the linked article presents none. In fact, without exception, all studies which have compared productivity in languages between compiled, manifestly, statically typed languages and interpreted, dynamically typed langauges have the dynamic languages easily winning out.

The article's author doesn't need to take measurements to show that the extravagant claims made by others are not supported by evidence - he just needs to show that those others do not provide evidence for their claims. The burden is on the others to show their claims are true.

The author discusses Prechelt's study.

Writing "In fact, without exception, all studies ..." is another example of what the author is objecting to - it's an extravagant unsupported claim - show us the reference list of "all studies" so we can check that what you say is correct!

Don't mean to criticize but some French use nonant...

2007-03-31T14:56:00.000-04:00

Don't mean to criticize but some French use nonante-neuf which is literaly ninety-nine. I'll go back to reading the rest of the article now.

I see that the above capture isn't a crash. I was...

2007-03-31T13:32:00.000-04:00

I see that the above capture isn't a crash. I was just referring to your statement:

If I then later break my promise, I won't get any useful restart options or diagnostics, but most likely an ugly crash.

I have looked into the Lisp condition system enough to be awed by it, but not enough to really use it (or comment on it) in a competent manner. I do realize that there's a big difference in power between Python's exception system and Lisp's condition system.

Of course, a debugger console is most likely not what you want in deployed code, but it's nice to have the option to find a bug, fix a bug, continue with the test where you left off. I know of no other language with that ability. I really do need to learn Lisp one day....

That isn't a crash. That's a debugger console. L...

2007-03-31T13:25:00.000-04:00

That isn't a crash. That's a debugger console. Lisp's condition system is far in advance of pretty much anything out there. It was asking if you want to try again with a different value. You could literally continue the program from that point with the new value. You don't need to restart the whole thing.

You can even recompile code and continue. That's what Lispers mean by dynamic language. Python and Ruby development is primitive by comparison.

Re: Matt M.I agree. CPAN, CTAN, PECL, PEAR, PyPI,...

2007-03-31T11:56:00.000-04:00

Re: Matt M.

I agree. CPAN, CTAN, PECL, PEAR, PyPI, and RubyGems are other examples. Hard for Sun or Microsoft to keep up with anything like that. And I'm guessing that the open-source nature of all the languages represented by the above repositories attracts programmers who are more interested in sharing their code than your standard Java/C# crowd.

Re: AnonymousPoint taken about LISP/Lisp spelling ...

2007-03-31T11:52:00.000-04:00

Re: Anonymous

Point taken about LISP/Lisp spelling -- I can never remember which way is currently accepted, as I don't really do any Lisp right now. But the article now has the "Lisp" spelling, at least.

I find your point about the dynamic+strong => static+weak change in using Lisp's static type checks intriguing. I think most languages with static type declarations enforce those declarations at compile time (to avoid the ugly crash you mentioned). Of course, the binary code is not type-safe, but the static language compilers can usually guarantee that the correct types will be used. I was not aware that in Lisp, the declarations were merely advisory to the programmer and not compulsory as in, say, Haskell or C++. It sounds like (from my limited experience) the worst of all worlds (weak, manifest, static typing) for the sake of performance. Is this a weakness, perhaps, of mixing static and dynamic typed names together in one program?

I ask because it seems like Pyrex and ML do something like mixed dynamic/static typing. (I know that ML is statically typed, but sometimes that type is "either A, B, or C".) The more the type inferencer can determine, the faster code can be produced. If the compiler can't guarantee the type of a parameter, however, it will fall back to the "safe" way of executing the code. That seems to me to be a better approach than trusting the programmer to remember all the "promises" made....

CPAN.org is the perfect example that community is ...

2007-03-31T11:50:00.000-04:00

CPAN.org is the perfect example that community is important to the use and adoption of a language.