I believe this conversation has gone enough off-course that it no
longer belongs on this mailing list. We're not discussing anything
related to Wicket anymore.
On Wed, Jan 19, 2011 at 11:57 AM, richard emberson
<richard.ember...@gmail.com> wrote:
>
>
> On 01/19/2011 07:22 AM, Martin Makundi 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).
>
> I guess concerning HTML, I would say that it did not have a good
> enough spec soon enough and, of course, MS did whatever they wanted
> anyway.
> Scala has a very, very detailed spec (do not try to learn the
> language by reading the spec first).
> Scala also has the incredible advantage that the Scala team
> can make changes that are not backward compatible, which is to
> say, Scala has had a long gestation period.
> This advantage was particularly useful in going from the 2.7 to 2.8
> releases where the whole collection framework was redone. They are
> finding out what works best and folding those changes back into the
> language. This will slow down with time (I expect the collection
> re-write is the last super big change).
>
>>
>> Scala maybe needs a bit more syntactical canonicity?
>
> I agree, languages have multiple ways of doing things:
> while-loop and for-loops
> i++ vs i += 1 vs i = i + 1 (Scala does not support i++)
>
> First, Scala is both OO and FP, so there are generally a
> couple of approaches - one that looks like Java and one that
> is more pipelined, data flowing through functions.
>
> So, it is true that Scala allows one to be "creative!?".
> Some of this comes from the vastly richer set of capabilities
> associated with the collection classes. In Java one has
> Iterator while in Scala there is a whole lot of extra
> standard methods.
>
> Just yesterday while working on my NIST RBAC code, I had to
> decide how to check access rights in a test class:
> Does a Session have a given Permission, where
> Roles are in a Set and RolesToPerm is a Map from Role to Permission:
>
> def checkAccess(session: Session, perm: Permission): Boolean = {
> // version 0, very Java-like, never considered
> for (role <- session.getRoles) {
> val pOp = roleToPerms.get(role)
> if (permOp.isDefined)
> if (permOp.get == perm) return true
> }
> false
>
> // or version 1, handling Option the Scala-way
> for (role <- session.getRoles) {
> roleToPerms.get(role) match {
> case Some(p) => if (p == perm) return true
> case None => // ignore
> }
> }
> false
>
> // or version 2, rather more functional
> sesson.getRoles.foldLeft(false) { _ || roleToPerms.get(_).getOrElse(null)
> == perm }
> }
>
> The first two versions are not too hard to understand, but the last
> one, unless you know what foldLeft does, is, I imagine, opaque to most
> Java programmers.
> ["foldLeft" sets the result value with an initial value, "false", and
> then iterates over the values of the container, "roles", performing
> the operation, "||", creating a new result value on each iteration
> where the first "_" is the current result value and the second "_" is
> the value from the container. "getOrElse returns the value looked up
> from "roleToPerms" and, if it does not exist, returns "null". Lastly,
> the iteration stops when the first true value, "== perm" is true;
> the normal "||" shortcutting.]
> That said, I consider the code to be functional
> programming in-the-small, a single line of code and, ultimately, more
> understandable (and more maintainable) than either of the proceeding
> versions. [There maybe a better way to pipeline the evaluation, this
> is just what I did.]
>
> I have very mixed feelings about DSLs. If every programmer in your
> project creates their own DSLs for their own section or, even worse,
> per class, then DSLs are very bad; less understandable code, a
> maintenance problem and a barrier to getting new hires up to speed.
> On the other hand, if a project controls the use of DSLs and they
> are well documented, they could (not will be, but could) be a boon
> rather than a bust.
>
>>
>> **
>> 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
>>>
>>
>
> --
> Quis custodiet ipsos custodes
>
