Slashdot Mirror
Scala, a Statically Typed, Functional, O-O Language
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..."
Different tools for different jobs.
That being said, does anyone know of a good comparison of languages broken down by what they're best at doing? How does one decide what the best language for what they want to do is? My google-fu is weak today. I found this: popular programming languages; but the analysis seems lacking.
To be fair, FailWhale has not been seen by me of late, and the Twitter devs attribute their salvation to Scala. However, there are some pretty good arguments that the Twitter developers Mother of All Fail was initially trying to write their own hand-rolled message queue instead of simply using one off-the-shelf.
Don't blame me, I voted for Baltar.
But if all you're doing is reinventing Perl with C-like syntax, it's not really a step forward.
Perl already has C-like syntax. It doesn't, however, have static type checking, let alone robust static type checking (with nice features like variance annotation etc.); nor does it have particularly robust functional programming support -- you can certainly do functional programming in Perl, but it isn't as clean and syntactically sugared as it could be; nor does perl have particularly clean OO if we're being honest -- yes it works and can be made to work quite well, but elegant isn't a word that comes to mind when I think Perl and OO; nor does Perl have function pattern matching and algebraic data types; nor does Perl have a nice concurrent programming interface based on the Actor model. None of this is really to say that Perl is bad -- it is very good for a great many things, and the features I've mentioned needn't hold it back. My point is that Scala is most certainly not re-inventing Perl. In fact Scala doesn't even have a particularly C-like syntax: it's less C-like than Perl really.
Craft Beer Programming T-shirts
FTA: actors in Scala are not a language feature, they have been done purely as a Scala library
So:
1. There will be no useful compiler warnings/errors for the feature, since compilers implement only the core languuage.
2. Even if the library code will be 100% bug free, you'll still have to drag a debugger though it when debugging a hard bug in nearby code.
3. The library's API will never acheive the self-consistency of the core language because of too many cooks spoiling the broth.
4. The library will be massively overfeatured, but still not do what you actually want.
5. The library will change more frequently than core langage, meaning nothing will compile in the real world without hacks.
6. The library designer will hypnotise the core language designer and impose his own stupid ideas on the core language.
7. (6.) will lead to the entropy death of the language; people will simply stop paying attention to new versions.
Seriously, we should be figuring out a minimal subset of concurrancy features that really *can* go into a core language, with compiler support, debugger support, good consistency (like the while loop which does the same thing in all languages) etc.
Then libraries can implement endless semantic sugar/bullet-point fluff on top of the core features, since that's what libraries are good at.
A very high volume of triviality is non-trivial.
I could use an alternative programming language for the JVM that is more expressive than Java. Both Scala and Groovy integrate well with Java at the language level, albeit with different type systems. While I do use Groovy from time to time, what kept me from Scala was that it is not well supported by IDEs (Eclipse/Netbeans - I hear things are somewhat better with IntelliJ). The problem is the nature of Java libraries. They tend to be deeply nested and often expressed in lower level abstractions and are difficult to use without strong IDE support. I don't need an IDE for Python (flat module systems, high level libraries), but certainly do for Java. With solid IDE support however, I am nearly as productive in Eclipse + Java as with dynamic languages, even for medium apps. Scala and Groovy come with their own standard libraries and I don't need IDE support as long as I stay within them. But sooner or later, I will need to step into plain Java land and I no longer feel productive. I would rather use straight Java for them.
The development experience is language + tools, not just the language. While Scala can piggy back on JVM and undercut the rest of the process that languages need to go through to mature and be accepted, Scala plugin (or someone else) has to provide a JDT equivalent first to have popular appeal.
I just wish there was a well supported superset of Java with productivity considerations that maintains 1:1 byte-code compatibility on compilation. Java purists can keep their language clean. But the rest of us can be happy too. Scala has that potential.... almost. So far, Groovy has been filling that role for me. Groovy will never have the kind of edit-time IDE intelligence simply due to it's dynamic nature. But for now, it stands ahead (after all, it has been around longer).
What does that even mean?
It means you're not qualified to even enter this discussion. Go take a course on programming languages and then get back to us.
Next biggest thing for the "guys with a job" crowd.
Learn some other language that isn't C#, Java, C++, VB.NET, or in fact particularly related.
Specifically, learn something with functional programming, or a different sort of object orientation (Common Lisp comes to mind, or Smalltalk or Objective-C), or declarative programming (like Prolog)...anything that's considerably different from any of the standard compiled OO languages.
Learn and improve, or don't learn and become unable to earn a living in the field.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Most languages are strongly typed so that's not a particularly useful metric.
Hardly. The One True Language for client-side web development, aka Javascript, is weakly typed, as is PHP, that ubiquitous server-side programming language. Perl is weakly typed. Good ol' shell script is weakly typed. Heck, even C is considered weakly typed (unless you enable -Werror, of course).
I was completely pleasant with the woman, we joked about the questions in fact. The simple fact was they had a stupid call screen process straight out the egotistical dot.com days, which showed much about the types of "engineers" they like to bring in.
Thanks for assuming that I was an ass thought. :)
--- I do not moderate.
they must have some of the old Amazon.com folks there. Amazon was like that. Same type of questions, same type of mistakes in what and how they asked the question except they did it in person. I had the same reaction as you did, told them they were wrong in the specification which led to their answer being an incorrect solution. They got pissed and ended the interview. I caught an early flight back :) Plus people were on call 24x7 and worked hellacious hours for low pay and lots of worthless stock options.
And when the going got tough, as I recall, Twitter fell over, as did most of the other darlings of the current social networking hypewave.
It's kind of amusing that people have started to think of simple web front ends to simple CRUD applications as if they're demanding. Indexing the entire WWW is demanding. Running the financial systems behind a bank is demanding. Modelling weather systems is demanding. The CAD models for a 60' yacht are demanding.
Running a web site that provides a trivial front-end to a database with one three-column table is not demanding, even if you're getting lots of hits. And it still fell over.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
>> , the rest of us either (a) remember the types of our variables
1) Strong typing helps compilers and processors, not programmers. A weak programmer wouldn't understand the value of a strongly typed language.
2) Any developer who says he 'remembers the types of our variables' is either lying, or inexperienced. You may remember it today, a week from today, or perhaps even a month. You will not in a year. Nobody who looks at your code will 'instantly know' unless you name your variables 'thisIsAnUnsignedInt32', which, would be pretty silly.
3) SE Asia and India produce many fine programmers (FYI, I'm a caucasian american, so no favoritism.). because of the lower prices of programmers from India and SE Asia you're statistically likely to see _more_ of them, hence more bad programmers.
Strong typing helps _only_ weak programmers, the rest of us either (a) remember the types of our variables or (b) expect "1" + "2" -> 3, not "12".
As a programmer with 25 years of experience, I could hardly disagree more. When developing any large project, static typing is hugely beneficial. It lets you catch far, far more errors at compile time. In a dynamic language, those would all be runtime errors that could easily slip through your testing and make it out to a customer. It makes automated refactoring possible. (Ever try doing a major restructuring of a 500k line code base written in a dynamic language? Good luck!) It enables all sorts of static analyses that let you be a more productive programmer. Try using a really good Java IDE like Intellij IDEA, then try the best Python or Ruby editor available, and you'll feel like you've gone back to the stone age. No "Find Usages"? No autocompletion? No "Go to Definition"? You simply can't do these things in a dynamic language, because the editor has no idea what the type of any variable is.
This isn't meant to criticize dynamic languages. They definitely have their place. But 90% of the symbols in most programs should be statically typed. I don't see why more languages don't simply offer both options. In those that do (e.g. Groovy), type declarations are simply optional. If you declare a type, it gets checked at compile time. If you don't, that symbol becomes dynamically typed. It works very well.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
That "why i hate" is a terrible editorial. What he is saying is that he doesn't want to think carefully about what he's doing. His objection isn't to languages really it is to clarity of thought. Tinkering and right brain is great for art, it isn't the right mode for engineering.
LISP, Perl and OCaml are far more useful than C++, Java and C#
Let's see:
I'm not sure what point you're trying to make, but it doesn't seem to have anything to do with either strong typing or static typing.
The academic idiots,
That's as opposed to the non-academic idiots, who apparently don't even know what "strong typing" means.
So who do you think will be writing the "components" for your magic system, and the infrastructure to make the system executable, designable, testable and usable? We have been progressing to increasingly high level code (and in some cases, as you say, component architectures), but the amount of code being written and maintained continues to grow, not shrink.
So the amount of code is growing, and it does more per unit mass, and software engineering skills are increasingly valuable and applicable, and you think this is a trend towards the elimination of code and software engineers? You may want to check your water and food sources for contamination.
Sam ty sig.
I'm not too worried. The idea behind COBOL was that once you got rid of that mathy way of writing code anyone could do it. The fact is that taking a process and breaking it into a series of steps and dealing with all the cases takes practice. The problem is not syntax or language structure the problem is thinking through a problem that way.
Until computers have common sense all languages are going have to look like
Do X ...
Read Y
Y Case 1
Y Case 2...
Y Case 3....
Not much for professionalism, are you? I can say with about 99% certainty that the fact that you know Haskell will have absolutely no effect on your career. The fact that you learned it will have a large effect on how well you can turn problems into programs.
The only stable asset you have is you. If you don't improve yourself, you'll get left behind, and in ten years you'll be working on legacy C# systems and not getting paid as much as the people working on the interesting stuff in whatever language is new and hot next decade.
I've watched small computer development be dominated by BASIC, Pascal, C, C++, Java, and C# (with a lot of Visual Basic thrown in). I have absolutely no reason to suspect it all stops here. Learn or die.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
At first, I thought you were asking questions about something you didn't understand. Then, it became you giving advice on something you didn't understand. But now, I think I understand. It was penis envy all along.
That is a matter of the way how the mind of a particular developer works.
I have troubel with dynamic typing, and I hate it to get me my errors shown by runtime when a compiler could have detected that error. Some people don't have this trouble, so they don't need static type checking. Other people develop even the simples script in a test driven development approach and don't need static types either.
However: even simple typos like foo.baar() // should be one a only ...
get compiled by dynamic languages and lead to an runtime error: method baar() not found! I make such typos in the hundrets a day, if I was forced to use languages like python I would hang myself.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.