Live data from Hacker News

Brand new Scala-lang.org

scala-lang.org

81–90 of 131 posts

Re: Brand new Scala-lang.org

#81
post #48
post #2

Nice to see the language page be as easy on the eyes as the language itself. There's almost no excuse not to use Scala if you're deploying on the JVM. On a related note, does anyone else see the Scala logo and confuse it for a symbol representing databases or hard disks? It just doesn't click with me

> There's almost no excuse not to use Scala if you're deploying on the JVM - Poor tool support (refactoring regularly broken on both IDEA and Eclipse). - Terrible backward compatibility story (want to use CoolLibrary v1.0, which was compiled with Scala 2.9 and you're using Scala 2.10? You're out of luck, you need the library to be compiled with the same version of the compiler). - Very slow compilations, and getting…

OK, so you work with Scala on personal projects, daily. The issues you bring up then are based on your own experience, and presumably not various postings on the net about Scala, fair enough.

So, what do you actually mean when you say, "The language is big (as big as C++) to the point where you must agree with your team on which subset to use"? Like you, I work in Scala daily and have never thought, shit, oh no, here we go again, the dreaded subset problem.

"It's so big that nobody can agree on which idioms actually to stick to: pure immutability? Functional style? OO only? Use scalaz or not?", use it exactly like Java...until you don't. Scala is not Python, there are many right ways to use the language.

The Scala-is-slow mantra is trance inducing, I agree, you just hear the phrase and voila, it's slow. Modular development (i.e. sub projects) largely mitigate the Scala-is-slow noise. Incremental builds are of course snappy, scalac and SBT have made great strides in this area, and SBT 0.13 furthers this trend (debunking the "getting worse at each version" nonsense).

According to Odersky Scala 2.11 will include [paraphrasing] aggressively stripping out unused/extraneous language features and improving compilation times.

Agreed on IDE support, it will come around, ScalaIDE has improved a ton during the past year (avoiding Juno helps).

I see the Scala glass as neither half full, nor half empty -- it's overflowing, future is bright ;-)

Re: Brand new Scala-lang.org

#82

The sbt site ( http://www.scala-sbt.org/ )is still impenetrable to anyone trying to understand wtf it does in under 15 minutes. (Why do I need this? How is it different than the scala compiler? Is it a package management system? Is it a REPL?)

You basically use it instead of Maven or Ant to build Scala/Java projects, but it's ridiculously comprehensive and extensive. I'm not sure calling it a mere "build tool" does it justice, more like "Recursive Extensible Project Management Tool" or something along those lines. And yes, it has both package management system and a REPL, among other things.

Re: Brand new Scala-lang.org

#83
post #46

Earlier quoted context omitted.

>but then Play as a framework looked very heavy for my usage. The terms "lightweight" and "heavyweight" and variants get thrown around alot describing frameworks, but can mean different things to different people: - size of framework codebase - size of app codebase - amount of code it takes to accomplish common tasks - memory footprint - deployment system - learning curve - feature list (barebones vs kitchen sink) et…

In my testing, I evaluated Play 2 (right on release), and Grails 2 (Groovy is nice). My thing is, Play seemed to do literally everything. I think it would be brilliant if I knew Scala well, but my problem is I dont even know Java! Ill use that as a segue: I had the same issue with Groovy/Grails -- great framework, nice language, but my lack of Java experience hasn't.made things as productive as I expected based on th…

Was in same boat as you 3 years ago, new to the JVM.

Started with a few pleasant months of pure Groovy, followed by 6 painful months with Grails (during the pre 2.x days). At that point I had my feet wet and realized that Groovy, as language, was not going to cut it (tried building a CRUD layer on top of Grails and Groovy's lack of static typing became a real thorn).

At the time James Strachan had ditched Groovy (the very language he had created, mind you) and was raving about the wonders of Scala. Interested I picked up the stairway book, Programming in Scala.

That changed my life as a programmer. Checked out Scalatra, Spray, Lift, and Play. Play wound up being the best fit.

I still get JIRA notifications for bug requests I created with Grails -- each one the devs just kick the can down the road (fix) to the next version, glad I left ;-)

Re: Brand new Scala-lang.org

#84
post #46

Earlier quoted context omitted.

>but then Play as a framework looked very heavy for my usage. The terms "lightweight" and "heavyweight" and variants get thrown around alot describing frameworks, but can mean different things to different people: - size of framework codebase - size of app codebase - amount of code it takes to accomplish common tasks - memory footprint - deployment system - learning curve - feature list (barebones vs kitchen sink) et…

In my testing, I evaluated Play 2 (right on release), and Grails 2 (Groovy is nice). My thing is, Play seemed to do literally everything. I think it would be brilliant if I knew Scala well, but my problem is I dont even know Java! Ill use that as a segue: I had the same issue with Groovy/Grails -- great framework, nice language, but my lack of Java experience hasn't.made things as productive as I expected based on th…

As hackerboos suggested, try Scalatra [1], the Sinatra of Scala frameworks (eg, simple, lightweight).

As for not knowing Java, there's not a whole lot of carryover from Java at the language level. There is at the JVM level obviously, but you can ignore JVM tuning and bytecode and whatnot till later.

In fact, I actually found learning Haskell to be more valuable than Java in understanding Scala. Learn You A Haskell [2] is one of the best general programming books I've read, Lipovaca is excellent at explaining complicated functional programming concepts.

[1]: http://scalatra.org/

[2]: http://learnyouahaskell.com/

Re: Brand new Scala-lang.org

#85
post #78
post #73

Earlier quoted context omitted.

I just think that dual goal is messy and not really a good goal. Can anyone comment on how possible it is to just ignore any OO stuff in Scala and just treat it like a normal statically typed functional language that happens to be on the JVM?

Why wouldn't you be able to? That's sort of what they're getting at when they say (if you follow the link) right under the headline: "Or anything in-between." Your discriminated unions would be "in drag" as case classes, of course. You would want to be aware of the OO parts of the language, but there's little that obligates you to use them.

I'm not sure, I haven't looked very deeply at the language, I'm not sure if most of the libraries and culture and such make use of OO, or if it's just baggage for Java interop.

Re: Brand new Scala-lang.org

#86
post #2

Nice to see the language page be as easy on the eyes as the language itself. There's almost no excuse not to use Scala if you're deploying on the JVM. On a related note, does anyone else see the Scala logo and confuse it for a symbol representing databases or hard disks? It just doesn't click with me

>> There's almost no excuse not to use Scala if you're deploying on the JVM.

The dev could be a lisper.

Re: Brand new Scala-lang.org

#87
post #73

Earlier quoted context omitted.

I just think that dual goal is messy and not really a good goal. Can anyone comment on how possible it is to just ignore any OO stuff in Scala and just treat it like a normal statically typed functional language that happens to be on the JVM?

Quite easy with a couple of caveats: 1. You don't care about working with java libraries. 2. You don't care about generating tons of memory overhead. Personally, if you don't have dependencies on java and if your goal is to do a pure functional application, I would stay away from the JVM as it just wasn't built for it.

I haven't had any trouble doing mostly pure FP with Clojure, as the general pattern is to wrap Java libraries to present a functional interface, I guess I'm curious if this is the attitude in Scala, or if you're sort of forced to embrace OO.

Re: Brand new Scala-lang.org

#88
post #46

Earlier quoted context omitted.

In my testing, I evaluated Play 2 (right on release), and Grails 2 (Groovy is nice). My thing is, Play seemed to do literally everything. I think it would be brilliant if I knew Scala well, but my problem is I dont even know Java! Ill use that as a segue: I had the same issue with Groovy/Grails -- great framework, nice language, but my lack of Java experience hasn't.made things as productive as I expected based on th…

Was in same boat as you 3 years ago, new to the JVM. Started with a few pleasant months of pure Groovy, followed by 6 painful months with Grails (during the pre 2.x days). At that point I had my feet wet and realized that Groovy, as language, was not going to cut it (tried building a CRUD layer on top of Grails and Groovy's lack of static typing became a real thorn). At the time James Strachan had ditched Groovy (the…

lol, now this is ironic, not having received a Grails JIRA notice in quite some time, after posting the above I checked my email and voila:

"Shared constraints not working in URL mappings Fix Version/s: 2.3-RC1 (struck through) Fix Version/s: 2.3-RC2 (the kicked can)" ;-)

Re: Brand new Scala-lang.org

#90
post #49

Earlier quoted context omitted.

Recruiter here, and unfortunately many companies still won't look at people without having specific language experience (and often a specific amount of language experience). I find this has traditionally been more true in the Java world, where I've had clients ask for x years of Java and > n years of a specific framework. I spent most of my 15 years working almost exclusively with Java shops that were often this spec…

I'm not a recruiter per se, but I have been recruiting. On the question " do Python shops hire non-Python programmers because they have to? ", from my experience the answer is Yes , but the reasons are twofold. On one hand, yes, it is harder to find Python developers and it makes no sense for a company to restrict itself to such a limited pool. On the other hand it is also a matter of culture - companies that use les…

Interesting points. A follow-up question for you regarding your belief in the focus on quantity over quality.

In your opinion, do you think that the perceived focus on quantity over quality is representative of the culture of some Java shops or a function of the Java language itself (a necessity for more programmers due to the nature of the language)?

I've run one of the larger Java Users' Groups in the US (Philadelphia) for over 13 years, but I keep a very open mind on things, and I have been critical of elements of the Java space in the past.

Post reply on HN