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
> >
>
