I originally mentioned the Kuhn book in the context of the politics of
change. Altering the focus, you brought up *the truth* as the view
held by those resisting change, which I believe is not the larger
insight to be gained from his book. It is still my contention that my
original interpretation is valid; Scala faces resistance to change and
the structure of that resistance, maps into those structures
identified by Kuhn.
Using a term you earlier used, I think it would be naive to believe
that entrenched business forces will stop the emergence of a new,
major development language. Such forces were aligned against C, C++
and Java, but the forces were overcome. In each case, rational
examination of the languages revealed advantages as well as
non-rational forces, such as Sun's marketing and glitter in the case
of Java, strengthening the prospects of the language's adaption. I
hope we can both agree that change will come.
But, I do not believe the change will be revolutionary but, rather,
evolutionary. A language that evolves from an existing ecosystem has a
much greater likelihood of becoming significant than a green field
language.
I paint and sculpt as well as do mathematics and physics and, for me,
language selection is far closer to math and physics than to the play
of colors or shape and form. I, thus, do not agree that choosing a
programming language is an exercise in artistry, but rather, its a
more rational process. And, if beauty is involved, then it is
scientific beauty and not artistic beauty. Are you Picasso? Maybe
even Mondrian? Hopefully, not Pollock.
Concerning the languages you listed as "the way forward", an important
criteria must be: where are the programmers coming from? One can wait
for a new generation or one can see if any existing programmers will
migrate from their current language to a new language. Some language
usages from the web:
Java 18%
C 16%
C++ 9%
Python 6%
C# 6%
Objective-C 3%
Ruby 2%
Lisp 1%
Scheme ~0.5%
Haskell ~0.3%
Scala ~0.3%
Eiffel<0.1%
Clojure ~0.0%
So, where might future Haskell or Clojure or Eiffel or Scala
programmers come from?
# So, what about Eiffel?
Eiffel (with DbC, "design by contract") is a 25 year old language and
its usage stats are down in the noise - well below Scala, Clojure and
Haskell - and showing its age. Hard to see a ground swell of C or Java
programmers switching to Eiffel.
Eiffel's grasp exceeded what could be supported; its notion of
"contract" was so big, it was hard to find a wrapper around it all.
Category Theory may provide for a pragmatic approach to reasoning
about interfaces (contracts) which might not encompass all possible
rely/guarantee predicates, but many. As such, the three laws of
Monads from Category Theory might yield a more coherent, reasoned
approach to DbC and interface design. Curiously, this has been
discussed by the author of Scala as a possible approach to adding DbC
to Scala. For the Scala-CLR binding there is native support for such
constructs while for the Scala-JVM binding, it would have to be done
with code.
# So, what about Haskell?
Haskell is the flag ship FP testbed which has been out there for close
to 20 years. There are no large enterprise applications written in
Haskell. It has certainly not taking the programming world by storm
whatever its merits. In addition, for Haskell, and all FP languages
for that matter, the world view required is not shared by most people,
Folks do not see the world as math functions (program mangers and
customers certainly don't); functional programming in-the-large is an
unnatural mapping of external objects and relationship to a FP design.
(That said, Category Theory is being used more in Physics and
non-computer Mathematics as a means of providing some guidance by
helping to find higher level relationships between areas of research,
but those are rather rarefied endeavors.) Again, where are the
converts to Haskell coming from? Just an occasional graduate student.
# So, what about Clojure?
Clojure is an interesting case; its immutable data structures are a
strength but as soon as you allow users to call into Java libraries
any program-level reasoning due to such data structures are suspect -
an issue with any FP language which is not 100% pure. In addition,
where is the pool of potential converts? Clojure is a rather large
leap for the 20% of programmers using Java (or for that matter for the
20% using C/C++) Converts would likely come from the Lisp (1% usage)
and Scheme (usage levels in the noise) community.
As an aside, I had considered porting the Clojure runtime to Scala.
There would have been many advantages over the Java-based
runtime, e.g.:
Scala with its immutable data structures would be a good fit,
Scala's coming parallelized data structures targeted to
multi-core environments saving the Clojure group much development
effort.
Scala would have given the Clojure community delimited continuations
which the Scheme folks would like and understand.
But, such a port, while interesting and I would certainly have
learned Clojure, would not have appreciably increased the number
of Scala users - so I choice Wicket.
# So, what about Scala?
I recently came upon a discussion of Joshua Bloch's "Effective Java",
its list of recommended practices and how they map into Scala.
Curiously, in each case, the article pointed out that Scala made
simpler or completely eliminated the need for the "Effective Java"
better-coding-practice. So, if one thinks that "Effective Java" makes
sense, so does, at least at the level of the recommendations, a switch
to Scala - the state of art has moved on from Java. As I have been
advocating, Scala is a better Java; switching from OO Java to OO Scala
is relatively easy and certainly Java's warts have become very
glaring.
As with any language and development team, one needs development
standards. In this, Scala is no different than Java, C++, C, etc. To
not let programmers use Scala because one don't trust them and that
the team's development practices are not being followed or are
inadequate is not a problem with the language but rather with those in
positions of authority and/or respect for failing to set the proper
environment.
Scala does allow users to access the existing, significant base of
Java libraries so that a whole universe of supporting libraries does
not have to be re-created for Scala. Also, if the use of its
functional and extended type capabilities are controlled, it offers a
relatively easy migration for the average Java programmer (or any of
the other OO languages listed above - a large pool of potential
converts).
The rate of change is increasing, A 100 years ago, change occurred much
slower than today. The establishment 100 years ago, those forces that
resist change as described by Kuhn, suffered few consequences for
their recalcitrance. But, now, change on the order of a few years is
the new constant, and it is only getting shorter (we are, in fact,
approaching the singularity). So, yesterday's guru, technical
innovator is today's stick-in-the-mud detractor - unless one rises
above the recurring drama Knuth discussed. Now a day, one might say,
Go Meta young man or become a Dunsel.
Quis custodiet ipsos custodes
