Hey mate,
I code Java for my day job, and write my fun code in Scala. I just love the
flexibility of Scala combined with the power to use all my existing Java
libraries. That said,
I don't see Scala overcoming Java anytime soon because it offers developers
_too much_ freedom. I had a real bad time using
http://dispatch.databinder.net for a project, because it fully utilized a
lot of Scala features to offer a really shit API. Java makes everyone
conform to a base level while preventing soaring, and it's a base level
that's sane. And when it comes to writing business code, as in "Code that
makes money", Scala's freedom doesn't offer overly much compared to Java's
enforced conformity.
Don't get me wrong, I <3 Scala, but while half of me wants to use it at
work, the other half is terrified of what the Java developers who write
Spring code like this:
<bean id="something class="java.lang.String">
<constructor-arg index="0">
<value>${someProperty}</value>
</constructor-arg>
</bean>
Would do with the power of Scala at their finger tips. (PS, that's real
Spring code that I saw (and refactored) today.)
On Tue, Jan 18, 2011 at 5:33 PM, richard emberson <
richard.ember...@gmail.com> wrote:
> 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
>
