
Scala: sharp and gets things cut - SanderMak
http://blog.fogus.me/2013/10/07/scala-sharp-and-gets-things-cut/
======
pron
There are so many problems with Scala, that the question of static vs. dynamic
typing becomes secondary. Static typing could well be downright awesome, but
Scala is still a mess.

I'm repeating the same line for the third time today, but I find that Scala is
for people who find Haskell too simple, and want to add mutability,
inheritance and macros on top of it, while dropping safety, purity, and much
of the type inference (and I'm certainly not a Haskell fan, but Scala makes
Haskell seem like Logo).

For the life of me I can't understand what the language designers want, or how
they think software should be written. It seems like they're finding it a fun
challenge to see how many features from different languages can fit in a
single compiler, and they justify each feature as necessary to solve some
arcane problem.

I think it's the complete opposite of languages like Clojure and Erlang (or
Java, even), whose designers started by pondering the major issues of software
development, and tried to come up with a coherent solution, rather than pile
on features, each plugs a specific hole, without any fundamental organizing
principle.

~~~
virtualwhys
> There are so many problems with Scala, that the question of static vs.
> dynamic typing becomes secondary. Static typing could well be downright
> awesome, but Scala is still a mess.

Well, gosh, it must be terrible, avoid it all costs!

> I'm repeating the same line for the third time today.

You're obviously not a fan of the language if you find yourself bashing it 3
times in a day, fair enough.

> I find that Scala is for people who find Haskell too simple

Scala is for those that want to get shit done without dealing with Java's
endless boilerplate, while still running on the performance beast that is the
JVM and benefiting from Java's massive ecosystem. As a bonus you get FP out of
the box, so you find yourself, without consciously being aware of it, favoring
immutable constructs (map,flatMap,fold, etc.) over imperative mutable
boilerplate ridden hacks to achieve the same, thereby, in complete
disagreement with the article at hand, becoming a better programmer.

With Haskell you get purity, unhindered FP elegance, and minuscule ecosystem,
a language interoperable with...itself it seems.

While it's true that Scala is perhaps overly feature rich, with the to be
released 2.11 the focus has been on aggressively stripping out unused features
from the language and improving compiler performance.

Following that, perhaps for 2.12, Odersky recently proposed on Twitter a
revision of the type system that had FP devotees up in arms since the proposed
change removes some of the complexity that makes libraries like Scalaz
possible.

At any rate, with Java8 there will be a squeeze in the JVM landscape,
alternative languages will be fighting for users as lousy legacy Java is soon
going out the window.

~~~
abalone
_> Scala is for those that want to get shit done without dealing with Java's
endless boilerplate_

I've always wondered about this argument. Haven't modern Java IDEs more or
less automated away the boilerplate?

Using a tool like IntelliJ IDEA or even Eclipse for that matter, I'm really
hard pressed to find something that could be autocompleted or generated that
hasn't been. They even have views that collapse or otherwise hide away
unnecessary verbosity.

Sure, you have a little more code to _look at_. But frankly, sometimes this
can improve readability vis-a-vis excessively concise and overloaded syntax.
It can make it easier to grok someone else's code.

I'm not saying there's no difference, just that it's a little odd that this is
the NUMBER ONE advantage always cited for Scala vs. Java. Am I crazy?

~~~
saryant
I think the conciseness can _improve_ readability. Consider these examples:

    
    
      List<String> list = getListofStrings();
      List<String> capitalized = new ArrayList<String>();
      for(String st : list)
        if(Character.isUpperCase(st.charAt(0)))
          capitalized.add(st);
    

Or...

    
    
      val list = getListOfStrings
      val capitalized = list.filter(_.head.isUpper)
    

Grokking two lines will take less time than grokking six lines.

~~~
VladRussian2
>Grokking two lines will take less time than grokking six lines.

when your mental/visual pattern machinery have been trained for 15+ years on
the latter case? :)

~~~
dragonwriter
Sure, if you are excessively habituated to reading _Language X_ and have some
kind of barrier to learning new things, _Language X_ will be better for you
for most uses. That's not really a feature of _Language X_ , though.

------
barrkel
I think you missed the point of that line.

Type annotations let you get the shape of the data structure out of your head
and into code. The compiler can then ensure that you're using the data
structure properly.

Whereas if you're using a dynamic language without type annotations, you need
to keep the shape of the data in mind; after that array index, hash lookup,
function call, you need to know what kind of thing it is you've got in hand,
and what you can do with it. Sure, you write tests to exercise the code and
flush out the mistakes, but that isn't as tight an iteration cycle as a
compiler - if living in an IDE, the cycle may be as low as a few milliseconds.

And this is the point of the "not a great programmer" comment. Making progress
even though you don't have the entire map of the whole program's data
structures in your mind all at once.

Having said that, I think this ability to deal with a lot of complexity in
working memory can be detrimental to good code, even in typed languages. I've
worked with some talented programmers that had an enormous capacity for
complexity, but that very complexity made them less inclined to abstract their
code. In fact, because they had less need for abstraction, their abstraction
skills overall were poorer.

~~~
mcv
> Type annotations let you get the shape of the data structure out of your
> head and into code.

This is by far the best argument for static typing I've ever heard. I'm not a
big fan of static typing (mostly due to Java). I like Scala, but I think its
type system is way over the top.

For the most part, I care about rapid development, and you'll always need unit
tests anyway, so they can also test your types for you. And Scala type
matching in its builtin switch statements can always get my type back when I
get handed an Object. With tools like that, I don't really need absolute type
safety.

But getting the shape of your data structures out of your head, that's
definitely an advantage.

------
badman_ting
I agree strongly with the statement the author calls out. Stop believing in
yourself and your amazing abilities, and embrace your incompetence. Stop
talking about what a great marksman you are, look down at your bullet-ridden
feet at long last, and embrace tools that make it harder to shoot yourself in
the foot.

This weekend I found a collection of Javascript tests meant to evaluate one's
abilities. I spent an hour trying to get the project to run, so I could take
the tests, but it was all built on piles of Jello. A bunch of slightly-
incompatible versions of libraries and frameworks and shit, so that 3 months
after its release I couldn't use it. Stop the madness. Build shit to last and
stop using things that make your next 5 seconds in emacs slightly easier at
the expense of everyone else.

------
Aqueous
Maybe it would be better to say, "I'm a pretty good programmer. However, I'm
not perfect, and I make mistakes. Static typing helps minimize the mistakes."

The one thing I don't like about Scala is type inference. We spend all that
time specifying the exact type of parameters and return values, but then we
can just lazily declare an immutable value val, set it equal to a return value
of a function, whose signature is in different file, and from a quick glance
at the code we can not tell what 'val' is. it might be convenient in the short
run, and splits the difference between convenience of dynamic typing and the
precision of static typing, but it does so at the cost of readability.

~~~
lmm
If you feel a particular value needs an explicit type you can always include
the type in the declaration. Or your development environment should be able to
tell you what type it is.

I do think scala needs an IDE to be used effectively, at least if you're
making heavy use of implicits and inferred types (and, as a sibling mentions,
indirect imports). But I think that's ultimately a good thing: it uses the
power available to us nowadays to allow a more compact representation of code
than would be acceptable in a plain text file (which is good for readability -
AIUI evidence is that code readability takes a big hit as soon as a function
spans more than one screen). Rather than throwing away the convenience of text
like the '80s "visual programming" efforts, it's more of a "progressive
enhancement".

~~~
Aqueous
Yes, I have started to enforce a policy of explicitly declaring val types, but
I would almost prefer it if Scala enforced this instead of me.

~~~
lmm
Making your IDE add them when it autoformats should be as simple as one
checkbox (he blindly asserts).

------
auggierose
Scala is the best language out there today for general purpose programming,
FULLSTOP.

Many people complain about the complexity of Scala, or how many features it
has, etc. Yes, there are some odd features (I am looking at you, native XML
support), but these are features I NEVER use. Just learn the fucking type
system (it's not that hard, all you need to understand for most of your coding
is [A], [+A] and [A <: B] and you are set) and stick to the features you like
/ understand.

To those who praise the purity of Clojure: That is nice, but comes with a high
prize. For example that you have to wait for something like Clojure.Typed,
which is already a non-issue with Scala, because Scala comes with BATTERIES
INCLUDED. Complaining that Scala has too many features is like complaining
that Clojure has too many libraries.

~~~
laureny
> Scala is the best language out there today for general purpose programming,
> FULLSTOP.

You have a very narrow view of what makes a good general purpose programming,
it's not just about its syntax and its type system.

Scala suffers from a lot of hurdles that make it awkward to use in production
and which lessen its productivity:

\- IDE support, still very shaky, each new version of the plugin adding new
features and breaking old ones, and the plugins randomly refusing to work now
and then

\- Tool support in general (it's sad that the best build tool is sbt, I was
hoping we had learned from ant and maven that we can build better build tools)

\- Slow compilation and getting slower at every release (memories of C++ and
template linking)

\- Backward compatibility still a problem. The compiler is a bit better now
but the library story is simply a non starter for most production work

\- And overall, the overwhelming impression that Scala is to Java what C++ is
to C. It's a very big language that keeps getting bigger at each release,
despite Typesafe promising they are working to fix that. They also promised
that Scala development would no longer be driven by papers published at
conferences, but that's a lie as well.

Also, some influential Scala people have been leaving Typesafe recently, and
not in very good terms (e.g. Paul Philips, who was the guy keeping the
releases together).

I just have a bad feeling overall about the future of such a language.

~~~
auggierose
The IDE support is pretty good, I don't have problems with it. Ask the Clojure
people how THEIR IDE support is ... sbt is a great build tool, better than ant
or maven, pretty much the best I am aware of for any relevant language. The
compilation speed is good enough for me, maybe you should upgrade your
hardware. If you have compatibiliy problems, don't move to the new version.
Wait until you have your issues fixed. You don't need to upgrade your Scala
version immediately just because there is a new one. As to Paul Philips
leaving, what was he responsible for, and what were the "bad terms"?

I have a really great feeling overall about the future of Scala. This feeling
is based on my 20 years programming experience with all sorts of languages,
and Scala is the best one out there right now. The IDE support and tooling is
far greater than for any other language that comes close to Scala. (When you
code in Java, even the greatest tooling in the world will not help your
productivity).

~~~
squidsoup
> Ask the Clojure people how THEIR IDE support is

Good from what I understand. Counterclockwise for Eclipse
([https://code.google.com/p/counterclockwise/](https://code.google.com/p/counterclockwise/))
received commercial support and sponsorship last year and is under active
development. Chris Granger's Light Table ([http://www.chris-
granger.com/lighttable/](http://www.chris-granger.com/lighttable/)) is an
interesting contemporary look at an IDE. Tim Pope's fireplace
([https://github.com/tpope/vim-fireplace](https://github.com/tpope/vim-
fireplace)) adds inline evaluation, a repl and some other tools to Vim.
There's emacs of course.

~~~
auggierose
I've done my share of Clojure programming, and none of the tools you mention
are usable in a serious setting. The only stuff I could use (and that was damn
hard to set up in the first place, and is "deprecated" for a year now) was an
Emacs based solution.

------
DanielRibeiro
This is an interesting post. I worry though that Odersky's point can make
people think that there are only two kinds of type: static, or dynamic.

James Iry did an amazing overview of the nuances of various kinds of type
systems on his _Types à la Chart_.

[1] [http://james-iry.blogspot.com/2010/05/types-la-chart.html](http://james-
iry.blogspot.com/2010/05/types-la-chart.html)

------
programminggeek
I think that typing is useful, but I say that as someone who wrote a bunch of
type checking code on top of Ruby to make my boundaries cleaner and more sane.
It made my code a lot nicer to work with, but I quickly realized that what I
really would prefer is strong interfaces and typing at the boundaries.

Thus, scala, go, java, c++, etc. make a lot of sense to me because you gain
performance and stronger boundaries are baked into the language.

I want strong typing because it makes my code better. I want it built into the
language because it makes my code cleaner.

------
nathansobo
I also found his talk fascinating, but the paper he referred to was a bit
unapproachable for me. Any suggestions for resources that could help get me
more comfortable with reading and understanding type calculi?

~~~
zeckalpha
Here's the Milner paper which describes ML's type system.
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.5276&rep=rep1&type=pdf)

Wikipedia also helps:
[https://en.wikipedia.org/wiki/Type_rules](https://en.wikipedia.org/wiki/Type_rules)

------
abalone
Absolutely static typing helps you be a better programmer. No programmer is
infallible, and static typing helps you catch a large class of your mistakes
sooner -- at the moment you write or compile them, rather than at runtime or
never.

The author's reasoning is quite poor. They don't even concretely define what
it means to be a "sharp" programming tool.

------
sandGorgon
There is a lot of focus on haskell vs scala and deep intricate discussions
about type systems, but here's a question - how is scala as a better java ?

For my purpose (working with hadoop), it has proved to be more than adequate -
I get a repl to work with java classes (serious productivity jump over those
who have to work with vanilla java), I dont have to muck about with classnames
<> filename mapping.

I come from the JRuby world and I have a secret fetish for Clojure - but the
near-Java performance of Scala is impossible to argue against.

My biggest, biggest problem is sbt - it is fairly sucky, since it inherits
Maven's Madness. Pet peeve - not sure why "sbt console" insists on compiling
class files before launching a repl. I mean, I'm launching a repl since
something did screw up, right ?

I think Scala can be much, much simpler and better - especially in compiler
error messages and tooling. But it is absolutely amazing as a Java
replacement.

~~~
eeperson
'sbt console' compiles before it launches a repl because it includes your
project's classpath. If you want a Scala repl that doesn't have your project's
classpath (and hence doesn't need to compile things) start a repl separately
from sbt.

~~~
clhodapp
Alternately, use "console-quick", which brings up a console with your
dependencies on the classpath, but not your actual code.

As a (lengthy) side-note, that name really bugs me. In sbt, we have console-
quick and console-project (brings up a console with your build on the
classpath). Argh! These are _kinds_ of consoles. They should be quick-console
and project-console! Alas, those are the names that Mark Harrah gave us, so
they're the ones we have to live with, I guess.

~~~
sandGorgon
whoa... THANK YOU for that!

------
aklein
"I am a great programmer and I choose static type systems because I demand
sharp tools."

I strive to build correct software, and I leverage a static type system to
enforce the absence of incorrect program behavior. Any other benefits are just
niceties.

~~~
ajanuary
* to enforce the absence of certain classes of incorrect program behaviour

------
mercurial
> I am a great programmer and I choose static type systems because I demand
> sharp tools. > Of course by taking this position you run the risk of pushing
> a fallacious, authority-based angle. However, in the weak or strong case
> you’re already pushing anecdotes around, so you may at least choose the one
> that is open for objective measurement.

Which part is open to "objective measurement"?

I don't know if I'm a good programmer, whatever that is, but I use static type
systems when I want a system to work both today and tomorrow after I refactor
it.

~~~
monstrado
These are all very subjective statements, things like "I choose ... because".
If you asked 20 programmers why they like statically typed languages, I am
willing to bet you will get quite the variety of answers. Personally, I think
statically typed languages scratch an itch that is different from programmer
to programmer.

~~~
mercurial
Ah, but the difference is that I'm not claiming my statements are open to
"objective measurements" :)

------
jaxytee
Scala transcends the static vs dynamic typing debate via it's duck typing.
Because of it's implementation of implicits, you get static type checking
along with the flexibility of a language like JavaScript or Python. IMO This
puts Scala head and shoulders above the rest of the programming world in terms
of language design.

~~~
anonymoushn
Scala lets you spend lots of time typing incomprehensible type signatures and
gives you less type safety than ML-family languages in exchange. Truly it is
the pinnacle of PL design!

~~~
mcv
Yeah, I hate those incomprehensible type signatures. Just give me an Object
and I'll match with the type I need.

~~~
_random_
I have a better idea! Let's just use strings for everything!

~~~
virtualwhys
thanks for the chuckle

------
seanmcdirmid
The article is weird. Martin Odersky is an incredibly good programmer, just
dive into the source code of scalac, he was probably just being modest to make
a point.

~~~
lnanek2
I think it is a better way to phrase it anyway. If you say you are an awesome
programmer and since you are awesome your decision to use static typing to get
you better compile errors and help your development is right, then people can
just argue that you suck. But if you say you suck and static typing allows you
to suck less, what are they going to say?

It's pretty widely admitted that languages need to help developers suck less
to succeed, see Java removing multiple inheritance, operator overloading, etc.
and becoming the premier business language. These were power features that
made it easy to shoot yourself (and team members) in the foot.

------
_random_
It will add more confusion with the actual sharp tools: C# and F#.

------
asdasf
His assumption is incorrect:

>but I suspect it’s an attempt to counter the idea that strong static type
systems like Scala’s are complicated.

Nope. It is simply stating the reason we use typed languages. Because we are
human beings, and make mistakes. Having a compiler automatically tell us when
we make those mistakes is very helpful. That's it. It has nothing to do with
"sharp tools", which untyped advocates also claim their tools to be. It is
simply that type systems can find a large number of bugs, at compile time,
with 100% certainty.

