Live data from Hacker News

Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

gridgaintech.wordpress.com

61–70 of 75 posts

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#61

Would it be wrong to think of Scala and Clojure as the F# of the JVM? I had been thinking of Scala as though it was Java++ (in analogy to C vs C++): a language that adds a few features on top of Java for better abstractions, but regular Java programmers can basically program Java in it (and read it as though it was Java). However, it seems like truly idiomatic Scala code involves heavy use of advanced functional and…

I would say yes. From C to C++ you can use the same tools and everything. Java to Scala is still a new language.

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#62
post #9
post #8

Earlier quoted context omitted.

It's Groovy still, like, slower than Ruby? That was always the big attraction with Scala - all the fun stuff, but less than a 5% performance penalty over vanilla java.

Groovy is still pretty slow, but last I checked the Groovy++ compiler can take unchanged Groovy code and compile it so that it is often as fast as Java.

unchanged? Are they doing massiv typeanalisis? What are the tradeoffs? This seams to "to good to be true". Everybody else that tries to staticlly compling dynamic languages has more or less failed.

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#63
post #3

My general feeling is that there is a business-model problem in the tech industry. The most important technolgies are underfunded. They are created by smart people in their free time, or by companies who do not have enough money. For example I've looked at Scala's Eclipse plugin: it was a horror. It is just question of money (hiring a bunch of good developers) to create IDE support which is not totally buggy and not…

One problem with infrastructure technology (programming languages, databases, IDEs, etc) is that all of the above is expected to be available for free by developers. So there is little incentive to develop a business around infrastructure technology. Sure people still do it, but not like the 80s when people still paid for PLs, IDEs, databases,etc. These markets have been drastically devalued by open source.

The problem isn't that developers "expect" this stuff to be free. It's that the quality of a particular development platform is related to how many people are using it - how many tutorials are there out there, how much sample code, how many libraries, etc.

There may be some social bias against paying for stuff, I think partially because people got burned with vendor lock-in. Technology changes so quickly, it's hard to know what a tool is worth before the fact.

But there's also a very real economic reality at play here. The most valuable platforms will be the ones with the most people collaborating on them, and that's always going to be the free or open platforms.

As you move up the infrastructure chain, I think people are more willing to pay for useful libraries or services, especially for ancillary stuff. But what rational person would build their business on something they didn't own?

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#64
post #2

Interesting that they feel this way. As a Groovy enthusiast, it feels to me like Scala's gotten all the press/mindshare over the last year, while Groovy is potentially doomed to sideline status. Lift gets some praise, and Play! and Roo are the new hotness, while Groovy/Grails doesn't get the love I'd like it to. Probably all "alt.java" tech will remain somewhat fringe, simply due to inertia. And although I wasn't in…

It seems like I get calls from recruiters every other week looking for people with Grails experience.

I used Grails for a project four years ago - I think it made a lot of sense then. We wanted a simple web UI for something that needed to deeply integrate with some java libraries. We had just done a relatively simple UI with Spring and it was pretty amazing how much better it was to work in Groovy.

However, these days I don't see why anyone would pick Grails over Rails. You can deploy rails on the jvm just fine, and it's much more mature. There are tons of tutorials and example code out there.

It's not a performance thing - it's just that ruby/rails is pretty mature now and runs on the JVM very well.

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#65

Earlier quoted context omitted.

I am a half step above a blub, but I've been doing some work in Scala and generally enjoy it. I do, however, think the Scala community needs to have a more convincing reply to the complexity argument than "You aren't smart enough to see its brilliance". My fear is that if things don't change, Scala will fall into a perl-like situation where it won't be able to shake its reputation and people will reject the language…

It's too late for that. Scala's community has been branded as a bunch of condescending intellectuals. Just like Ruby's community was branded as a bunch of pierced, macbook users in 2005. Neither are really true -- but first impressions mean everything.

Comments like that always remind me of this image...

http://www.picshag.com/show.php?f=pics/112010/java-c-php-rub...

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#66

Earlier quoted context omitted.

I used them a bit with some image processing. Was awesome to see all 8 cores pegged w/ one line of code!

Java or Scala? list.par().map(f);

I've found that if the list is very large, using list.par.map(...) hits the memory limit & then simply hangs.

I process upwards of a million facilities ( a facility is the exposure on a commercial loan a bank makes to a client ), trying to forecast their expected loss over 12 future quarters.

I rewrote my code like so :

val facs:List[Facility] = ...populated via jdbc query ///

val N = 1000

facs.grouped(N).foreach( group => {

   group.par.map( fac => expectedloss(fac)
})

Now the outer loop is sequential but the inner loop is parallel. It chugs along, and processes the entire million plus facilities! I get some control via the N. Currently my N is 1000 and all 8 cores running at 100% capacity, but I can slow down the workload with smaller N.

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#67
post #54

I like Scala, sad to see that it is not gaining the required momentum. There are many people complaining about Scala and we don't see many people who are using it successfully talk about its abilities and elegance, I would love to see the scala experts/Typesafe respond with something that demonstrates the usefulness/applicability of Scala to the masses, and may be Typesafe/Partners can offer an easy to follow video t…

> "You are wrong.You haven't learned it properly" Do you have a link? Maybe this unhelpful behavior can be figured out in person. I always experienced the Scala community as a very friendly and helpful one, focused on getting stuff done. Imho the talk about “bad behavior” outnumbers the actual occurrences of bad behavior by a few magnitudes.

> Do you have a link?

http://blog.joda.org/2011/11/scala-ejb-2-feedback.html?showC...

I don't question the intent of the Scala community. There's no mystic group of evildoers there trying to degrade newcomers. But the mailing list is very intimidating. It doesn't feel like a place where newbies can come in and ask "How do I do a 'foreach' loop?".

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#68

Earlier quoted context omitted.

I used them a bit with some image processing. Was awesome to see all 8 cores pegged w/ one line of code!

That does not say much, without actually specifying how much data is processed. It's great if you can spread calculations among 8 cores, but if a single-threaded C process provides better performance (let alone a parallel C implementation), what does it say? Could you provide more data points? (By the way, in C such loops can typically be parallelized by adding one OpenMP pragma.)

> if a single-threaded C process provides better performance (let alone a parallel C implementation), what does it say?

It doesn't say much until you define what's most important to you. Is it more important that you can use Scala and get your code working more quickly or do you have more time to write and debug a C program and do you really need to do that for performance reasons? Does the code need to function as part of a larger Java/Scala or C application, etc. In other words, and as always, you need to pick to right tool for the job.

The JVM is very fast now days, in my work the issue of performance vs. C never comes up. Obviously there are still valid uses for C these days, but you can get very decent performance from the JVM and that often means you can finish your work faster.

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#69
post #54

Earlier quoted context omitted.

> "You are wrong.You haven't learned it properly" Do you have a link? Maybe this unhelpful behavior can be figured out in person. I always experienced the Scala community as a very friendly and helpful one, focused on getting stuff done. Imho the talk about “bad behavior” outnumbers the actual occurrences of bad behavior by a few magnitudes.

> Do you have a link? http://blog.joda.org/2011/11/scala-ejb-2-feedback.html?showC... I don't question the intent of the Scala community. There's no mystic group of evildoers there trying to degrade newcomers. But the mailing list is very intimidating. It doesn't feel like a place where newbies can come in and ask "How do I do a 'foreach' loop?".

While it takes a while to understand how he approaches problems and solves them, his offer is honest and his judgment is correct.

He basically says that if the blog author actually had a look at the language before bashing it, he would have found valid issues.

I agree with that. The author's complaints are unsubstantiated and don't reflect the issues people encounter in reality.

Re: Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing

#70

Would it be wrong to think of Scala and Clojure as the F# of the JVM? I had been thinking of Scala as though it was Java++ (in analogy to C vs C++): a language that adds a few features on top of Java for better abstractions, but regular Java programmers can basically program Java in it (and read it as though it was Java). However, it seems like truly idiomatic Scala code involves heavy use of advanced functional and…

more likely scala than clojure - i think a lot of the clojure community are there for the language, and see the jvm as incidental (or even an annoyance). newbie questions on the clojure mailing list are divided between "new to fp" and "new to the jvm ecosystem", and the clojure-in-clojure (with an eye on eventually targeting multiple platforms with a core layer) project has a lot of excitement around it.
Post reply on HN