Live data from Hacker News

Why Java folks should look forward to Scala

blog.dhananjaynene.com

31–36 of 36 posts

Re: Why Java folks should look forward to Scala

#31

Earlier quoted context omitted.

> The first two uses of () are anonymous functions No they're not. They are just containers for arguments to a function. In Scala whenever you call a function which takes as it's only parameter another function, you can even replace them entirely with curly brackets: scala> (1 to 5).map(_ * 5) res1: scala.collection.immutable.IndexedSeq[Int] = Vector(5, 10, 15, 20, 25) is equivalent to: scala> 1 to 5 map { _ * 5 } re…

"Perhaps your original point stands that in Clojure you have _better_ visual clues for picking out anonymous functions at a glance" Yes, this is what I was trying to get at. Thanks for clarifying the examples, though. So, using _ in any expression makes that expression an anonymous function? Is _ by itself the identity function?

> So, using _ in any expression makes that expression an anonymous function?

Ah, I should have said - the syntax above only works with one-liners. The following wouldn't work:

    scala> apply(val y = _ * 50; y * 100, 10)
    scala> apply((val y = _ * 50; y * 100), 10)
    scala> apply((x: Int) => val y = x * 50; y * 100, 10)
etc.

Instead you would need to explicitly surround the method body with curly brackets:

    scala> apply((x:Int) => { val y = x * 20; y }, 10)
    res18: Int = 200

And in this case, it's obvious what is happening.

So it's more like providing a one line expression where a function is expected makes it an anonymous function. The use of _ is simply a shortcut when you don't need to assign parameters to a local variable. It even works with multiple parameters. I.e. compare:

    scala> (1 to 5).foldLeft(0)((accumulator:Int,x:Int) => accumulator + x)
    res22: Int = 15
To:

    scala> (1 to 5).foldLeft(0)(_ + _)
    res19: Int = 15

Re: Why Java folks should look forward to Scala

#32

C# isn't a realistic option for a lot of people with big investments in the JVM. It is clearly an interesting language, but, it's no F#. Obviously there are no silver bullets that make software development easy. But after having written a handful of high performance, high availability systems in Scala, the benefits over the other alternatives on the JVM are so evident to me, it's easy for me to get frustrated that th…

"It is difficult to argue against the idea that there are too many ways to do things in Scala. There is more than one way to do a lot of things, and I personally find the right way for me to be fairly evident after writing a few thousand lines of code." And that is the problem. Most people will never reach the state of having writing a few thousand lines of code, because they are to confused to begin with. In my mind…

The people who actually manage to write a few thousands lines of Scala (and end up happy), are great people to code with (or hire) in my experience.

It's easier to better engineer complicated things in simple ways when you are less encumbered by non-essential complexity. Once you surmount the learning curve, Scala brings a lot. If you can't or won't put enough in to make it, well, sure, it won't be for you. Personally I like solving problems that are hard enough to benefit from Scala's expressiveness. But I completely concede that for lots of people, there's just no reason not to keep on doing Java. Or Cobol for that matter.

Re: Why Java folks should look forward to Scala

#33

I still can't believe how many people are unaware of C#. Coming from a java background, C# is a far better route than Scala. The Scala syntax, I must say is not as readable: def apply() = l map (_())

The problem is not being unaware of C#, the problem is being aware of Microsoft.

Re: Why Java folks should look forward to Scala

#34
If Java is a tool that provides the functionality needed for a particular developer, why investigate a new language? Seriously? It isn't just a case of the developer and the language features that matter to a commercial business, there are the IT folks running the thing, their familiarity with the tools, the logging facilities, etc.

Tools are great and learning new ones is a good thing. But articles like "X should look forward to/embrace Y" are short sighted unless they take into account the simple fact -- what is the end goal. If it is shipping product, the whole team needs to be on board from design, implementation, running, and maintenance.

Re: Why Java folks should look forward to Scala

#35

Earlier quoted context omitted.

"It is difficult to argue against the idea that there are too many ways to do things in Scala. There is more than one way to do a lot of things, and I personally find the right way for me to be fairly evident after writing a few thousand lines of code." And that is the problem. Most people will never reach the state of having writing a few thousand lines of code, because they are to confused to begin with. In my mind…

The people who actually manage to write a few thousands lines of Scala (and end up happy), are great people to code with (or hire) in my experience. It's easier to better engineer complicated things in simple ways when you are less encumbered by non-essential complexity. Once you surmount the learning curve, Scala brings a lot. If you can't or won't put enough in to make it, well, sure, it won't be for you. Personall…

I agree, I just gave reasons what in my mind prevents others to follow the same path.

Re: Why Java folks should look forward to Scala

#36
post #22

Earlier quoted context omitted.

Gosu, Ceylon ann Fantom all have really nice designs, from what little I've seen of them. I think the big corporate backer (Red Hat) makes a big difference.

These languages are all pretty well designed but without tool support they can't really hold a candle to Java for those developers that want strong IDEs. Scala and Groovy are pretty well supported but still far behind Java on this mark.

100% agreement, which is why we, the Gosu guys, are working feverishly on IDE support.
Post reply on HN