class scala[A] { def apply[B](f: (A) => B) = directly to forehead }

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > class scala[A] { def apply[B](f: (A) => B) = directly to forehead }

Tarion: Dec 1, 2014

After using scala for about a year...

The good:

1. for comprehensions definitely can make using futures for async programming nice.

The bad:

1. Linked List as the default data structure.
2. Implicits make reasoning about things hard.
3. Cake really should be called spaghetti.

The ugly:

1. 'return' statement.
2. Collections libraries.

Overall, my impression is that it's a nice research language that various people at big companies decided to use in production because it was cool rather than because it was ready.

# ¿ Dec 17, 2015 13:04

Adbot: ADBOT LOVES YOU

# ¿ May 13, 2024 05:02

Tarion: Dec 1, 2014

Asymmetrikon posted:

What's wrong with lists?

This is ultimately a great summary: http://cglab.ca/~abeinges/blah/too-many-lists/book/#an-obligatory-public-service-announcement

For me, it's mostly performance and the fact that working with non-linked sequences in scala just seems harder because every interface uses List, so I end up having to convert to a List anyways.

Cryolite posted:

Coming from C# where the List type is backed by an array (like ArrayList in Java) I know I was surprised to learn Scala's List is really a linked list. I expected a type named List to have the performance characteristics of an array-backed data structure.

For idiomatic Scala (immutable and functional) I guess it makes sense for it to be a linked list. It's just different and I have to change my thinking when going back and forth.

Idiomatic Scala is pseudo-functional. The fact that it's running on the JVM (and much of the time ends up needing to call Java code) and various other things make it way harder to actually benefit from the purity of functional programming, so I'm just left with poorly performing Lists everywhere.

Steve French posted:

You mean linked lists as the default ordered collection. I don't see that as much of a negative. It's quite easy to use something different if need be, though there are a lot of warts (hidden or otherwise) in the collections library. I still prefer it to any other language's standard collections though.

Implicits, if used excessively or improperly, can be tough, but it also enables some really great general patterns and simplifications if used well (see: typeclasses)

I agree about the cake pattern. Gave it a try, do not like it. I much prefer the gradual and pragmatic approach outlined here: http://di-in-scala.github.io/

What about the return statement? You don't like that it exists? (I rarely use/encounter it)

For what it is worth, I fully believe it is a production ready language, and use it as such. There are a lot of really high quality tools built with/for it. Finagle, in particular, I find to be excellent.

I've never seen that di link before, but that's basically what I did for a codebase I'm working on that I got to write from scratch. Much nicer.

And my point about production vs research language is more about the language than the tools and even more specifically about the design of the language and approach to it's design. The tools are fine.

# ¿ Dec 19, 2015 14:12

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > class scala[A] { def apply[B](f: (A) => B) = directly to forehead }