Live data from Hacker News

Scala – 1 Star – Would Not Program Again

overwatering.org

81–90 of 324 posts

Re: Scala – 1 Star – Would Not Program Again

#81

I tried learning Clojure, I really did, and I have to agree, the syntax is simpler, but I can't really read Clojure or code in Clojure the way I do in Scala, I don't know why. Whenever I read articles about Scala, I keep finding it amusing, prehaps this is because I had experience with Java, but for me Scala is a life saver, can't go back to Java after this. And I won't go back to Ruby, Python or JavaScript. So I can…

This times 1000. I have been using Scala for the past 3 months in a play framework app that serves json. Today I had to write some quick Java for an Android client, and was quickly reminded how much freedom Scala's expressiveness gives you vs Java old cruft.

I mistakenly wrote a Java anonymous inner class that called a closed over variable from the outer scope like one would do with Scala closures. Of course the Java compiler threw an error because I didn't mark the variable as final.

When programing in Scala, one never has to deal with such low level rigidness. It just let's you get shit done.

Re: Scala – 1 Star – Would Not Program Again

#82

The section on HTTP headers and typing is a little concerning to me. I've been making rust-http recently and (before I was aware of Spray) I felt strongly about the typing. So, I'd like to discuss this. Am I wrong after all? Here clearly is someone that disagrees with me. I think I should probably write up a long blog post on the topic explaining my reasoning and so forth. rust-http is, at present at least, rejecting…

But what practical problem is such a scheme actually solving? If I write

    response["headre"] = ...
I have a bug, sure, but an obvious bug that will be fixed very quickly. With this type system I am now limited in an annoying way. I don't get it.

Re: Scala – 1 Star – Would Not Program Again

#83
post #62
post #30

Earlier quoted context omitted.

Honestly I haven't used Ring/Compojure/Enlive beyond tutorials so at this point I'm very intrigued but don't have much to say yet. My belief though is that there is some peace of mind that comes from the idea of what you might call "page composition" -- that this piece of data sits in this template, that it rides on top of this simple model, that it is in ORM from database. There is a huge amount of linearity and con…

> My belief though is that there is some peace of mind that comes from the > idea of what you might call "page composition" -- that this piece of data > sits in this template, that it rides on top of this simple model, that it > is in ORM from database. There is a huge amount of linearity and convention > throughout the stack and because of the dynamic nature of Ruby lots of gems > can be sprinkled throughout without…

thanks for your input. I see what you're saying about the Closure namespaces and function system making more sense. That's what has been attracting me toward it, along with some general fondness for the elegance of Clojure.

I feel you whole-heartedly about the tangled web of OO. That's why I ultimately chose to leave Rails & start pursuing JVM languages. JVM languages seem to be daunting to Rails/Django folks because of all the "boilerplate, syntax, complexity" but I've found that a lot of the tools are so mature that it is not really such a burden. So yes, as an aspiring programmer who wants to have a reach beyond CRUD, the mystery of Rails & it's "fugly" libs eventually turned me off. Aside from things breaking/slowingdown with every version and needing excessive optimization not to accumulate at the interpreter, I came to the realization that the extra time that would be needed to understand more technologies for the different layers of the application (with Java.... Spring/Hibernate/etc.) there is a gain in that well... you actually understand what is going on rather than this tangled mess. I often had to re-factor code in Rails to kindof fit awkwardly between gems. From studying Javascript I learned a lot about asynchronous/aspect-oriented programming and am pleased to see that these concurrency issues are fundamental to most work that is happening on the JVM. I thought Scala/Play was a healthy medium between these two worlds but I'm starting to understand that maybe one needn't compromise.

Re: Scala – 1 Star – Would Not Program Again

#85

Problem: author is pining for Go, and doesn't know it. Solution: author should abandon the JVM ecosystem and use Go. - Fast compiles. - Ultra simple, non extensible syntax, yet not verbose in practise. - The code you see is 100% of the code. - A culture of implementing the simple algorithm. - Stable, with version compatibility guarantees. - Nobody is trying to make the types jump through hoops, so the type inference…

It's hard to take your comment with impartiality when 90% of your comments mention Go.

Re: Scala – 1 Star – Would Not Program Again

#86

The section on HTTP headers and typing is a little concerning to me. I've been making rust-http recently and (before I was aware of Spray) I felt strongly about the typing. So, I'd like to discuss this. Am I wrong after all? Here clearly is someone that disagrees with me. I think I should probably write up a long blog post on the topic explaining my reasoning and so forth. rust-http is, at present at least, rejecting…

I'm with you, in favor of strongly typed headers. Working with strings can be very error-prone; you might not catch typo bugs until your system is in production and handling some rare case for which failure is expensive.

It seems to me that, in the worst case, the downside of your current scheme is an extra field dereference, as in `request.headers.extensions.get("crazyNewField")` instead of `request.headers.get("crazyNewField")`. I think that cost is easily outweighed by the benefits.

Re: Scala – 1 Star – Would Not Program Again

#87
post #81

I tried learning Clojure, I really did, and I have to agree, the syntax is simpler, but I can't really read Clojure or code in Clojure the way I do in Scala, I don't know why. Whenever I read articles about Scala, I keep finding it amusing, prehaps this is because I had experience with Java, but for me Scala is a life saver, can't go back to Java after this. And I won't go back to Ruby, Python or JavaScript. So I can…

This times 1000. I have been using Scala for the past 3 months in a play framework app that serves json. Today I had to write some quick Java for an Android client, and was quickly reminded how much freedom Scala's expressiveness gives you vs Java old cruft. I mistakenly wrote a Java anonymous inner class that called a closed over variable from the outer scope like one would do with Scala closures. Of course the Java…

Well, be careful with those closures. Scala's compiler won't (yet) throw an error if you close over a variable from the outer scope while operating on a Future.

The Scala team does have a plan to fix this though. Of course, if you aren't operating asynchronously or you're only closing over immutable values it doesn't matter anyways.

Re: Scala – 1 Star – Would Not Program Again

#88

I'd say a lot of the critiques are fair but quite exaggerated. I work on a large Scala codebase and yes, the compile times for a fresh start across the codebase are very long, but TDD-type loops are very short, because you're generally waiting for two files (your test target and your test code). Still, the compiler performance in Scala is perhaps my chief criticism, though hardly a show-stopper. As codebases in any l…

Hey, this is one of the best comments I've ever read on HN. You should consider adapting this and some of your other comments into independent blog posts.

Re: Scala – 1 Star – Would Not Program Again

#89
Question - the job/hiring post on hen for November has many positions for clojure and one definitively for Scala. Here, I see references to investment banks using scala.

Has scala become a readable alternative to java, while most of the future focus is on clojure? Does anyone know how real life performance compares between both.

From my viewpoint, scala is in use at several banks and Twitter - clojure doesn't really have a big name advocate behind it. From a startup standpoint, isn't talent/hiring an issue?

Post reply on HN