I propose we skip the Scala meeting for September 24th, as we don't
have a presenter/topic, and get back together in late October for
Andrew's talk on SLICK.
For anyone looking for a Scala substitute in September, Brian McKenna
from Atlassian is giving a YOW talk on Roy, a statically-typed
functional language that compiles to Javascript.
Looks very interesting - I'll definitely be there.
In the past 2-3 months I've spent alot of time investigating how to do
statically typed, functional programming in the browser via both
ScalaGWT and Xtend/GWT. Neither approach has proved particularly
satisfying or trouble-free, although the need for something decent
remains. Roy just might be it.
I've only watched their Google IO video, but the type safety looks interesting.
> ScalaGWT and Xtend/GWT. Neither approach has proved particularly
> satisfying or trouble-free, although the need for something decent
> remains. Roy just might be it.
I currently use Vaadin - built on GWT - also because I wanted static
type-checking. I didn't go with straight GWT because Vaadin keeps
everything on the server-side so I don't need to think about
client-vs-server representations of my domain objects.
It has a Scala wrapper called Scaladin, which makes writing event
handlers easier. Though it's not a straight drop-in replacement, so
I'm just using the plain API and writing (very minimal) Scala where
useful.
Curious to know what troubles are you seeing with ScalaGWT &
Xtend/GWT? - first time I've heard of them.
> --
> You received this message because you are subscribed to the Google Groups "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scala-melb?hl=en-GB.
Unlike alot of people, I really wanted to like Dart, but like alot of
people I'm not super impressed by what Ive seen. It seems overly
verbose, and the type system is, by their own admission, weak and
unsound: http://www.dartlang.org/articles/why-dart-types/
Keep in mind that Google still have to convince everybody else to use
it, and that looks like an uphill battle.
The fact that HelloWorld.dart weighed in at 20k of JS (or whatever it
was) at Dart's launch, was a stuff-up, and another reason why this
jumbo seems unlikely to ever lift off the runway.
Would be great to hear a convincing defense of Dart...?
>> ScalaGWT and Xtend/GWT. Neither approach has proved particularly
>> satisfying or trouble-free, although the need for something decent
>> remains. Roy just might be it.
> I currently use Vaadin - built on GWT - also because I wanted static
> type-checking. I didn't go with straight GWT because Vaadin keeps
> everything on the server-side so I don't need to think about
> client-vs-server representations of my domain objects.
> It has a Scala wrapper called Scaladin, which makes writing event
> handlers easier. Though it's not a straight drop-in replacement, so
> I'm just using the plain API and writing (very minimal) Scala where
> useful.
Interesting that you like Vaadin too. I had a good long play with it as well.
This criticism is going to sound a bit vague, but: client side
-behavior and -state is ideally keep in the client. It's so much
simpler that way. I don't want to write server-side code that renders
screens that will display a million miles away. It just silly. And
synchronizing session state between the client and server is always
trouble-prone; in Vaadin, in Wicket, in Seam.
So many things get much simpler if you treating the browser as a
programmable platform that you install your JS app into, (on-demand,
by visiting a web page).
But to do this, we need decent programming languages in the client.
For me, "decent" implies "statically typed".
> Curious to know what troubles are you seeing with ScalaGWT &
> Xtend/GWT? - first time I've heard of them.
ScalaGWT basically doesn't work ATM. And there seems to have been some
non-announced decision to discontinue the initiative. I know that it
depends upon Google accepting the so-called "JRibble" patches to GWT
core that they have so far declined.
Xtend works ok with GWT. Buts its APIs are missing alot of basic stuff
you expect in Scala, eg Option, and it's lambda expressions don't
inter-op very easily with Functional Java, which itself doesn't work
easily with GWT.
So, please don't pay too much attention to my ClojureScript talk then :)
More seriously, I do quite like the looks of Roy - I'd be keen to play with
it. Seems like a nice option for a JavaScript front end that is quite a
lot "thinner" than the heavyweight options (Dart, ClojureScript, GWT etc),
but adds rather more functionality than a very thin front end like
CoffeeScript.
- Korny
On 4 September 2012 18:07, Ben Hutchison <brhutchi...@gmail.com> wrote:
> On Tue, Sep 4, 2012 at 5:18 PM, King Lung Chiu <kinglung.c...@gmail.com>
> wrote:
> >> In the past 2-3 months I've spent alot of time investigating how to do
> >> statically typed, functional programming in the browser via both
> Unlike alot of people, I really wanted to like Dart, but like alot of
> people I'm not super impressed by what Ive seen. It seems overly
> verbose, and the type system is, by their own admission, weak and
> unsound: http://www.dartlang.org/articles/why-dart-types/
> Keep in mind that Google still have to convince everybody else to use
> it, and that looks like an uphill battle.
> The fact that HelloWorld.dart weighed in at 20k of JS (or whatever it
> was) at Dart's launch, was a stuff-up, and another reason why this
> jumbo seems unlikely to ever lift off the runway.
> Would be great to hear a convincing defense of Dart...?
> >> ScalaGWT and Xtend/GWT. Neither approach has proved particularly
> >> satisfying or trouble-free, although the need for something decent
> >> remains. Roy just might be it.
> > I currently use Vaadin - built on GWT - also because I wanted static
> > type-checking. I didn't go with straight GWT because Vaadin keeps
> > everything on the server-side so I don't need to think about
> > client-vs-server representations of my domain objects.
> > It has a Scala wrapper called Scaladin, which makes writing event
> > handlers easier. Though it's not a straight drop-in replacement, so
> > I'm just using the plain API and writing (very minimal) Scala where
> > useful.
> Interesting that you like Vaadin too. I had a good long play with it as
> well.
> This criticism is going to sound a bit vague, but: client side
> -behavior and -state is ideally keep in the client. It's so much
> simpler that way. I don't want to write server-side code that renders
> screens that will display a million miles away. It just silly. And
> synchronizing session state between the client and server is always
> trouble-prone; in Vaadin, in Wicket, in Seam.
> So many things get much simpler if you treating the browser as a
> programmable platform that you install your JS app into, (on-demand,
> by visiting a web page).
> But to do this, we need decent programming languages in the client.
> For me, "decent" implies "statically typed".
> > Curious to know what troubles are you seeing with ScalaGWT &
> > Xtend/GWT? - first time I've heard of them.
> ScalaGWT basically doesn't work ATM. And there seems to have been some
> non-announced decision to discontinue the initiative. I know that it
> depends upon Google accepting the so-called "JRibble" patches to GWT
> core that they have so far declined.
> Xtend works ok with GWT. Buts its APIs are missing alot of basic stuff
> you expect in Scala, eg Option, and it's lambda expressions don't
> inter-op very easily with Functional Java, which itself doesn't work
> easily with GWT.
> -Ben
> --
> You received this message because you are subscribed to the Google Groups
> "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scala-melb?hl=en-GB.
-- Kornelis Sietsma korny at my surname dot com http://korny.info "We do not quit playing because we grow old, we grow old because we quit
playing" - O.W. Holmes
> On Tue, Sep 4, 2012 at 5:18 PM, King Lung Chiu <kinglung.c...@gmail.com>
wrote:
> >> In the past 2-3 months I've spent alot of time investigating how to do
> >> statically typed, functional programming in the browser via both
> Unlike alot of people, I really wanted to like Dart, but like alot of
> people I'm not super impressed by what Ive seen. It seems overly
> verbose, and the type system is, by their own admission, weak and
> unsound: http://www.dartlang.org/articles/why-dart-types/
> Keep in mind that Google still have to convince everybody else to use
> it, and that looks like an uphill battle.
The Dart type system is described as "unsound", but what does this mean?
Does it let incorrect programs type-check? So does Haskell. Is the type
system itself undecidable? So is Scala's.
I think it is more honest to say the type system is impractical.
I first saw Dart at YOW! Brian was in the room. It was at that moment I
learned that Roy is one of our only hopes out of the javascript
catastrophe. I work with guys who use javascript all day long and I have
long desired to get them out of that disaster. Dart is not that.
> The fact that HelloWorld.dart weighed in at 20k of JS (or whatever it
> was) at Dart's launch, was a stuff-up, and another reason why this
> jumbo seems unlikely to ever lift off the runway.
> Would be great to hear a convincing defense of Dart...?
I am reasonably confident that no such thing exists.
> >> ScalaGWT and Xtend/GWT. Neither approach has proved particularly
> >> satisfying or trouble-free, although the need for something decent
> >> remains. Roy just might be it.
> > I currently use Vaadin - built on GWT - also because I wanted static
> > type-checking. I didn't go with straight GWT because Vaadin keeps
> > everything on the server-side so I don't need to think about
> > client-vs-server representations of my domain objects.
> > It has a Scala wrapper called Scaladin, which makes writing event
> > handlers easier. Though it's not a straight drop-in replacement, so
> > I'm just using the plain API and writing (very minimal) Scala where
> > useful.
> Interesting that you like Vaadin too. I had a good long play with it as
well.
> This criticism is going to sound a bit vague, but: client side
> -behavior and -state is ideally keep in the client. It's so much
> simpler that way. I don't want to write server-side code that renders
> screens that will display a million miles away. It just silly. And
> synchronizing session state between the client and server is always
> trouble-prone; in Vaadin, in Wicket, in Seam.
> So many things get much simpler if you treating the browser as a
> programmable platform that you install your JS app into, (on-demand,
> by visiting a web page).
> But to do this, we need decent programming languages in the client.
> For me, "decent" implies "statically typed".
> > Curious to know what troubles are you seeing with ScalaGWT &
> > Xtend/GWT? - first time I've heard of them.
> ScalaGWT basically doesn't work ATM. And there seems to have been some
> non-announced decision to discontinue the initiative. I know that it
> depends upon Google accepting the so-called "JRibble" patches to GWT
> core that they have so far declined.
> Xtend works ok with GWT. Buts its APIs are missing alot of basic stuff
> you expect in Scala, eg Option, and it's lambda expressions don't
> inter-op very easily with Functional Java, which itself doesn't work
> easily with GWT.
> -Ben
> --
> You received this message because you are subscribed to the Google Groups
"Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to
> Interesting that you like Vaadin too. I had a good long play with it as well.
> This criticism is going to sound a bit vague, but: client side
> -behavior and -state is ideally keep in the client. It's so much
> simpler that way. I don't want to write server-side code that renders
> screens that will display a million miles away. It just silly. And
That's a common criticism of Vaadin and we'll probably disagree on
this, but I tend to think whether client or server side makes sense
depends on the type of app you write.
Are the apps you're working on doing much processing on the
client-side? Or does it mainly act as a 'data fetcher' on user events?
Vaadin's good for the latter.
> synchronizing session state between the client and server is always
> trouble-prone; in Vaadin, in Wicket, in Seam.
Perhaps it's the type of app I work on, but I actually find that with
Vaadin I don't think about client & server at all; I just focus on
reacting to UI events and then updating the appropriate UI component.
This was the main reason I chose Vaadin; it allowed me to simplify my stack.
> So many things get much simpler if you treating the browser as a
> programmable platform that you install your JS app into, (on-demand,
> by visiting a web page).
Probably depends on where your pain points are.
I agree with this though: you can do a lot more on the client-side if
you push most of the code to the browser.
> But to do this, we need decent programming languages in the client.
> For me, "decent" implies "statically typed".
I prefer type safety too, which is why I try to avoid Javascript ...
not always possible though.
>> Curious to know what troubles are you seeing with ScalaGWT &
>> Xtend/GWT? - first time I've heard of them.
> ScalaGWT basically doesn't work ATM. And there seems to have been some
> non-announced decision to discontinue the initiative. I know that it
> depends upon Google accepting the so-called "JRibble" patches to GWT
> core that they have so far declined.
> Xtend works ok with GWT. Buts its APIs are missing alot of basic stuff
> you expect in Scala, eg Option, and it's lambda expressions don't
> inter-op very easily with Functional Java, which itself doesn't work
> easily with GWT.
> -Ben
> --
> You received this message because you are subscribed to the Google Groups "Melbourne Scala User Group" group.
> To post to this group, send an email to scala-melb@googlegroups.com.
> To unsubscribe from this group, send email to scala-melb+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scala-melb?hl=en-GB.
On Tue, Sep 4, 2012 at 6:47 PM, King Lung Chiu <kinglung.c...@gmail.com> wrote:
> Perhaps it's the type of app I work on, but I actually find that with
> Vaadin I don't think about client & server at all; I just focus on
> reacting to UI events and then updating the appropriate UI component.
I do like Vaadin, I think it's one of the best stateful-server style
web frameworks, and I appreciate how it "just works" almost all the
time. And I agree with your observations about different types of apps
etc.
However, in a broad sense, the paradigm Vaadin arose in, the dominant
paradigm of the past decade, where the browser is merely a display
device and the web app "runs" in the server, is passing. Its
inefficient, an "Age of Steam".
Would you really choose a server round-trip, to handle user input, if
you could conveniently process it in-browser?
On Tue, Sep 4, 2012 at 6:27 PM, Korny Sietsma <ko...@sietsma.com> wrote:
>>For me, "decent" implies "statically typed"
> So, please don't pay too much attention to my ClojureScript talk then :)
Credit well deserved to Rich Hickey and Clojure for some great ideas
and very some eloquent writing [eg http://clojure.org/state]. I
understand that some of Scala's immutable data structures were
inspired from Clojure. I don't know much about ClojureScript, but if
it brings Clojure to the browser, then yay for it.
However, there's no getting away from it: Static typing is so damn
powerful. Its gives so much return on so little investment. Statically
typed codes live longer, healthier lives. And so any decision to omit
the sharpest knife in the drawer is probably a mistake, even for
Clojure.
The lack of type closes off some pathways that Clojure might have
enjoyed open, in the area of type-driven method dispatch, ie
type-classes. It's no accident that all dynamic languages end up
inventing some form of OO dispatch (Protocols in Clojure's case
http://clojure.org/protocols).
The reason is that everyone needs to solve the same basic problem:
abstracting over different kinds of data. And when your static model
has no notion of what kinds of data you have, the only option
remaining is indirecting off a runtime pointer associated with one of
the data values: OO- dispatch.
In contrast, statically typed languages have the option to abstract
over data based upon it's Type, well before there is an entry in the
heap. This also allows dispatch on all parameters symmetrically (not
just the first as in OO) without the runtime performance impacts of
multi-methods. (In Scala this dispatch process is realised via
compile-time implicit search.)
It further offer the possibility of using different implementations of
a type class in different contexts (in Scala, but not Haskell, as
typeclass defs are local), without any need to swap pointers around
awkwardly at runtime.
