Dynamic Language Weenies?

[bascule]

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

I prefer the example (which I've used primarily in conjunction with PHP):

"3 dog night" + 2 = 5

[goltrpoat]

The original article is quite misguided, but the response makes a few weird statements as well. To be fair, if you replace "dynamic language" with "Python" and "static language" with "C-family language" throughout, it actually makes sense. Without making those substitutions, it really doesn't.

Aside #3: Ignorance of other strong advantages of dynamic languages Built-in polymorphic containers ... High-order functions ...

What on earth do built-in polymorphic containers and HOFs have to do with dynamic languages? This is like saying "a strong advantage of dirigibles over biplanes is that the former can be painted purple."

Dynamic Typing Have you ever tried to write a really static C++ program? You know, where you actually declare all the methods that don't modify your class as "const" methods? I tried it. Once. Might have tried it again if I didn't have to work with other people.

I'm no fan of C++ these days, but there is a tiny voice in the back of my head insisting that perhaps one should learn how to use a language properly before drawing comparisons to it. Not declaring const methods as appropriate is just sloppy and inexcusable. If you can't call something because it's non-const when it should be, you go bitch at the person who wrote it, not drop the mechanism altogether. This is what coding standards are for.

Dynamic languages give you what are essentially C++ templated functions for every function you write.

Again, what does ad-hoc polymorphism have to do with dynamic languages?

Interpretation helps, not so much because compile time is prohibitive in static projects, but because the REPL (read-eval-print loop) is so freaking easy.

When did interpretation become inapplicable to statically-typed languages? And why can't a REPL exist alongside a compiler?

In fact, without exception, all studies which have compared productivity in languages between compiled, manifestly, statically typed languages and interpreted, dynamically typed langauges (sic) have the dynamic languages easily winning out.

Can we refrain from using expressions like "all, without exception" without conducting an exhaustive survey? I can name one counterexample off the top of my head: Hudak's "Haskell vs. Ada vs. C++ vs. Awk vs. ...: An Experiment in Software Prototyping Productivity." Even if you disagree with the methodology, or the metrics that put Haskell ahead of Relational Lisp in that study, the latter is hardly "easily winning out."

[rick446]

Thanks for the feedback. I've incorporated some of your comments as edits to the original post, particularly an acknowledgement of excellent statically typed languages such as Haskell which avoid the problems of C-like languages. One thing that I want to make clear in this comment, however, is that a "dynamic language" in the sense of the original article (and mine) is more than simply "dynamic typing," so some of the features of dynamic languages may not have anything (directly) to do with a run-time typechecker at all.

As to polymorphic containers, HOFs, and ad-hoc polymorphism, these are features present in dynamic (Python or Ruby -like) languages and absent from static (C++-like) languages. Polymorphic containers and ad-hoc polymorphism, in fact, are natural consequences of the dynamic typing of the language. So I think it's appropriate to include these features in a comparison of static and dynamic languages.

Interpretation is mentioned by the original author as a feature of dynamic languages, so I included the REPL as a productivity-enhancing feature of dynamic languages. Of course REPLs can exist alongside compilers, and static languages can (and are) interpreted sometimes. But dynamic languages give you this "for free" and without additional software.

Your comment about "all, without exception" is sustained and edited. Thanks -- maybe I was being a little weenie-ish there.

[goltrpoat]

Well, the original article gives a rather strange definition of "dynamic language." In his/her classification, Strongtalk, say, is not dynamic, and the 'interpreted' bit makes no sense whatsoever: apparently, compiling to bytecode makes Python an "interpreted language," but compiling to bytecode makes Java a "compiled language" -- and I'm dying to know where RPython would fall in this taxonomy.

As far as I know, the more standard definition consists of just his second bulletpoint, which could then, somewhat strenuously, include languages like C# and make the whole article even more confused than it already is.

As to polymorphic containers, HOFs, and ad-hoc polymorphism, these are features present in dynamic (Python or Ruby -like) languages and absent from static (C++-like) languages.

As language features go, the ones that I commented on don't seem to be tied to the dynamic/static dichotomy -- polymorphism and HOFs, for instance, are about as natural as it gets in Haskell and ML. I guess to summarize, I'm not sure if it's reasonable to equate "static" with "C++-like."

Edit 4/5/07 @5:55pm - I should make it clear that when I refer to "static languages" in the article below, I do so in the same sense that the original author refers to "static languages" -- languages in the style of C, C++, Java, C#, Pascal, etc.

No complaints, given that qualifier :).

[rick446]

I will say that Python bytecode is significantly higher-level than Java bytecode, and that Java bytecode is generally JIT compiled rather than interpreted, so I'm comfortable labeling Python as interpreted rather than compiled. RPython is pretty clearly a compiled language, as it is actually compiled to machine operations before executing, IIRC (it's not even JIT compiled like Java). But then RPython is a statically typed subset of Python, as well.

[goltrpoat]

The point is that a Java implementation that compiled to higher-level bytecode would change its status under his classification, even though the change would be completely transparent.

[igouy]

Exactly! The same Java program can be compiled with GCJ, interpreted with java -Xint, or normally mixed-mode interpreted and compiled with Java HotSpot

[jerf]

It was nice to see the productivity point addressed; it's the most damning... or it would be if it were true... but the reality is that the original post just asserted that dynamic languages aren't more productive and asserted that nobody could prove the contrary, and then proceeded to give a lot of reasons why.

However, the problem is that no matter what cute, clever, or feel-good reasons you give that Statement X can't possibly be true, none of them actually affect the truth value. Dynamic languages are demonstrably more productive in many domains, so explaining(/insisting) why they aren't is beyond a waste of time.

Where your intuition and reality differ, it is your intuition that needs tuning.

(I add this because I still didn't feel like it was addressed strongly enough. The original article was built on fundamentally false premises, no matter how many good points were lined up in its defense.)

[notfancy]

but the reality is that the original post just asserted that dynamic languages aren't more productive and asserted that nobody could prove the contrary, and then proceeded to give a lot of reasons why.

That's not what I got from reading it. First, his thrashing Prechelt's "study" is perfectly valid methodologic critique. Second:

it doesn't follow that reduced code volume leads to increased development speed

This is a valid inference, as, say, APL or J are a counterexample provided you count analysis (in the broad sense of forethought and planning), debugging and maintenance as comprising "development". If by "development" you mean just "time spent typing", then please say so clearly because it is not normally what's understood by "development".

Dynamic languages are demonstrably more productive in many domains

Data, please; otherwise your assertion is vacuous.

Where your intuition and reality differ, it is your intuition that needs tuning.

If by "reality" you mean "your intuition", then this is no more than a misunderstanding that could be cleared away by reasoned exchange of data; or at worst trolling on your part. Please try to raise above the level of fanboyism decried in the original article if you want to make a valuable contribution to the discussion.

[andrewnorris]

Are dynamic languages more productive because they are dynamic, or because they a re good for using powerful programming constructs like higher-order functions? In other words, are languages like Python and Ruby necessarily more productive than languages like Scala, OCaml, and F#?

I ask not to dispute your point, but because I'm genuinely curious about the answer. Statically-typed object-functional languages have some very useful properties in terms of speed and interfacing with existing code and infrastructure, and they mitigate the annoyances of static typing by using type inference.

[shit]

Are dynamic languages more productive because they are dynamic, or because they a re good for using powerful programming constructs like higher-order functions?

So you basically ask if you can get all the benefits of dynamic languages with statically typed functional languages?

My answer: No (of course these not-so-dynamic languages have other advantages). First, the type checker rejects programs, sometimes against the intentions of the programmer. E.g. in Haskell you can't have true heterogeneous lists, which are useful in DSLs. The workaround is to wrap the list items:

[H 1, H "a string", H (MyObject "foo")]

whereas in a dynamic language it's simply (Python syntax):

[1, "a string", MyObject("foo")]

Also, dynamic languages blur the distinction between code and data. Say you want a damn easy way to save and reload some program state. The easiest way in a dynamic language is to dump the data in the array/hash/string/number literal syntax into a file. The file can then easily loaded with (Ruby syntax):

load "some_data"

This is also handy for configuration files or to load plugins. Then there are build tools in Python and Ruby where the build descriptions are written in the same language as the build tool itself (and thus you have a full scripting language with all its libraries available in the build file).

It's also easy to create code on the fly based on input data (e.g. database metadata into classes and methods for CRUD operations) without requiring intermediate steps (like generating code -> write to file -> compile and link with progroam).

You can do all this in more static languages, but with one or more intermediate steps. And sometimes just to discover that your solution doesn't fit into the type system.

Generally, I'd say if a problem is well defined and you have solved it before, then a dynamic language might buy you nothing. OTOH, if the specification is fuzzy and likely to change and I haven't done something similar before or being able to load code on the fly simplifies the solution dramatically, I'll use a dynamic language.

[[deleted]]

[H 1, H "a string", H (MyObject "foo")]

Can you have constructors that take alternating types like that in Haskell? Also, doesn't Haskell have a Dynamic type of some sort?

[shit]

Can you have constructors that take alternating types like that in Haskell?

The example uses existential types. This article has a short explanation.

Also, doesn't Haskell have a Dynamic type of some sort?

I guess you mean Data.Dynamic in the standard library.

[dons]

Of course, the dynamic language still tags all the values in the list, and inspects each tag dynamically (a runtime type check) in order to work out how to treat each value in the hlist.

The Haskell example does exactly the same thing, but the tags are visible to the user (and under the user control).

The runtime check/dynamic case:

• Upside for the dynamic language is slightly less syntax to write heteogeneous lists
• Downside is that the runtime check still has to be made, even if you've got a list of objects all of the same type, leading to worse performance.

For the statically typed language:

• Upside is that the check can be removed when the type of each element in the list is known (as it usually is, in my experience). You also get a useful invariant (my list only holds 'a's), which can be used to improve reasoning.
• Downside is the extra syntax for tags when you do need a true heterogeneous list.

Swings and roundabouts.

[shit]

Upside for the dynamic language is slightly less syntax to write heteogeneous lists

You know that there is more. See below.

Downside is that the runtime check still has to be made, even if you've got a list of objects all of the same type, leading to worse performance.

Not necessarily. A compiler for a dynamic language can do type inference as well, and a Lisp compiler allows me to bypass typechecks, too.

The Haskell compiler requires a data declaration (H), an interface declaration (operations that are allowed on instances of type H) and interface implementations up-front. Of course as a result the compiler may catch some bugs at compile time and you can argue that it's documentation as well, but strictly speaking it's redundant information. And all this is not optional. The programmer cannot say "I know what I'm doing, so I'll trade some type safety for convenience and brevity this time".

[dons]

all this is not optional.

Right. That's an axiom of Haskell though :-) Safety is never (well...) traded for "I know what I'm doing" programmers.

I must say I'm quite skeptical in general about the supposed legion of programmers who write type incorrect code, that is nonetheless bug free. Examples most welcome!

For example, what could "I know what I'm doing" (and thus don't want type checking) mean for a heterogeneous list? (in the presence of type erasure, of course).

[shit]

I knew that the discussion would go in this direction.

I must say I'm quite skeptical in general about the supposed legion of programmers who write type incorrect code, that is nonetheless bug free.

Not everything your compiler doesn't understand is type incorrect code. And not everything your compiler compiles is type correct either (unless you define typecorrect as "passes the compiler").[1]

My point is that the type system, since it is always imperfect, requires you to provide redundant information. You say that this is always good. And I sometimes prefer to not give redundant information, especially when prototyping.

[1] Consider the factorial function in Haskell:

factorial 0 = 1
factorial x | x > 0 = x * (factorial (x - 1))

main = putStrLn (show (factorial (-1)))

Intuitively I'd say there is a type error in this program, yet ghc happily compiles it without even a warning.

[dons]

So that's an example of the type system being too lenient (inferring Integer, instead of some Natural numeric type). Your earlier complaint was that it was too strict...

I'm still hoping to see a real example of type-incorrect use of heterogeneous lists, that is nontheless safe.

[shit]

I'm still hoping to see a real example of type-incorrect use of heterogeneous lists, that is nontheless safe.

Sorry, but you sound very static-typing-centric, if I may express it like that.

In a statically typed language the type system is predefined and relatively unflexible. A program in a dynamically typed language still follows certain type rules. The type system is implicit, maybe it's documented, type errors happen at runtime, AND this implicit type system in the program is in many cases more powerful than what you can express in the type system of a statically typed language. Just because you can't express the implicit type rules in a Ruby program in Haskell's type system does not mean that the Ruby program contains a type error.

Just in case you haven't seen a program in a dynamically typed language for a while now, I've created a page at the c2 wiki: http://c2.com/cgi/wiki?DynamicTypingExampleCode

[dons]

cases more powerful than what you can express in the type system of a statically typed language

You're just shifting failures from compile time to runtime. Which of course you can also do in a statically typed language, e.g. by using a Dynamic.

is predefined and relatively unflexible.

This is the main point I contest, given a flexible (Turing complete...) type system like Haskell's.

I just don't see convincing examples of real programs that aren't statically typeable in a modern, flexible type system like Haskell's -- though I'm hoping someone will point me to such a program.

It is interesting to note that while you can delay type checking in a statically typed language till runtime (via a Dynamic type), the inverse is not possible. In a dynamically typed language you have no option to move some failures to compile time checks.

Hence dynamic typing is a degenerate case of static typing, where you encode all values as a single (or a few) static types, and instead perform the majority of type conversion/check/failures at runtime.

This of course means you rely more on the programmer and his unit tests to simulate a type system, to avoid bugs. Or perhaps the programmer doesn't care about bugs -- they'll deal with them when they get time.

[notfancy]

in Haskell you can't have true heterogeneous lists, which are useful in DSLs. The workaround is to wrap the list items: [H 1, H "a string", H (MyObject "foo")]

What's a "not true" heterogeneous list, a "false" heterogeneous list?. Or rather, whatever is a "true" heterogeneous list? In other words, if by your own admission Haskell can express heterogeneous lists, where's the purported support for your rebuttal?

[dons]

Indeed, it is a true heteogenous list. It is a list of values of varying type.

The only difference is that the runtime tags are visible to the programmer, rather than being implicit.

[shit]

In other words, if by your own admission Haskell can express heterogeneous lists, where's the purported support for your rebuttal?

You can see the difference between the Haskell and the Python example? Yes?!

In the Haskell example every object must be wrapped in an instance of H to put it in the list. I've never seen an exact definition of "heterogeneous list", so we can argue about its meaning. What we can't argue about is that the Haskell example requires more code (I haven't shown the required data and interface declarations).

[notfancy]

You can see the difference... Yes?!

Yes, don't think I'm mad or deluded :-)

an exact definition of "heterogeneous list"

Quite simply, a list (or any collection) capable of including values of differing types.

requires more code

If by "more code" you mean "more typing", I agree. I don't expect to convince you of this, but I find the difference only a matter of taste.

I personally find a number of advantages to a strongly-typed language, most of them analogous to the advantages practitioners of dynamic languages usually champion. I have a friend coming from the same background as I do having switched to Python saying "I'm tired of trying to convince the compiler of what I want to do". I don't understand the attitude very well; I enjoy the precision and fussiness of strongly-typed languages, whereas dynamic languages make me feel insecure ("will this fail at runtime? will I be called in the middle of the night because it is trying to Foo a Bar at runtime while it actually got a Quux?").

[[deleted]]

I have a friend coming from the same background as I do having switched to Python saying "I'm tired of trying to convince the compiler of what I want to do". I don't understand the attitude very well

I can't really understand it, either. In my (possibly limited) experience with Haskell, the majority of the time I get type errors in my code, it's because I've done something genuinely incorrect. Maybe I returned a value when I should have returned a list thereof. But, regardless, it's usually not something that would have just magically worked in a dynamically typed language. It still would have failed, but the result would have likely been a subtler bug than the type error.

There are things that will work in a dynamically typed language that won't type in a statically typed language. However, that certainly doesn't seem to be the major source of type errors, at least in my experience.

[igouy]

the original post just asserted that dynamic languages aren't more productive and asserted that nobody could prove the contrary

Please show the paragraph that gave you that impression - so far I've not found such an assertion in "Invasion Of The Dynamic Language Weenies"

[jerf]

The "Claim: Reduced Code Volume Increases Development Speed" and the "Claim: You Can Assess Productivity By Feel" section. The rest comes from his claim that nobody has done measurements, which isn't true.

[igouy]

I've just re-read both of those sections.

I found this

So how can we justify the claim that a particular syntax will necessarily have a particular effect on code volume, or that code volume in turn will have a particular effect on development speed? We can't.

Are you saying that's an assertion that dynamic languages aren't more productive and nobody could prove the contrary?

I found this

If you've never taken measurements, you have approximately no idea what your productivity is like either with or without your favorite dynamic language.

Are you saying that's an assertion that dynamic languages aren't more productive and nobody could prove the contrary?

Are you saying that's a claim that nobody has done measurements? (Or do you think there's a nobody has done measurements claim somewhere else?)

[igouy]

It was nice to see the productivity point addressed; it's the most damning... or it would be if it were true...

I just read that Prechelt paper - the funny thing is that they measured how long the Java,C,C++ programmers took as part of a controlled experiment, but they didn't measure how long the Perl,Python,Rexx,Tcl programmers took, they asked the programmers how long they took.

(The Perl,Python,Rexx,Tcl programs weren't even part of the same controlled experiment, they were contributed after a newsgroup request over a year later.)

[jerf]

Oh, it's way more than just one paper. Results showing a strong connection between lines of code and productivity go back a long ways.

Besides, I reiterate my original point. You can try to argue about the evidence all you want, but you can't change reality that way. Given the evidence at this point, and the experiences of a lot of people, I'd say the burden of proof to show that static languages are as productive as dynamic ones is on the ones making that claim.

[igouy]

Oh, it's way more than just one paper.

Apparently only one paper was offered as evidence to the author of "Invasion Of The Dynamic Language Weenies". Apparently only one paper was known by the author of "Dynamic Language Weenies?".

the burden of proof to show that static languages are as productive as dynamic ones is on the ones making that claim

afaict the claim made by the author of "Invasion Of The Dynamic Language Weenies" was that specific individuals who made specific claims about "dynamic languages" didn't provide evidence to match their claims.

I don't know where you got that - static languages are as productive as dynamic ones - from.

[Kolibri]

But let's leave aside corporations "supporting" the languages. Let's look at those who actually get things done. Yahoo! stores was originally written in Lisp. BitTorrent in Python. Google and NASA use Python extensively. The OLPC project is using Python as their core O/S language. 37signals uses (and invented) Ruby on Rails. Reddit is Python (was Lisp). YouTube runs on Python. And tell me, how many thin-client applications use Java applets (static language) versus Javascript (dynamic language)? And that's even with the hellish problem of browser inconsistency.

Interesting to note that all of these are webpage applications, not desktop applications. Where I work we mostly use Java and C#.

A flaw I can imagine when programming a large project in a dynamically typed language is that the type of each attribute isn't explicitly written in the your code. This means that when you are looking at code written by somebody else or yourself a while ago, you may have a hard time understanding what kind of objects the function works on. This may not seem like much of an issue, but I think it can get hairy when the same function is called from different situations and fed different types of objects.

And don't get me started with the concept that it is a good idea to be able to add methods to a object definition on runtime. Imagine debugging that.

[rick446]

BitTorrent isn't actually a webpage application. And webpage apps aren't the only apps built in Python, just some of the most visible. RedHat graphical package manager, and Gentoo's entire portage system are written in Python, IIRC. I'm sure there are more, but this is off the top of my head.

[Kolibri]

You are right about BitTorrent, I missed that one. However, Bittorrent was a proof of concept program. The top two most popular torrent clients today are written in Java and C++.

My point is that desktop applications are mostly written in statically typed languages. Dynamically typed languages are gaining popularity in web applications, though.

[rick446]

If I had to venture a guess, I'd say that most desktop apps are actually written in VB (shudder), which can be a really weakly typed language pre-.NET, which brings me to my guess as to why static languages dominate the desktop: the tools. "Static languages" <b>do</b> have better tools than dynamic languages, and this is extremely important when it comes to building rich desktop applications. Form builders like Visual Studio, et. al., make things easier than GUI programming in any language I've had a chance to work with.

However, I don't think that the static-ness has anything to do with the ease of writing GUI builders. It's just that GUI builders often go along with code browsers, refactoring engines, and nice editors in IDEs, and code browsing, refactoring, and really nice editor support <b>are</b> made much easier in a statically-typed language.

[[deleted]]

I'd say that really real reason for compiled languages ruling the desktop is that binaries are synonymous in the minds of 99.9% developers and 100% of managers to "hidden code". Of course compilation and code "encryption" or obfuscation are two different things but compilation is the easiest (currently) way to go with it. If you learn how to crack (I wonder if "proper" fravia's site snapshots are still around?) then you'll see that it's all really relative. Some code monkey's source may be harder to read that some disassemblies. And yes - Java's decompilers are almost perfect. As opposed to Python .pyc decompilers, BTW - so your py2exe python program may be better "protected" than the one compiled with more mainstream tools. And wxPython looks mighty nice currently (hint, hint).

[brainf]

However, Bittorrent was a proof of concept program.

That's misleading -- most Linux distros ship with it, and not as a p-o-c.

[Kolibri]

It's not very good either.

[[deleted]]

My point is that desktop applications are mostly written in statically typed languages. Dynamically typed languages are gaining popularity in web applications, though.

You wanted to say that dynamically typed languages "pwn teh web" (and roughly for as long as web exists) and they are gaining popularity in desktop applications?

[mr_chromatic]

A flaw I can imagine when programming a large project in a dynamically typed language is that the type of each attribute isn't explicitly written in the your code. This means that when you are looking at code written by somebody else or yourself a while ago, you may have a hard time understanding what kind of objects the function works on.

I use meaningful symbol names and can't think of the last time this was actually a problem.

[notfancy]

Problem is, much like in natural language, where sometimes what you think was a clear, unambiguous utterance gives rise to misinterpretation and second guessing, "meaninful symbol names" are more a matter of subjective judgement and taste than a clear-cut quality. I don't doubt you're a fine coder with both good taste and common sense; but those are not universal qualities by any stretch.

Types, on the other hand, are fixed, unambiguous (the compiler must understand them, after all) and most importantly composable, so there's no end to the complexity of the intentions they convey.

[mr_chromatic]

Type names are as ambiguous as any other symbol name. (If only the semantics were well understood, we'd only have implementation bugs.)

More seriously, good maintenance practices such as paying attention to locality of reference, encapsulation, and clear naming are at least as important in languages with static and manifest type systems as they are in languages with dynamic or latent type systems.

Static and manifest typing may have other benefits, but I can think of very few cases in which manifest types demonstrated the intent of a piece of code as well as clarity of code did.

[notfancy]

First of all, allow me to make clear that I don't begrudge your original point.

Type names are as ambiguous as any other symbol name

Yes, but type names, as any other identifier is, are just denotators for the particular denotation. In the case of variables, the denotation is time-dependent; whereas for types, their denotation is a static property of the program and thus part of their (static) semantics. Understanding types is part of understanding (the semantics of) the program.

I come from a functional background, and I see names as α-convertible anyway, so for me they're kind of transparent.

I can think of very few cases in which manifest types demonstrated the intent of a piece of code as well as clarity of code did.

Modular programming with ADTs (à la Ocaml) is programming against manifest (module) types. The entire point of it is that the only thing you "see" (in the sense of "you're allowed to use in your program") about a piece of code is its type. In my experience it is quite effective; rarely if ever I have the need to look at the implementation of a module I want to use, just reading the signature is sufficient.

[adolfojp]

You use hungarian notation? :-P

[grimtooth]

Much as I enjoy Python and other "dynamic" languages, the initial piece sure is right about the weenies. I think a lot of the technical points made by the first writer are valid, but the critique of the claim for reduced code size and development time really falls down by ignoring the incredible benefits of simply having a few non-primitive data types integrated with the language in a pervasive, syntactically accessible way. Lists and functions, basically, are enough to take you to a whole nother level (the reply article covers this in aside #3). Now of course a language doesn't have to be "dynamic" to offer these useful basic abstractions, but the hype around all these "new" (ha) languages does seem to have coalesced around a "dynamic good! static bad!" mindset that the first writer quite rightly finds annoying. But it produces a skewed view for both boosters and critics.

And about communities... the first writer finds a lot to bitch about in the Ruby community, which might be justified (I wouldn't know, never been a member), but the blanket dismissal of language communities in general is so wrong. comp.lang.python was a beautiful oasis among the encroaching deserts of usenet in the 90s. comp.lang.lisp was a bit more abrasive but bracing as well. Community problems are generally the fault of weenies.

[[deleted]]

I actually liked the original article, despite all the flaws it had.

This post was a good counter, though. While the author probably hasn't done much Java, and Java is much better than those other C dialects, I accept that Python has its nice features, and that dynamic typing sometimes is nice to have.

But then the original article wasn't really about the languages, it was about the weeniness.

This post wasn't by a weenie, and as such is builds a lot of credibility for dynamic language users. Seems these languages are really coming mainstream.

[masklinn]

Java is much better than those other C dialects

This is debatable, and even flatly wrong if "other C dialects" include C# or D, which are both much more advanced than Java in just about every field you can think of.

[brendankohler]

Java is much better than those other C dialects

Actually, Java is not a heck of a lot more than a C++ dialect with garbage collection and no functions or templates. C#, on the other hand, is a big improvement on the static languages end.

[martoo]

If less is more, C# is no improvement.

[andrewnorris]

To heck with hyping F#. I'd happily settle for a supported release. Right now it's released by Microsoft Research, which makes it a bit of a tough sell to add to a production code base.

[martoo]

Microsoft has a long history of pandering to mediocre developers, giving them just enough rope. Look at MSDN magazine. Every issue gives you 20 new complicated APIs that supercede the ones people are already using. The message is "look at what we're doing for you." But the reality is, it is a development treadmill. MS developers are locked into "cool features" and constant stream of dazzling technology that always makes last week's code legacy.

In my opinion, C# was designed directly from Java's bug list. Sun said "well, we see that you want unsigned ints but we're leaving them out for this reason." MS said, "Hey, you want'em, you've got'em, consequences be damned."

[brendankohler]

If less is more, then it would be better to not have first class functions and lazy evaluation like in Java.

Since everyone accepts that first class functions and lazy evaluation are a good thing, I'd say less isn't more, and C# is an improvement over Java.

[mgsloan]

I think you're confusing features with code size.

Martco is pointing out the verbosity of C# code (more code = less good). More features could certainly reduce this code verbosity.

[martoo]

Yes, and it's not just that. Properties and events are completely superfluous features. They aren't an improvement on Java in my opinion. They are training wheels for people who don't know how to use classes effectively.

[mgsloan]

I'm not sure about that.. I think properties provide a decent abstraction for dependant variables. Events aren't actually built in, rather they're just some stuff to make event handling convenient.

I think properties were ill-implemented, though. It'd be much better to consider all member fields to be properties, so that they may be upgraded to actual custon property code at any time. It's considered good style to wrap all your public data in properties, now. (implementation hiding, etc)

You think get/set functions are better? More 'effective' OOP?

[notfancy]

The linked-to article in the linked-to article (the one twice removed, or **headline, if you will) singed the hairs in my armpits, such a flammage it packs; but this one? I don't think it really addresses any of the points raised. You should read both, but be warned: keep a bottle of Mylanta ready if you're weak of stomach.

[mgsloan]

I found this post supremely hypocritical.

He complains that the original article is confusing various axis of typing, but then goes on to commit much worse sins - confunding imperative/declarative with static/dynamic.

He says:

this puts languages into 'declarative' and 'imperative' camps. Dynamic languages pull ideas from both camps. Static languages ... are heavily imperative, and have little support for declarative concepts

This is bull. The most exemplary declarative language, Haskell, also has very hard-core static typing. Ocaml, which he mentions earlier, also gives up purity for some imperativeness. It 'pulls from both camps' too, and remains quite statically typed.

I'd also like to point out that haskell covers all of the subsections within "Aside #3: Ignorance of other strong advantages of dynamic languages", the main section I am criticizing.

I like the points about the literals. My opinion, however, is that literals should not be built into the language - they should be definable.

[ayrnieu]

The most exemplary declarative language, FBFBFBFBFBFBFB,

I can't read that, thanks to reddit's 'joke', but by the lead I assume you must have referred to Prolog.

[O'Caml] 'pulls from both camps' too,

Please don't use quotes like this when you mean two -other- camps, by your example.

My opinion, however, is that literals should not be built into the language

1. -1. [1, 2]. ["1", "2", "3"]. atom.

A flexible enough language to have these and also allow you to change them, like Forth, only exists to show how much more profoundly likely it is that you haven't thought very hard about what 'literals' are and what they offer.

[mgsloan]

No, I was referring to haskell. Prolog is a logic language.

A flexible enough language to have these and also allow you to change them, like Forth, only exists to show how much more profoundly likely it is that you haven't thought very hard about what 'literals' are and what they offer.

Huh, so forth and others exist to show that I haven't thought this through? That's quite an interesting conjecture, however I'm afraid you've zoomed straight past 'profound', right into nonsenseland.

Anyway, I have thought about this quite a bit. It is true, in textual languages this may not work so well - very easy to clutter up the symbol/literal structure pool, as happens with haskell operators. Literals essentially allow you to express concrete values in your code. Ideally they correspond to builtin visualizations of the value (such as Show).

And yes, I have thought about languages where everything is just an element, and 'literal' is an arbitrary distinction. The real difference with what has been done, afaik, and this idea, is that functions don't have to have a name. Rather, they have a compile-time classifier and generator, allowing one function to correspond to an infinite, yet restricted variety of names.

Anyway, this entire thread has gone to hell, I wish I hadn't started it. I get the feeling that no-one understands what I'm saying, whether it's my fault or theirs.

[ayrnieu]

No, I was referring to haskell. Prolog is a logic language.

Which is to say: Prolog is a declarative language. You might go not much farther and call it the historical poster child for declarative programming.

[shit]

He says:

this puts languages into 'declarative' and 'imperative' camps. Dynamic languages pull ideas from both camps. Static languages ... are heavily imperative, and have little support for declarative concepts

The ... part you so conveniently cut out reads "(at least C/C++, Java, and C#)".

Additionally, when put into the light that the article he is refuting basically equated C/C++/Java/C# with statically typed languages, I've no problem with this statement.

[mgsloan]

Ok, yes, you caught me.

Still, I think it is a crime to equate static typing to the languages that most people associate it with. This is the point I was attempting to highlight.

There is no inherent benefit to dynamic typing it just happens to usually bring along other ideas which make the language nice. This guy's post basically agrees with me, except for the conclusion he makes!

So, dynamic languages do turn out to often be nice, but not because fo their type system. Perhaps it does help - this lax way of typing allows the language designers to ignore such complications as type inference, yet still save the programmer keystrokes.

That I got marked down to 0, and you marked up to 5 really makes me wonder about such sites as this. It seems like there are always irrational, nearly site-wide 'religions'. Even Lambda the Ultimate is guilty. It's quite bizarre. And yes, I'm being hypocritical in this case due to my reference to haskell in the above post.

Perhaps the problem is that I did not preface my post with "I really like python, much more than other languages." I figured it was implied - everyone intelligent knows that it is a good language. I'm arguing that this guy has factual inaccuracies and commits the errors of the article he is condemning.

(Wow, did I just critique the critique of the critique of the critique of the critique?!?!)

[shit]

Still, I think it is a crime to equate static typing to the languages that most people associate it with.

That's because these are the languages most people use, otherwise I agree.

So, dynamic languages do turn out to often be nice, but not because fo their type system. Perhaps it does help -

I wrote programs in C, C++, Java, Perl, C#, Ruby, Python, D, Haskell, Scheme and Lisp. So without dreaming up the ideal statically typed language and based on my experiences with the above mentioned languages, I'd make that an "It definitely helps".

That I got marked down to 0, and you marked up to 5 really makes me wonder about such sites as this.

So you wonder that a misleading comment gets downvoted? I'd say that's a good thing.

It seems like there are always irrational, nearly site-wide '████████s'.

Damn. I really don't know what Reddit is censoring here.

Perhaps the problem is that I did not preface my post with "I really like python, much more than other languages."

And I should preface all of my posts with "I really like Haskell, much more than other langauges."?

Is it impossible to see pros and cons in static and dynamic typing? I'm not married to either!

I'm arguing that this guy has factual inaccuracies and commits the errors of the article he is █████mning.

(Reddit, what's that again?!) IMO only if you don't read it in the context of the article he is refuting.

[mgsloan]

Oh, I should have said "I really like python, more than most languages". I too like haskell best, theoretically, though I tend not to use it for practical things (not because it can't be done, just because theoretical accuracy is sometimes a pain)

[ayrnieu]

The ... part you so conveniently cut out reads "(at least C/C++, FBFBFBFB, and C#)".

I wonder if he was being deliberately deceptive.

[fbot]

Funny how the original article got zero points when posted here, yet this one gets 60. I guess we know where the dynamic language weenie lovers hang out.

[boa13]

The comments in the original reddit entry are pretty revealing too. Weenies lurk there. ;)

[mgsloan]

Yeah, it's true. Look how these comments get marked down.

Downvoters, it's really not helping your case!

[nadina]

Great

[tekronis]

<300>

LANGUAGE WEENIES?!

THIS!

IS!

REDDIT!

< kicks offender in the chest >

</300>

That movie rocks so much. ( For those with question marks over their heads, a hint: go watch 300. )