Live data from Hacker News

Scala – 1 Star – Would Not Program Again

overwatering.org

271–280 of 324 posts

Re: Scala – 1 Star – Would Not Program Again

#271
post #238

Earlier quoted context omitted.

>I have a bug, sure, but an obvious bug that will be fixed very quickly I love that there are people who say things like this totally seriously.

I'm not sure what you've done to make you feel like being condescending is something you have earned, but please feel free to share your body of work. I've worked on very large, complex, mission critical systems my entire career. Medical devices mostly. If you're not catching these sorts of errors early then you aren't modeling and testing your software correctly (or at all). All of the objects in the world aren't go…

What an odd response. I haven't done any OO programming in nearly a decade, and I would not consider doing it ever again. I don't know where you got the idea that OO has anything to do with this. I do catch these sorts of errors early on, because they are type errors, and thus the compiler catches them. That is very much the point. The fact that you think you are infallible and can write 100% perfect test coverage, while thinking I am being condescending is pretty hilarious.

Re: Scala – 1 Star – Would Not Program Again

#272

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…

People think I am pining for go too, for similar reasons. Yet I tried very hard to like go, and was unable to put up with such a primitive language just for the nice tooling. Not everything is a "you just need to use go" in disguise.

Re: Scala – 1 Star – Would Not Program Again

#273
post #27

I'm always interested to see intelligent criticisms of one of my choice languages. Let's take a look at what he has to say: Slow build times complaint > It is essentially impossible to practice TDD in Scala simply due to the time it takes to compile. Hrmm, that's interesting, because it sure seems like other people are able to do this. I agree, the slow build times are annoying, but let's not exaggerate. SBT critique…

>Maybe if this guy had cared enough to do a five second google he'd realize that Scala doesn't use hindley-milner type inference.

That's his point. Scala doesn't use HM and it needs to. He says the reason it doesn't is because of the JVM, which seems misguided.

Re: Scala – 1 Star – Would Not Program Again

#274

Scala after 2 weeks = 1 star Scala after 2 months = 3 star Scala after 6 months = 5 star Show me a statically typed language on the JVM that trumps Scala -- it doesn't exist. Show me an ecosystem in that statically JVM based language that trumps that of Scala (Akka, Play, Slick, sqltyped, Squeryl, Spray, Scalatra, Lift, Blue Eyes, Unfiltered, etc., etc.) Yes, compile times are a hassle (for deployment that is, increm…

I had the opposite experience. I went into scala very optimistic, and initially would have rated it 4 star to stick with your rating approach. But after a month it was down to 3, then another month it was down to 2 and we were investigating alternatives.

Re: Scala – 1 Star – Would Not Program Again

#275
post #271

Earlier quoted context omitted.

I'm not sure what you've done to make you feel like being condescending is something you have earned, but please feel free to share your body of work. I've worked on very large, complex, mission critical systems my entire career. Medical devices mostly. If you're not catching these sorts of errors early then you aren't modeling and testing your software correctly (or at all). All of the objects in the world aren't go…

What an odd response. I haven't done any OO programming in nearly a decade, and I would not consider doing it ever again. I don't know where you got the idea that OO has anything to do with this. I do catch these sorts of errors early on, because they are type errors, and thus the compiler catches them. That is very much the point. The fact that you think you are infallible and can write 100% perfect test coverage, w…

Not odd at all; you were being condescending, trying to paint me as someone who isn't as good a programmer as you are. Maybe I'm not, but I've written some very robust systems code in my career, so don't be so quick to write people off.

I don't think I'm infallible (straw man much?), but I do think that dead simple errors such as this would be caught by any amount of actual testing. That said, I wouldn't be against a better design. Why doesn't this library provide a way to add arbitrary headers? Oh, right, that would still involve using a string. Gasp, no, that shouldn't be allowed. We have to protect the poor users of our library. Yeesh.

You can't always protect a programmer from themselves while still allowing the flexibility/power needed to get shit done. I'd rather use the map than some overly architected and frustrating library. I have a problem with abstractions that get in my way.

Re: Scala – 1 Star – Would Not Program Again

#276
post #238

Earlier quoted context omitted.

>I have a bug, sure, but an obvious bug that will be fixed very quickly I love that there are people who say things like this totally seriously.

I'm not sure what you've done to make you feel like being condescending is something you have earned, but please feel free to share your body of work. I've worked on very large, complex, mission critical systems my entire career. Medical devices mostly. If you're not catching these sorts of errors early then you aren't modeling and testing your software correctly (or at all). All of the objects in the world aren't go…

Why not use every tool at your disposal that can catch bugs early? Static typing does that. Sure, you can catch bugs later with testing, but why not take advantage of automated tools (i.e. the compiler)? That's one less test you have to write.

Re: Scala – 1 Star – Would Not Program Again

#277
I think that many of these criticisms, while perhaps valid in some ways, are unfair. Why single out Scala, when other, more popular languages have these same issues? The intent of this post seems to be to discourage using Scala on any project again, but it is difficult for me to discern the proposed alternative. Is it Haskell? A fine language, but seems to lack the tools that even Scala has, and it's not on the JVM. Is it JavaScript? Java? I'm not sure which comparisons to make. So to address each point:

The compile times criticism is probably one of the more valid ones. Was incremental compilation enabled in Gradle, though? It was only specified that daemon mode was used.

The libraries and community criticism, I think, is completely unfair. There are lemons in every community. Part of getting to know an ecosystem is learning the parts you don't like. For example, I don't think that anyone should attack the entire Java ecosystem simply because Java EE with its EJBs exists, or because Struts exists, or WebSphere.

Is the magic syntax criticism specific to Spray and SBT? But I thought that Gradle was the build system, and that's in Groovy. I'm a bit confused, here. Again I think this is about picking libraries you find readable, and again I think it is not fair to judge an entire ecosystem because of one or two bad library choices.

The HTTP header criticism...is this about Spray again?

Not using Scala because it doesn't have Hindley-Milner type inference is not fair, either. This seems like an unusual standard for which to hold any language, really. Is it only ML languages like Haskell that have this?

Really I'm not sure why any or all of these would make Scala an inaccessible language, or even what inaccessible means in this context. Is it simply that Scala has too many language features? So should we all go back to BASIC? Or is Java the answer? But wait, Java is adding more language features, too! Where do we draw the line? In the Java world, there are so many libraries that provide the functionality that Scala has baked in. Are using third-party libraries such as Guava, Project Lombok, and LambdaJ really preferable to using Scala?

I definitely agree that you can make code unreadable by using too many language features or libraries, but it should be agreed upon what the best practices are for a project between its developers. For instance, on a Java project, everyone might be using JUnit and Mockito for unit testing. Then one day, a single developer decides he wants to introduce PowerMock or something, instead. His pairing partner could explain to him why this is a bad idea; or it could be rejected in a code review or similar. The same idea holds for Scala, I think. If not everyone understands something like implicit types, they should be avoided.

Re: Scala – 1 Star – Would Not Program Again

#278
post #202

Earlier quoted context omitted.

Hobby wise: Haskell, Rust, Nimrod, Haxe Shipping code: Go, Erlang, C++11 (avoiding legacy), F# (with Xamarin) I program in many more, but those are probably my top 8 right now.

You never work with scripting languages? (i.e., why is there no Python, Ruby or Javascript in your lists? or maybe I do'nt know Haxe, does that replace them?)

Most of the stuff I work on is highly concurrent. GILs are the devil. Almost all the joy and ease you from GIL languages is lost as you try to go concurrent and have to use (in python for example) multiprocess and gevent ... then you start getting caught on the rough edges and poor ideas in those tools... and everything falls apart.

Re: Scala – 1 Star – Would Not Program Again

#279
Having used Scala for over a year, I can say it is a mixed blessing for me.

On the one hand it's an improvement over the verbosity and rigidity of Java. And often it is fun to write in (lots of clever tricks you can use and feel good about... until you have to come back to the code several months later).

On the other hand, I absolutely hate to dig into Scala code written by others. To me it feels like C++ all over again. There are so many concepts in the language that more often than not you find your knowledge of the language lacking, and have to put the task at hand on hold to brush up on your Scala skills. If there are more than a couple of (Scala loving) codevelopers on the project, you end up spending more time learning about the language than actually using it.

So, to sum it up: I would use Scala if I absolutely had to use JVM and I had control over the the subset of the language used in the codebase. Otherwise, I'd pick something else. Thankfully, there are saner alternatives to JVM these days when it comes to high level/static typing/high performance (e.g. Go).

Re: Scala – 1 Star – Would Not Program Again

#280
post #273
post #27

I'm always interested to see intelligent criticisms of one of my choice languages. Let's take a look at what he has to say: Slow build times complaint > It is essentially impossible to practice TDD in Scala simply due to the time it takes to compile. Hrmm, that's interesting, because it sure seems like other people are able to do this. I agree, the slow build times are annoying, but let's not exaggerate. SBT critique…

>Maybe if this guy had cared enough to do a five second google he'd realize that Scala doesn't use hindley-milner type inference. That's his point. Scala doesn't use HM and it needs to. He says the reason it doesn't is because of the JVM, which seems misguided.

He states that H-M is not used because of the lack of reified generics, which is completely irrelevant. (Hint: type systems perform analysis at compile time; "reified generics" means having type arguments available at run-time.) H-M is not used because it is not compatible with subtyping or method overloading, which are both critical for Java interop. There is no particular reason that Scala needs to use exactly the H-M system.
Post reply on HN