Don't get me wrong, I'm all about seeing a Wicket-like Scala-based
project (and would contribute to it), but that's not what we've been
debating here lately on this thread. If you guys want to talk about
coming up with a from-the-ground-up Scala-based, Wicket-inspired
project, then I'm all ears and think we should start putting something
in github or something.
On Wed, Jan 19, 2011 at 12:09 PM, Martin Makundi
<martin.maku...@koodaripalvelut.com> wrote:
> What about rewriting wicket into most wonderful tight functional scala style?
>
> def : webserver {
> homepage,
> logoutpage,
> onlinestore,
> }
>
> ...
>
> ;)
>
> **
> Martin
>
> 2011/1/19 James Carman <ja...@carmanconsulting.com>:
>> 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
>>>
>>
>
