Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Scala, a Statically Typed, Functional, O-O Language 299

inkslinger77 notes a Computerworld interview with Martin Odersky on the Scala language, which is getting a lot of attention from its use on high-profile sites such as Twitter and LinkedIn. The strongly typed language is intended to be a usable melding of functional and object-oriented programming techniques. "My co-workers and I spend a lot of time writing code so we wanted to have something that was a joy to program in. That was a very definite goal. We wanted to remove as many of the incantations of traditional high-protocol languages as possible and give Scala great expressiveness so that developers can model things in the ways they want to. ... You can express Scala programs in several ways. You can make them look very much like Java programs which is nice for programmers who start out coming from Java. ... But you can also express Scala programs in a purely functional way and those programs can end up looking quite different from typical Java programs. Often they are much more concise. ... Twitter has been able to sustain phenomenal growth, and it seems with more stability than what they had before the switch, so I think that's a good testament to Scala. ... [W]e are looking at new ways to program multicore processors and other parallel systems. We already have a head start here because Scala has a popular actor system which gives you a high-level way to express concurrency. ... The interesting thing is that actors in Scala are not a language feature, they have been done purely as a Scala library. So they are a good witness to Scala's flexibility..."
This discussion has been archived. No new comments can be posted.

Scala, a Statically Typed, Functional, O-O Language

Comments Filter:
  • Type erasure (Score:5, Informative)

    by shutdown -p now ( 807394 ) on Tuesday August 18, 2009 @02:17PM (#29108971) Journal

    Scala is great, but one really annoying thing about it is that it inherits type erasure [safalra.com] implementation of generics from Java. This means that you cannot overload methods on argument with the same generic class with different type parameters, cannot implement the same generic interface with different type parameters on the same class, cannot check whether a class implements a particular generic interface for a given type parameter, etc. They did fix some issues [lamp.epfl.ch] - for example, you can instantiate arrays - but it's still far from perfect.

    I understand the need to match Java's broken model for the sake of interoperability, but surely a better way can be devised for pure Scala code? It's pretty much the only area where Scala noticeably lags behind advanced .NET-hosted languages (such as Nemerle or F#).

  • by hey ( 83763 ) on Tuesday August 18, 2009 @02:20PM (#29109011) Journal

    Like mod_perl ?

  • by Fnord ( 1756 ) <joe@sadusk.com> on Tuesday August 18, 2009 @02:24PM (#29109071) Homepage

    You mean like Mason [masonhq.com]? Possibly you're looking for something more like Catalyst [catalystframework.org]?

    These things have been available for Perl for a long time.

  • by Anonymous Coward on Tuesday August 18, 2009 @02:30PM (#29109177)

    http://en.wikipedia.org/wiki/Strongly_typed

  • by Ann Coulter ( 614889 ) on Tuesday August 18, 2009 @02:33PM (#29109209)

    Strongly typed languages usually make type conversions explicit and enforce type restrictions; whereas weakly typed languages usually allow implicit type conversions and relax type restrictions.

    Explicit type conversions disallow a value of type T to be treated as a value of type S without invoking a function that takes a value of type T and returns a corresponding value of type S. For example, a conversion from an integer type to a floating point type requires the invocation of a function that performs the conversion. Contrast this with implicit type conversions where a value can be treated as almost any type depending on how it is to be used.

    Type restrictions only allow certain operations to be done to certain types. For example, numerical addition mïay only be performed on numerical types. A lack of type restrictions allow for numerical addition to apply for, say, booleans, for example.

  • by Ephemeriis ( 315124 ) on Tuesday August 18, 2009 @02:47PM (#29109441)

    What does that even mean?

    It basically means that variable types are rigidly enforced and conversions are explicit.

    It's annoying, but also eliminates some possible mistakes.

    For example, say you've got a float variable: FloatNum1
    And a couple integer variables: IntNum1, IntNum2

    Some languages don't care much about variable types and do conversions on the fly. So you could write code to do
    IntNum2 = (FloatNum1 + IntNum1)
    and nobody would complain. No errors. Nothing. It would compile and run just fine. At least, assuming you didn't lose something important in a rounding error somewhere.

    A strongly typed language will not allow that. It will kick out errors, refuse to compile, and generally pitch a fit. You are not allowed to add a float to an integer, and you certainly aren't allowed to assign it to another integer variable. Instead, you do something like this:
    IntNum2 = (Float_to_Int(FloatNum1) + IntNum1)

  • by Dgtl_+_Phoenix ( 1256140 ) on Tuesday August 18, 2009 @02:49PM (#29109477)
    Assuming you're not being merely rhetorical (because the definition is kind of loose), strongly typed just means that the language makes some restrictions on how operations operating on different value types can be intermixed. Assuming that you're not a programmer, I'll give an example. Letâ(TM)s say you have a BMW Z4 roadster. It's a car. Understanding the nature of cars, you know that it can be classified as a vehicle, a sports car, a BMW sports car, and a BMW Z4 roadster. Strongly type languages make restrictions like you can't just say: roadsterCar car = myCar. This is implicitly is saying my car is roadster. Rather you have to explicitly say that the car is a roadster (called a cast) like this: roadsterCar car = (roadsterCar) myCar This concept has a number of benefits, most of which are related to catching programming mistakes before they become bugs or immediately at runtime. Without strongly typed languages, you won't notice that you tried to call a bike a BMW Z4 roadster until you try to get it up to 140 miles an hour. And by then you might have tried to do valid but nonsensical things that might have really broken something.
  • Scala is a joy... (Score:5, Informative)

    by sitarlo ( 792966 ) on Tuesday August 18, 2009 @02:52PM (#29109529)
    Probably the most robust JVM compatible language to date. Even the creater of Groovy digs Scala: http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html [blogspot.com]
  • by SL Baur ( 19540 ) <steve@xemacs.org> on Tuesday August 18, 2009 @03:07PM (#29109729) Homepage Journal

    My point is that Scala is most certainly not re-inventing Perl.

    True, it also doesn't appear to be a reimplementation of anything. It's somewhat related to Java (Scala programs execute with the JVM).

    The code snippets on the website http://www.scala-lang.org/ [scala-lang.org] are intriguing. It's certainly a terse language. That's both good and bad.

  • by SL Baur ( 19540 ) <steve@xemacs.org> on Tuesday August 18, 2009 @03:15PM (#29109837) Homepage Journal

    Scala is statically typed. Most languages are strongly typed so that's not a particularly useful metric.

    Static typing means that every object type is known at compile time and thus type safeness can be enforced before the code is executed.

  • by Thuktun ( 221615 ) on Tuesday August 18, 2009 @04:27PM (#29110915) Journal

    Since Scala's been out since early 2004 [wikipedia.org], it's entirely possible to have had five years of experience with it.

  • Re:Type erasure (Score:4, Informative)

    by pjt33 ( 739471 ) on Tuesday August 18, 2009 @04:35PM (#29111059)

    The third of your listed limitations is semi-bogus: you can't check generic type information with instanceof, but java.lang.Class.getGenericInterfaces gives you the information you need if you're prepared to write a method to process it.

    I can't help feeling that the first two can be worked around too if you're prepared to be more creative with your Miranda methods than javac.

  • Re:Doomed (Score:2, Informative)

    by Adm.Wiggin ( 759767 ) on Tuesday August 18, 2009 @05:01PM (#29111411) Journal
    Finally, the comment I was looking for, since I was too lazy to look up his picture.

    For the curious: http://www.alenz.org/mirror/khason/why-microsoft-can-blow-off-with-c.html [alenz.org]
    And the followup: http://khason.net/blog/computer-languages-and-facial-hair-%E2%80%93-take-two/ [khason.net]
  • by speedtux ( 1307149 ) on Tuesday August 18, 2009 @08:07PM (#29113191)

    According to common usage, Python and Scheme are both "strongly typed" as well, since they guarantee that all type errors in programs are detected. This is in contrast to "weakly typed" languages like Perl or K&R C, in which many type errors are silently ignored. That is, all four combinations of strong/weak and static/dynamic typing are possible.

    Some people are using the term "strong typing" as a synonym for "static typing"; I wouldn't really care, except that there is no good other term to describe what "strong typing" means.

    From a practical point of view, it seems pretty clear that "strong typing" (in the first sense) is important, but I have seen little evidence that static typing is all that useful in a general purpose programming language.

  • by Anonymous Coward on Wednesday August 19, 2009 @03:16AM (#29115771)

    Parent suggested:

    y = [x*x for x in list]
    vs
    (let ((y (map (lamba (x) x*x) list)))

    Personally I prefer a syntax like

    y = list.map (function (x) x * x);

    where the BNF for a lambda should be something like

    lambda-expression := FUNCTION '(' params-list ')' statement
    | FUNCTION ':' return-type '(' params-list ')' statement ;

    so you could even write

    square = function : int (x:int) { return x * x; };
    y = list.map(square);

    if you don't feel like trusting the compiler's ability to do type inference.

This file will self-destruct in five minutes.

Working...