What about rewriting wicket into most wonderful tight functional scala style?
def : webserver {
homepage,
logoutpage,
onlinestore,
}
...
;)
**
Martin
2011/1/19 James Carman <[email protected]>:
> 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
> <[email protected]> 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<[email protected]>:
>>>>
>>>> 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<
>>>>> [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
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Quis custodiet ipsos custodes
>>>>
>>>
>>
>> --
>> Quis custodiet ipsos custodes
>>
>
