If you’re doing a focused command-line application, you may be fine with pure functional code or pure OO code. But most modern apps aren’t just dealing with object simulation or calculations. They’re working with lots of data structures, and therefore need dynamic objects and reflection. They need to manipulate sets of data easily, and do concurrent programming. Functional programming is invaluable when working with data or making algorithms extensible.

PL/1 suffered from committee design.. But I agree, languages have always been far ahead of the industry as a whole. Think SmallTalk and LISP. LISP never went really mainstream until it got put in Java’s syntax as Javascript. Programmers are hard-headed.

Regarding SQL/LINQ and integrated XML… Those are both easily implemented with dynamic objects and dot operator overloading (Present in most ‘dynamic’ languages). No need for a language addition there.

Regarding concurrent programming… I see a hybrid approach here. Almost all ‘concurrent’ programming is best expressed in the asynchronous begin/end form. For actual calculations (vs. I/O, audio, video, or web-service calls), I like the philosophy of clojure.

If you actually read my article, you should already know my opinion on contract-based vs. test-based programming.

What languages do you currently use on a day-to-day basis?

C# is actually a bit of an improvement, e.g., var s = “hello”; s is typed as a String. And C# has talented language designers, so it is certainly one to watch.

The point really is that typed languages don’t have to have unreadable code. It’s just that the mainstream ones tend to, though this is likely to change, slowly.

Strangely enough, from looking at Scala’s feature set you might mistake it for one of the dynamic languages. I’d assumed that (like C# and Java), each of those ‘dynamic’ features would introduce syntactical overhead since the behavior isn’t inherent to the language approach.

I’ll probably have to try a small app in Scala to see whether the type system gets in my way or not… If structural typing is the default, then Scala might just make it onto my ‘list’.

> Can you say you have ever encountered this in a real application?

I said ‘potential’.

> Static typing provides a false sense of security just like compile-time checks do.

Actually, types prove that certain categories of runtime errors are impossible. They can do much more than catch typos. It’s a shame that most people’s experience of types is from C, C++ and Java, because I can’t think of worse implementations of it. People have a wider view of untyped languages than of typed ones.

For example, if I am working outside an IDE I can do a refactor, and generally the code won’t compile until I have fixed all the resulting problems. This is even true within an IDE, as IDEs don’t support every refactor you might want.

Support for typing in the language helps me, a programmer who thinks in types, because it helps me to keep track of things. If I’ve made an error in my thoughts, I’ll get a compile error.

> Compile-time checking is really just a productivity feature.

That’s a non-argument. You could argue that anything above assembler is a productivity feature.

> Static typing helps catch a small class of typos, but causes an incredible amount of programmer overhead.

I hope I’ve addressed the typos bit above. Whether it causes programmer overhead depends on the programmer and the type system.

>> Types can express a lot more than you might expect. They can make unit tests unnecessary (or at least smaller), and in the case of QuickCheck/ScalaCheck they can improve unit tests no end.

> I’m no Scala expert – could you provide a real-world example of this?

This is from my current codebase; it’s a ScalaCheck test inside a Specs specification:

“Converting an EventsCGI to a String and back” should {
“not be lossy” in {
property { e: EventsCGI => { EventsCGI.fromURL(e.toString).toString == e.toString } } must pass
}
}

ScalaCheck will generate up to 500 EventsCGI objects (according to rules I defined elsewhere), and run this test on them. When it finds a failure, it will try to ‘shrink’ the failure case, meaning that it generates more EventsCGI objects but with smaller values and runs the test again, so that the developer gets a small value. I can’t really paste more than that, which is the downside of asking for a real-world example. It also doesn’t really show off type inference, but the ScalaCheck docs should do that.

Can you say you have ever encountered this in a real application?

>More importantly, not having types available makes it hard to think in types, i.e., it makes it hard to reason about your code.

I don’t think it makes it harder to reason about your code at all. Static typing provides a false sense of security just like compile-time checks do. Compile-time checking is really just a productivity feature. Static typing helps catch a small class of typos, but causes an incredible amount of programmer overhead.

> Types can express a lot more than you might expect. They can make unit tests unnecessary (or at least smaller), and in the case of QuickCheck/ScalaCheck they can improve unit tests no end.

I’m no Scala expert – could you provide a real-world example of this?

scala> def doDuckLikeThings(duck: { def walk: Unit; def quack: Unit }) = { duck.walk; duck.quack }
doDuckLikeThings: (AnyRef{def walk: Unit; def quack: Unit})Unit

scala> class Swan { def walk = println(“I’m walking”); def quack = println(“waaak”) }
defined class Swan

scala> doDuckLikeThings(new Swan)
I’m walking
waaak

A potential problem is that there’s no real way to know whether the method means to the object’s author what it means to you. aBath.run is quite different to anAthlete.run. More importantly, not having types available makes it hard to think in types, i.e., it makes it hard to reason about your code. Types can express a lot more than you might expect. They can make unit tests unnecessary (or at least smaller), and in the case of QuickCheck/ScalaCheck they can improve unit tests no end.

Type inference does mitigate the problem slightly (It’s appearing in many static languages now), but here’s the question:

If it walks like a duck and quacks like a duck…. Can we let it in with the other ducks? Or does it need an license?

When it’s so easy to check to see how the duck walks and quacks… Why deal with the overhead and limitations of the license?

In my opinion, contractual programming is a case of premature optimization on a severe scale.

Where they don’t support something, support can be added. For example, Haskell doesn’t support OOP out of the box, but you can add that as a library (I believe such a library exists).

None of the languages you listed satisfy one of your checks for high-level language; implicit typing. They are all untyped languages.