Scala 2.8.0 Beta distribution

Discussions

News: Scala 2.8.0 Beta distribution

  1. Scala 2.8.0 Beta distribution (23 messages)

    Some Java folks have already opined that Scala is too complex. The list of new stuff - and fixes - in the upstart language is quite extensive. The Scala team released the first beta of Scala 2.8. What is in it? A redesigned collection library; a new array implementation; type specialization; extensions to type constructor inference; support for nested Java annotations, and way more.
    Scala 2.8 adds support for nested Java annotations. For annotations on fields, it is now possible to specify which synthetic members (getter / setter) will have the annotation.
    Site http://www.scala-lang.org Annotations http://www.scala-lang.org/sid/5

    Threaded Messages (23)

  2. Scala is easy !!![ Go to top ]

    I thought too that Scala is hard, I almost gave up because I could not pick it up in one weekend (which I normally do with the usual suspects: ruby, python, lua etc...). But using scripting languages is like building a castle with sand. If it gets big enough it breaks down unless you write tons of test-scripts. Then oreilly released "http://programming-scala.labs.oreilly.com/" and I continued and discovered that it allows still a java-like programming style for beginners and has a smooth transition path to new (eg. functional) concepts. Like always, its a trade-off. My investments in learning scala now pay-off. There lies so much beauty in each- and every corner of the language that I got addicted. The eclipse plugin has currently (2.8 beta release) not yet the same standard as the java tools, but its getting better each day !
  3. Re: Scala is easy !!![ Go to top ]

    Try IntelliJ IDEA (OpenSource community version works just fine) with the Scala plugin. It's definitely better than Eclipse.
  4. Re: Scala is easy !!![ Go to top ]

    I thought too that Scala is hard, I almost gave up because I could not pick it up in one weekend (which I normally do with the usual suspects: ruby, python, lua etc...). But using scripting languages is like building a castle with sand. If it gets big enough it breaks down unless you write tons of test-scripts.

    Then oreilly released "http://programming-scala.labs.oreilly.com/" and I continued and discovered that it allows still a java-like programming style for beginners and has a smooth transition path to new (eg. functional) concepts.

    Like always, its a trade-off. My investments in learning scala now pay-off. There lies so much beauty in each- and every corner of the language that I got addicted.

    The eclipse plugin has currently (2.8 beta release) not yet the same standard as the java tools, but its getting better each day !
    Thank you for writing it out. I couldn't pick up scala either (in a few weekends, not just a weekend). Your case is a stimualtion for me to look at it again.
  5. Re: Scala is easy !!![ Go to top ]

    Scala isn't easy for the average programmer. It requires rather intelligent programmers to make use of the functional aspects in a sensible way. The average programmer isn't very intelligent. So whenever a clever dude in a shop picks up a language like this, the rest will suffer because they don't grok the fundamentals.
  6. Re: Scala is easy !!![ Go to top ]

    Scala isn't easy for the average programmer.

    It requires rather intelligent programmers to make use of the functional aspects in a sensible way.

    The average programmer isn't very intelligent.

    So whenever a clever dude in a shop picks up a language like this, the rest will suffer because they don't grok the fundamentals.
    It is true that becoming a master in Scala takes a lot of effort (I'm certainly not there yet). But you can begin using Scala productively after a modest amount of study if you write your code similar to how you would program in Java. Scala offers a lot of nice features that can make this modest route worthwhile.
  7. Re: Scala 2.8.0 Beta distribution[ Go to top ]

    Great news! 2.8 is a significant milestone for Scala (many would argue for 3.0 moniker). Although many of us would not touch scripting stuff with a mile long poll - Scala is a different universe. Yes, it takes more than a weekend to pick it up - but this is the first time since early 90s I am so excited about a new language. One of the major advantage for the actual commercial/enterprise work for Scala is that it is 100% compatibly with Java and Java eco-system. JBoss, Tomcat, Spring - you name it - all natively used when developing in Scala. And unlike Groovy you don't lose staggering amount of performance - and it's actually developed by people who understand language design... Another frequently overlooked advantage is that Scala is not linked to any specific framework: Ruby and Groovy would never exist without RoR and Grails. Especially for Groovy (at least now) - is is a one-framework language. Scala on the other hand is a general purpose language from its core and developed highly independently yet in a cohesive manner. Nikita Ivanov. GridGain - Cloud Development Platform
  8. Re: Scala 2.8.0 Beta distribution[ Go to top ]

    And unlike Groovy you don't lose staggering amount of performance - and it's actually developed by people who understand language design...
    Yes, there are some situations where Groovy might not be fast enough, but saying that Groovy is a badly designed language is ... at best unfair. The Groovy language was designed to be very close to Java, which minimizes the effort for learning it and makes it easy to switch between Groovy and Java whereever needed. It is a dynamically typed language with the typical advantages and disadvantages of dynamic typing. Closures, metaprogramming, syntactical sugar for XML handling and many other features make it a joy to use for most scripting purposes.
    Another frequently overlooked advantage is that Scala is not linked to any specific framework: Ruby and Groovy would never exist without RoR and Grails. Especially for Groovy (at least now) - is is a one-framework language.
    Groovy has been around for several years before Grails came out and it was successfully used for scripting. Groovy is not linked with one framework either, but at least it has a "preferred" framework. While the statement about Grails is correct in theory, it's not in practice. Grails provides a framework that comes with support for MVC controllers, persistence, template management, transactional services and a lot more. However the strength of Grails is the plugin infrastructure, which makes all aspects of Grails pluggable. So if you like GWT over the core Grails template and UI system, go with the GWT plugin for you UI. In fact all core components are plugins which turns Grails into more of a meta framework, than just a simple MVC framework that forces you into one way of doing things. About 400 plugins show that this infrastructure is well alive and developing rapidly. All that does not mean that I don't like Scala or that one is better than the other. It comes down to your requirements, but in many situations Groovy and Grails are a great choice for scripting as well as for building small to large and complex applications. Stephan Albers
  9. YAHL[ Go to top ]

    Scala is an interesting language, but currently, it is at best yet another hyped language. While it's functional concepts are interesting, they suffer twofold: Firstly from the usual problem with all functional languages: (Clever) Programs are not understandable but anyone but the original programmer, secondly, because all functional programming in scala is built on sand, since each and every function can induce side effects. It is interesting for its parallel processing support, but there is little benefit in using a language for something where a concise and well designed library in Java does the Job equally well. The obsession with "concise" code will swing back in a couple of years, since concise usually means harder to understand, especially once "operator overloading" is used heavily . We are currently at a point where obsession with conciseness and defaults is at its maximum in most programming environments. The odd thing is that typing speed or trivial errors in for loops never was the prime problem in the last couple of years but built times, container startup times and test data provisioning... On top of this there is no more tangible job market for Scala than for LISP fifteen years ago.
  10. It has merits[ Go to top ]

    This point of view has certain merits for sure. One feature of Scala that overrides most of the skepticism for me is the fact that it is statically typed unlike anything else that came in lately in JVM-based languages. Obviously, the fact that it is 100% compatibly with Java/JVM doesn't hurt either. I don't know if Scala will succeed in replacing Java (doubt it in a short term) but it certainly going to displace Groovy and dent Java more than we currently thing, IMHO. Best, Nikita. GridGain - Cloud Computing Platform.
  11. Re: YAHL[ Go to top ]

    Scala is an interesting language, but currently, it is at best yet another hyped language. While it's functional concepts are interesting, they suffer twofold: Firstly from the usual problem with all functional languages:
    (Clever) Programs are not understandable but anyone but the original programmer,
    What evidence do you have to support this assertion? Why are *all* functional languages impossible to understand? Or are you just prejudiced against functional languages?
    secondly, because all functional programming in scala is built on sand, since each and every function can induce side effects.
    So can every variable, method, or class in objected oriented programming. What's your point?
    It is interesting for its parallel processing support, but there is little benefit in using a language for something where a concise and well designed library in Java does the Job equally well.
    No good multithreaded code in Java is "concise". The executor framework, Atomic classes and queues help with this, but writing good, multithreaded code in Java is an exercise in careful design. Behind all those classes is really ugly synchronization. Functional languages are great with concurrency because the messages that call functions pass immutable messages. The best way to avoid concurrency issues is to use immutable objects.
    The obsession with "concise" code will swing back in a couple of years, since concise usually means harder to understand, especially once "operator overloading" is used heavily .
    Prove that Scala encourages operator overloading before you make those statements. Are you going to tell me with a straight face that Java 5 features such as varargs, the enhanced for loop and even generics make code harder to read?


    We are currently at a point where obsession with conciseness and defaults is at its maximum in most programming environments. The odd thing is that typing speed or trivial errors in for loops never was the prime problem in the last couple of years
    The old-school for loop had NPEs waiting to happen in nested loops. The conciseness of the enhanced for loops helps to prevent these kinds of runtime errors.
    but built times, container startup times and test data provisioning...

    On top of this there is no more tangible job market for Scala than for LISP fifteen years ago.
    Just because nobody's hiring for a programming language makes it a poor language? By your measure, PHP is a wonderful language because so many sites use it and so many companies hire PHP programmers.
  12. Re: YAHL[ Go to top ]

    What evidence do you have to support this assertion? Why are *all* functional languages impossible to understand? Or are you just prejudiced against functional languages?
    Functional programs are per se harder to understand. This is not a "problem" with the languages but with the underlying algorithms. Essentially, functional programs are like induction proofs on steroids whereas normal programs are like dashboard calculators on steroids. I claim the latter is easier to understand by and for most people.
    secondly, because all functional programming in scala is built on sand, since each and every function can induce side effects.

    So can every variable, method, or class in objected oriented programming. What's your point?
    The point is that "immutable" structures in Scala are mostly mutable data! Thus they are bound to experience race conditions in concurrency in exactly the same way data in normal Java does.
    Functional languages are great with concurrency because the messages that call functions pass immutable messages. The best way to avoid concurrency issues is to use immutable objects.
    Scala for the most part will not pass immutable objects!
    Prove that Scala encourages operator overloading before you make those statements.
    Are you kidding?? "Operator overloading" is one of the chief features in Scala that makes it a prime candidate for "Domain Specific Languages".
    Are you going to tell me with a straight face that Java 5 features such as varargs, the enhanced for loop and even generics make code harder to read?
    Generics: Yes, they make code harder to read but they have a certain point. The enhanced for loop is not a replacement for a for loop but it is for 99% of scenarios a short form of an Iterator. Varargs do indeed make code harder to read/understand if not carefully used.
    The old-school for loop had NPEs waiting to happen in nested loops. The conciseness of the enhanced for loops helps to prevent these kinds of runtime errors.
    Did you ever come across a construct called an "Iterator"?? Is it really so hard to keep track of two or three indices?? I stand in awe that people think, this is hard and error prone but functional programming is easy!
  13. Re: YAHL[ Go to top ]

    The point is that "immutable" structures in Scala are mostly mutable data!
    You lost me here. Could you humor me and elaborate?
  14. Re: YAHL[ Go to top ]

    The point is that "immutable" structures in Scala are mostly mutable data!


    You lost me here. Could you humor me and elaborate?
    Immutable Structures in Scala are mainly immutable Lists that contain objects. There is very little that prevents one from changing the content of an object, as long as it is not a primitive or a string. So there is in fact very little data that is immutable on the language level. Which may be the main reason the Scala Book is sprinkled with warnings about this situation.....
  15. Re: YAHL[ Go to top ]

    The point is that "immutable" structures in Scala are mostly mutable data!


    You lost me here. Could you humor me and elaborate?

    Immutable Structures in Scala are mainly immutable Lists that contain objects. There is very little that prevents one from changing the content of an object, as long as it is not a primitive or a string. So there is in fact very little data that is immutable on the language level. Which may be the main reason the Scala Book is sprinkled with warnings about this situation.....
    I see. It's easy to create new immutable object types in Scala, though.
  16. Re: YAHL[ Go to top ]

    The point is that "immutable" structures in Scala are mostly mutable data!


    You lost me here. Could you humor me and elaborate?

    Immutable Structures in Scala are mainly immutable Lists that contain objects. There is very little that prevents one from changing the content of an object, as long as it is not a primitive or a string. So there is in fact very little data that is immutable on the language level. Which may be the main reason the Scala Book is sprinkled with warnings about this situation.....
    Just define your fields as vals and the object will be immutable.
  17. Bull...[ Go to top ]

    Just define your fields as vals and the object will be immutable.
    This is just the kind of arrogance that drives me mad. Why do you think Odersky et al time and again stress that vals are not immutable in their Scala book?! The only thing a val does is to prevent you from reassigning the variable. It does NOTHING to prevent mutation of the val itself. Scala gives you tools to create immutable data structures but this is mainly through coding convention. So does, on a lower level, Java (to some extent): Make all fields private and only define a constructor and setters.
  18. Re: Bull...[ Go to top ]

    Scala gives you tools to create immutable data structures but this is mainly through coding convention. So does, on a lower level, Java (to some extent): Make all fields private and only define a constructor and setters.
    Both Scala and Java support immutability with the val and final keywords. It's just not supported at a composite level for which the definition would be something like: ::= []* []* That is an immutable object can only be composed of immutable objects and primitive vals. I would hope this is pretty basic stuff to anyone who programs in Java much less Scala. I've thought for a long time that it would be a really good idea to have a immutable (of const if you prefer) keyword that would enforce this at the composite level at compile time and at runtime.
  19. Re: Bull...[ Go to top ]

    I've thought for a long time that it would be a really good idea to have a immutable (of const if you prefer) keyword that would enforce this at the composite level at compile time and at runtime.
    The problem is that this is a very hard restriction as it would also mean to prevent subclassing at some level (you cannot be sure that a derived class is still an immutable data structure). Also it would take away a lot of the benefits you get with Scala Traits.
  20. Re: Bull...[ Go to top ]

    I've thought for a long time that it would be a really good idea to have a immutable (of const if you prefer) keyword that would enforce this at the composite level at compile time and at runtime.


    The problem is that this is a very hard restriction as it would also mean to prevent subclassing at some level (you cannot be sure that a derived class is still an immutable data structure). Also it would take away a lot of the benefits you get with Scala Traits.
    You could have a mutable subclass of an immmutable class. You could have an immutable class of a mutable subclass, though. As I mentioned above, there would need to be runtime checks. That would allow you to create an immutable list of Object, for example. I don't see how this would eliminate the benefit of traits. This would only matter if you required immutability. If you don't, everything would work as it does today.
  21. Re: Bull...[ Go to top ]

    You could have a mutable subclass of an immmutable class. You could have an immutable class of a mutable subclass, though.
    Correction: could not have an immutable class of a mutable subclass
  22. Re: Bull...[ Go to top ]

    You could have a mutable subclass of an immmutable class. You could have an immutable class of a mutable subclass, though.


    Correction: could not have an immutable class of a mutable subclass
    Arrgh... could not have an immutable subclass of a mutable class.
  23. Congrats for 2.8 and comments[ Go to top ]

    Congrats to the Scala team for 2.8 Learning Scala is like drinking beer - once you get used to it, you'll like it but the first few times you drink it most find it overwhelming. Just remember you don't have to chug your first glass of Scala! Use the language as your tool, start coding your 1st project in the same fashion as you do in Java then integrate it's functional and syntactic sugar over time as you get comfortable with it. My code Scala is typically half the length than the same thing done via Java, plus it's more concise and is easier to maintain. Even ignoring performance, concurrency, etc. easier maintenance makes the learning curve for Scala more than worthwhile to me. Groovy is nice too and similar in many ways, but it's a dynamic language... Unless I needed Grails, I don't see any reason why I'd go back to using Groovy again.
  24. Re: Scala 2.8.0 Beta distribution[ Go to top ]

    I delved into Scala a bit a couple years ago. I was frustrated at how fast it was changing and the lack of easy to understand documentation about the core language. People will tell you that Scala is really very simple and what people think is complicated is just the libraries written on top of it. That's great and all but I couldn't find any usable documentation on that underlying language. A lot appears to have changed in the last few years. There are a number of books and from what I hear, 2.8 is going to be a pretty stable version. It might be time to take another look.