scala

[czerwonka]

I'm curious to know if anyone here has experience with Scala, and if
so, where do you see Clojure adding value over Scala. Why would I
move. I can write imperitive OR functional, and it's type-safe
without cruft. And I'm not wanting to go back to Emacs.

[Brett Morgan]

There are those of us who prefer to live in a dynamically typed world. And yes, I have coded in scala, and will do so again.


Brett Morgan http://brett.morgan.googlepages.com/

[Randall R Schulz]

Or, to take it a bit further...

Compare an contrast these JVM-based languages:

1) Clojure
2) Scala
3) Groovy

My glib take on it is that Clojure is a dynamically typed language done
right. Scala is a statically typed language done right and Groovy
is ... something else.

Randall Schulz

[czerwonka]

On Jun 8, 2:36 pm, "Brett Morgan" <brett.mor...@gmail.com> wrote:
> There are those of us who prefer to live in a dynamically typed world. And
> yes, I have coded in scala, and will do so again.
>
> Brett Morganhttp://brett.morgan.googlepages.com/
>

In my mind, you live on either side of a type/untyped language. I
live on the typed side. If that's the only argument, then I'll take
Scala for obvious reasons. I'm looking for an argument that makes me
think "hmnn... not sure I can do that in Scala" or "wow - that's so
much easier using Clojure". So for, Clojure is more restrictive and
from what I can tell, given it's purely functional and in Scala I have
an option.

[a r]

On Sun, Jun 8, 2008 at 9:53 PM, czerwonka <andy.cz...@gmail.com> wrote:
>
> On Jun 8, 2:36 pm, "Brett Morgan" <brett.mor...@gmail.com> wrote:
>> There are those of us who prefer to live in a dynamically typed world. And
>> yes, I have coded in scala, and will do so again.
>

> In my mind, you live on either side of a type/untyped language. I
> live on the typed side. If that's the only argument, then I'll take
> Scala for obvious reasons. I'm looking for an argument that makes me
> think "hmnn... not sure I can do that in Scala" or "wow - that's so
> much easier using Clojure". So for, Clojure is more restrictive and
> from what I can tell, given it's purely functional and in Scala I have
> an option.

To me, dynamically typed languages with an extensible syntax are on
rather less restrictive side. If you could please elaborate on what
you exactly had in mind that would be great.

-r.

[Raoul Duke]

> To me, dynamically typed languages with an extensible syntax are on
> rather less restrictive side.

[overblown caricatures ensue]

yeah, i could see a clojure bigot saying:
macros can be good.

i could see a Scala bigot saying:
macros can be bad.

;-)

sincerely.

[Ted Neward]

Or you could imagine a bigot who uses both saying, "Macros are good in some
places, and bad in others."

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 270.0.0/1489 - Release Date:
> 6/7/2008 11:17 AM
>

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.0.0/1489 - Release Date: 6/7/2008
11:17 AM

[Rich Hickey]

Static vs. dynamic has been beaten to death, so let's just presume the
benefits and drawbacks of each accrue to Scala and Clojure
respectively.

I think Scala is interesting work, and I haven't spent much time with
it, so I'll just speak for Clojure, other than to say I've seen enough
to know that Clojure is substantially less complex than Scala.

Clojure is predicated on my personal opinion, after many years of
doing it, that imperative programming is not a very good idea in most
situations. So, I consider it an attribute, and not a restriction of
Clojure that it makes 'doing the right thing' (FP) the easy and
default way. Even without concurrency in the picture, I think it
yields better programs, and in the face of concurrency it is, IMO, the
only way to go. You do have an option for imperative programming in
Clojure - calling Java. But imperative programming is not something I
want to promote, and Java is perfectly adequate at it, so Clojure adds
no imperative constructs of its own.

However, Clojure acknowledges the need for the illusion of change in
most real programs that are not merely calculations. That is, multiple
parts of a program may want to associate an identity with state that,
at different times in the program, may be different. It takes the
necessary step, as does Erlang, of making sure that change happens
only inside a language construct that has enforced concurrency
semantics. Again, this is not restrictive, this is enabling, because
with unconstrained mutation the correctness of a concurrent program is
the onus of the programmer.

Someone would choose Clojure who valued its simplicity, extensibility,
dynamism and holistic functional-programming/persistent-data-
structures/concurrency model, and who understood, or sought to attain,
the power offered by Lisp.

If that's not you, that's ok. Neither Clojure nor Scala is better than
the other - they're different.

Rich

[czerwonka]

On Jun 9, 7:14 am, Rich Hickey <richhic...@gmail.com> wrote:
> On Jun 8, 1:28 pm, czerwonka <andy.czerwo...@gmail.com> wrote:
>
> > I'm curious to know if anyone here has experience with Scala, and if
> > so, where do you see Clojure adding value over Scala. Why would I
> > move. I can write imperitive OR functional, and it's type-safe
> > without cruft. And I'm not wanting to go back to Emacs.
>
> Static vs. dynamic has been beaten to death, so let's just presume the
> benefits and drawbacks of each accrue to Scala and Clojure
> respectively.

[czerwonka] Agreed.

>
> I think Scala is interesting work, and I haven't spent much time with
> it, so I'll just speak for Clojure, other than to say I've seen enough
> to know that Clojure is substantially less complex than Scala.

[czerwonka] I what way? Syntax? I definitely see the argument given
Scala's implicit defs (witchcraft). Does this complexity cost come as
a result of type safety? I think so in some cases.

>
> Clojure is predicated on my personal opinion, after many years of
> doing it, that imperative programming is not a very good idea in most
> situations. So, I consider it an attribute, and not a restriction of
> Clojure that it makes 'doing the right thing' (FP) the easy and
> default way. Even without concurrency in the picture, I think it
> yields better programs, and in the face of concurrency it is, IMO, the
> only way to go. You do have an option for imperative programming in
> Clojure - calling Java. But imperative programming is not something I
> want to promote, and Java is perfectly adequate at it, so Clojure adds
> no imperative constructs of its own.

[czerwonka] I guess this is where I sit on the fence. Scala's default
is to promote immutable data structures. It promotes 'val' over
'var'. It gives you a choice though, I think because unless one wraps/
replaces all the Java libraries with their functional equivalent, you
end up using imperative whether you like it or not. I guess that's
really my argument. Interop forces you there. Doesn't it?

>
> However, Clojure acknowledges the need for the illusion of change in
> most real programs that are not merely calculations. That is, multiple
> parts of a program may want to associate an identity with state that,
> at different times in the program, may be different. It takes the
> necessary step, as does Erlang, of making sure that change happens
> only inside a language construct that has enforced concurrency
> semantics. Again, this is not restrictive, this is enabling, because
> with unconstrained mutation the correctness of a concurrent program is
> the onus of the programmer.

[czerwonka] Scala has its Actor library which closely resembles
Erlang. You're right though, given it's a library, it allows you to
use shared state. I nevertheless do find it extremely powerful to be
able to express a this DSL using a typed language. There are some STM
implementations that are also very interesting. You're right though,
the onus is on the programmer to get it right. It's a helluva lot
easier though. Scala offers you a paradigm for concurrency that's not
based on locks and it looks like a language construct.

>
> Someone would choose Clojure who valued its simplicity, extensibility,
> dynamism and holistic functional-programming/persistent-data-
> structures/concurrency model, and who understood, or sought to attain,
> the power offered by Lisp.

[czerwonka] I'm unfortunately not a Lisper, but I'm reading SICP and
trying to at least understand a bit about that world. I'm also very
interested in concurrency and your talk got me interested in Clojure.
I agree that locks just don't work. Saying that, I don't have the
answer, so I'm looking to you to give me the answer. :-) Great
presentation btw.

>
> If that's not you, that's ok. Neither Clojure nor Scala is better than
> the other - they're different.
>
> Rich

Andy

[Rich Hickey]

On Jun 9, 2:10 pm, czerwonka <andy.czerwo...@gmail.com> wrote:
> On Jun 9, 7:14 am, Rich Hickey <richhic...@gmail.com> wrote:> On Jun 8, 1:28 pm, czerwonka <andy.czerwo...@gmail.com> wrote:

> > I think Scala is interesting work, and I haven't spent much time with
> > it, so I'll just speak for Clojure, other than to say I've seen enough
> > to know that Clojure is substantially less complex than Scala.
>
> [czerwonka] I what way? Syntax? I definitely see the argument given
> Scala's implicit defs (witchcraft). Does this complexity cost come as
> a result of type safety? I think so in some cases.
>

Complexity comes as the result of the type system, object system etc.
Clojure has a very tiny core.

> > Clojure is predicated on my personal opinion, after many years of
> > doing it, that imperative programming is not a very good idea in most
> > situations.
>

> [czerwonka] I guess this is where I sit on the fence. Scala's default
> is to promote immutable data structures. It promotes 'val' over
> 'var'. It gives you a choice though, I think because unless one wraps/
> replaces all the Java libraries with their functional equivalent, you
> end up using imperative whether you like it or not. I guess that's
> really my argument. Interop forces you there. Doesn't it?
>

Not really. A lot of use of Java is on the I/O side of an application.
The logic and model can avoid Java, or use parts of it functionally.

If you build an immutable object out of Java/Scala final/val fields
you don't end up with a persistent data structure, so you don't have a
mechanism for change other than full copy. If you use Scala's
immutable collections, but then store them in Scala's unmoderated
'vars' as recommended to support change, then you don't have a
mechanism for change coordination other than locks.

Contrast with the Clojure approach of using Clojure maps as 'objects'
- they are immutable and efficiently persistent - and storing them in
one of Clojure's 3 reference types, all of which have concurrency
semantics.

Giving people advice is different from giving people a complete
method, and using it uniformly in the libraries.

> > However, Clojure acknowledges the need for the illusion of change in
> > most real programs that are not merely calculations. That is, multiple
> > parts of a program may want to associate an identity with state that,
> > at different times in the program, may be different.

> [czerwonka] Scala has its Actor library which closely resembles
> Erlang.

I question whether Erlang's actors-waiting-for-a-data-message-in-a-
blocking-switch-statement model is the right thing to emulate. Here
too, Clojure's holistic design comes into play, as both its
transactional refs and autonomous asynchronous agents support the same
change-as-function-of-state model, with both the altering function and
the state being the exact same functions and persistent data
structures you use everywhere else.

Contrast with the difference between interacting with Scala Classes/
Objects and Scala Actors. Everything that was a method in the first
case becomes a message data type in the second - very different.

> You're right though, given it's a library, it allows you to
> use shared state. I nevertheless do find it extremely powerful to be
> able to express a this DSL using a typed language.

I have no doubt Scala's flexibility will allow people to accomplish
almost anything. But when everyone can do almost anything, they do,
and then their pieces don't compose. If everyone using Scala takes a
different approach to mutability and concurrency, you won't be able to
compose reliable concurrent programs. I find it highly unlikely that
Scala programmers will eschew vars in their objects, in which case
they are no better off than in Java, which offers final fields just
like Scala's vals. That's not really functional programming and is not
going to yield its benefits.

If people do want to get the benefits of functional programming and
safe concurrency in Scala they will have to voluntarily adopt, and
enforce by convention, the same sort of 'restrictions' Clojure
holistically supports and enforces.

If they want those benefits in Clojure, they just use it.

Rich

[czerwonka]

On Jun 10, 9:04 am, Rich Hickey <richhic...@gmail.com> wrote:
> On Jun 9, 2:10 pm, czerwonka <andy.czerwo...@gmail.com> wrote:

[snip]

> I have no doubt Scala's flexibility will allow people to accomplish
> almost anything. But when everyone can do almost anything, they do,
> and then their pieces don't compose. If everyone using Scala takes a
> different approach to mutability and concurrency, you won't be able to
> compose reliable concurrent programs. I find it highly unlikely that
> Scala programmers will eschew vars in their objects, in which case
> they are no better off than in Java, which offers final fields just
> like Scala's vals. That's not really functional programming and is not
> going to yield its benefits.
>
> If people do want to get the benefits of functional programming and
> safe concurrency in Scala they will have to voluntarily adopt, and
> enforce by convention, the same sort of 'restrictions' Clojure
> holistically supports and enforces.
>

[czerwonka] Your argument if fair. Give people the rope, and they'll
hang themselves. I'd love to be able to express compile-time
restrictions within a DSL (don't use var here). I've done so in Java
using AOP, but I had to do so because the language gave the developer
enough rope. I'll try and write something significant in Clojure and
report back. Now I have to install Emacs. I was hoping to avoid
that. ;-)

[Randall R Schulz]

On Tuesday 10 June 2008 08:57, czerwonka wrote:
> ... Now I have to install Emacs. I was hoping to avoid that. ;-)

At least Emacs is an option for you. I've found I cannot retrain my
Vim-afflicted basal ganglia.

Anyway, the NetBeans plug-in ("EnClojure": <http://enclojure.org/>,
<http://sourceforge.net/projects/enclojure>) is pretty good. I'd prefer
something in IDEA so I don't have to run two IDEs, but given the choice
between Emacs and NetBeans, I chose NetBeans.

Randall

[Brian Watkins]

Vim and clojure are awesome together.

Okay, it'd be nicer if those square brackets didn't mess up the
indenting. Aren't we worried that Algol-style programmers who are
attracted by the elegance of lispy parens will be put off by the
paucity of parentheses in Clojure?

-B

[Mike Benfield]

FWIW, here's my experience:

I was playing with Scala immediately before I found Clojure. I really
enjoyed it at first but as I learned more it gradually came to seem
overly complicated. As far as the type system I started feeling like I
would actually prefer Java pre-generics. There are just so many
features and... for what? I started feeling like none of it was
helping me write better code in practice.

So I suppose this is just rehashing the dynamic vs. static typing
issue, but Clojure's simplicity in that regard was refreshing.

Plus:

- It's a Lisp.
- I like its approach to concurrency.
- I like its rejection of Java OO and its use of multimethods.
- It's a Lisp.