Just some responses to your statements.
You are right about concise code. If it becomes too terse it can be arcane
if the symbols used to not convey any meaning to the operators. These are
things we have to teach all developers on our team and can become
burdensome. Functional programming has the unfortunate pre-existing
condition of having *lots* of these items. Probably form staying "academic"
or "elite" for too long. However, proliferating these is probably more a
matter of time. We all know the integration symbol. If these things
become useful enough, eventually everyone will be taught them in school.
Until now, I try to ensure DSLs or symbols used in code a "mostlly readable
to an average developer".
There is however the opposite. If code is too explicit it can be painful to
maintain or learn to begin with. Why do we not write in Assembler? Why
move to higher level languages?
Your point on productivity is taken. Productivity is usually an argument
that *both* sides use without quantitative argument. My response is that
I'm not sure I'm more productive, but I feel much happier and can code for
longer periods of time in Scala. Not exactly a quantitative argument
either, but it's enough to make me choose Scala over Java.
As to your point about Java being less complex well, I hate to point this
out, but I believe Java is "just as complex" as Scala to some extent. If
you'd like to start pointing out inconsistencies, let's look at how strange
things can be in Java (they only appear intuitive because you're familiar
with them).
1) Java is object oriented. Except for primitives. Scala conceptually
unifies all values as objects. Yes this makes for confusion coming from
Java, but is quite nice when writing real Scala applications.
2) Static vs. non-static members of a class (in scala, all values are on
instances of an object, albeit there are singleton objects as part of the
language).
3) if statements vs. ?:. In Scala these are simple the if-expression.
4) Threading as part of the language, not just the VM + library. That's
why synchronized("JOSH") {} works just fine. Oh, to be safer, you should
synchronized("JOSH".intern()) {}. Having a language that supports
concurrency is important. However, in Java you end up mixing paradigms when
pulling in other synchronization mechanisms (read/write locks, etc.)
All of this, you are willing to accept because you know Java well, so it
doesn't seem complex. However learning Java (without already knowing a
C-like language) would be just as difficult, if not more, than learning
Scala.
Scala does a lot to re-use language features in multiple locations to great
effect. For example, try-catch blocks utilize normal pattern matching
semantics for their catch block. However, coming from Java, there are a
few things I think are hard to learn (closures *not* being one of them):
1) The type system. Scala could use some clean up here, but for the most
part you have five mechanisms at your disposal.
a) Type Lower Bounds (a.k.a. something akin to ? super A )
b) Type Upper Bounds (a.k.a. something akin to ? extends A )
c) Co/Contravariance annotations
d) Type combinator ( A with B)
e) Implicit resolution [ This defers type inference in mystical ways ].
2) Implicit views and Implicit values. This is how scala statically adds
magic to classes. It's also how scala experts can coerce the type
inference to "Do The Right Thing (TM)" on user's code. Stepping into
scala, you can treat this as a black box, however the advanced APIs (like
collections) will quickly force you to learn a bare minimum here.
3) Too much integration with Java. This is perhaps one of the biggest
strengths of Scala, but also provides a *lot* of complexity on the system.
Rather than chosing a "Scala" way to do things, often times Scala opts to
have things operate the way a Java developer would expect, as we expect a
lot of developers coming to Scala from Java. This familiarity can cause
issues with learning Scala. I remember struggling with try catch blocks at
first until I released that Scala had unified the concept of
pattern-matching with catching exceptions. I remember being confused the
first time the compiler asked me to make sure I has a value to return from
my if expression.
Comparing Scala to Wave I think is a misnomer. I think comparing Scala to
C++ is far better. C++ aimed at tight integration to C to pull C
developers into the new "object oriented" world. C++ is a rather complex
language with a bunch of interesting features. We can all argue over the
ugly features of C++, and a lot of this could perhaps be blamed on C
integration. However, of all the better OO languages at the time, C++ rose
in popularity, never quite replacing C.
Java comes around and attempts to pull C/C++ developers onto a crazy Virtual
Machine with garbage collection. I'd argue a lot of the rough edges in
Java come from attempting to be useful (i.e. pull C/C++ developers along).
I'm also very glad the designers of the langauge made the decisions they
did, because it meant a widespread Java adoption and proliferation of the
joys of a VM and GC.
Scala is gaining popularity. Scala attempts close integration with Java,
while trying to encourage its users to utilize a blend of Object Oriented
and Functional programming. The hope is to bring this new arsenal of
features to Java developers and free us to write better programs. I see it
taking a similar lifecycle to C++, of which I still program in
professionally. Perhaps Scala didn't quite do the "work well with the
older well-known" part right, but I think it's pretty darn close. Combined
with the huge surge in Scala libraries and utilities recently, my prediction
would be Scala to reach critical mass very shortly. Case in point, I hope
you all have read this techincal
report<http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBIQFjAA&url=http%3A%2F%2Flamp.epfl.ch%2F%7Eimaier%2Fpub%2FDeprecatingObserversTR2010.pdf&ei=ohReTJ_LD8GblgfoyPm7CA&usg=AFQjCNEdY1-mrWx4Sev3tCqrhRzDbaoDTg&sig2=aBZ1P6wC6fjAy0JcSKov3Q>
.
Also, as to your Open Source momentum point. I'm of the opinion that Scala
libraries should not strive for Java interoperability. This castrates a
lot of the useful features of Scala, much like writing C APIs in C++.
However, just like C and C++, there are mechanisms to provide a "Java Bridge
API" to a complex, useful Scala library. Most of the libraries I use in
Scala are not very easy to use within Java, nor do they attempt to be. The
Scala community is thriving with its own new libraries, and can make use of
the innovation occurring from the Java community.
Finally as to your point # 5, I simply have to laugh. Do you use the
google collections API? Do you make use of spring-jdbc (or many other
Spring libraries)? Do you use the new java.util.concurrent API from Java 5?
All of these make use of functional concepts, and all of them are great
libraries. Java is better because of the functional ideas that have been
ported to it. It's even adding closures soon, which is a very functional
concept. Isn't one of the rules in "Effective Java" - Prefer Immutable
Objects? Functional programming has influences a lot of the way you write
code in Java. Anytime you register a callback to execute at the completion
of some task, think: "this is somewhat functional in nature". Functional
programming is not Haskel or ML or Lisp. Functional Programming is a set
of concepts that revolve around functions as basic building blocks of
code. Object oriented programming is a set of concepts that revolve around
objects with behavior and state as basic building blocks of code. I find
these to be very compatible paradigms and often cross pollinate.
So, this became somewhat of a rant. I hope you enjoy. I don't think I've
posted anything flame-worthy here, but let me know if any of it is.
On Sat, Aug 7, 2010 at 8:30 PM, Liam Knox <[email protected]> wrote:
> I have on agree this to a certain extent.
> Maybe extreme Scala advocates need to take a lesson from Google Wave on
> this ;)
>
> Just because a language is packed full of features that make highly skilled
> developers more productive in no way means mass adoption or does it
> guarantee success.
> From working with a large teams with varying skill levels of developers I
> would indeed say it would be mad to move to Scala at this point for
> productivity claims. It just would not be more productive to do this.
>
> Indeed I feel Java 7 starts to bridge this gap in a large way.
>
> As for the other arguments
>
> 1. Conciseness : You can always have bad code regardless of conciseness,
> see Perl or APL for good examples. I don't buy this argument at all. Good
> Java development can produce very concise code already. This is not a
> winning argument
>
> 2. Productivity: The argument of individual productivity is completely
> irrelevant. You have to look a teams and indeed whole firms on this point
>
> 3. Complexity: Java is less complex this is a plus point fact.
>
> 4: Open Source momentum: Even though you have interop the opensource Java
> Libraries will all feel more natural in the pure Java world.
>
> 5. Functional Programming: Most developers see this as a big plus point
> but one must keep asking why, as functional programming has been around for
> donkeys years, has it still had little impact to date?
>
> I think the Jury is still out on Scala
>
> On Fri, Jul 30, 2010 at 6:40 PM, Blanford <[email protected]> wrote:
>
>>
>> There seems to be a Scala movement gaining steam on this site.
>>
>> I hate to break it to you all, but Scala will be going absolutely
>> nowhere!!
>>
>> There are many reasons for this:
>>
>> 1. Scala solves no practical business problem.
>>
>> 2. Scala is not easier than the alternatives.
>>
>>
>> Want to escape from Java? Your options will be dynamic type (ala
>> groovy, jython).
>>
>>
>> Sorry.
>>
>>
>> p.s.
>>
>> Stop bothering your employers with requests for esoteric software,
>> unless they really save money and/or time.
>> It is irresponsible to introduce software that has no track record,
>> unless it truly answers a big question that no other software (that is
>> more known) can answer.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "The Java Posse" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<javaposse%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
