I agree with you on this. I am surprised at the point at what made Scala fail - maybe the implementation and the complexity was something that these guys ignored..
Surely, FP has its own area of suitable implementations. There are so many places where it can be properly implemented but there is surely no better point than the point on the PM's choice of using Scala or not? Regards, Jitesh Dundas On Sun, Aug 8, 2010 at 5:58 PM, Liam Knox <[email protected]> wrote: > I am a very realistic chap. Scala does not live in the same light as Java > vs C++ > All I am hearing is 'I like Scala therefore is has to succeed'. This means > nothing > > As far as I understand it Beta-max is better than VHS and also Google Wave > is.was the next big thing > Rationally you have to look at what really works. > > On Sun, Aug 8, 2010 at 5:58 PM, Kevin Wright <[email protected]>wrote: > >> >> >> 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]<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.
