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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
