I will stick by it. Scala is more complex due to the amount of constructs
present in the language and the permutations this leads to in constructing a
solutions
I like your point about productivity though, If I went to my employer and
argued that I want to use Scala 'because it makes me more happy', no doubt I
would be secure in one thing, loss of job.
Productivity is a massive point. The productivity argument has to be viewed
at the macro level, this is where Java succeeded over C++ in the long run,
and largely because of its simplicity as a language, doing away with mind
fields like pointers and manual memory management. Add to that the Web
aspect at that time, and you had a language that had capacity to go viral
quickly.
But still you will see vast amounts of C++ a) because there are a lot of
systems out there written in C++ b) There are a lot of developers
maintaining/extending these.
I don't see Scala vs. Java has the same comparable benefits and I think the
lack of uptake proves this. Maybe if someone like SpringSource actually
started investing in it it would be a sign that things are changing.
I don't think comparing to Google Wave is an absolute misnomer, more a
topical tongue in cheek. What I would say is if it's designer wanted Scala
to supersede Java as the predominant language of choice at any time soon
then they made fundamental mistakes early on in making it too different from
Java. This seems the crux of Google Waves problems.
I definitely feel that if someone had pushed a refined version of Java, with
some form of closures, resource management and no primitives types/typed
exceptions, at the same time as Scala went live, it would of gained far more
adoption.
As for Functional programming. Sure you can use functional styles in
Java/Scala/C++, or in whatever language you can pass around some kind of
function construct. That isn't my point. Of course I have used
google-collections etc, etc and it is all very powerful. But my point is
clearly none of these pure functional languages have hit the big time, so
how exactly do you quantify say how Scala's support vs. Java's, improves
productivity?
The 'new' functional/OO fusion panacea that is only available in flavors F#
or Scala and solves the worlds problems, really doesn't exist.
On Sun, Aug 8, 2010 at 11:50 AM, Josh Suereth <joshua.suer...@gmail.com>wrote:
> 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 <liamjk...@gmail.com> 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 <euroscript...@gmail.com>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 javapo...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com>
>>> .
>>> 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 javapo...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com>
>> .
>> 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 javapo...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com>
> .
> 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 javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
