Live data from Hacker News

Why Java folks should look forward to Scala

blog.dhananjaynene.com

21–30 of 36 posts

Re: Why Java folks should look forward to Scala

#21
post #2

I knew I felt some unease with Scala's abbreviated lambda syntax, but couldn't pin down what it was that bothered me. Seeing these examples clarified it: def apply() = l map (_()) println (users filter (_.age The first two uses of () are anonymous functions, the last is a tuple. The only way to tell them apart, best I can tell, is the use of _ turns the scope of the surrounding parens into a lambda. Clojure uses the…

Yah, scala uses "_" a lot:

http://www.slideshare.net/normation/scala-dreaded

The visual clue is the method/function signature which you get from the REPL or IDEA scala plugin. I think F#, O'Caml and haskell programmers rely on these heavily also

(There is talk of deprecating one "_" usage)

http://groups.google.com/group/scala-language/browse_frm/thr...

Re: Why Java folks should look forward to Scala

#22
post #9

There is no doubt in my mind that if Java had added just a few features of these languages we wouldn't be having this discussion. My MVP would be lambdas, type inference, properties and extension methods and that would probably have been enough to make explorations outside of Java mere curiosities. In the mean time, I'll keep helping out on JDK8 to get 2/4 in there.

Gosu has lambdas, type inference, properties and extension methods: http://gosu-lang.org It's a Java-compatible JVM language that doesn't change stuff up too much, just addresses some shortcomings of Java.

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.

Re: Why Java folks should look forward to Scala

#23
post #20

Earlier quoted context omitted.

More to the point, Microsoft is continuously improving C# I was at a conference back in 1997 where we came up with a wish list of features we'd like in Java for high performance computing. We all knew it was useless to ask this from Sun, but we did anyway. The first version of C# had everything we asked for in it, and even early versions of C# had a 'delegate' mechanism that was, more or less, method pointers. C# 3.0…

comparing modern italian to ancient latin. Offtopic but interesting tangent: that's comparing declined languages ( with nominative, accusative, dative etc cases) to languages that use prepositions and other particles instead. Kind of like comparing static type languages vs. clojure and erlang.

Latin has prepositions as well, although I see your point. I've made the same case before that Latin is a statically typed human language whereas most of English grammar depends on "runtime" information.

Re: Why Java folks should look forward to Scala

#24
post #22

Earlier quoted context omitted.

Gosu has lambdas, type inference, properties and extension methods: http://gosu-lang.org It's a Java-compatible JVM language that doesn't change stuff up too much, just addresses some shortcomings of Java.

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.

Re: Why Java folks should look forward to Scala

#25
post #11

Earlier quoted context omitted.

That is only one way of writing that snippet. Another would be: def apply() = l.map((f) => f()) Is that more clear?

This actually is one of my frustrations with Scala, too many right ways to do the same thing. Makes it easier to write but harder to read especially when people have drastically differing styles. One of the advantages of Java is how easy it is to read and use someone else's code since the base language is so limited.

Same here, i love the "There should be one and only one obvious way of doing things"-paradigm of Python. Scala is in my mind the complete opposite to that.

Re: Why Java folks should look forward to Scala

#26
post #17

Earlier quoted context omitted.

This actually is one of my frustrations with Scala, too many right ways to do the same thing. Makes it easier to write but harder to read especially when people have drastically differing styles. One of the advantages of Java is how easy it is to read and use someone else's code since the base language is so limited.

Exactly. I thought perl (and c++) demonstrated that TMTOWTDI is a misfeature pretty convincingly, but I guess some people weren't paying attention.

I got banned for saying Scala is the c++ of jvm. ;)

Re: Why Java folks should look forward to Scala

#27

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, consistency is a prerequisite to a short learning curve. How can it be short if what you have learned in the past is constantly questioned along the way?

When the experts provide multiple ways of achieving the same thing, they force the act of making the choice upon everyone, which is a huge barrier for beginners. Scala could attract a lot more beginners, if it didnt make them think about choices at every step of the way.

Re: Why Java folks should look forward to Scala

#28
post #2

I knew I felt some unease with Scala's abbreviated lambda syntax, but couldn't pin down what it was that bothered me. Seeing these examples clarified it: def apply() = l map (_()) println (users filter (_.age The first two uses of () are anonymous functions, the last is a tuple. The only way to tell them apart, best I can tell, is the use of _ turns the scope of the surrounding parens into a lambda. Clojure uses the…

> 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 }
    res3: scala.collection.immutable.IndexedSeq[Int] = Vector(5, 10, 15, 20, 25)

The _ symbol is equivalent to the % in your Clojure example. So both examples above are equivalent to:

    scala> (1 to 5).map((x:Int) => x * 5)
    res2: scala.collection.immutable.IndexedSeq[Int] = Vector(5, 10, 15, 20, 25)



You don't need _any_ characters or visual indicators to declare an anonymous function. Example:

    scala> def apply(op: Int => Int, y: Int) = op(y)
    apply: (op: (Int) => Int, y: Int)Int
Can then be called as:

    scala> apply(_ * 10, 10)
    res4: Int = 100
Or:

    scala> apply((x:Int) => x * 10, 10)
    res5: Int = 100
Or even:

    scala> apply((_ * 10), 10)
    res6: Int = 100
Perhaps your original point stands that in Clojure you have _better_ visual clues for picking out anonymous functions at a glance, but I disagree that you even need them in the Scala code you posted.

Re: Why Java folks should look forward to Scala

#29
post #21
post #2

I knew I felt some unease with Scala's abbreviated lambda syntax, but couldn't pin down what it was that bothered me. Seeing these examples clarified it: def apply() = l map (_()) println (users filter (_.age The first two uses of () are anonymous functions, the last is a tuple. The only way to tell them apart, best I can tell, is the use of _ turns the scope of the surrounding parens into a lambda. Clojure uses the…

Yah, scala uses "_" a lot: http://www.slideshare.net/normation/scala-dreaded The visual clue is the method/function signature which you get from the REPL or IDEA scala plugin. I think F#, O'Caml and haskell programmers rely on these heavily also (There is talk of deprecating one "_" usage) http://groups.google.com/group/scala-language/browse_frm/thr...

Those myriad different meanings of "_" depending on context is positively Perl-like.

Seems like a good Scala style guide would ban the use of it altogether, or just white list a couple of uses.

Are both {} and () equally valid delimiters for scoping an anonymous function? If so, always using {} would help to avoid confusion with tuples.

{ _ + _ } as a function taking two arguments seems just wrong to me. Shouldn't it be { _1 + _2 }?

Re: Why Java folks should look forward to Scala

#30
post #2

I knew I felt some unease with Scala's abbreviated lambda syntax, but couldn't pin down what it was that bothered me. Seeing these examples clarified it: def apply() = l map (_()) println (users filter (_.age The first two uses of () are anonymous functions, the last is a tuple. The only way to tell them apart, best I can tell, is the use of _ turns the scope of the surrounding parens into a lambda. Clojure uses the…

> 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?

Post reply on HN