On 8 August 2010 06:55, Liam Knox <[email protected]> wrote: > 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
Have used both languages professionally, I find Scala's consistency to be refreshing Java: primitive types / Scala: everything is an object Java: `switch` on numeric types only / Scala: pattern match against *anything*. Java: special-case handling for concatenating to strings / Scala: implicit conversions usable in many scenarios beyond string concatenation Java: special notation for catching exceptions / Scala: reuses pattern-matching Java: mix of checked/unchecked exceptions / Scala: all exceptions are unchecked Java: equals() doesn't work on primitives, `==` gives the wrong answer on objects / Scala: `==` Just Works(tm) wherever you use it This consistency means that you don't have to learn special rules for different parts of the language, and can actually help unify concepts and reduce the number of permutations used. Speaking of which, any Turing complete language has exactly ∞ possible permutations for constructing any given solution, this is not a useful figure to compare. 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. > So your employer is resistant to change and likes people to be unhappy. Fine, just don't wish that on the rest of us. 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. > `Raw` collection types, checked exceptions, lack of type-inference, the need for SAM interfaces. These are all also minefields. Then there's null pointers. Termed the "billion dollar mistake" by inventor Tony Hoare ( http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare ) Scala has the ability to eliminate NPEs when not doing Java interop... > 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. > They started investing in Groovy first, which would suggest that they know of Java's imperfections. More importantly, Scala is a strongly-typed language, and Spring is rather shoddy when it comes to strong typing... > 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. > I think many of the arguments against Scala are rationalising a very human and very emotional "resistance to change" Any non-Java language attempting to gain mind-share would have something found wrong with it, simply because it isn't Java This, more than anything else, is the biggest barrier to Scala's adoption, and was the biggest problem with Wave 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? > Imagine google-collections without the need for all those SAM types, and without every parameter having to be <? super X> or <? extends Y> That should give you an idea :) The 'new' functional/OO fusion panacea that is only available in flavors F# > or Scala and solves the worlds problems, really doesn't exist. > Programming languages solve problems for programmers programmers solve problems for other people people solve problems for the world And hey! Just getting rid of NPEs would make the world measurably better, if only by a very very small amount. > On Sun, Aug 8, 2010 at 11:50 AM, Josh Suereth <[email protected]>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 <[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]<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. > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
