Live data from Hacker News

Scala – 1 Star – Would Not Program Again

overwatering.org

151–160 of 324 posts

Re: Scala – 1 Star – Would Not Program Again

#151

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…

If you hadn't mentioned Go, you could have described Java with these bullet points (with the exception of the last). Why throw away all the proven libraries, extremely good garbage collector, IDEs, intrumentation? Java is a perfectly fine language and if you think it is too verbose, there are good other options such as Kotlin, Groovy (which offers static typing nowadays), Ceylon etc.

Re: Scala – 1 Star – Would Not Program Again

#152
post #34
post #7

Just shut up and use Java. It's fine.

I don't think it is. There are reasons people are working hard to avoid it, and it's not just 'shiny-new-thing' syndrome.

Except that a huge chunk of the industry outside the Hacker News, Reddit, and start-up bubble is using Java or C#. In fact, I have many CS and AI graduates as friends, who love programming in the Java ecosystem.

Re: Scala – 1 Star – Would Not Program Again

#153

Earlier quoted context omitted.

Having never used Scala before, does its type system provide details about errors that other languages do not? Watching a compile fail because of an incorrect type is not something I have run into very often, if ever, in other languages that provide similar type systems. I mean mistakes can happen and if the type system can catch it for free, so to speak, that is great. I'm not about to argue that it is completely us…

In Haskell, and I assume Scala, you can name types of the same form, so I might say a TimeSeries is a list of floating point values. If I use that data type, you can't accidentally pass a different kind of list of floating points even though they're the same type.

Yes, you can do this in scala with type aliases

Re: Scala – 1 Star – Would Not Program Again

#154
post #97

> This issue reached its pinnacle for us when we were unable to figure out how to replicate the magic response composition syntax used by Spray to abstract away the addition of CORS headers to HTTP responses. I'd just put any kind of application, whether built in Scala, node.js or Go or ruby on rails behind a nginx proxy and use that for setting the headers. That simplifies a lot of things. I hope your HTTP headers a…

Say you are building a redistributable app with Javascript clients. People will deploy in behind Ngnix, Apache, IISm ad sometimes with nothing at all.

The last thing you want is to make the deployment harder.

Re: Scala – 1 Star – Would Not Program Again

#155

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…

Languages like Ruby and Python allow for expressive, high-level customization, metaprogramming, and DSL creation. However, especially in the latter, the potential chaos is curbed by a strong culture and encouragement of self restraint, readability, and simplicity. From the sound of it, this is not so true for Scala.

Scala is pulling out of that phase. Scalaz 7 removes a lot of the less-readable operators (e.g. you now have to write "Kleisli" rather than "☆"). The Requests HTTP library, long mocked for its periodic table of operators, has fallen out of favour (I'm not sure it's even maintained any more).

I can't speak for SBT because I don't use it, but Spray is probably the nicest library for defining HTTP APIs I've ever used, in any language. As for type inference, yes it's imperfect, and maybe disappointing for someone used to Haskell, but coming from Python I found the set of type annotations I needed to add to make my Scala compile was a subset of the ones I wanted to document anyway.

Re: Scala – 1 Star – Would Not Program Again

#156
post #133

Earlier quoted context omitted.

> But because the plumbing must be laid out so meticulously and in every situation, it is often hard to see how things work at a high level. You can't see an architectural sketch in Java, you can only see endless classes in endlessly nested subdirectories. This is a very low level of abstraction, and helps the layperson (such as someone approaching a new open source project) build up an understanding from the base el…

> The only real outlier being Javascript which gets its popularity from being the only option for the browser. This is probably the reason for Javascript's popularity, but if you ignore some bad language design, Javascript is a very simple language with a very small number of concepts that you need to understand to start getting work done in it. Even Python (which I think is the simplest of the widely used dynamic la…

That doesn't qualify as simple in my book though. Javascript has fewer concepts that programmers need to keep in their heads, but they are horribly inconsistent and quirky. Python, on the other hand, is consistently designed so that there are very few cases where you get hit with unexpected behavior.

Re: Scala – 1 Star – Would Not Program Again

#157
post #23

Earlier quoted context omitted.

I'll echo all of this (minus scalaz, we don't use that). I'll give an example of the power of Scala's type system. When I first convinced one of our founders to give Scala a try, he used it to write the first pass of our analytics service. He'd never written Scala before but once it compiled, it ran correctly on the first try, that's the power of its type system.

Having never used Scala before, does its type system provide details about errors that other languages do not? Watching a compile fail because of an incorrect type is not something I have run into very often, if ever, in other languages that provide similar type systems. I mean mistakes can happen and if the type system can catch it for free, so to speak, that is great. I'm not about to argue that it is completely us…

A simple example: consider scalaz's NonEmptyList[T] class, which turns a failure to populate a list into a compile error rather than a runtime error.

A more complicated example. In one scala system I worked on we had a master/slave postgres db system. We were replacing a legacy RoR system with a Scala system, and in the RoR system there were all sorts of data inconsistency errors caused by people writing to master and reading from the slaves before replication occurred.

In the Scala system which replaced it, we set up a monadic action system. A function which hit the database would have a type signature either PReader[T] or PWriter[T] - this was the only way to access a java.sql.Connection short of manually calling jdbc. Combining the two forms yields a PWriter:

    for {
      _ 
The whole operation runs in a single transaction against the correct database, and any attempt to do the wrong thing is a compile error.

Re: Scala – 1 Star – Would Not Program Again

#158
post #23

Earlier quoted context omitted.

I'll echo all of this (minus scalaz, we don't use that). I'll give an example of the power of Scala's type system. When I first convinced one of our founders to give Scala a try, he used it to write the first pass of our analytics service. He'd never written Scala before but once it compiled, it ran correctly on the first try, that's the power of its type system.

Having never used Scala before, does its type system provide details about errors that other languages do not? Watching a compile fail because of an incorrect type is not something I have run into very often, if ever, in other languages that provide similar type systems. I mean mistakes can happen and if the type system can catch it for free, so to speak, that is great. I'm not about to argue that it is completely us…

It's partly culture; Scala makes types that little bit easier to use (e.g. case classes, type inference), so things that you might pass as an untyped Map[String, Object] in other languages, you tend to pass as a case class instead. e.g. using spray in scala, the type system will catch if you misspell a HTTP header, because, as the article complains about, they're represented as types.

(Though of course there is an escape hatch, you can use RawHeader(name, value) if you need to).

Re: Scala – 1 Star – Would Not Program Again

#159

Earlier quoted context omitted.

In Haskell, and I assume Scala, you can name types of the same form, so I might say a TimeSeries is a list of floating point values. If I use that data type, you can't accidentally pass a different kind of list of floating points even though they're the same type.

Yes, you can do this in scala with type aliases

Type aliases don't solve that problem. You need to use something like Shapeless' newtype.

Re: Scala – 1 Star – Would Not Program Again

#160

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…

When I read about Scala the first time I felt it was awesome! I bought some books and tried to get into it.

But when I read production code it was aweful because of all the DSLs.

Scala does much to reduce code to whats necessary, like python, but there is so much more that it does, which confuses the code readability later :\

The DSLs also lead to bad API design.

The devs are always like "uhuuu if you don't like the DSL just use the normal functions" and write the horrible DSL stuff without the DSL.

(asd ~! fdd %%% sdasd) gets to asd.doSomethingRatherComplicated( with( fdd ) ).alsoGetSomeStrange( sdasd.compile() )

It looks like they are using the ability to build "easy" DSLs as excuse for bad API-design.

Post reply on HN