
Five years of Scala and counting: debunking some myths - logician_insa
http://manuel.bernhardt.io/2015/11/13/5-years-of-scala-and-counting-debunking-some-myths-about-the-language-and-its-environment/
======
leothekim
Although I agree with most of what the author says here about scala and its
benefits and features, this is hardly a debunking and more of a strongly
opinionated defense. Some of the arguments are along the lines of "hey SBT
isn't just a bunch of symbols" or "I upgraded my MacBook and compilation times
are not a problem" or "tooling is better now". Reassurances yes, debunking
hardly.

Scala compilation time is probably the worst problem I have with scala, and it
still is frankly. I have seen no evidence that this has improved from personal
experience and after talking with devs I know working in large scala code
bases (Foursquare, Twitter).

Even if there are speed improvements in the scala compiler in future versions,
the author doesn't address binary incompatibility between major scala versions
either which, along with slow compilation times, makes it a serious PITA to
upgrade to a scala version that might actually compiler faster.

[edit] hit submit too early last time, re-edited after regathering my
thoughts.

~~~
bad_user
Scala developers end up on the defensive because many of the claims are either
because of misunderstandings or are fashion driven, being repeated ad-nauseam
many times by people with only a superficial experience of the language.

For example I'm going to make the claim that SBT indeed isn't just a bunch of
symbols, but rather one of the best build management tools in existence. For
anybody going to challenge that I'm going to start mentioning the complete
clusterfuck of other platforms and languages, like that of C/C++, or that of
Python, or that of Javascript, or that of C#/.NET, or that of Haskell. SBT not
only does demonstrably a better job than most, but works well out of the box
and is relatively pain free. It has its own set of problems of course, but
what tool doesn't.

Compatibility issues are real. But you know, the nice thing about those
compatibility issues is that it forced the community to come up with
solutions. At least Scala and SBT are addressing compatibility issues, whereas
the transition from Java 6 to later versions is proving to be next to
impossible and I don't think I have to mention Python 3 or ECMAScript 6.

Compilation times haven't been that much of an issue for us because our
codebase is split into services and libraries that have a reasonable size. And
on the switch from Scala 2.10 to 2.11 I definitely saw an improvement, with
the claims of 30% being about right.

I do agree that they can do better, taking a look at similar languages with a
slightly better story, like Haskell. However what people are usually missing
is that this is usually a trade-off with compile-time safety.

The more static a language is, the harder it is to compile it. The compilation
cost for a dynamic language like Javascript is zero, the cost being completely
amortized with everything happening directly at runtime. When going from
Javascript to Java or C#, for people that prefer Java or C#, people go from
zero to a very noticeable and resource intensive AOT compilation step and many
times this tradeoff is worth it (depending on whom you ask) for safety,
performance or tooling reasons. Well, Scala is a more static language than
Java, it infers a lot of things, it has better generics, it does implicits
which can then model type-classes and even the infamous CanBuildFrom pattern
and so on, giving you a nice balance between productivity and safety in a
static language. And that doesn't come for free.

~~~
diek
> whereas the transition from Java 6 to later versions is proving to be next
> to impossible

I've never heard of anyone having issues going from Java 6 to later versions,
at the language level or JVM level.

~~~
pjmlp
Android?

Without community hacks.

~~~
oblio
Yes, but is that because of Java compatibility (which has been generally
exemplary) or maybe because of other issues (I'm thinking of Oracle vs
Google)?

~~~
pjmlp
First it starts by Google playing cheap and doing a Microsoft move on Sun.

Before I get the usual Sun CEO approved it reply:

[http://nighthacks.com/roller/jag/entry/my_attitude_on_oracle...](http://nighthacks.com/roller/jag/entry/my_attitude_on_oracle_v)

Second, at least on lambdas they could generate inner classes for older
devices and update DEX format now that Dex is compiled AOT to native code. So
only the compiler dex2aot would be required to be updated.

Currently there is zero public feedback on the new compiler chain (Jack &
Jill), but from the sources it appears it is Java 6.5 all the way.

They have some unit tests that appear to be related to Java 8, but no one
knows what is their idea.

In a few years (by Java 10 timeframe), according to the actual roadmap which
might still change, Java will have modules, a JNI replacement, reifeid
generics, value types, new array type, GPGPU support, AOT compiler....

If nothing changes, assuming Android 4.4 devices will be gone, the only change
will be from Java 6.5 to Java 7, if Android's team attitude is to stay like it
currently is.

But at least they spend time doing those stupid devbytes videos, doing
continuous buggy releases of the support library and Google services.

Android Java is definitely the second coming of J++/J#.

~~~
Scarbutt
_AOT compiler...._

Compiler to native code? aren't the big performance gains done in the JVM?

~~~
pjmlp
Not if startup time matters or if you need to deploy into systems where
dynamic linking is not possible.

The majority of the commercial third party JVM vendors do offer AOT as part of
their toolchain.

Similarly .NET always had a JIT/AOT model. The novelty with .NET Native is
static compilation and integration of the Visual C++ backend.

I don't if this is true, but I read somewhere that AOT was tabu at Sun.

Oracle is now improving Java to cover the use cases where it still fails short
vs other alternatives, so having an AOT compiler in the reference JDK instead
of forcing devs to get it from a third party is part of their roadmap.

How it will look like in the end, it is not 100% clear.

------
jinst8gmi
I've been using Scala primarily for a few years now after using Java since the
90's. Well written Scala code is much more pleasant to write and maintain than
Java (true even for JDK 8). Scala's feature set is great, but you need to have
good taste to use it effectively. It's a bit like the gang of four design
patterns which some developers, especially Java developers, go looking for
places to apply as many of them as possible. Rather consider where the
features add value - they are _very_ useful when used appropriately. When used
sensibly Scala is amazing. You just have to keep an eye on the new guys so
that they don't just use advanced features all over the place where they
aren't appropriate. Fortunately that type of behaviour isn't that common but
does feed the Scala is complex meme. After a few years with Scala I consider
my time spent primarily with Java as lost years.

~~~
yashap
Agreed, love Scala, and I think it can lead to super maintainable code bases,
but you do have to be careful. The worst offence is probably when people start
to get comfortable with implicits, and start throwing them everywhere,
definitely need a good code review process to stop that.

Also, the article left out probably my two favourite parts about Scala -
awesome language level support for concurrency, and pattern matching. Whenever
I go to languages without these features, I really miss them.

------
joslin01
Scala is my favorite language at the moment. I've used (professionally) Java,
C#, Perl, Python, Ruby, Objective-C, and Swift. I played with Go and started
writing a simple library
([https://github.com/joslinm/validate](https://github.com/joslinm/validate))
to get acquainted with it.

Above all else, what always gets to me with Scala is its powerful generics. It
truly is first-class. I'm excited for macros as well.

~~~
edgyswingset
As someone interested in Scala but _barely_ having used it, how do Scala's
generics differ from C#'s reified generics? I've always found it difficult
using generics on the JVM in comparison to the CLR because of boxing. I did a
preliminary search but couldn't really find a good comparison between C# and
Scala generics that was up to date.

~~~
runT1ME
Scala has higher kinded types (or, generics over generics). This is amazing
(but can take a while to see why/get confortable with). .NET doesn't have this
feature.

~~~
edgyswingset
Thanks, this is what I was hoping someone would write!

I searched around a bit about HKT's and although I can't say I understand
them, I can see how the ability to do something like provide a constructor
over a type could be useful. It feels like it has a lot of use in writing very
general-purpose libraries, or perhaps a DSL that can map to a wide variety of
different types. Interesting!

------
k__
> Scala has so many complex features

I think operator overloading and implicit conversions are the biggest problem.

You look at Scala code and first don't get anything because it's full of
library specific symbols.

Then these implicit conversions mangle your objects behind your back and you
don't even know what's happening at run time.

I like the ideas behind these features, but as a beginner, they always scared
me away after looking into "production code" :\

~~~
dudul
Implicit conversions are now considered an anti-pattern and not recommended.

~~~
the_af
Is "Pimp my Library", as used to be recommended by Odersky, also an anti-
pattern now? It uses implicit conversions, if I'm not mistaken.

~~~
sjrd
No, Pimp my Library is not an anti-pattern. It even received dedicated syntax
with `implicit class`es. Contrary to general implicit conversions, implicit
classes are not dangerous because things are not actually _converted_ as far
as the developer can see (yes, under the hood, it's an implicit conversion,
but it doesn't bite you). You're simply adding methods on existing classes,
which is similar to extension methods in several other languages.

~~~
wtetzner
And in fact, if you combine implicit classes with values classes (e.g.
implicit class RichFoo(val value: Foo) extends AnyVal { ... }) then you're
effectively just adding extension methods, and there's not even an allocation
involved.

------
phamilton
I find that Scala is pretty successful if you are already a seasoned Java
developer. Coming from other ecosystems, simple questions like "How do I use
an execution context other than the global one?" are answered in terms of
established Java practices. ("Just call this with an Executor.") And down the
rabbit hole you must go. That plus a ton of leaky abstractions (also requiring
a knowledge of standard Java practices) has been a big source of frustration
for me. But I suppose that if you were already dealing with these quirks in
Java, Scala is a nice improvement.

~~~
muraiki
This was one of my largest barriers in learning Scala. It seems that one needs
to learn Java first because you're going to have to understand how it and
Scala interact at some point.

------
jcadam
I really don't foresee any of these alternative JVM languages getting much
traction in my industry (Defense/Aerospace).

I use Scala where I can at work (mostly smaller projects where I am the only
developer and can thus get away with it), but every place I've worked over the
last few years has been staffed with developers who are actively hostile to
the thought of using any language other than Java. And right now, Java is king
in the Defense industry. It's the new Ada, except I'd rather be coding in Ada
than Java.

On my own side projects, I don't use Scala, because I would never choose to
target the JVM for greenfield development. But that's just me.

~~~
Irish
european space agency is/was actively hiring scala devs specifically

~~~
pjmlp
Yep,

[https://ileriseviye.wordpress.com/2014/12/22/how-and-why-
is-...](https://ileriseviye.wordpress.com/2014/12/22/how-and-why-is-scala-
used-in-aerospace-industry/)

------
eranation
Using Scala for about 5 years after being a Java dev for another 5 years. This
post captures my view pretty accurately as well. Including book
recommendations. I want to believe that most software engineers don't avoid
checking scala just because of some "one star" post about it or other rants.

~~~
oelang
I would add 'Scala in depth' to the book recommendations, it's similar to
'Effective java', the book you need after you have used the language for more
than one year.

------
kod
As far as books go, Scala for the Impatient is one of the few I'd recommend.
The first half of it is available for free

[https://www.typesafe.com/resources/e-book/scala-for-the-
impa...](https://www.typesafe.com/resources/e-book/scala-for-the-impatient)

------
kafkaesq
_But seriously now: don’t let yourself be scared off by “category type theory”
and other fancy-sounding words. You do not need all of this theoretical
background in order to learn and become a fluent Scala developer. I know,
because I have not bothered to look at those things until 4 years with the
language. And when I did it’s not like I had an epiphany, throwing out all the
code I had written until then. In fact, I was monading all over the place,
just had no idea how the things I was building and using were called._

Works for the author, I suppose. Me, I'd prefer to have a solid grasp of the
abstractions I'm using -- and an equally solid understanding of how the
programming constructs I'm using correspond to those abstractions -- before
using them to crank out production code.

~~~
whateveracct
Here's an example. At my job, we make heavy use of scalaz Disjunctions and
Validations along with Applicative/Monadic combinators to handle errors.
Everyone on the team is capable of writing and modifying error-handling logic
that uses these tools, even though not every developer has a strong working.
understanding of what an Applicative or Monad is.

------
whodatninja
great read! I'm 3 years into the language and brought it into my company. As
part of mentoring other devs coming from a web background, I kept repeating
the mantra, "make it work the simplest way first" then explore the options
scala gives you. As long as there were units tests for the logic, the details
could change. The more I use the language, the more fascinated I become. Heck,
I just learned about Bottom types last week!

~~~
the_af
I can see why you have this mantra, but doesn't this approach lead to
programming in Scala as if it were Java (aka "you can program in Java in any
language"), which results in unidiomatic code?

~~~
Irish
only if you believe the java way is the simplest way.....which I don't think
is true

~~~
the_af
Good point! I absolutely agree with you, and it's very likely I've misread the
parent post. It's just that sometimes I hear people at my workplace conflate
"the simplest way" with "the way I'm more familiar with, coming from Java".

~~~
whodatninja
should have put an example to help clarify. For example, instead of throwing
implicits around, i'd recommend they manually declare arguments like
ExecutionContexts. Also sometimes the best way to teach someone from an OO
background, is to first let them write their code imperatively, then work with
them gradually to move to more functional approaches.

------
oxplot
I've recently started on Rust. Can someone who knows both Rust and Scala draw
comparison on the myths the author is talking about?

~~~
steveklabnik
I don't really know Scala, but...

Rust doesn't have inheritance, let alone multiple inheritance. We do have
traits, which I assume work similarly, it looks like.

On to the ones that are listed under "myths":

IDE support is coming along: [https://www.rust-
lang.org/ides.html](https://www.rust-lang.org/ides.html)

I rarely hear people say that Rust has too many features, or if they do,
they're comparing it to a language with a GC.

Rust's compiler can be faster, and it's getting better all the time.
[https://raw.githubusercontent.com/sanxiyn/sandbox/master/rus...](https://raw.githubusercontent.com/sanxiyn/sandbox/master/rust/time.png)

Rust doesn't really have traditional OOP, so yeah, a lot of it does go out the
window.

Rust doesn't have some Scala features like Higher Kinded Types that lead to
this kind of perception, so it's not quite the same. Our type system can be
hard for totally different reasons ;). The borrow checker stuff.

~~~
whateveracct
> We do have traits, which I assume work similarly, it looks like.

Rust traits are more like typeclasses. Scala traits more more like Java
interfaces w/default definitions and some other things.

------
ape4
In Java its such a pain to always account for possible exceptions. You have
explicitly catch it or explicitly pass it on. Scala frees you of this hassle
by not enforcing anything. So handy.

~~~
catnaroek
Explicit exceptions in method signatures are a language design mistake. If you
need to handle multiple classes of return values, that's what sum types are
for. Exceptions exist to communicate _secret messages_ from a raiser to a
handler, preventing anyone in the middle from intercepting them.

~~~
ape4
Maybe. But Scala lives on the JVM so it needs to deal with them.

~~~
kilotaras
JVM doesn't care about checked exception. It's enforced only in the java code
by javac.

------
graffitici
I had read somewhere that there were talks of creating a smaller subset of
Scala, one that's easier to learn. I believe it wasn't going to have implicit
arguments (or conversions?).

I think Odersky had mentioned something of this kind. Anybody else remembers
something of this sort?

~~~
flavor8
They could call it Java.

~~~
jinst8gmi
By the same logic SVN is a simplified Git

------
nileshtrivedi
> Play has both APIs in Java and Scala, so you can slowly transition from one
> to the other (provided that you architect your application correctly
> especially in terms of database access).

What does he mean by "architecting the application correctly"? I have a
project in production which uses Play framework in Java and I'd be interesting
in transitioning this to Scala? What should I look out for?

This is the only discussion I could find for such a migration:
[http://grokbase.com/t/gg/play-
framework/151wb9eebq/migrate-s...](http://grokbase.com/t/gg/play-
framework/151wb9eebq/migrate-step-by-step-from-java-ebean-to-scala)

------
icedchai
The problem with Scala is it that it's too complicated. This results in slow
compile times, poor IDE support, and on and on. I worked with Scala for about
10 months back in 2011. Never again.

~~~
emergentcypher
None of these things are really a problem any more. Scala has come a long long
way since 2011.

~~~
icedchai
I am going to give it another look. It has been quite a while.

------
piokoch
I am curious to what extent Paul Phillips lecture
[[https://www.youtube.com/watch?v=4jh94gowim0](https://www.youtube.com/watch?v=4jh94gowim0)]
is just a rant or in-depth Scala criticism. If he's right then seems that we
should not expect bright future for Scala.

I am wondering what Scala experts would say (I don't know Scala sufficiently
to trust my judgment)?

~~~
bonobo3000
The rant is mostly about the Scala collections API. I think the "expert"
opinion is that yes, Scala collections are broken and incredibly complex, and
theres a proposal for new implementations here:

[https://github.com/lampepfl/dotty/issues/818](https://github.com/lampepfl/dotty/issues/818)

I think the talk was pretty influential, but atleast the community is
responding. I don't think it spells doom for Scala.

~~~
amock
More than the specific problems with collections that he talks about, I think
the problem of allowing clearly broken methods into the standard collections
is the real issue. Why would they accept an implementation f map where map
isn't safely composable? Why would they use incorrect type signatures? Why
would they allow so many casts? I haven't finished the video yet but every
issue he brings up seems to be about more than a mistake in a library.

It looks to me like you can't trust Scala because the people behind it are ok
with accepting clearly broken or poor quality implementations.

~~~
adriaanm
You don't have to trust us (though you can -- trust me :-)). Take a look at
the source, check some references of happy Scala users. Submit a PR to fix
what you don't like. Ask a question on our forums/stack overflow.

Whatever you decide, I'd recommend rounding out your view of Scala by
consulting more sources than Paul's rants. There's a lot of hyperbole there.
This of course doesn't mean he's wrong, and we've certainly listened to him
and fixed some of the issues he complained about (I was in the front row of
that talk).

------
hcarvalhoalves
I can see how Scala is an improvement over, e.g., Java, and other languages
with weaker type systems and bad abstractions.

Since it's often the case big and complex languages succeed, for some
definition of success, I'm sure it will be as successful as Java.

~~~
whateveracct
To be fair, the only at all comparably production-ready languages that __don
't __have substantially "weaker type systems and bad abstractions" compared to
Scala are Haskell and to a lesser extent Ocaml and F#.

------
hibikir
Scala is my favorite language. I use it every day. And yet, the language, and
its ecosystem, have big problems nobody wants to tackle. They have nothing to
do with the myths people talk about though.

For me, the biggest problem is how fractured the community is. Scala is not a
very opinionated language at all, so work from different subcultures barely
looks like the same language. Working with scalaz? You won't touch the
standard library at all. Finagle? Twitter came up with a Futures library
before it came standard with Scala, and there seems to be no interest in
migrating out of that, so you have multiple libraries for basic concurrency
(along with the scalaz version of course). Those groups, that use the language
so differently, do not share many interests when it comes to the evolution of
the language, what parts are good and bad. This leads to much infighting, and
an environment where instead of learning Scala, what people learn is that the
community is divided, and often very rude. It makes learning a challenge. Each
community also has a different idea of what it is considered acceptable
behavior to other human beings. The scala mailing lists has postings that make
your average Linus Tovalds post seem sensible and polite.

Another part that makes learning a challenge is how different application
level Scala and library level Scala are. In a language like Java, it's easy to
go into the standard library, or into whatever popular library you want to
use, and look under the covers, even and a newbie, and learn how to write
idiomatic Java (whether that's good or not). In Scala, the standard library,
and pretty much every major library out there, use language features that are
not needed at all for regular use, but are very valuable for building
libraries, and yet make the code very hard to understand for someone new. For
the worst case of all, look at the source code of Shapeless: Even very
seasoned Scala programmers find it difficult to understand, because it's
attempting to do things that the designers never even expected people to do
with the language.

Another problem, related to the previous one, is that since it's so easy to
build DSLs in Scala, pretty much every major library does it. Internal DSLs,
implemented around a bunch of implicit conversions that you need to understand
pretty well to solve syntax errors. For instance, say you want to use json in
your spray web service. There are two ways to do it: Follow a tutorial without
understanding it and hope you do not have errors, or spend the time to
understand the type class pattern.

And that leads to the last, problem: There are basic intro articles out there.
There's information for experts. But the route from basic knowledge to mastery
is a big cliff with very little information, and it's easy for people to give
up. As it is now, Scala is a language better learned tribally: You have a few
gurus, and when complicated questions happen, go ask one of the gurus to see
if he can teach you about whatever problem you are having, or about how a
feature really applies to your problem.

I love Scala, I really do, but if the community problems are not resolved, the
rest of the problems will not get resolved. It will remain a hard language to
learn, and other languages that right now do not offer all the rich features
of Scala will just steal what they can and replace it instead, just because
they have better, less fractured communities.

~~~
adriaanm
(Scala team lead @ Typesafe here). Thanks for the kind & insightful words!

We absolutely want to resolve the issues you're referring to, and we welcome
everyone's help and input to speed up this process. We're working on refining
our process and our plans regarding library evolution, especially in light of
the recent controversy around adding a JSON module to our platform.

The first (baby) step I've taken towards bringing the communities closer was
embarking on modularizing the standard library in 2.11, which will continue in
2.13. The goal was to create room for other modules to compete with the ones
that were originally in scala-library and to allow community maintainers to
step forward and own a module (every module now has a community maintainer,
who is in charge of everything, short of promoting staged artifacts to maven).
I'm very pleased with how this turned out, and we'll continue this effort in
2.13, where we'll focus on modularizing the collections library. (We alternate
compiler and library-focussed releases for smoother upgrades, 2.12 is focussed
on making the most of Java 8's new VM features.)

Two more examples, in which I was not involved: the design of the 2.10 Future
API, which was done in collaboration with Twitter; I'm also very excited about
the prospect of including Reactive Streams in JDK 9!

Personally, I prefer to write a bit of boilerplate over relying too much on
extreme implicit magic to eradicate every last line of unneeded code, but I
think it's cool that you can do that it you like to. (Disclaimer: I did a lot
of work on enabling this implicit magic, between implementing support for
higher-kinded types and improving the interaction of implicit search, type
inference and dependent method types.)

The whole Scala Team is very concerned with the experience of our community in
our forums, and we do our best to step in when things get out of hand,
including banning repeat offenders (which we don't do lightly). Because Scala
fuses so many different PL concepts, it's not possible to make everybody happy
all the time.

I really like Martin's quote on using abstraction responsibly:

> [...] trading abstraction capabilities for basic features > is exactly the
> opposite of my design philosophy. > My design philosophy is more like free
> speech. > We protect it even if it is abused. In fact free speech would be a
> > fiction if there were no abuses. In the same way, abstraction >
> capabilities would be a fiction if there was no over-abstraction. > I
> completely agree this approach comes with challenges. It is our >
> responsibility as good engineers to realize that abstractions have >
> benefits as well as costs, and to collectively develop designs where > the
> benefits exceed the costs.

Regarding learning the language, I believe we have a lot of excellent post-
tutorial material out there, including many books and the Coursera classes.
There are many stages of Scala mastery, but you don't have to get to the boss
level in order to be productive. Part of the joy of Scala for me is that you
can keep learning new features and improve your understanding of how it all
fits together (quite nicely, if you ask me).

------
AhtiK
There's just one sad trouble with the current state of tooling: Scala and SBT
in IntelliJ IDEA do not go together.

Each Scala run inside SBT-enabled project takes >10 secs minimum to run. Every
single run. SBT make is invoking the full SBT startup sequence and is unable
to reuse the session. This comes from the context of using Play Framework
where you can't substitute SBT with something else.

I do hope that SBT server becomes a reality at some point and IntelliJ Scala
plugin is able to fully use it.

~~~
uberdog
I've been developing a Play app in IntelliJ for the past year. When run in
development mode ($ activator run) it recompiles only the necessary files when
you make a change, save, and reload the page in the web browser. I can even
switch branches to another developer's work and don't have to restart the
server. I'm not sure what you're talking about. Maybe you have something set
up incorrectly.

~~~
AhtiK
SBT and Play work together great and activator run recompiles incrementally,
this setup is OK.

The issue is with IntelliJ -- when I want to run Play app from IntelliJ, not
from command prompt, to get easier debug support when running the app or junit
tests. Running tests from IntelliJ is more convenient than using activator
shell.

Yes, I could provide -jvm-debug flag to the activator command line but this
works only when fork:=false, which can't be always used.

------
vbezhenar
An interesting note is that new language Kotlin which aims to the similar
niche has many things mentioned in the article. It handles NPE a bit
differently and I'm not sure about multiple inheritance, but compilation is
definitely fast, IDE support is wonderful, no need to learn another build tool
and no monads allowed (joke, but language is more practical, than academical).

For me it's a strong competitor to Scala, if you want to use something better
than Java.

------
meowzero
What are scala people's opinion of nested functions? Is it good practice to
use them? I never liked them because it clutters up the functions and makes
them bigger. I like have short functions. And looking for them in the code
isn't really a problem.

~~~
nullspace
I started writing an explanation about how nested functions are great, but at
some point you stop making a distinction between `val a: A` and `val a: A =>
B` in the scope of a def.

A bunch of my code is interspersed with these function vals. It's useful when
within a function when you repeatedly apply the same transformation in
multiple places. It kinda makes the code easier to read once you stop making
that distinction.

re:short functions - I am not as much in favor of them as I used to be before.
IMO, splitting functions into smaller ones are fine as long as there is some
"meaning" to splitting them ( mostly related to your domain logic ). But I
have stopped splitting functions just to make it smaller. When your code is
referentially transparent, I think the size of your function really matters
less.

------
shekhar101
Great post. On a side note, I loved the blog design. Simple and elegant, and
the font is crisp!

------
dschiptsov
To put it simple - Scala puts together the best parts of Standard ML
(functional programming - so one could reason about code as a form of
calculus, plus pattern matching on type-constructors with destructuring,
partial application, etc) Smalltalk (everything is an object and objects
communicate via messages passing by calling methods - the original concept of
"pure OO" by Alan Kay and the best part of Smalltalk implementation) plus
foundation ideas from Erlang (an Actor and messaging DSL based on high-order
procedures and some syntactic sugar). Together it is already worth switching,
especially afrer realizing what a crap Java is compared to this conscise and
well-researched mix of complementing each other features). Scala is also
famous for its emphasis on immutable collections, which makes GC less painful.

Scala initially is a product of a single remarkably well-trained mind, instead
of committee of mediocrity.

Clojure, BTW, was a solo remake of Scala's approach (Java interloop, emphasis
on collections, immutability, etc) while starting from Common Lisp (strong,
dynamic typing) instead of Standard ML (strong, static) as its basis.

Actually, the Scala course on Coursera is very good start.

~~~
aij
> the best parts of Standard ML

Hindley-Milner type inference?

I really miss having proper type inference in Scala. I'll admit, the "we will
infer the types as whatever javac would have said they should be from left to
right" is a lot more effective than one would think, but still feels rather
primitive.

------
khgvljhkb
Is it sad how Java developers live their lives?

~~~
TurboHaskal
The do seem to live in a capsule, out there in some parallel universe.

~~~
zokier
Or are HNers the ones living in a capsule (or more pointedly, in a bubble :)
)?

