Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Note that although many prominent Scala people program in a very Haskelly style, mutable variables are significantly more idiomatic/first-class in Scala than they are in Haskell.


I agree.

The fact that Scala is proper multi-paradigm, and has a first-class functional sublanguage as well as a first-class imperative sublanguage is part of its great appeal.

I have mentored quite a few people over the last couple of years in Scala. In my experience, going from imperative Java, C, Python straight to Scalaz/Typelevel/higher-kinded monad style pure functional programming never works, and drives Scala-beginners away.

What works extremely well is to start with Scala as a nice Java without semicolons, and then, as they become more proficient in the OO/imperative Scala fragment, gradually to introduce more advanced features, starting with case classes.

The reputation Scala has for being too difficult comes from certain parts of the Scala elite trying to convince everybody, including beginners, that higher-kinded purely functional Scala is the only way to use the language. Nothing wrong with this style of programming per se and it's great that people are pushing the envelope, but the conceptual gap is too big for a language learner hailing from the imperative world (which is most of them).


Oh I'm sure that's true, but as a recovering Python programmer I'm uncomfortable with justifications of mutability under any except the most extreme circumstances. ("In our codebase we avoid writing side effecting code", my colleagues said, whilst filling the codebase with side effecting code.)


This, too, will pass. Mutability is fine, if isolated and carefully accounted for. However, to understand when it's fine and when it isn't, you have to bring years of experience both in imperative and functional world.


I just sidestepped the issue by becoming a Haskell programmer and I'm glad I no longer have to deplete my judgement by making those kind of decisions :)


There's value in that, sure. But when programming one is generally modeling a business process, and some of those processes really are easiest to understand by thinking in terms of a thing that changes. So it's nice to have a programming language that lets you talk about things that change in a natural way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: