Scala is a modern multi-paradigm programming language running on top of a Java VM or .NET runtime. Recently version 1.4.0.3 has been released.
Scala smoothly integrates features of object-oriented and functional languages.
In Scala, every value is an object and the language supports OOP for instance via subclassing , traits, and mixins.
Scala is also a functional language in the sense that every function is a value. The language supports anonymous, higher-order and nested functions as well as currying.
There is also integrated support for pattern matching, parametric polymorphism, etc.
It just seems too shallow to matter. 5 Lines for a hello world? Or you bend the reality or it seems “just another language for the JVM”, despite it having support for .Net.
I disagree: I looked at this language before and IMHO it has a very nice syntax.
Much cleaner than Java or C# syntax..
5 Lines for a hello world?
This measurement is downright stupid. The language HQ9+ is amongst other things optimized for Hello World programs, hence the source for Hello World is:
H
Following your logic, HQ9+ is therefore a better programming language, although you can accomplish hardly anything in it. 🙂
http://en.wikipedia.org/wiki/HQ9_Plus
Right!
It’s stupid to want to write less code. Suddenly some genious will write a program to generate another program or will want an IDE to help him to control the code.
Conciseness matters a lot when you are not maintream. Mainstream languages, despite being verbose, have lots of mindset and tools to keep people interested in them, but new languages have a lot of stablished competition, and the “coolness” is shared even with brainf–k languages or languages like the guy above suggested.
H
Having just had a look at it there, I can say it seems a lot more powerful than Ruby. The ability to use all the classes in the JDK is also incredibly powerful (it means you can use Swing for one thing).
It seems like the first decent attempt to mix the best parts of functional languages (which are generally great at representing algorithms) with object-orientated languages (which are great for representing data).
Now of course, it requires knowing a bit about functional programming (I did Haskell myself in college), but if you know that much, you can get going really fast. I saw the article an hour ago, and I came up with my Swing-powered Hello, World example just there:
object HelloWorld
{
def main (args : Array[String]) : Unit =
{
import javax.swing._;
val frame = new JFrame();
val label = new JLabel (“Hello, world”);
frame.add (label);
frame.pack();
frame.show();
}
}
Now of course, that’s incredibly procedural and java-like, but if you look at the quick sort example in the Scala by Example guide (http://scala.epfl.ch/docu/files/ScalaByExample.pdf) you’ll see that you can use as many functional programming idioms as you want to drastic reduce the amount of code you have to type.
I have to say, I’m very impressed. Thanks to the anonymous poster for submitting the story.
Hmmm looks something like Ruby with a bit of Python and C mixed in
Might be worth a quick peek.
I’m not sure it is right to compare it to Ruby which has dynamic type and automatic variable declaration.
Scala has variable declaration (prevents stupid typos from ruining your day), static typing but with local type inferencing which means that most of the times a simple ‘var x = <expression>;’ is enough: it makes programs safe AND readable.
[ D has introduced local type inferencing recently and C# will have it for version 3.0, apparently this (nice) feature is spreading.. Granted Limbo (a nice language for Plan9) had it ages ago, but the more the better. ]
So Ruby is more flexible than Scala, but for big programs I prefer mandatory variable declaration and static typing..
Yeah, i’m just getting into the whole Python, Ruby, Perl universe of languages
Not really for business purposes (for that i have to use c#, java, visual basic and c), but more for pleasure 
One thing i’ve noticed about Ruby and Python is that you can just write code (granted there is a potential for that little spelling mistake), and not worry about all the other hmmm boring stuff
Not sure if i could do that with Scala, although im willing to give it a go…right now my sum total of knowledge concerning scala is about a paragraph
I don’t like dynamic typing: I think it introduces ambiguity and makes it easier to make subtle errors.
For example, in JavaScript, I wrote
var a = 0.95;
a = a + getCookieValue (“fontResize”);
and was amazed to find that instead of getting 1.10 I got 0.9515. This is because JavaScript has polymorphic operators without any clear way of identifying the type. The correct way was
a = 0.95;
a = a + ParseFloat (getCookieValue (“fontResize”));
PHP is a bit better, as it doesn’t use polymorphic operators (+ is addition and . is concatenation). However the whole type coercion thing is really messy. It means PHP has two equality operators:
== means has equal values
=== means has equal values of the same type
This all comes down to something that Anders Hejlsberg (one of the C# designers) called “simplexity”. You add this cool feature, such as not having to declare a type, to make a language easier. However once you get down to doing some serious work, you start running into these weird errors, and then you realise that in fact there are different underlying types, and you have to do weird things (ParseFloat, ===, etc.) to get around this. Consequently, the method of making the language easy, while successful in the trivial “Hello, world” case, actually makes the language more complex in the real-world case.
In JavaScript, seeing as we already use “var”, surely it wouldn’t have been much harder to write
float a = 0.95
a = a + getCookieValue (“fontResize”)
which would immediately trigger a syntax error with a nice message explaining what went wrong.
While this is the primary problem I have with dynamic languages, another problem I have is that when you don’t have to declare variables, there is not way the compiler can detect a typo. For example this code will compile without an error
var myCrucialResizeAmount = 0.95
var a = ParseFloat (getCookieValue (“delta”));
c = a * myCrucialResizeAMount + b / q;
document.getElementById (‘Text’).style.fontSize = c;
The problem here is that because of my typo, the value will be b / q. However there is no obvious error that will alert me to that, and in a large piece of code, it can be hard to find the offending mistake.
The final problem with dynamic typing is that it makes it profoundly difficult for an IDE to identify a type, and thus provide an auto-complete feature. Given that any OOP language with its salt these days will come with a huge library, the inability of an IDE to help you out is a major dent to productivity.
This is why I like static typing: for very little extra work on the part of the programmer, you get a whole load of assistance and quality assurance from the compiler and the IDE. I’d rather a tiny bit of “hmmm boring stuff” then half a day trying to manually search for a typo. It is also why I like what I’ve seen of Scala so much.
Very well said, BryanFeeney.
Sure, static typing can be a bit annoying. But the gains in maintainability and readability and IDE/compiler assistance more than make up for the incovenience of static typing. Even in a dynamically typed language, you still have to know the types of the objects being used in the program if you want to get it to work how you expect.
Maintain 50k lines of Java source.
Maintain 50k lines of Python source.
Come back when you’ve realized that static typing offers you very little when you have unittests, which you should be writing anyways to verify that your code is correct.
You should write unit tests anyway, but with dynamically typed languages the tests have to be more elaborate to catch the stuff the compiler (of a statically typed language) would have caught automatically and immediately. Then when the test reveals a defect, you get bitten by hard-to-see bugs like typos in variable names.
That’s really dependent on the language and compiler. Typos in variable names can only cause a problem in languages that auto-vivify variables (like Python and Ruby). In the Lisp and Smalltalk families of dynamic languages, this cannot happen because you have to explicitly create variables via something like a LET binding. Moreover, good dynamic language compilers do type inferencing and can catch many type errors anyway. I write Lisp code in CMUCL, and I can’t remember the last time it missed a type error in non-polymorphic code. It will, of course, not catch errors like there being no specific method corresponding to a generic function call, but in a similar situation, Java would throw a dynamic type error anyway.
BryanFeeney, you’re failing to take into account type inferencing. One need not write out type names to get static type checking if the language and compiler are smart enough.
You mention Anders Hejlsberg and C#. C# 3.0 will support type inferencing. It becomes especially important when you would otherwise have code like:
SomeReallyObnoxiousClassName foo = new SomeReallyObnoxiousClassName();
That could become:
val foo = new SomeReallyObnoxiousClassName();
And a sample of what type inferencing can do:
Prelude> let a = 0.95
Prelude> let b = a + “hello”
<interactive>:1:12:
Couldn’t match `Double’ against `[Char]’
Expected type: Double
Inferred type: [Char]
In the second argument of `(+)’, namely `”hello”‘
In the definition of `b’: b = a + “hello”
With regard to your SomeReallyObnoxiousClassName example it has to be said, there isn’t all that much extra typing involved between the two examples when you take into account copy and paste, or even auto-complete.
Also your prelude example is a bit scary: I’m a fan of forcing as many errors as possible to happen at compile time, as opposed to testing for them at run-time (though unit-testing does help in this latter regard).
I’m still not convinced by type-inferencing, I’d worry about what happens when someone changes the signature of a method: e.g., lets say you have
class ArcaneClassIDidNotWrite
{
float getDialogDelta();
{
// work and then
return result;
}
}
class VeryMuchRemovedFromAbove
{
void doSomethingInfrequent()
{
val a = new ArcaneClassIDidNotWrite();
val b = a.GetDialogDelta();
val scale = 2 / b
this.property *= scale;
}
}
All is well and good. However lets say in the future that the signature of getDialogDelta() is changed from a float to an int. Because of type-coercion, this will cause neither a compile time nor a run-time error. However it will cause significantly unexpected results, as the scale will now be zero for every value of getDialogDelta() greater than two, which will occur occasionally.
Thus, without any warning, you get an occasional, infrequent, run-time error; the kind that’s really hard to track down.
Now of course, an expert would say I should have written 2.0 / a up there to prevent that happening, but that brings us back to my argument about simplexity. My opinion is that languages should avoid as much ambiguity and “magic” as possible, so as to make it as hard as possible for the average programmer to make mistakes. After all, any idiot can write a program that works some of the time, the hard work is in writing a program that works all of the time.
However, with all that said, I can live a lot easier with type-inference than I can with dynamic typing.
And you can just call me Bryan 😉
But would Scala do type inferencing in the VeryMuchRemovedFromAbove class? From what I’ve read so far, it seems it would only do local type inferencing. So the inference would be done for the variable ‘a’ in the example, since the knowledge of the type is available in the same class, but not for ‘b’ which is assigned from a function in another class.
In the ML family of languages, type inferencing does not allow for types to be unknown. If the compiler cannot infer a type, it will require you to insert a type declaration. In practice, you tend to have to insert declarations in the function prototype, and can leave them off in the code itself. I’m not sure what Scala would do in this case, but in Standard ML, the compiler would know the types of ‘a’ and ‘b’, either via inferencing or a declaration, and because there is no type coercion in SML, would signal a compile-type error.
It looks like to a decent first attempt for anybody coming from the functional camp. For somebody coming from the object camp, I’d say Dylan is a better attempt.
Stop it! Thom you don’t know shit about what makes a programming language interesting do you? Even if you did, this is OSNews not Programming Language news, I’ve got lots better sites for that. Concentrate on Operating Systems and keep the f–k away from programming languages, either there is no to little discussion or it turns into a f–king flame fest.
Well done sir!!
A truly well thought out and interesting reply. I particularly commend you on your use of grammar and knowledge of your chosen subject.
If you’re not interested in how software is created (Operating Systems included) then maybe you should go back to using an ‘etch-o-sketch’ instead.
I’m writing a comment not a novel; for that perfect grammar is neither necessary nor expressive enough. Now do tell me how a JavaVM based language is related to Operating Systems and keep in mind that >>the VM is a type of OS<< and >>the VM interfaces with the OS<< are not good enough reasons for including this or any other language >>news<< on this here OSNews site.
I take personal offence to low quality and irrelevance of most news items posted by Mister Thom Holwerda, who I feel has single handedly degraded the quality of OSNews.
Now that that is out of the way, this is to you Mister johnktayloer. UP YOURS!
Well it appears that you do have some knowledge of operating systems after all, although apparently quite limited as you don’t seem to consider that parts of Linux (and other operating systems for that matter) are held together by various computer languag….nah forget it…I will call it pixie dust instead to make it simpler for you….operating systems aren’t created by computer languages….they just appear on Christmas day like some magical wonderful thing…
If you don’t consider fundamental parts of an operating system to be relevant to an operating system then might I suggest other boards that might be of interest to you?
http://www.tkga.com/messageboard.html
or
http://www.crochetpatterncentral.com
oh and considering the last line of your message, yeap, right back at you.
Relevant programming languages for an OS:
Linux/Unix: ASM, C
Windows: ASM, C, C++
MacOSX: ASM, C, C++, Objective-C
What OS is programmed in Scala?
To act smart you need to be smart, but you fail.
I’d suggest you stop using the service OSNews provides or at least stop reading news items from Thom if you don’t like these. And I *urge* you to stop spreading irrelevant information in threads like this one. You don’t provide *any* value to a discussion about the topic at hand. Don’t annoy everyone with your nonsense.
I am very impressed with Scala. It seems that Scala combines the advantages of funtional and OO programming into a synthesis that looks very appealing and Done Right(TM). Congratulations to the team and keep going. Scala has the potential to be a real winner!
@johnktaylor
You forget about the type systems. While Scala is convenient to program (thanks to type inference) in it is completely type safe (something that cannot be said of any of the languages you listed). 😉
You got me
I quickly glanced over the Scala doc 
was having to much fun talking to the ijiot a couple of posts up 
it looks as if its got a bsd license so that pretty much means it wont turn into a dead language…or at least I hope it wont…its worth a look…that is when i get this damn windows box reinstalled 
I also find Scala’s mix of functionnal and object style interesting, the only thing I wonder is:
– from a performance point of view, is that strange mix a problem?
– is-it possible to have it compiled? I’m not a big fans of language with VMs, especially for client application which needs fast startup, high interactivity..
There may be a little performance impact, depending on the features you use, but so far Scala seems to be nearly as fast as Java.
To give an example I concentrate on functions as values. Consider a generic signal/slot example. In Java you use interfaces to implement callbacks, so you might try this (OSNews HTML parser doesn’t like angle brackets, so I substitute them with french quotes «», the code layout is messed up anyway):
class Signal«R, T»
{
interface Slot«R, T» {
R slot(T arg);
}
public void connect(Slot«R, T» obj) {
_slot = obj;
}
public R emit(T arg) {
return _slot.slot(arg);
}
private Slot«R, T» _slot;
}
class Sender
{
public Signal<Integer, Integer> signal = new Signal<Integer, Integer>();
public void send() {
for (int i = 0; i < 10000000; ++i)
signal.emit(i);
}
}
class Receiver implements Signal.Slot<Integer, Integer>
{
public Integer slot(Integer arg) {
return arg * 2;
}
}
public class Interfaces
{
public static void main(String[] args) {
Receiver recv = new Receiver();
Sender sender = new Sender();
sender.signal.connect(recv);
sender.send();
}
}
on my Pentium IV 2.4 GHz machine running Fedora Core 4 Linux with Suns JDK 1.5 the timings are (averaged from 10 runs):
real 0m1.159s
user 0m0.944s
sys 0m0.072s
Using Scala (and function values in particular) you may write something like this:
class Signal[T, R]
{
def connect(f: T => R) = this.f = f;
def emit(arg: T): R = f(arg);
private var f: T => R = _;
}
class Sender
{
val signal = new Signal[int, int];
def start = {
var i = 0;
while (i < 10000000) {
signal.emit(i);
i = i + 1;
}
}
}
class Receiver
{
def slot(arg: int): int = {
arg * 2;
}
}
object MainClass
{
def main(args: Array[String]) = {
val receiver = new Receiver;
val sender = new Sender;
sender.signal.connect(receiver.slot);
sender.start;
}
}
First note that the Receiver class doesn’t have to implement an interface which results in very loose coupling between Sender and Receiver which is very nice. The timings on the same machine are (again averaged from 10 runs):
real 0m1.255s
user 0m0.976s
sys 0m0.132s
which is only slightly slower than the Java version. I for myself don’t mind this small performance decrease for the increased expressiveness I gain in turn. Of course this is no real benchmark, but it should demonstrate that at least using this one particular feature doesn’t have a strong performance impact. I hope the situation is similar with other abstraction mechanisms of Scala too.
In this case, this looks natural that both have the same performances, I should clarify my sentence about performance: as far as I’ve seen from the documentation, the mixed functionnal object oriented style of Scala seems to create lots of object.
Whereas in ‘usual’ imperative styles you tend to reuse the same objects more often.
Anyway I was surprised that even though I tend to dislike functionnal language syntax (tried to learn Ocaml, but disliked it), I liked Scala’s syntax.
The only thing that makes me a little cautious is that it is labelled a ‘research language’, last time I used a ‘research language’ it was Pascal and this was such a complete failure..
Both Ruby and Python, barring C extensions of course, are completely type-safe.
The difference is not one of type safety versus lack thereof, but statically-determinable type safety vs lack thereof.
Both Ruby and Python, barring C extensions of course, are completely type-safe.
I’ve always thought “type safe” is a tricky term when comparing languages.
First, since the Python type system is weaker, saying that both Scala and Python are “type safe” doesn’t say much. Python is structurally typed and doesn’t have parametric types, which means that the type checking allows more (possibly unsafe) things to get by without errors (even at runtime).
Secondly, there’s a fundamental difference between static type safety (which I would just call “type safety”) and runtime checking. Runtime checking is more of a robustness/security feature, while a static type system is something you take into account when designing your program. From the programmers point of view, his valid Python program can still have type errors. A valid program written in a fully type-safe language cannot have type errors. If you could write a C interpreter that detected all error conditions and handled them “gracefully”, would that make C type safe?
Scala is one of the best languages I’ve seen in a while. It’s not really like Ruby or Python. If you aren’t a fan of static typing, Scala probably isn’t for you; powerful static typing is probably one of its primary goals. But if your only experience with static typing is in a language without type inference, you might want to give Scala a shot.
I’ve always thought “type safe” is a tricky term when comparing languages.
Not really. “Type safe” means that programs cannot violate the type system of the programming language. Nothing more, nothing less.
First, since the Python type system is weaker, saying that both Scala and Python are “type safe” doesn’t say much. Python is structurally typed and doesn’t have parametric types, which means that the type checking allows more (possibly unsafe) things to get by without errors (even at runtime).
Absolutely correct. However, that has nothing to do with type safety. The fact that Python’s type system is less expressive than most modern functional languages doesn’t change the fact that its every bit as safe. The lack of expressivity might mean that the programs are less safe, but the type system itself is no less safe. Indeed, it’s silly to argue about “degrees” of type-safety. Either a program can subvert the type system or it cannot.
Secondly, there’s a fundamental difference between static type safety (which I would just call “type safety”) and runtime checking. Runtime checking is more of a robustness/security feature, while a static type system is something you take into account when designing your program.
Yes, but no matter how you get to it, the program still cannot violate the type system. “Type safety” refers to the existinance of that protection. You’re talking about the nature in which that protection is provided. Surely a worthwhile point, but not one directly relevant to the definition of the term.
From the programmers point of view, his valid Python program can still have type errors. A valid program written in a fully type-safe language cannot have type errors. If you could write a C interpreter that detected all error conditions and handled them “gracefully”, would that make C type safe?
Such a language would be type-safe, but it would no longer be C. An implementation of C that does not allow type errors cannot be conformant to the C standard. You say a “valid” program written in a fully-type safe language cannot have type errors. That’s not the definition of “type safety” — that’s the definition of “static type safety”. Conflating the definitions make “type-safe” useless and redundant as a term.
But if your only experience with static typing is in a language without type inference, you might want to give Scala a shot.
LOL. I’ve fiddled around with Haskell and the like, and honestly, there is a reason I’m in the dynamic typing camp. I’m an engineer, not a mathematician, and I see no particular value in trying to express everything through the type system. That said, I’m sure lot’s of people find that very useful. I’m just trying to defend the integrity of “type safe” as a term that has a specific meaning.
I’ve fiddled around with Haskell and the like, and honestly, there is a reason I’m in the dynamic typing camp. I’m an engineer, not a mathematician, and I see no particular value in trying to express everything through the type system.
Yes, types can get very complicated, but only if you do complicated things. With dynamic typing you still have to mentally keep track of them, otherwise you’ll just end up with dynamic type errors and have no idea where they come from, or how to fix them without breaking something else.
Having to write the type down might help you get things clear in your own mind when you write the code, and it can certainly help yourself and others when trying to understand the code later.
Admittedly though, languages like Java and C require too many obvious and tedious type annotations. On the other hand I think full type inference like in Haskell is going too far, because it is often difficult to follow and produces confusing error messages in unexpected places.
Therefore local type inference, where function arguments and results have to be explicitly typed, while local variable types are inferred, seems like a very good compromise to me.
Yes, types can get very complicated, but only if you do complicated things. With dynamic typing you still have to mentally keep track of them, otherwise you’ll just end up with dynamic type errors and have no idea where they come from, or how to fix them without breaking something else.
That’s the thing. I’ve never found types to be particularly complicated. I have to mentally keep track of them, but I’d have to do that anyway because I generally need to know what I’m operating on in order to do anything with it. I suppose having the compiler double-check my work adds a layer of safety, but in practice, I cannot say I make enough type errors for the loss of flexibility to be worthwhile. This becomes especially true when using something like SBCL, which catches almost all of the type errors I do make. The rest are almost always the result of polymorphism, and I’m not willing to give up polymorphism to prevent the occasional runtime error.
That’s the thing. I’ve never found types to be particularly complicated. I have to mentally keep track of them, but I’d have to do that anyway because I generally need to know what I’m operating on in order to do anything with it. I suppose having the compiler double-check my work adds a layer of safety, but in practice, I cannot say I make enough type errors for the loss of flexibility to be worthwhile.
Fair enough. But that still leaves the documentation issue, unless you don’t need to revisit your code at a later time.
Also, dynamic type errors can appear far from where the actual mistake was made. If you call a function with the wrong type the actual error might be thrown somewhere in any function invoked by that function. But at least in that case the problem is somewhere on the current call stack. Things get even more difficult if the offending value is just stored in some data structure, causing an error at some later point.
And of course dynamic type checks have a significant run-time cost, so any check that can be eliminated at compile time or even startup time is a good thing.
This becomes especially true when using something like SBCL, which catches almost all of the type errors I do make.
So I guess we’re talking more about explicit vs implicit rather than static vs dynamic typing?
The rest are almost always the result of polymorphism, and I’m not willing to give up polymorphism to prevent the occasional runtime error.
You don’t need to, that’s why parametric types are finally making it into mainstream languages.
Simple type parameters suffice for most cases of polymorphism, particularly for handling lists or other
containers. More complicated cases can be expressed
with type bounds.
Sure, there’ll always be examples that can’t be expressed in a static type system, but with bounded parametric types they won’t crop up terribly often, and they can of course be handled through explicit run-time checks (aka downcasts).
Reminds me a bit of http://www.nemerle.org. It’s a also a hybrid OO-functional language but it only runs on .Net or mono.
This is good ol phb marketing buzz.
Wake the f–k up people. It is just another language meant to sell more shitty slow applications to morons.
…but do we NEED another? I mean, Ada offers many or most of what this language offers and compiles down to machine code, not a VM program.
I really do like how it looks tho’.
Well you’ve said it more or less yourself: you prefer the way Scala ‘look’ to Ada verbose syntax which I think many people dislike..
I doubt that the new Ada standard in preparation will include local type inference, too bad: verbosity while in theory good for robustness hurts readability..
IT is pretty much a fashion industry and I don’t expect Ada to become fashionable any time soon, granted there is now an open-source compiler but compared to Java’s big standard library, this is not enough..
“It looks like to a decent first attempt for anybody coming from the functional camp. For somebody coming from the object camp, I’d say Dylan is a better attempt.”
Could you elaborate on this?
Dylan is a multi-paradigm programming language based on Lisp. It is first and foremost an object language, and secondarily a functional language. It has very powerful object-oriented constructs, like generic methods, multimethod dispatch, dynamic typing, etc, but much more run of the mill functional constructs (full lambdas, but limited currying and no parametric polymorphism). In comparison, Scala seems to have several of the modern functional-programming features, but has a pretty primitive Java-like OOP model.
Depending on your point of view, one language or the other seems like a much better blending of OOP and FP. Personally, I couldn’t live without generic methods, but I can live without pattern matching. I’d imagine an Haskell programmer would see things quite differently.
more curly braces and arrow syntax. What ever would we do without another one of those?
Oh yeah, I forgot to mention semicolons. Oh no, I forgot my semicolons! Compilation failed! AHH!