Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

Scala Designer Martin Odersky On Next Steps 94

rfernand79 writes Infoworld has an interview with Martin Odersky, designer of Scala, in which they discuss the future of this popular language. Three versions are discussed as being part of the Scala roadmap: The first one (2.12) focuses on better integration with Java 8, and making use of the latest improvements in the JVM. The second one (Aida) focuses on cleaning up the Scala libraries. But the third one (Don Giovani) is about a fundamental rethink of Scala, with a strong focus on simplicity.
This discussion has been archived. No new comments can be posted.

Scala Designer Martin Odersky On Next Steps

Comments Filter:
  • "Guyth" (Score:3, Funny)

    by smittyoneeach ( 243267 ) * on Saturday September 06, 2014 @10:45AM (#47841201) Homepage Journal

    But the third one (Don Giovani) is about a fundamental rethink of Scala, with a strong focus on simplicity.

    "Guyth. Let uth dump all the thyntaxth exthept the parens, and put the left one before the thymbol name."
    "Hey, man: what's with the sudden lisp?"

    • Isn't step 3 basically "scala is old. let's make a new cool language instead."?

    • Yes, dynamic languages like Clojure are nice, but so are static ones. I actually consider Scala a dialect of ML, much in the way that Ruby is a dialect of Smalltalk.

      • Technically, with Lisp being a metalanguage and more of an idea than a single artifact (unless we're talking about Common Lisp), building a statically typed language on top of it isn't exactly inconceivable.
  • Simple is good (Score:5, Insightful)

    by djbckr ( 673156 ) on Saturday September 06, 2014 @10:59AM (#47841297)
    I really like Scala, but I only use a small subset of all the crazy (and what I consider a bunch of superfluous) language features. Simpler Java with Closures is what is should be. Granted I'm not a language expert/theorist, but most of us that code for a living aren't. Trying to read some of the more esoteric features of Scala leaves me with "I thought it was supposed to make my life easier". When I have to spend an hour looking up syntax to describe what the code is doing - well, that doesn't work for me.
    • >Granted I'm not a language expert/theorist, but most of us that code for a living aren't. What exactly do you mean by this?
    • by Anonymous Coward

      I have the same problems as you with Scala. Add to that constantly changing libraries and it is a no go for me in projects.
      Kotlin looks more interesting.

    • Re:Simple is good (Score:4, Interesting)

      by pijokela ( 462279 ) on Saturday September 06, 2014 @12:51PM (#47841849)

      I've been using scala for two years now and I think there is a simple trick to avoiding the problems you mention:

      1. Many of the language features are best left to library designers so that application code is easy to understand. This is not a problem unless you make it one.
      2. Carefully choose what libraries to use. Specifically avoid using all the esoteric stuff in github. Especially if the library is very "functional" and has lots of "operators". Just don't use them. Using Play and Akka and the stuff that typesafe uses I haven't really had too much trouble with migrations or code that is impossible to understand.

      And, coming from 10 years of Java, I am loving Scala development. :-)

      • by Anonymous Coward

        I second that!

        Coming from 12 years of Java and using Scala for around 1.5 years and following exactly same guidelines and using Akka to do my PhD research,,, life is heaven with Scala.

    • Re:Simple is good (Score:4, Insightful)

      by phantomfive ( 622387 ) on Saturday September 06, 2014 @01:26PM (#47842029) Journal

      Granted I'm not a language expert/theorist,

      Most people who design languages aren't either. It's a big elephant, and most language designers only see one side. There are the functional guys (like the Haskell designers) who see that immutability reduces bugs, but they don't see the benefits of object oriented programming the way Bertrand Meyer does. But Bertrand Meyer doesn't understand the benefits of run-time type binding, the way Alan Kay does. Alan Kay has a good understanding of message passing, but is an eternal academic.

      Most programming language innovations are syntactic sugar, merely changing the way we write things. It's rare that a new language idea comes along that actually makes a difference.

    • by plopez ( 54068 )

      Simpler Java + closures==Groovy

      • Groovy is not really very simple. But more importantly, it's not a simpler Java at all. Since Groovy is dynamic and Java is static, they are completely different languages that bear a superficial syntactic similarity.

    • I'm with you on this point. I generally won't find a team already using Scala. They are out there, but very rare. In most cases, you would be in a JVM shop, and have to convince your team mates that Scala is a good fit for such and such reasons. Well, language features like implicit casting and variables make it a very hard sell, to say the code that we are producing is maintainable. Because it surprises Java programmers see things suddenly works because you have imported a package.
  • Every time I teach a beginner's course, I am reminded of just how ugly Java really is. Here's a simple example:

    - Comparing two "int" variables, you use ==
    - Comparing two Integer variables, you probably want .equals()
    - But it is possible to have two different Integer objects with the same value - this is when you wand ==
    - But Java wants to save memory, so in fact == and equals yield the same result for values from -128 to +127

    That's one example, but there are lots more. A more advanced example are the generi

    • by peppepz ( 1311345 ) on Saturday September 06, 2014 @12:43PM (#47841807)

      Every time I teach a beginner's course, I am reminded of just how ugly Java really is. Here's a simple example:

      - Comparing two "int" variables, you use == - Comparing two Integer variables, you probably want .equals()

      Comparing *any* object, you want to use equals(), there's no "probably".

      - But it is possible to have two different Integer objects with the same value - this is when you wand ==

      No, you don't. Comparing two Integer objects, as any other object, with ==, will compare the two references to the object in order to determine if they point to the same object. The object contents won't be looked at. This is simple to learn and teach, and elegant as a design. I find no ugliness whatsoever in this.

      - But Java wants to save memory, so in fact == and equals yield the same result for values from -128 to +127

      Although you didn't mention it, you are thinking about autoboxing. Java makes efficient use of memory and, by using == to test object identity instead of equals() you can detect this optimization. This can't influence any working code (because comparing the results of .equals() and == makes no logical sense) and certainly isn't confusing.

      A more advanced example are the generics that disappear when the code is compiled. I understand the arguments for doing it this way, but I disagree with them - if you have generics, you ought to be able to query the types at run-time. There are lots and lots of highly questionable design decisions - basically, 20 years of backwards compatibility.

      It's past time to clean house. Building a new language on top of the established JVM technology seems like a very good idea indeed. Perhaps Scala can fulfill this role...

      Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.

      • Re: (Score:2, Informative)

        by 0123456 ( 636235 )

        Comparing *any* object, you want to use equals(), there's no "probably".

        Except small Integer objects are usually cached, so == works. Except if someone manually created a new one.

        This is one of the most retarded things about Java. Certain types work with == and certain instances of certain types work with ==, and others don't. I've had to fix a ton of Java bugs which happened because someone accidentally used '==' when they meant to use 'equals'. It really is at the bash-your-head-on-the-table level of stupid design.

        • . I've had to fix a ton of Java bugs which happened because someone accidentally used '==' when they meant to use 'equals'.

          How did that code even get committed? That sort of thing is easy enough to test.

        • Exactly. It's been a while, but I remember tracking down one bug in a framework that managed other classes. The developer had assumed that all objects were, in fact, different objects. However, with Strings, Java used its cute little cache. In the framework this meant that two objects that should have been different had the same reference (== was true), which led to problems. The details escape me - it's been a while - but tracking this down was not trivial.

          It's all well-and-good to say that you should only

        • No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and it "works" with compiler-generated structures in the same way as comparing C strings with == instead of strcmp() may happen to "work", or comparing C arrays using > may happen to "work". The difference between a value and a reference is a very basic concept of programming, and in the case of Java it's explained very early in learning courses. If anything, languages that
          • No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and ...

            Oh my god. Excuse me, but you are so very wrong. Yes, it DOES work and is a GOOD THING to compare references sometimes. For example, if you are implementing your own general hash-based collection class, you will find that your lookup code runs significantly faster if you first compare object references for equality before comparing the object's hash followed by comparing the objects themselves for equality. That is to say: (1) First compare object references using ==. If equal, you're done immediately becau

            • Please read the post I was replying to, it was claiming that checking for object value equality using == sometimes works. That's what doesn't work, and rightfully so. Sorry if it wasn't clear, but unfortunately I'm using the mobile site and I can't find the "quote parent" option.
              • Ok, cool... Ya, after I posted that and re-read it, I thought to myself, "I wonder if he was referring only to Integer, in which case I'm going to feel like an a-hole for being so harsh." Apologies if I came across as harsh.

                Question... what did you mean by "For any kind of object" then?
                • That there is no inconsistence in Java between classes for which supposedly you can get away with == and classes which require you to use equals(), as was suggested in the post I was replying to.
                  • I'm pretty sure, though, that even any class that requires you to use equals(), you can still use == as a fast-precheck. That is, a==b implies a.equals(b) for all objects a,b in all classes. The converse, of course, is not the case: a.equals(b) does not imply a==b. And the inverse is not true: a!=b does not imply !a.equals(b). But the contra-positive is true: !a.equals(b) does imply a!=b.
      • I think you misunderstood what bradley13 wrote. Java pre-constructs the low valued Integer objects, so that == and .equals will always return the same answer. But for larger values, they don't. This is entirely independent of autoboxing.

      • Scala has type erasure, too, and IIRC it was designed by one of the guys who are responsible for the design of type erasure in Java.

        You are correct. I believe that the Pizza language, which became Java generics in the Tiger release, was designed by Martin Odersky. Type erasure in Tiger was deemed necessary for backwards compatibility with Java 1.4 code.

        And consequently, Scala has type erasure for interoperability with Java. IIRC, James Gosling wanted many features like generics in Java, but couldn't get

    • by gweihir ( 88907 )

      Good example. The core problem is that Java was never indented as a mainstream language, but for embedded programming. In embedded systems, trade-offs like the ones you describe make sense and programmers for embedded systems understand them. In a general-purpose language, they are insane and a reason that Java should never have become popular. The whole inheritance model is deeply broken as well and basically prevents general teaching of the concepts and ideas, because Java is a jumble of special cases. Un

      • The core problem is that Java was never indented as a mainstream language, but for embedded programming.

        s/never/not originally/

        FTFY

        • by gweihir ( 88907 )

          "Never" as in "Not before the design was mostly fixed". This makes my statement correct. Of course intentions can be changed without changing the design, but that is meaningless.

  • by Anonymous Coward

    "But the third one (Don Giovani) is about a fundamental rethink of Scala, with a strong focus on simplicity"

    In other words, don't bother with Scala just yet since we haven't made up our minds about the syntax and will probably start all over.

    This isn't even taking into consideration the forking of syntax between Typesafe's Scala and Typelevel's Scala.

    I find it amusing when other JVM languages bash Java's baggage while they are young, but then they too get old and find out they created a bunch of baggage t

    • In other words, don't bother with Scala just yet since we haven't made up our minds about the syntax and will probably start all over.

      One of the links actually lists the changes they are thinking of. To me they all make sense and they won't change the language too much while making the life of the compiler easier - and the result more predictable to humans.

      Let me know when you get that binary compatibility between versions of Scala figured out.

      Just a few months ago I saw a project at work that could not migrate to Java 8 because some of the libraries in the project do not work with Java 8 libs. The problem is that the lib in question wants to do bytecode enhancement and fails with the new lib format. Scala is more complex, no

    • In other words, don't bother with Scala just yet since we haven't made up our minds about the syntax and will probably start all over.

      Actually, no. It's not about modifying the syntax. It's about bringing some very exciting ideas from research into Dependent Object Types into a mainstream language.

  • by Anonymous Coward

    Seriously, it's very easy to write code that you yourself can't even understand the next day.

    • by gweihir ( 88907 )

      Too much language flexibility and an inexperienced programmer can do that. A good programmer does not have that issue. I have given Perl and C code to students on many occasions to extend or modify it and never had any complaints.

  • by gweihir ( 88907 ) on Saturday September 06, 2014 @03:44PM (#47842637)

    In The press, maybe. In actual use, it seems rather doubtful.

    • It depends on what we mean by "popular". If popular means that more lines of Scala are being written than Java, then, no, Scala is not popular.

      But if we mean that the Scala programmers are in demand, then yes, Scala is popular.

      • by gweihir ( 88907 )

        The second definition is problematic, as, for example, Cobol programmers are still in demand.

      • by Xest ( 935314 )

        "But if we mean that the Scala programmers are in demand, then yes, Scala is popular."

        No it doesn't, because popularity sits on a spectrum, and the level of demand for Scala programmers is at least an order of magnitude lower than for Java, C#, C++, Python, Javascript, and PHP developers for example. Popular would imply Scala is high on the demand rankings, it's just not, not by any measure.

//GO.SYSIN DD *, DOODAH, DOODAH

Working...