Yeah.. scala is like javazcribl ;)
2011/1/19 Gustavo Hexsel <ghex...@gmail.com>: > Flexible syntax is a big part of it, but combined with operator override, > it's a potential hole for understanding. > They will never officially do that because one big use-case for scala is > DSLs, in which this is an advantage (and the main scala team just got a > reasonably large funding from a group that is interested in using Scala as > DSLs). > > I'm with Richard, only strict coding standards will move Scala into > mainstream (ok ok, there are a FEW mainstream projects, but I mean > MAINmainstream). I'm not sure why it was never officially proposed yet... > > []s Gus > > > On Wed, Jan 19, 2011 at 7:22 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> The only thing that bugs me about scala is its flexibility of >> accepting different kind of notation. It's that what was the >> "downfall" of html: making complilers flexible to allow various human >> input and as end result none of the browsers work correctly because >> the truth is only "in the eye of the beholder" (or creator only, in >> this case). >> >> Scala maybe needs a bit more syntactical canonicity? >> >> ** >> Martin >> >> 2011/1/19 richard emberson <richard.ember...@gmail.com>: >> > Yea, >> > >> > I have consistently advocated using Scala with strong coding >> > standards - standards that are actually believed in and enforced. >> > I have referred to it as OO Scala, Scala which is strong on the >> > Java-like Object-Oriented features plus functional programming >> > in-the-small, but refrains from using functional programming >> > in-the-large, many of Scala's "functional goodies" and advanced >> > type capabilities (and if any of these really have to be used, they >> > should be approved by the group and be documented in detail). >> > >> > The reasons for Scala and using it with limitation are: >> > Scala is a better Java and >> > The use of Scala's "advanced features" must be controlled so that >> > code is understandable, maintainable and, most importantly, so that >> > one can access the existing programmer labor pool and not have to >> > limit one self to the very small number of FP programmers out there. >> > >> > Those who advocate the use of Scala's advanced features on large >> > projects are really advocating that Scala be only a niche language. >> > >> > Richard >> > >> > On 01/18/2011 11:02 PM, Liam Clarke-Hutchinson wrote: >> >> >> >> 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 >> >>> >> >> >> > >> > -- >> > Quis custodiet ipsos custodes >> > >> >
