Why people use C++ to facilitate making business a mess? ** Martin
2011/1/19 Liam Clarke-Hutchinson <[email protected]>: > 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 < > [email protected]> 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 >> >
