Frank Lloyd Wright: Rereading the Classics

Kurt: Hey, Frank Lloyd Wright?
Wright: Oh no.  Not you again.
Kurt: No, no, this is just a courtesy call.
Wright: What kind of courtesy?
Kurt: I'm just letting you know that more people are complaining about Fallingwater.
Wright: What!?  How is that courteous?
Kurt: I'm just saying, maybe you should have taken a more modular approach.
Wright: What does that even mean?  If I ever live long enough to find you--
Kurt: Oh.  You won't.

Man, I love time traveling.

Three, largely unrelated points brought to mind by a recent paper Rereading the Classics, by  Panagiotis Louridas:

Why do people consider weak typing an advantage?
Yes, it will save you the laborious effort of declaring a variable type, yes, it will save you  the effort of having to declare classes or interfaces for polymorphism.  But neither of these  are particularly time-consuming or challenging processes.  The effort you save by not generating  an interface is far overshadowed by the challenge you will have later trying to decipher your  code.

What is a function taking?  Can I get a list of types I can pass in?  With strong typing, you  can.  With duck typing, you're in trouble.  Java got this one right.  Interfaces are  lightweight, flexible tools to address polymorphism.  If you disagree, then I suspect that you  don't know how to use interfaces properly.

Why is there a distinction between "classic" languages and "pragmatic" ones?
An interesting distinction is brought up between those uncompromising, yet broadly influencial  languages that never take off in industry (Lisp, Smalltalk), and those more-compromising  languages that eventually do (Java).

It casts a spotlight on the question: when is compromise acceptable in a language (or  architecture)?  Consistency and simplicity are generally optimal: they give a developer a  clearer understanding of how to work within the environment.

One of my favorite features in Smalltalk is the way in which it sidestepped the performance  penalties of a strictly object-oriented framework: even though all operations are defined as  smalltalk code, functions may also defer to optimized assembly commands, substantially speeding  up things like arithmetic.  However, if a developer wished to modify any of these functions, he  can still modify the Smalltalk code, ignoring the assembly optimization.  This was one of the  few structural compromises in the language, and it was a very powerful one.

What made Java more widely adopted than Smalltalk in industry?  There's a host of non-technical  reasons (the backing of Sun, good timing), and many technical ones (simplified deployment over  the web through [much-derided] applets, in-order arithmetic expressions, the ability to  implement many interfaces in a single class, support of C-style primitives).  The more tools you  give developers to work with, the more people will willingly adopt the language.  The added  flexibility doen't necessarily make a language superior, but it does make it more accessible,  and a large development community is the single most powerful attribute a language can have:  someone, somewhere will find a way to do what you want to do, and make their suggestion public.

Biocomputers and quantum computers the two most substantial paradigm shifts in 21st computing)  will most likely follow a similar pattern.  A powerful, inflexible language will be created and  be met by all sorts of worship by the academic community, but the technology will only take off  once a more familiar language is released incorporating aspects that made the uncompromising  language so powerful.

Does form in always follow function in a programming language?
The article gives much focus to the statement that "form always follows function" in nature, and  so should it in technology.  What does this mean exactly?

Well, one good example is that most languages are structured in a sequential manner, mirroring  the capabilities of the underlying hardware paradigm.  Single-core execution predominated for  decades, and our languages were built with that in mind.

There is a good chance that the increasing adoption of multi-core systems will eventually result  in a new style of programming.  Not merely synchronization control, or fork/joins, but an  altogether new style.  If form follows function, perhaps our code will eventually be split into  parallel tracks, visually organized as a side-by-side list of streams of code.  If the code is  executing on multiple cores, it should probably *look* to a developer like it is executing on  multiple cores.




Viewing the evolution of programming languages can provide a sense of how the field progresses,  and, to some degree, can assist one in anticipating future changes.  But perhaps more  significantly, it can give one a better understanding of why things are as they are now.  You  never really understand your own country until you've visited another.  You never fully  understand your language unless you see the ideas that created it.