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…
Scala – 1 Star – Would Not Program Again
151–160 of 324 posts
Re: Scala – 1 Star – Would Not Program Again
#152Just 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.
Re: Scala – 1 Star – Would Not Program Again
#153Earlier 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.
Re: Scala – 1 Star – Would Not Program Again
#154> 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…
The last thing you want is to make the deployment harder.
Re: Scala – 1 Star – Would Not Program Again
#155I'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.
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
#156Earlier 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…
Re: Scala – 1 Star – Would Not Program Again
#157Earlier 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 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
#158Earlier 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…
(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
#159Earlier 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
Re: Scala – 1 Star – Would Not Program Again
#160I'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…
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.