The End of Dynamic Languages

Interesting given the open sourcing of Swift today. One of the main complaints (more from the smalltalk style side) is that Swift grafts static types onto Obj-C in a way that makes it worse or at least difficult to do many things.

The point about IDEs is good too. Most dynamic languages don't have great IDEs IMO.

@Clark It can be confusing to discuss because there are several separate issues that get lumped into what sounds like a binary choice between static and dynamic: types, generics, data structure style, dispatch, etc.

"Most of the mainstream ones out there today were designed by amateurs, people with no formal CS background, or no adequate background in compiler construction."

*picks up jaw from floor*

This has to be the most ridiculous things I have ever read.

Brendan Eich (JavaScript), Yukihiro Matsumoto (Ruby), John Osterhout (Tcl), Guido van Rossum (Python), and Larry Wall (Perl) are not amateurs. What arrogance and snobbery to assert such a thing.

"Cowboys to the left of me,
Martinets to the right..."

Actually, the sensible thing is to have a soft, latent type system which can be progressively hardened to provide improved correctness checks and performance optimization. That would allow code to scale from quick-n-dirty hack or exploratory prototype (when it's more important to work fast, test fast, and throw away often, without having to dot every single 'i' before it even runs), to a stable polished application (when it's important to prove correctness before you inflict it on users) according to changing needs. But, you know, programmers.

@Clark: A lot of what you describe are bad ideas like Cocoa Bindings, which is an abomination unto itself, or Core Data, which just does at run-time what ought to be done at build-time. For gluing View to Model you really want a declarative DSL, something that moves time and sequential control decisions out of the programmer's hands and into the machine's. (I'd say 'FRP', but that term's already been rendered useless by imperative muppets, just like everything else they misunderstand.) For assembling custom object graphs, a homoiconic language where code is data that can be manipulated just like any other makes it simple to construct the logic for a given schema. Unfortunately, Swift's not the right solution either, because it's so big and complicated and unconstrained it can neither scale down to function as a restricted task-specific language nor do metaprogramming through recursive evaluation.

As for Swift's type system, it really is a painfully shallow and ill thought-through bag of shite, a cheap and hasty C++ knockoff that could have been vastly better were its authors better versed in languages outside the imperative C* family. But that's what happens when you send compiler hackers to do a mathematician's job. Dynamic languages may be the work of rank amateurs, but frankly so too are mainstream static languages*. So color me unimpressed with the lot of them and their stupid childish culture wars.

--

* Protip: a static type system is a Declarative Set Algebraic DSL, not dirty compiler annotations for allocating memory on stack cos you're too damn lazy to calculate it yourself. (Even my weakly dynamically typed language understands this, which is why its coercion and constraint checking system is intended to support Set operations... just as soon as SourceKit and swiftc stop puking and crapping themselves long enough for me to actually implement them**.)

(**I've been at this same problem for weeks, and what ought to be straightforward if inelegant double-dispatch logic has been repeatedly bent out of shape just trying to find a magic incantation that will make it build without crashing, never mind run correctly. Today's awesome behavior: dispatching directly to a base class method even though it's been overridden in the subclass whose instance I'm actually passing. So much for correctness proofs and developer efficiency.)

@Kevin Walzer: Sure they are, but that's less important than the question of whether they managed to build the solution they were after in a cost-justifiable length of time.

In modern mainstream programming's massively anally-retentive OCD culture, where languages like C* and Java are incredibly good at generating the appearance of vast amounts of developer productivity without actually producing anything useful or even fit for purpose, that's no small achievement and definitely not to be sniffed at. It's just unfortunate that such languages over time tend to outgrow their area of competence and effectiveness; the computational equivalence of the Peter Principle at work.

But again that's programmer culture at work, in this case the pathological packrat-ism that means they can never just throw away an acquired tool in favor of learning a new one, but must instead pound it to destruction making it do things for which it was never intended or designed. (Then congratulating themselves upon their proverbial dog for being able to walk on its hind legs at all.)

Not that the kitchen sink fetishists of C++ or factory-factory-factory-workers of Java can talk, mind. And frankly if that lot had their way, us 'amateur' tool creators would be locked out completely, and we'd never get the tools we need to do our jobs, because that lot are incapable of making them for us.

"It seems to me that what people really like about static languages is IDE support for things like simple refactorings and autocompletion."

Bingo.

"...where languages like C* and Java are incredibly good at generating the appearance of vast amounts of developer productivity without actually producing anything useful or even fit for purpose..."

Not sure if satire or serious.

"Not sure if satire or serious."

Obviously you've never encountered "enterprise development". :p

Enterprise development is my day job. In Java.