'Whatever makes you think that beta max was such a failure?' - that it was, and absolute and total commercial failure, as was Toshiba HD, both basically beaten to the punch, end game massive losses.
I think you are missing the general point. My argument is at the macro level. This is about far more than just a self appointed technical Phd in what language is best. You have to ask questions. Why has pure functional programming failed for the last N+ years? Why did Beta Max fail? Why did Google Wave fail? Why will Scala fail? and Why is Java a success ? All I see from Scala advocates here is a pure self assessment at that micro level. I like Scala therefore it is great. I think Smalltalk suffered this same delusion of grandeur. Indeed it is interesting, but certainly it was out of sync with software at that time at failed due to this. Personally I am taking a barometer in general judgement about Scala, as mentioned mine is SpringSource. On Sun, Aug 8, 2010 at 9:53 PM, Kevin Wright <[email protected]>wrote: > Whatever makes you think that betamax was such a failure? > The "professional" derivative, known as betacam, was the de-facto standard > in many scenarios - right up until digital technologies took over. > Although supplanted it still continues to be popular, and even comes in an > HD variant. VHS can make neither of these claims. > > Of course, home users (who might be considered the video recording > equivalent of "script kiddies") went with VHS > There's a lesson to be learnt here: For a certain audience, PHP will be > more popular than Scala. > But for those who are deep into system work, or for who quality matters, > betacam will rightly be recognised as the technically superior format. > I can live with that... > > > As for wave? I don't think any open-source software ever truly dies. > It lives on in Novell Pulse and in the collaborative features of google > Docs. > > > On 8 August 2010 13:28, 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. >> > > > > -- > 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.
