Why Java Developers Should Check Out Scala(techrepublic.com)
techrepublic.com
Why Java Developers Should Check Out Scala
http://www.techrepublic.com/blog/programming-and-development/why-java-developers-should-check-out-scala/5753
13 comments
"dynamic and functional"
I don't understand what you've said here. The two terms are entirely orthogonal. There are functional langauges which are dynamically "typed", and there are functional languages which are statically typed. Lumping the two terms together is misleading and useless.
Static typing (done correctly) is just straight up better than dynamic typing. End sentence. I cannot count the number of times I have had errors at runtime working in python that simply would not have existed at all if I was using a statically typed language. With a sufficiently expressive type system, the types do not get in the way, but you still get compile-time enforced correct static semantics.
I don't understand what you've said here. The two terms are entirely orthogonal. There are functional langauges which are dynamically "typed", and there are functional languages which are statically typed. Lumping the two terms together is misleading and useless.
Static typing (done correctly) is just straight up better than dynamic typing. End sentence. I cannot count the number of times I have had errors at runtime working in python that simply would not have existed at all if I was using a statically typed language. With a sufficiently expressive type system, the types do not get in the way, but you still get compile-time enforced correct static semantics.
I agree. Static typing is great. I don't know why all these scripting languages choose to throw out static typing. If a variable is always going to be an integer I don't know why its important to be able to stick characters, strings or objects into it without seeing any errors. It's good for a beginning programmer perhaps, but even with that I tend to disagree since it encourages bad practices.
At some point I just got tired of seeing the same types of errors and wanted my tools to work a lot better. Python / PHP / Ruby aren't improved by lacking static types. How hard would it be to add static types into PHP, Ruby, or Python?
http://stackoverflow.com/questions/1365333/will-php-become-a...
At some point I just got tired of seeing the same types of errors and wanted my tools to work a lot better. Python / PHP / Ruby aren't improved by lacking static types. How hard would it be to add static types into PHP, Ruby, or Python?
http://stackoverflow.com/questions/1365333/will-php-become-a...
I'm a big static typing fan, but the facts are out there, startups use Rails and Django, and front end is JavaScript, all are dynamically typed, yet very popular.
A good static typed language that the only difference between it and Ruby / Python is the type system, has a good chance in being accepted by a larger audience of developers, both enterprise and startups.
People prefer dynamic as they don't like to compile, and it provides rapid code / refresh cycles, I don't think anyone would say no to less bugs and better refactoring, and to self explanatory APIs using content assist.
A good static typed language that the only difference between it and Ruby / Python is the type system, has a good chance in being accepted by a larger audience of developers, both enterprise and startups.
People prefer dynamic as they don't like to compile, and it provides rapid code / refresh cycles, I don't think anyone would say no to less bugs and better refactoring, and to self explanatory APIs using content assist.
I meant to say "more inclined toward dynamic over static, functional over object oriented." didn't mean to tie functional and dynamic together, thanks for the clarification.
Scala is a great statically typed functional, object oriented language, which allows most people to enjoy both worlds.
Scala is a great statically typed functional, object oriented language, which allows most people to enjoy both worlds.
By the way, I agree with all you said, I hope it's evident I'm a big static typing fan.
what languages, if any, do you think get static typing right?
Haskell and SML both have sufficiently expressive type systems that I do not ever find myself writing correct code that fails to typecheck. If the code fails to typecheck, I have done something wrong.
(If the code does typecheck, then I have guaranteed a lot of static properties of my code, but it may still be incorrect in terms of dynamic semantics.)
(If the code does typecheck, then I have guaranteed a lot of static properties of my code, but it may still be incorrect in terms of dynamic semantics.)
This is probably sounds insulting, but I just wanted to give you a warning.
I spent some time deciding if your first sentence was a parody (Look at us new vim mac users with functional languages and git and startups).
Very sorry that I am a C++ programmer, working in visual studio, as opposed to writing the latest to-do app in scala using vim.
I spent some time deciding if your first sentence was a parody (Look at us new vim mac users with functional languages and git and startups).
Very sorry that I am a C++ programmer, working in visual studio, as opposed to writing the latest to-do app in scala using vim.
I'm using eclipse, and I can't leave my IDE, but I admire people who managed to free themselves from being dependent on an IDE, autocomplete / content assist. I tried VIM / Emacs / TextMate, didn't work for me, but perhaps I'm too old for new tricks, and already hooked to eclipse's shortcuts (ctrl+1 has no equivalent, I hardly need to write code, it's 50% shortcuts) I did like SublimeText 2, and use it for sass / scss / CoffeeScript and node development.
No parody was intended, I have all respect to all developers where ever they are and what ever IDE / non-IDE they chose to work with.
No parody was intended, I have all respect to all developers where ever they are and what ever IDE / non-IDE they chose to work with.
Half the people pushing Scala tout Scala's tooling ecosystem.
I use IntelliJ IDEA with the Scala plugin and you get code-complete and type aware tooling.
In fact every developer I know that writes production Scala code uses an IDE.
I have fuckall of a clue what an IDE has to do with Scala except for some sort of lifestyle statement.
I use IntelliJ IDEA with the Scala plugin and you get code-complete and type aware tooling.
In fact every developer I know that writes production Scala code uses an IDE.
I have fuckall of a clue what an IDE has to do with Scala except for some sort of lifestyle statement.
> Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land.
rpearl already made a similar objection, but I think you're confusing things a bit here. How much of Scala is influenced by Ruby and Python? Aren't the main goodies in Scala related to the type system?
Programmers using those "mainstream" dynamically typed languages don't have terribly much to be smug about, sure they're less verbose than Java, but I'd suggest they should also invest in learning a functional language or two, like Scala.
rpearl already made a similar objection, but I think you're confusing things a bit here. How much of Scala is influenced by Ruby and Python? Aren't the main goodies in Scala related to the type system?
Programmers using those "mainstream" dynamically typed languages don't have terribly much to be smug about, sure they're less verbose than Java, but I'd suggest they should also invest in learning a functional language or two, like Scala.
It's kind of interesting to see that the myth that functional and object-oriented programming are somehow mutually antagonistic is so readily accepted that it can even be perpetuated in an ode to an object-oriented functional language such as Scala.
"Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land. which is great news for everyone."
Groovy does the same thing with less friction and switching overhead.
Groovy does the same thing with less friction and switching overhead.
Nanana... I know both, and Scala and Groovy are complety different tools
Groovy is great to Websites and fast development they remove the code complexity and verbosity of java using type inference, some functional goodies like closures and add DSL capabilities,I use it everyday and it's a very nice tool.
Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example) and is way closer to the functional paradigm than Groovy, but it's more complex.
So you gotta choose wisely so you don't end up with the hammer to a screw kind of problem.
My view:
Groovy is for fast development and WEB stuff mainly because of Grails which is an awesome tool as well.
Scala is more a backend tool when you need Horse Power, but that's because the lang is more complex, I don't like Play and Lift is not as easy to understand as Grails.
Again no Flamewars please.
Groovy is great to Websites and fast development they remove the code complexity and verbosity of java using type inference, some functional goodies like closures and add DSL capabilities,I use it everyday and it's a very nice tool.
Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example) and is way closer to the functional paradigm than Groovy, but it's more complex.
So you gotta choose wisely so you don't end up with the hammer to a screw kind of problem.
My view:
Groovy is for fast development and WEB stuff mainly because of Grails which is an awesome tool as well.
Scala is more a backend tool when you need Horse Power, but that's because the lang is more complex, I don't like Play and Lift is not as easy to understand as Grails.
Again no Flamewars please.
Wasn't trying to start a flamewar. Yes, they're completely different tools. Per the original quote though
"it (scala) allows enterprise developers to taste some of the goodies of Ruby / Python"
Groovy fits that bill far better than Scala if you're primarily looking for a taste, without having to adopt the complexity of a new worldview.
"it (scala) allows enterprise developers to taste some of the goodies of Ruby / Python"
Groovy fits that bill far better than Scala if you're primarily looking for a taste, without having to adopt the complexity of a new worldview.
I am sorry I said no flamewars because of what I was saying, to point that I didn't want to start one.
Your answer was not the flamewars kind at all.
And yes Groovy fits perfectly in that statement.
Your answer was not the flamewars kind at all.
And yes Groovy fits perfectly in that statement.
> Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example)
I believe Groovy also supports actor concurrency via gPars. That said, I still haven't seen anything like Akka on any other language, specifically its distributed processing p2p feature. To me Akka is Scala's 'killer app'. I agree I don't like the new Play framework. I didn't mind the magic being taken away but with taking the magic out, they also killed any form of convenience without providing a replacement.
I believe Groovy also supports actor concurrency via gPars. That said, I still haven't seen anything like Akka on any other language, specifically its distributed processing p2p feature. To me Akka is Scala's 'killer app'. I agree I don't like the new Play framework. I didn't mind the magic being taken away but with taking the magic out, they also killed any form of convenience without providing a replacement.
" I stil haven't seen anything like Akka on any other language".
You can use Akka from java but the messages are effectively dynamically typed which isn't a big deal. However, as Rich Hickey said, a queue is simpler than an actor (Go understands this also). Java has excellent blocking queue implementations. In fact java has libs that support all kinds of concurrent solutions and they are not that complex.
I still like Scala though (and really like Go but my work is on the jvm)
You can use Akka from java but the messages are effectively dynamically typed which isn't a big deal. However, as Rich Hickey said, a queue is simpler than an actor (Go understands this also). Java has excellent blocking queue implementations. In fact java has libs that support all kinds of concurrent solutions and they are not that complex.
I still like Scala though (and really like Go but my work is on the jvm)
> You can use Akka from java
True, but I just got sick of Java being a 2nd class citizen on Akka.
> In fact java has libs that support all kinds of concurrent solutions and they are not that complex.
hmmm does java have a distributed concurrent solution that isn't complex? Aside from Akka, I am not aware of any.
True, but I just got sick of Java being a 2nd class citizen on Akka.
> In fact java has libs that support all kinds of concurrent solutions and they are not that complex.
hmmm does java have a distributed concurrent solution that isn't complex? Aside from Akka, I am not aware of any.
I like Groovy, but I think even the author said once that if he knew about scala, he might have not invented Groovy (if anyone knows the link to the quote, and if it's indeed true, please comment)
It was James Strachan who said that. He is credited with the initial idea and set the project in motion in 2004. He stopped commiting in 2005 and Groovy 1.0 was released in 2007.
He made the scala statement in 2009. He's certainly entitled to his opinion. But I find the title "Author" or "Creator" a little harsh to people like Guillaume Laforge and others who have really brought the project from beta to 2.0 in the 7 years since he quit.
He made the scala statement in 2009. He's certainly entitled to his opinion. But I find the title "Author" or "Creator" a little harsh to people like Guillaume Laforge and others who have really brought the project from beta to 2.0 in the 7 years since he quit.
James Strachan set the Groovy project in motion in mid-2003, not 2004. He stopped posting to the mailing list in December 2005. James credits Bob McWhirter as being his co-creator.
Jochen Theodorou led the technical effort on Groovy since then. Other major committers over the last 5 years include Paul King, Alex Tkachman, Cedric Champeau, and Jeremy Rayner. I don't know for sure about before that. Guillaume Laforge's main technical effort was writing some utility functions very early on.
Although Guillaume has the title "Project Manager", he's really No.2 to the real management force behind Groovy, i.e. Graeme Rocher, who leads the Grails development. If Grails switched languages, Groovy would disappear almost overnight as it's not used much in anything else significant. OReilly's total worldwide book sales of Groovy (all titles) over 12 months is 1205 books (http://radar.oreilly.com/2012/04/computer-book-market-2011-p...).
> really brought the project from beta to 2.0 in the 7 years since
A few weeks before Groovy 2.0's "final release" in June this year, Grales 2.1, Griffon 1.0 and Gradle 1.0 were all released, bundling Groovy 1.8. Listen to what Groovy's users are doing, not what its fanboys are saying. Groovy 2.0 is nothing more than beta-quality software offered to production users so they'll "unit test" it in their workplaces. No-one should be using Groovy 2.x until Grails bundles it.
Jochen Theodorou led the technical effort on Groovy since then. Other major committers over the last 5 years include Paul King, Alex Tkachman, Cedric Champeau, and Jeremy Rayner. I don't know for sure about before that. Guillaume Laforge's main technical effort was writing some utility functions very early on.
Although Guillaume has the title "Project Manager", he's really No.2 to the real management force behind Groovy, i.e. Graeme Rocher, who leads the Grails development. If Grails switched languages, Groovy would disappear almost overnight as it's not used much in anything else significant. OReilly's total worldwide book sales of Groovy (all titles) over 12 months is 1205 books (http://radar.oreilly.com/2012/04/computer-book-market-2011-p...).
> really brought the project from beta to 2.0 in the 7 years since
A few weeks before Groovy 2.0's "final release" in June this year, Grales 2.1, Griffon 1.0 and Gradle 1.0 were all released, bundling Groovy 1.8. Listen to what Groovy's users are doing, not what its fanboys are saying. Groovy 2.0 is nothing more than beta-quality software offered to production users so they'll "unit test" it in their workplaces. No-one should be using Groovy 2.x until Grails bundles it.
"Groovy 2.0 is nothing more than beta-quality software offered to production users"
Unlike, of course, every other piece of software's x.0 release, which are always 110% battle hardened and tested through years of rigorous process, ensuring no downtime, data loss or corruption, and smooth sailing. Yea, groovy's totally unique in that. I bet they just made some random commits during the final 2.0 bundling without even looking at the keyboard while they typed as well.
Groovy book sales were down. So what? Maybe groovymag has had an adverse impact on oreilly? :)
Unlike, of course, every other piece of software's x.0 release, which are always 110% battle hardened and tested through years of rigorous process, ensuring no downtime, data loss or corruption, and smooth sailing. Yea, groovy's totally unique in that. I bet they just made some random commits during the final 2.0 bundling without even looking at the keyboard while they typed as well.
Groovy book sales were down. So what? Maybe groovymag has had an adverse impact on oreilly? :)
When Groovy's two biggest users (i.e. Grails and Gradle) each release a major point version (Grails 2.1 and Gradle 1.0) less than a month before Groovy 2.0's release, that says more about what their project managers think about Groovy 2.0's production-readiness than anything they or anyone else might say.
Groovy 2.0 bundles two jars, one for Groovy scripts using Java 7's invoke-dynamic, the other for scripts using type-checking and static compilation available via optional annotations. Invoke-dynamic and type-checking/compilation _can't_ be used together: you need to choose only one jar to use. The roadmap plan is for them to be merged together in Groovy 2.1. Groovy 2.0 should never have been released until it was a single functioning jar.
Groovy 2.0 bundles two jars, one for Groovy scripts using Java 7's invoke-dynamic, the other for scripts using type-checking and static compilation available via optional annotations. Invoke-dynamic and type-checking/compilation _can't_ be used together: you need to choose only one jar to use. The roadmap plan is for them to be merged together in Groovy 2.1. Groovy 2.0 should never have been released until it was a single functioning jar.
I don't see the lack of faith thing as much as you. I see it as the features those projects have been working on don't rely on any Groovy 2.0 functionality, so they'll push it out sooner and give people more functionality in those projects now, and explore the impact on Groovy2 on their respective projects after it's release and shakes out.
> Groovy does the same thing with less friction and switching overhead.
Are you the same M.Kimsal who sells subscriptions to "groovymag" ?
Are you the same M.Kimsal who sells subscriptions to "groovymag" ?
Yes I am. To the extent I have a vested interest in Groovy, it may or may not be relevant to my original post. My larger point was, as I said before, if the purpose is to offer a 'taste' of dynamic functionality, a la ruby/python, to Java developers, Groovy is a much simpler way to go about it. Should people then get a real hankering for it, you've got more options, either with more groovy, or jruby or jython or scala or what have you. Nothing more.
Umm, so you're saying vi is "new wave"?
No, but having young fresh out of college developers prefer it over eclipse/VS, is new (to me), but I have a very narrow point of view of only the people I know from college / work / online.
I don't understand why the RoR community needs to endorse Scala as sucking less than Java?
Here is one of the first empirical Scala vs Java studies:
http://www.neverworkintheory.org/?p=375
Here is the actual paper: http://www.rz.uni-karlsruhe.de/~kb95/papers/pankratius-Scala...
Quote from the conclusion: With respect to effort, this study refutes the claim that Scala programs are faster to develop: in comparison to Java, Scala requires more effort, and especially more testing and debugging effort.
Here is the actual paper: http://www.rz.uni-karlsruhe.de/~kb95/papers/pankratius-Scala...
Quote from the conclusion: With respect to effort, this study refutes the claim that Scala programs are faster to develop: in comparison to Java, Scala requires more effort, and especially more testing and debugging effort.
This was a study that used Master's students who had been developing Java for 4 years and Scala for 4 weeks. It's pretty weak methodologically.
My anecdotal evidence agrees with the study. Type inference is also the reason the Scala compiler is so much slower than the Java compiler.
Scala has been on the market (i.e. promoted to a broader audience) since 2005 or so. There is plenty of evidence now that Scala is more complex than Java and less suitable for enterprise applications. Despite the fanboy-ism here and on reddit: the Scala hype is over. Definitly.
Having used Scala some myself, I wouldn't be surprised that if we look back in ten years, we have come to the conclusion that Scala is the C++ of modern times. It tries to support relatively opposing paradigms (functional programming - object oriented/imperative programming), has a very extensive type system, and drags in a lot of historical baggage via Java.
I guess everyone has encountered the C++ is 'C with better strings and arrays'-type of programmer who doesn't use RAII or the STL. Or the template-fanatic programmer that wants to drag in template meta-programming into every corner of the project. Or the STL fanatic that wants to replace every for-loop by a function in std::algorithm, even if there is no appropriate fit or it requires building a bunch of stateful function objects (thank god we have closures now). Etc.
If projects do not impose serious restrictions, such a broad language will quickly become an incomprehensible mess.
Being a recovering C++ fanatic myself, I believe more in smaller languages try to solve a particular problem now. For instance, take Prolog, it's a beautiful language for what it is aimed at: logic programming. All the weird object-oriented Prolog experiments have died out by now, and it's a language that you use when you want to solve a particular kind of problem.
I guess everyone has encountered the C++ is 'C with better strings and arrays'-type of programmer who doesn't use RAII or the STL. Or the template-fanatic programmer that wants to drag in template meta-programming into every corner of the project. Or the STL fanatic that wants to replace every for-loop by a function in std::algorithm, even if there is no appropriate fit or it requires building a bunch of stateful function objects (thank god we have closures now). Etc.
If projects do not impose serious restrictions, such a broad language will quickly become an incomprehensible mess.
Being a recovering C++ fanatic myself, I believe more in smaller languages try to solve a particular problem now. For instance, take Prolog, it's a beautiful language for what it is aimed at: logic programming. All the weird object-oriented Prolog experiments have died out by now, and it's a language that you use when you want to solve a particular kind of problem.
Yes. Scala is C++ of the JVM.
Local type inference is not necessarily expensive. Type inference is abundantly used in Go, and yet it's probably one of the fastest compilers.
There are also languages that do Hindley–Milner type inference (ML, Haskell) with good compile times.
There are also languages that do Hindley–Milner type inference (ML, Haskell) with good compile times.
I am sure that you can have much cheaper type inference. However, if you turn on the compiler profiler for Scala, you can see that most of the time is spent in type inference. They don't do HM.
A couple of peculiarities in the study that place Java at a disadvantage:
1. Examples using outdated low level concurrency primitives such as wait and notify. Use of java.util.concurrent would have made the code much more terse and safe
2. Java performance affected by use of the outdated java.util.Stack class. It is well known that this class uses redundant synchronization. The docs recommend using a Deque implementation instead.
1. Examples using outdated low level concurrency primitives such as wait and notify. Use of java.util.concurrent would have made the code much more terse and safe
2. Java performance affected by use of the outdated java.util.Stack class. It is well known that this class uses redundant synchronization. The docs recommend using a Deque implementation instead.
Scala hits such a sweet spot (at least for me). It's a pleasure to use, the language is so flexible, and you can write very nice, succinct and easy-to-reason-about code. The support for higher-order functions and closures, etc is really nice. I've been doing some android development in Scala and it has a huge impact on productivity.
Java's pretty tedious for certain tasks, but it does lend itself well to large teams coding on a large code base and being able to understand everything quickly. Yes, Eclipse is much more heavyweight than vim, and Java's a whole lot more heavyweight than Ruby, but I'd rather peruse through 10M lines of Java code in Eclipse than 1M lines of Ruby code in vim any day.
Even so, I run into the infuriating aspects of Java from time to time, and that's when Scala comes in. I see it to Java as Coffeescript is to Javascript.
Even so, I run into the infuriating aspects of Java from time to time, and that's when Scala comes in. I see it to Java as Coffeescript is to Javascript.
But 10M line of Java gets a lot less work done than 1M line of Ruby.
Bad idea.
Better: Why Language Developers Should Stop Making Languages on Top of the JVM.
Imagine if Ruby or Python were only available on top of the JVM... There may be a need for versions of a language that live in the JVM, but don't make the entire ecosystem dependent on it.
Better: Why Language Developers Should Stop Making Languages on Top of the JVM.
Imagine if Ruby or Python were only available on top of the JVM... There may be a need for versions of a language that live in the JVM, but don't make the entire ecosystem dependent on it.
In fact it's not... Java JVM is a great piece of software it's extremely reliable and fast, the language is what sucks a bit ( I am a Java Dev btw ),If I remember right Ruby IN THE PAST had some problems with concurrency, and that is were JRuby came from (correct me, if I am wrong... No flame wars please.), so reinventing the well takes time and sometimes goes wrong for a while.
Some wikipedia: "JRuby supports interpreted mode, AOT mode, and JIT mode (the last two modes are available since version 1.1[19]). JRuby evolved from being several times slower than Ruby Reference implementation[32], to being several times faster.[33] [34]."
I learned a bit of Scala and I think it's a awesome lang, if you have time to learn it properly otherwise it might to pull your blanket, because it's a little trick at some things.
I would definetly like to work with it, in fact I plan use it in my next side project together with Backbone.js
Some wikipedia: "JRuby supports interpreted mode, AOT mode, and JIT mode (the last two modes are available since version 1.1[19]). JRuby evolved from being several times slower than Ruby Reference implementation[32], to being several times faster.[33] [34]."
I learned a bit of Scala and I think it's a awesome lang, if you have time to learn it properly otherwise it might to pull your blanket, because it's a little trick at some things.
I would definetly like to work with it, in fact I plan use it in my next side project together with Backbone.js
You didn't explain what's wrong with the JVM. Please do.
The JVM is very fast and ubiquitous. Targeting the JVM allows the language developers to focus on the language rather than re-inventing a runtime (which is a monster project)
The JVM is very fast and ubiquitous. Targeting the JVM allows the language developers to focus on the language rather than re-inventing a runtime (which is a monster project)
A big advantage to targeting one of the two big managed environments is that they come with batteries included. Unlike the Ruby and Python teams, Scala's developers didn't have to spend time on developing their own JIT compiler, or their own standard libraries, or their own memory manager, or any of that.
Which is part of why it's so mature despite being so young. Open-source languages that don't target a managed environment have historically needed a lot longer to marinate than Scala did.
Which is part of why it's so mature despite being so young. Open-source languages that don't target a managed environment have historically needed a lot longer to marinate than Scala did.
So basically you're saying that they didn't want to do the hard work and used the JVM as a shortcut. Sounds like good engineering practice to me. When things get hard, just find a lazy shortcut.
Marination is generally a good thing. Things come out tastier. Same for new languages. The robust Python / Ruby / PHP ecosystems seem to be working just fine without the JVM.
Marination is generally a good thing. Things come out tastier. Same for new languages. The robust Python / Ruby / PHP ecosystems seem to be working just fine without the JVM.
Sounds like good engineering practice to me.
Me too. After all, Scala's engineers weren't looking to create a whole new platform; they were just looking to create a new language. And a good engineer won't waste enormous amounts of time working on out-of-scope tangents unless there's a good reason to do so.
NIH doesn't count as a good reason.
Me too. After all, Scala's engineers weren't looking to create a whole new platform; they were just looking to create a new language. And a good engineer won't waste enormous amounts of time working on out-of-scope tangents unless there's a good reason to do so.
NIH doesn't count as a good reason.
I agree. But as Scala gets more and more popular, they're going to become a whole ecosystem and platform unto themselves. But because they're on the JVM, all the new tools etc are going to be customized to handle unique JVM-only issues. It's a classic platform lock-in situation. And Oracle is driving the wheel here.
Not sure how that's going to work out much better than all the great tools that were built on top of Microsoft's MFC framework. People didn't realize that it was a bad idea until it was too late to change.
Sometimes in CS it really makes sense to build things slower and more carefully to avoid issues that may only come up years down the road.
Not sure how that's going to work out much better than all the great tools that were built on top of Microsoft's MFC framework. People didn't realize that it was a bad idea until it was too late to change.
Sometimes in CS it really makes sense to build things slower and more carefully to avoid issues that may only come up years down the road.
Scala is a great way for enterprise developers to evolve a little toward functional programming.
the JVM is still here to stay, and many Ruby web apps move to JRuby when they need to scale, and this is a fact.
If we want to close the gap between enterprise and startups, Scala is a great way to go. and I'm sure it will have non JVM versions in the future, if not already.
My language of choice at the moment, I like Ruby and Python, but I like a static typed language, I got used to it.
the JVM is still here to stay, and many Ruby web apps move to JRuby when they need to scale, and this is a fact.
If we want to close the gap between enterprise and startups, Scala is a great way to go. and I'm sure it will have non JVM versions in the future, if not already.
My language of choice at the moment, I like Ruby and Python, but I like a static typed language, I got used to it.
Would you rather have the JVM as your ecosystem or no ecosystem at all?
If Scala can't survive without the JVM perhaps it's just not a good idea.
If enough people care about Scala they'll make it work independently of the JVM. JVM-based Scala is perhaps a good way to bootstrap the language, but I don't see how it's a great long-term strategy.
If enough people care about Scala they'll make it work independently of the JVM. JVM-based Scala is perhaps a good way to bootstrap the language, but I don't see how it's a great long-term strategy.
And if people cared enough about Rails they would make it work independently of Ruby, except that makes no sense.
Nice lol. If enough people cared about Microsoft Office, they'd make it run without windows.
Tons of similar and true examples. What about: If enough people cared about java they'd make it run without the jvm.
Tons of similar and true examples. What about: If enough people cared about java they'd make it run without the jvm.
In general, this is true, but the proper way to view Scala is as a 'fixed' version of Java. Scala isn't really competing for the same mindshare as Ruby/Python/etc., and for good reason. Scala is basically what Java should have been (or at least, that's the goal).
Scala is not truly functional - like Java, it is object-oriented. It just so happens that, once you step outside the Java bastardization of that term and think about a more 'pure' OO, the result is fairly functional-looking. OO and FP aren't really competing paradigms; rather, OO is a more complex paradigm that can be constructed from a functional system. (The inverse is technically true too, but much uglier in practice).
(To give an example of what I mean, Scala supports first-class objects, and functions/methods are included in that statement. Scala does not support first-class, module-level functions (outside an object). That's not functional programming; it's object-oriented! But if you design your OO system well, you get something similar. Java does this badly, because methods aren't first-class objects - and unlike C, you can't really use pointers/references to fake the same behavior, so you get the worst of both worlds).
Of course, Scala has to deal with limitations of the JVM - that's their compromise to gain binary inter-compatibility - but the designs of the two languages are a night-and-day comparison.
Scala is not truly functional - like Java, it is object-oriented. It just so happens that, once you step outside the Java bastardization of that term and think about a more 'pure' OO, the result is fairly functional-looking. OO and FP aren't really competing paradigms; rather, OO is a more complex paradigm that can be constructed from a functional system. (The inverse is technically true too, but much uglier in practice).
(To give an example of what I mean, Scala supports first-class objects, and functions/methods are included in that statement. Scala does not support first-class, module-level functions (outside an object). That's not functional programming; it's object-oriented! But if you design your OO system well, you get something similar. Java does this badly, because methods aren't first-class objects - and unlike C, you can't really use pointers/references to fake the same behavior, so you get the worst of both worlds).
Of course, Scala has to deal with limitations of the JVM - that's their compromise to gain binary inter-compatibility - but the designs of the two languages are a night-and-day comparison.
It is possible to be both object-oriented and functional—for example, OCaml and several Lisps are functional languages that nonetheless feature object systems. The two paradigms are not necessarily in conflict, and Scala is a perfect example of a language which is both. (The definition of 'functional language' is vague and generally somewhat informal, but broadly speaking it has more to do with how one approaches problems than e.g. where functions are defined.)
> The two paradigms are not necessarily in conflict.
Agreed - that's my whole point. It's better to think of object-oriented programming as a construction within FP. Of course, some (badly-designed) OO languages like Java sandbox you and restrict your access to some of the more powerful, higher-order concepts, which is why they seem to be 'in conflict', when in reality, one is just a more abstractly implemented, whereas the other's more specifically implemented.
> Scala is a perfect example of a language which is both.
No, it's not - for example, functions have to exist within an instantiation of a class (a singleton object counts). By providing true first-class objects (unlike Java), you get many of the same benefits as first-class functions, but it's fundamentally not the same thing.
Really, an easy way to create a language which supports both is to start with a very basic language with true first-class functions and closures (like Lisp) and then define a few closures that encapsulate state (objects), and then add a couple of basic macros that turn generic functions into bound methods (ie, automatically provide the implicit parameter instead of calling it explicitly).
...which is why I agree that they're not in conflict - a well-designed OO system can be easily implemented within a well-designed functional system!
(The reverse doesn't work so well because you can easily add an implicit parameter to generic functions, but you can't completely remove an implicit parameter from a bound method, even if you pretend it doesn't exist - ie, treat all methods as static methods).
Agreed - that's my whole point. It's better to think of object-oriented programming as a construction within FP. Of course, some (badly-designed) OO languages like Java sandbox you and restrict your access to some of the more powerful, higher-order concepts, which is why they seem to be 'in conflict', when in reality, one is just a more abstractly implemented, whereas the other's more specifically implemented.
> Scala is a perfect example of a language which is both.
No, it's not - for example, functions have to exist within an instantiation of a class (a singleton object counts). By providing true first-class objects (unlike Java), you get many of the same benefits as first-class functions, but it's fundamentally not the same thing.
Really, an easy way to create a language which supports both is to start with a very basic language with true first-class functions and closures (like Lisp) and then define a few closures that encapsulate state (objects), and then add a couple of basic macros that turn generic functions into bound methods (ie, automatically provide the implicit parameter instead of calling it explicitly).
...which is why I agree that they're not in conflict - a well-designed OO system can be easily implemented within a well-designed functional system!
(The reverse doesn't work so well because you can easily add an implicit parameter to generic functions, but you can't completely remove an implicit parameter from a bound method, even if you pretend it doesn't exist - ie, treat all methods as static methods).
A "first-class function" is a function that can be passed to a function, returned from a function, assigned to a variable, or stored in a data structure or basically used in any way that you would use any value. In Scala:
object Foo {
def f1(x : Int) : (Int => Int) = {
return { y : Int => x + y }
}
def f2(f : Int => Int) : Int = { return f(5) }
val f3 = f1(1)
val f4 = List(f1(2), f1(3), f1(4))
}
> In that sense, functions are on equal footing with values.
But function objects are not on equal footing with non-function objects. You can nest function objects or non-function objects inside other function/non-function objects, but at the root, you need an object that isn't a function.
At the end of the day, yes, you can do the same things, but my original point was that this doesn't make Scala functional: it makes Scala object-oriented (Java, by contrast, is not properly object-oriented, because it has four kinds that aren't objects).
But function objects are not on equal footing with non-function objects. You can nest function objects or non-function objects inside other function/non-function objects, but at the root, you need an object that isn't a function.
At the end of the day, yes, you can do the same things, but my original point was that this doesn't make Scala functional: it makes Scala object-oriented (Java, by contrast, is not properly object-oriented, because it has four kinds that aren't objects).
Scala does not support first-class, module-level functions (outside an object).
Sure it does.
Sure it does.
object f {
def apply(x: String) = s + " - foo"
}
val t = f("bar")I don't understand what you mean. That's a function definition within an object; it's not top-level.
EDIT: Okay, I see the confusion. That seems like a 'top-level' function in the sense that it's not acting on any parameter that's not explicitly passed to it, but it is still bound to the singleton object 'f'. That would be analogous to the following Python code:
class F(object): def __init__(self): pass
Just because you ignore the implicit parameter doesn't mean it doesn't exist. Scala handles the implicit parameter differently, but the function still very much needs to exist inside the namespace of another object.
EDIT: Okay, I see the confusion. That seems like a 'top-level' function in the sense that it's not acting on any parameter that's not explicitly passed to it, but it is still bound to the singleton object 'f'. That would be analogous to the following Python code:
class F(object): def __init__(self): pass
def x(self, s):
return s + 'hi'
Just because you ignore the implicit parameter doesn't mean it doesn't exist. Scala handles the implicit parameter differently, but the function still very much needs to exist inside the namespace of another object.
Not quite.
"When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable."
So it's much closer to:
"When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable."
So it's much closer to:
class F(object):
# you can't actually do this in Python, because F() isn't bound at this
# point, but that's close to what Scala does.
__name__.f = F()
def __call__(cls, s):
return s + "bar"
f("foo")
Inferior (or 'unworkable', before you edited the comment)? Where are you getting that from? I never said that - I use Scala myself (and used to use it at work). Java is certainly inferior, because Java is OO done badly.
> "When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable."
Now I've lost track of what you're quoting from, but that's by definition very OO. It's a modified form of the messaging pattern employed by Smalltalk.
Scala isn't a functional/object-oriented hybrid; it's purely object-oriented (even more so than Java) because it has one single kind[1]: the object (Java pretends to have one, but it really has five, if you really wanted to get pedantic).
So we shouldn't be celebrating Scala for being a functional hybrid - we should celebrate as being 'OO done right' (well, mostly right), which was the stated and failed intent of Java.
The distinction is subtle, but the important thing to remember is that I'm operating on the premise that proper OO is essentially a subset/extension of FP, not an alternative. So what I'm saying is that this doesn't show that Scala is 'more functional' (vs. 'less functional') - rather, it shows that Scala is good OO (vs. bad OO, ie Java). I agree that it's a bit like the 'white horse is not a horse' argument, but it becomes important when we start talking about non-white horses; ie, functional languages that aren't OO).
[1] I'm kind-of (no pun intended) abusing the term 'kind', but I can't think of a non-overloaded synonym as the moment, other than 'type' which would be worse.
> "When you apply parentheses surrounding one or more values to a variable, Scala will transform the code into an invocation of a method named apply on that variable."
Now I've lost track of what you're quoting from, but that's by definition very OO. It's a modified form of the messaging pattern employed by Smalltalk.
Scala isn't a functional/object-oriented hybrid; it's purely object-oriented (even more so than Java) because it has one single kind[1]: the object (Java pretends to have one, but it really has five, if you really wanted to get pedantic).
So we shouldn't be celebrating Scala for being a functional hybrid - we should celebrate as being 'OO done right' (well, mostly right), which was the stated and failed intent of Java.
The distinction is subtle, but the important thing to remember is that I'm operating on the premise that proper OO is essentially a subset/extension of FP, not an alternative. So what I'm saying is that this doesn't show that Scala is 'more functional' (vs. 'less functional') - rather, it shows that Scala is good OO (vs. bad OO, ie Java). I agree that it's a bit like the 'white horse is not a horse' argument, but it becomes important when we start talking about non-white horses; ie, functional languages that aren't OO).
[1] I'm kind-of (no pun intended) abusing the term 'kind', but I can't think of a non-overloaded synonym as the moment, other than 'type' which would be worse.
The quote's from Programming in Scala, I wanted to look up exactly how the apply() sugaring is described by the author of the language. I'm not sure it is by definition OO, it just looks like operator overloading to me, similar to C++'s operator() or Python's __call__.
Maybe I'm misunderstanding your broader point - claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency, and that it's such an obvious one you don't need to explain why. From my perspective the only reason I care about namespaces is a) that I can namespace my functions and b) so that I don't have to type things out longhand - the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me, and seems to me to be nearly irrelevant in evaluating if a language is "really" OO or "really" functional. If module-level functions are important to the question I would like to know why. :)
Maybe I'm misunderstanding your broader point - claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency, and that it's such an obvious one you don't need to explain why. From my perspective the only reason I care about namespaces is a) that I can namespace my functions and b) so that I don't have to type things out longhand - the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me, and seems to me to be nearly irrelevant in evaluating if a language is "really" OO or "really" functional. If module-level functions are important to the question I would like to know why. :)
> claiming that Scala doesn't support module-level functions implies to me that you feel this is a deficiency
It's not a deficiency, but it emphasizes the fact that Scala is object-oriented, not functional. Scala supports first-class objects, and you get more functional features than Java because, unlike Java functions, Scala functions are objects.
In other words, Scala's support for certain functional features is a corollary of its support for first-class objects, not because of its support for first-class functions.
> the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me
Which probably means that most of this discussion may be irrelevant to your interests too. :-)
That's not meant to be rude - I'm being a bit facetious, but I'll readily admit that the OO 'vs.' FP is far too subtle for most people to care about... and that's fine. Beyond a certain point, it's a discussion with more academic value than practical value.
But if you really care, let me try and explain the following:
> If module-level functions are important to the question I would like to know why. :)
Lack of module-level functions is a hint (though not proof) that Scala is 'OO first, and FP by coincidence'. Objects are just classes that are automatically created and instantiated with a singleton. Scala permits nesting of objects (objects within objects). The nested objects may themselves be function objects or non-function objects. However, at the root, you must have a non-function object.
In other words, picture Scala code as a tree: functions may appear as inner nodes or leaf nodes, but they may not be the root node, which is reserved for a non-function object. Inner/leaf nodes are of type
psuedocode:
Furthermore, if Scala functions are implemented as internal methods on variables (which are objects), that means that there is no way in Scala to write a function that is not eventually compiled to a method - ie, an object-bound function. If we can't break this binding, it's hard to make the case that functions are truly first-class. Objects are first-class, and because Scala provides first-class object support (unlike Java), many features of first-class functions can be simulated by using first-class objects, but that's subtly different from treating the function itself as the first-class citizen.
For contrast, the inverse would be a functional languages with first-class functions and no first-class objects. All objects are constructed from functions (ie, 'bound to functions' in some sense), and there's no way to create an 'unbound' object, whereas there is in Scala.
It's not a deficiency, but it emphasizes the fact that Scala is object-oriented, not functional. Scala supports first-class objects, and you get more functional features than Java because, unlike Java functions, Scala functions are objects.
In other words, Scala's support for certain functional features is a corollary of its support for first-class objects, not because of its support for first-class functions.
> the exact implementation of namespacing (module-level vs module/object-level) is irrelevant to me
Which probably means that most of this discussion may be irrelevant to your interests too. :-)
That's not meant to be rude - I'm being a bit facetious, but I'll readily admit that the OO 'vs.' FP is far too subtle for most people to care about... and that's fine. Beyond a certain point, it's a discussion with more academic value than practical value.
But if you really care, let me try and explain the following:
> If module-level functions are important to the question I would like to know why. :)
Lack of module-level functions is a hint (though not proof) that Scala is 'OO first, and FP by coincidence'. Objects are just classes that are automatically created and instantiated with a singleton. Scala permits nesting of objects (objects within objects). The nested objects may themselves be function objects or non-function objects. However, at the root, you must have a non-function object.
In other words, picture Scala code as a tree: functions may appear as inner nodes or leaf nodes, but they may not be the root node, which is reserved for a non-function object. Inner/leaf nodes are of type
psuedocode:
type Object
type ScalaFunction extends Object
type NonFunctionObject extends Object
Furthermore, if Scala functions are implemented as internal methods on variables (which are objects), that means that there is no way in Scala to write a function that is not eventually compiled to a method - ie, an object-bound function. If we can't break this binding, it's hard to make the case that functions are truly first-class. Objects are first-class, and because Scala provides first-class object support (unlike Java), many features of first-class functions can be simulated by using first-class objects, but that's subtly different from treating the function itself as the first-class citizen.
For contrast, the inverse would be a functional languages with first-class functions and no first-class objects. All objects are constructed from functions (ie, 'bound to functions' in some sense), and there's no way to create an 'unbound' object, whereas there is in Scala.
Scala runs on CLR too.
I think the more interesting thing is a link in one of the comments:
Admittedly, that's an article from 2011, and it's probably on hacker news somewhere already, but still...
http://www.infoworld.com/d/application-development/scala-the-android-programming-language-you-didnt-know-you-had-170999
Admittedly, that's an article from 2011, and it's probably on hacker news somewhere already, but still...
Scala compiler and library implementation ships as a se of jar files, so it can be used in any env that provides the Java API.
No. I think Scala is a fine language, with lots of neat features. But it does not give the developer enough of a leap - someone has already mentioned a parallel between C -> C++ and Java -> Scala. I think this is a reasonable comparison.
This is why I tell folks to avoid Scala and pick one of two other great options which offer a fundamental change from Java:
* Groovy (dynamic lang, easy to pick up _and_ master) * Clojure (the power of LISP, steeper learning curve)
There's a bunch of stuff out there which explain why NOT Scala, so I won't regurgitate it here.
This is why I tell folks to avoid Scala and pick one of two other great options which offer a fundamental change from Java:
* Groovy (dynamic lang, easy to pick up _and_ master) * Clojure (the power of LISP, steeper learning curve)
There's a bunch of stuff out there which explain why NOT Scala, so I won't regurgitate it here.
For anyone who wants to learn more about Scala: Martin odersky's scala class at Coursera starts in two weeks.
For anyone who's interested, coursera is offering a Scala course taught by Odersky this fall. It starts the 18th of September.
https://www.coursera.org/course/progfun
https://www.coursera.org/course/progfun
It is too easy to write dense indecipherable code in Scala. Until someone at least comes up with an "Effective Scala" that is as complete as Josh Bloch's "Effective Java" at outlining the best practices for readability and maintainability, Scala will not be an acceptable replacement for Java in larger organizations.
Look at Suereth's "In Depth" (also Horstmann's book is an excellent intro
http://www.amazon.com/Scala-Depth-Joshua-Suereth-D/dp/193518...
http://www.manning.com/suereth/
http://www.amazon.com/Scala-Depth-Joshua-Suereth-D/dp/193518...
http://www.manning.com/suereth/
[deleted]
we need a new world where haskell is the new C(++) and Clojure(script) is the new JAVA(Javascript).
However, as much as it may surprise, most developers of this world, as much as they would like to work in a startup, work in a gray, corporate enterprise, write Java, Spring and Hibernate, or .NET, and have no clue about anything beyond that.
Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land. which is great news for everyone.
There are many Enterprise developers who are amazing developers and architects, and can benefit any startup, the more they get close to newer "trends" the more likely the connection will happen.
Young startups will benefit, 40+ enterprise Java architects will benefit, and perhaps the talent wars will have a cease fire.
I'm pushing everyone I know to take a look at Scala, it's here to stay, and if you take a look at play framework, it's looking even more like the next big thing.
It all comes down to the community, if the ruby / rails community will be scala / play friendly, and endorse it as a "ok it's Java but we hate it less", it will help it take off.
As an enterprise developer, I really need something like scala / play to take off, as I won't be able to get ruby on rails / django in the same way I could get play / lift. as much as I think they are great frameworks, it's hard to sell to the enterprise crowd.