
Using Scala Will Make You Less Productive - bartonfink
http://grundlefleck.github.io/2013/06/23/using-scala-will-make-you-less-productive.html
======
sramsay
The OP jokingly names a law after himself at the end, but I move that we _do_
name something after him. I'm going to call it Ahmdal's Condition. It goes
like this:

 _In this lengthy [post|comment], I’ll share my thoughts and opinions on
[THING IN COMPUTING, TiG hereafter] . . . Using a cavalcade of flawed data;
logical fallacies; biased opinion; startling lack of citations; and basic
nonsense, I will convince you that using [TiG] will make you less productive.
I will finish with an underwhelming and unexciting conclusion. You have been
warned._

Think of it! "I'm offering my thoughts here under Ahmdal's Condition, of
course . . ." "Well, I think you're starting from Ahmdal's Condition . . ."
"That works under Ahmdal's Condition, but assuming stricter conditions . . ."

Honestly, it's genius. If I had a magic meme wand, this guy would be famous by
the end of the day.

~~~
jamesaguilar
Is it necessary to provide randomly controlled trial/other scientific data to
talk about things you don't like in a programming language? Do you have the
same standard for talking about things you _do_ like in a programming
language? My only problem with the article is that the hyperbole/sarcasm (e.g.
"I've given irrefutable scientific evidence...") is not so well done.

~~~
loup-vaillant
Rational evidence doesn't have to be scientific.

But.

Even first hand anecdotal evidence has its limits. It really needs to be
blatant to be significant. Second hand anecdotal evidence is even worse. If
the phenomenon you want to catch is subtle, you generally a good deal of
reliable data. That generally means something "scientific".

~~~
jamesaguilar
My point is that people demanding scientific data for criticisms had better do
the same when their favorite language gets praised. Of course, personal
evidence is less strong than scientific evidence. That much should be obvious
to anyone.

~~~
loup-vaillant
> _My point is that people demanding scientific data for criticisms had better
> do the same when their favorite language gets praised._

Ah, the dreaded double standard. Easy trap. Personally, I avoid it by trying
to have objective criteria. I end up with crude and imperfect measures (LOC
count, number of defects…), but at least they're not too biased.

> _personal evidence is less strong than scientific evidence._

Actually, this is not necessarily true about first hand personal evidence.
While a host of biases are out to cloud your judgement, science can be weak
for two reasons: (i) the studies may not amount to much evidence, either
because the controlled experiments are also artificial, or because there may
not have been much of them (it is quite expensive to do the same project
multiple times with arguably similarly skilled teams), or both. (ii) What
applies to the majority of people may not apply to you specifically (though
you'd better have strong evidence as to why this is the case).

Now, _second hand_ personal evidence… that's much harder, because (ii) doesn't
apply, you also have to trust whoever is telling you the story, and this story
hold far, far less information than what you would have gathered by living it
yourself. Still, it may yet be stronger than sufficiently weak scientific
evidence.

Now, a blog post by a random programmer? Okay, that one is always weaker than
science.

------
ryanobjc
Interesting post, a little random, ultimately it's really hard to 'prove'
something like this in a single article. Studies maybe, but there'll always be
someone saying something contrary.

I can only really offer my experience, which is architecting and building out
a 25kloc app and team to go along with. Mostly, because we avoided the
'clever' scala stuff as much as possible, things went well. Maven instead of
sbt. Jetty instead of play. The only scala DSL we used was squeryl.

If I was doing it again, I'd probably rethink the use of scala. As helpful as
it was, it was also a pain in places. Having to rewrite all our for loops was
not cool. Case classes saves on boilerplate, but frankly you only write that
stuff once, so it didnt really save us on a lot. Intellij elides most of the
junky boilerplate (import statements, generating setters/getters, etc) in
Java, so ...

Now a days with the advent of Java8, we have access to lambdas, function
pointers/interfaces, and the functional stream system, I am interested to see
how far one can get in just pure java. Java is the new scala it seems.

~~~
kasey_junk
Honest question that I haven't taken the time to figure out. Do I still have
to have only 1 file per class/interface in Java 8?

~~~
mason55
No, in fact you frequently have more when you start using case classes. Plus
you frequently have the companion object that goes with your class that acts
as a singleton.

~~~
kasey_junk
I understand the limitations of Scala with regard to class/trait/objects etc.
What I'm asking is if it is still an issue in Java 8? I'm shocked every time I
drop back into java land that people haven't revolted against this terrible
requirement.

~~~
edwinnathaniel
Why is this an issue or a big deal? Really.

~~~
kasey_junk
Because it adds friction between separating implementation and interface. That
is one of those things I want to be as seamless as possible. Is it a big deal
in the case of 1 interface and 1 class? No not really. But in the case of
thousands of them it becomes an issue.

It's actually one of the biggest things I notice when I come back to java
land.

~~~
edwinnathaniel
I think with modern Java libraries (and testing libraries as well), the days
of 1:1 interface=>classes are almost gone.

I rarely do that any more these days so hopefully it'll become non-issue in
the future for you.

------
mcv
Scala has a couple of features that make it by far the best programming
language ever conceived by mankind. But it has a couple of other features that
utterly ruin it with total unrecoverable brain damage.

I would really, really appreciate a Scala without all the crazy, but with all
the brilliance. Or, you know, just a community that doesn't go out of its way
to overuse all of that crazy.

Just drop the incomprehensible type declarations and the incomprehensible
operators. Maybe add dynamic typing, even. Then you'd have a really nice
language.

~~~
anonymoushn
Moving to a simpler type system is not the only option. If you want to avoid
the incomprehensible type declarations while _increasing_ the strength of the
guarantees the language makes at compile time, you might consider OCaml.

~~~
bad_user
Personally I find Scala to be more elegant than OCaml. In OCaml OOP is a
strange add-on, whereas in Scala it's an elegant mix.

------
sandGorgon
Has someone learned Scala and Go simultaneously ? This may seem a strange
question - but I underwent this when I solved the Stripe CTF gitcoin
challenge. I think that particular challenge was the most interesting because
it branched into the leaderboard challenge.

I wrote the same code in Ruby-Celluloid, Python-subprocess, Scala-Akka and Go.
When I did this, I came to an strange realization - I absolutely did not have
fun writing Scala/Akka code as much as I did writing Go (minus the unused
variable fascism).

Again, I'm not at all arguing the ecosystem of the JVM vs Go, but I just had a
much better time grokking Go code than Scala/Akka - especially the package
manager (pulling deps directly from github, etc.) I even sent in a patch for a
go package ("gocmd" on github) barely a couple of hours after I first
_touched_ go for the first time in my life.

I dont have production worthy experience in either, so I dont have a strong
opinion... but I really ended up wondering if Go makes Scala obsolete.

~~~
anentropic
Oh good it's not just me... found it very annoying that the Go compiler
complains of unused variables!

~~~
sandGorgon
Arent there people (like me) who will pay good money for a version of the Go
compiler without that check ?

Does anyone know if I can disable it in the source code somehow and build a Go
compiler (I doubt it though - if Go was never built with things like deadcode
optimization because of this enforcement)

~~~
nutate
I found it a bit of a restriction, but ideally I'm not shipping code with
unused variables, so why put them in. In the worst case I'd viciously comment
things out, then uncomment them and add them back where I'd deleted once I
figured out what the problem was.

~~~
sandGorgon
If you chart out a software project from "blank file" to "write one line -
code review by 8 people before merge", then Go is suited to the latter. I find
myself writing a lot of malleable code when I'm prototyping and Go is really
getting my way.

I dont dispute it is really useful (I worked for 6 years writing C, so I know
about traps) but I really, really, really wish they would put a command line
option to disable it.

~~~
edwinnathaniel
My IDE (IntelliJ or Eclipse) will remove unused variables when I save the
file.

Very very handy...

------
Aqueous
I really disagree with this article. Type safety combined with Play's refresh-
recompile trigger means it is not meaningfully less productive than PHP, and
maybe moreso because compiling is usually an indication of your program's
correctness, so you don't waste time tweaking-reloading-tweaking-reloading.
Compiling is slow, yes, but it saves you more time than it costs you because
static typing means a whole class of bugs just never happen for you.

I know that the IDE support is lacking but this doesn't really bother me since
I don't use an IDE with Play apps. I always use a text editor, since I find
that IDEs tend to do a bunch of things badly, whereas a text editor and a
terminal each do a single thing very well. There's nothing you said about the
features of an IDE that I couldn't do just as well with a well-defined find-
replace (besides variable extraction - not familiar with variable extraction.)

You can be productive in any language - Java, Scala. But I find that Scala's
conciseness - the fact that I can do an operation on a whole collection of
case classes using pattern matching and the collection API functions that
would take 30 lines using classic Java - ends up making me more productive
than I have been in those other languages. Maybe it's just me.

~~~
ebiester
So, how do you write your unit tests? Within grails and guard (and other
systems as well), I save my file and I have all the relevant unit tests
running immediately. I have less than a second lapse.

At least, when I was working within play, it was painful enough to discourage
me from test driving my code, especially if implicits were involved.

~~~
Aqueous
I spend most of my time running specs2 - unit specs - from the command line.
I'm sure I could have sbt trigger on save but since I save pretty much
constantly I'd have the tests running all the time. I will freely admit the
compile time on tests is a bit extreme but I've found that it doesn't
appreciably slow me down, since I typically run the tests when I'm confident
the new code will pass.

As for integration tests those run via Specs2/Selenium as well but I rarely
run them from my own machine as they are continuously running on Travis CI
whenever I push to our repositories.

------
virtualwhys
"Not Knowing Scala Will Make You Less Productive", is the more appropriate
title.

Scala is not, in my experience, a hit the ground running type language. You
have to learn the ropes, discover the various gotchas (of which there are
many), etc. before you begin to blow away your former self in terms of
productivity.

------
penland
Man that's a bad post about Scala. Scala has a lot to love and a bunch to hate
within the language itself, but writer doesn't appear to have the ability to
actually discuss it.

~~~
mcherm
I completely disagree. The blog entry contains enough details to make me think
that Graham actually understands Scala. And he raises valid complaints:

* Compile-time is slow * IDE support is more poor than Java * Overuse of operator overloading is confusing * Implicit confusing

I don't necessarily agree with all of these criticisms, but it's a very valid
piece of "feedback" to the Scala community.

~~~
hp
Scala doesn't have operator overloading btw. It just doesn't restrict method
names very much. This is very different from how C++ treats operators as
special cases.

If you give your methods bad names, it really is not the language's fault. You
can probably find a way to make a bad API even if you are limited to a-zA-Z0-9
...

If a library has an inscrutable set of method names blame the lib not the
language.

~~~
hapless
Operators are treated specially in scala. Methods with certain names have
wildly different precedence rules.

The special operator rules allow library authors to create a "DSL" without
using the (difficult) macro system. This almost never ends well.

------
playing_colours
A very important point for me in Scala is that now I can consider building the
company stack with it. The libraries and infrastructure are really getting
better. We have Play for web applications, Spray, Scalatra and more for APIs,
actors / futures / STM / Akka for concurrency, and you can easily intergrate
Akka with Play and Spray, use the same patterns at different parts of your
infrastructure. We have Scala.js for frontend work. Growing numbers of
frameworks for Big Data. Those are maturing and being developed for industry
needs, tested in production at some known companies. Don't forget it's based
on solid JVM with huge amount of Java libs available.

I have confidence to advise building real businesses with Scala stack and not
looking like an irresponsible guy who just wants to play with the latest and
shiniest stuff hazarding a company's business. I also see how Typesafe is
focusing on solving bad parts: compiling time, stability, etc.

You can also stay away from advanced / theoretical / crazy parts of Scala most
of time. You don't need to use Scalaz, advanced type system features etc.
There are also immature libraries, toys and proof-on-concepts, but you cannot
blame Scala for your choice.

~~~
mason55
I'm curious about the fact that you're using both Play & Spray. Are you using
them in the same app? It seems like there's a lot of overlap between the two
and that by switching to Spray as your backend you'd just be generating static
HTML with Play.

~~~
playing_colours
Spray (or Unfiltered at my previous project) is used for a different part of
the project. It's basically used on parts where you can expect high load, lots
of requests / responses and tight integration with Akka system for processing
large amounts of data. Play framework was used to provide UI for our data team
or end users to see statistics, do some operations and it's not bombarded by
large amound of requests.

~~~
mason55
Makes sense. I'm building out on Play right now but given that my long-term
goal is to have a JS view + REST endpoints I'm still not decided on whether I
want to stay on the Play UI/template model or switch to something like
Backbone.js + Spray.

------
auggierose
I've seen that post previously here. It did not become better.

------
camus2
Well the problem with Scala is at first it looks like a concise java but it's
not. Truth is it's closer to Lisp with a C syntax. If you dont understand some
idioms like lazy evaluation, everything is a method or pattern matching you
probably should use it. I think scala rocks. The only downside is the slow
compiler. But SBT , worksheets , stuff like that are just awesome to toy with
stuffs in an interactive manner.

~~~
chimeracoder
> Truth is it's closer to Lisp with a C syntax.

The only similarity that Lisp and Scala have are that they are both functional
programming languages[0].

Scala is a heteroiconic language. At least until recently, Scala didn't even
have macros (I think they may have added that recently).

Scala is a nice language, but saying that Scala is somehow like Lisp is doing
a disservice to both languages.

[0] Even the statement that Scala is functional is itself debatable - one can
make the argument that it is "just" more purely object-oriented than Java, but
that's a whole separate discussion.

~~~
adrianm
Why do people think Lisp is a functional programming language? If anything,
traditional Lisp is the antithesis of a functional programming language. What
Lisps are you referring to?

Maybe we're just defining our terms differently, but the closest Lisp comes to
a functional programming language is Clojure and before that Scheme.

This is not meant to deride Lisp in any way (Clojure is my language of choice,
after all) - I think all Lisps enable a fundamentally unique way to reason
about programs, but that's a characteristic of Lisp and not of functional
programming languages.

~~~
barrkel
People think of Lisp as an implementation of lambda calculus, which is at the
theoretical core of pretty much all functional programming languages.

~~~
nbouscal
Unfortunately we've overloaded the term 'functional programming' a bit too
much. Foundation on the lambda calculus is definitely core to most functional
languages, and I see how it would be reasonable to think of that as their
defining feature, but it seems that the community has instead gravitated
towards 'referential transparency' as the key thing. With the former
definition, Lisps are definitely functional; with the latter, most of them are
definitely not. Most Lispers I know consider e.g. Common Lisp to be a multi-
paradigm language, not a functional one, for this reason.

------
hhm
My main impression after using Scala a little bit (admittedly some time ago):
it has some very cool functional features, but they are too slow when compared
with the non-functional features. When working on a program for which
performance matters, this means that you end up working on a Java-like subset
of the language in most of the program.

~~~
kasey_junk
Well I would argue that when you are working on something where performance
matters on the JVM you end up working on a very C-like subset of your
language. Java makes the translation to that subset easier than Scala, but you
can certainly do the same translation from Scala.

------
bad_user
> _If functional programming is what you want, you can do it in your
> language._

This is a fallacy that gets repeated over and over, ad-nauseam. No, you can't
do functional programming in any language. In Java it's more than just lack of
syntactic sugar. Java's type system actively fights against functional
programming. This is a bit like saying that you can do OOP in any language.
Yes, you can have GObject in C. Yes, for Java there have been attempts like
www.functionaljava.org ; but it sucks so badly that almost nobody does it,
unless they are forced to do it.

In fact I challenge the author of this article to show me a piece of FP code
that he wrote in Java by himself.

> _What about all the wonderful things in the standard library? Yep, filter
> and map and fold operations on collections out of the box is nice. That the
> SDK uses Option instead of null is an improvement. These things are nice,
> but I generally get what I’m looking for by adding some libraries to core
> Java._

I do know Java's ecosystem and he must be speaking about Guava, as there's no
other stable library for Java that has persistent data-structures. And Guava
kind of sucks, so if you're looking for persistent data-structures, might as
well implement them yourself, it's fun and it might open your eyes to what
functional programming is ;-)

Speaking of Guava's Option, lets talk about how Guava's Option is not a Monad,
or for those that don't know what that is, basically a context that implements
map and flatMap with certain properties. Scala's Option also implements filter
and fold, etc... which in regards to the purpose of a Monad, in the words of
Erik Meijer, _is to guide you through the happy path_. Now that's a little
closer to functional programming and speaking of Erik Meijer, people might be
interested in what he thinks about Scala:
[https://twitter.com/headinthebox/status/438355100310831104](https://twitter.com/headinthebox/status/438355100310831104)

On the bad things he lists:

> _Compile Time_

Scala's type-system is much more static, leaving much less room for accidental
bugs. Scala's compiler does things that in other languages you'd need to run
specialized tools to get the same results or to write more tests. A single
sentence or paragraph can't do it justice, but the big compile times are
perfectly justified and this is coming from a developer that prior to Scala
preferred dynamic languages with instant edit/reload cycles.

Besides, these times have been dropping as the core Scala devs have been
making improvements, with another batch of optimizations coming in Scala 2.11.
And incremental compilation in general works great. And I'm a developer, I
have a good dev machine - if you don't have an SSD and at least 8 GB of RAM,
then you've got no excuse.

> _The IDEs_

I've been using IntelliJ IDEA since a year ago and for people reading the rant
exposed by the article - IntelliJ IDEA 13 for Scala is everything you'd expect
an IDE to be and more. I never had problems with renaming things. I never had
problems with finding all usages of a type. IntelliJ IDEA 13 works flawlessly
for viewing the inheritance hierarchy and I'm doing the Cake Pattern which is
freakishly heavy on the traits ;-) Other languages only dream about such
awesome IDE support.

> _Overuse of Operator Overloading_

He complains about SBT, but I thought we were talking about the language and
the standard library. Pity that he doesn't exemplify an instance in which "+"
is overused.

> _Implicit_

He mentions implicit parameters, but exemplifies with implicit conversions.
Implicit conversions are in fact considered experimental and starting with
Scala 2.10 the compiler will issue warnings in case you're using them without
allowing "language.implicitConversions", being replaced with extension methods
by means of implicit classes.

Yet, he doesn't mention Type Classes, the main use-case for implicit
parameters. IMHO, I can't stand languages that do not have this form of ad-hoc
polymorphism.

> _How much of your time, as a software developer, do you spend doing stuff
> that is language agnostic?_

That's setting up a straw-man. The problem we as software developers are
trying to solve when picking new languages is one of gaining access to
abstractions that are otherwise very difficult to express and use. Implement
something like Iteratees in Java, a higher-level abstraction for safe
asynchronous stream processing with back-pressure built in and you'll see what
I mean.

~~~
copergi
>Scala's type-system is much more static, leaving much less room for
accidental bugs. Scala's compiler does things that in other languages you'd
need to run specialized tools to get the same results or to write more tests

That is a bogus excuse. Languages with better type systems have faster
compilers: haskell, clean, F# and especially ocaml. Paul Philips makes a
pretty convincing argument that scalac is slow because it is a big mess.

~~~
bad_user
Haskel's compiler is much slower than Scala. Ocaml's compiler is also slow.

F#'s type system doesn't do higher kinded types, or type classes, amongst
other being much less sophisticated.

I'm really tired of hearing the Paul Philips argument. Scala 2.11 is a big
refactoring addressing many of his complaints. Will that stop people from
using the Paul Philips argument in conversations? Of course not, as many
people weren't interested in his actual arguments.

~~~
copergi
GHC is faster than scalac, and GHC is the slowest haskell compiler. Ocaml
optimizing compiler completely destroys scalac (and GHC), nevermind the
bytecode compiler which is way faster than that. Being tired of reality
doesn't change reality. When the single most knowledgeable person in the world
on the internals of scalac talks about why scalac is slow, it is more likely
that he is correct than some random scala fanboy on hn.

~~~
bad_user
GHC can be freakishly slow, especially with -O which is needed and is on the
whole a lot slower than scalac, yes. You can claim otherwise of course, but oh
look, it even has bugs in it:
[https://stackoverflow.com/questions/17822539/debugging-
compi...](https://stackoverflow.com/questions/17822539/debugging-compile-time-
performance-issues-caused-by-ghcs-constraint-solver)

I never dismissed Paul Philips' arguments. In case you missed my not-so-subtle
critique, I'm complaining about people referring to his presentation as a tool
for bashing Scala, without having listened to those arguments. What's a "
_mess_ " anyway? Scala-js.org happened in a fantastic time-frame because it
reuses Scala's reference compiler. How many languages can claim such
performance?

People are also working on fixing many of the problems raised by Paul Philips,
with Scala 2.11 being a result of that work. And oh look, Paul Philips is
still on the contributors list, amongst many others: [http://scala-
lang.org/news/2014/03/20/release-notes-2.11.0-R...](http://scala-
lang.org/news/2014/03/20/release-notes-2.11.0-RC3.html)

You're doing both an _appeal to authority_ for an otherwise unconstructive
criticism (yours, not Paul's) and an _ad-hominen_ in absence of actual
arguments. Also for a random fanboy, at least I'm putting a real name behind
my 2016 days old account ;-)

~~~
copergi
>GHC can be freakishly slow

So can scalac. Many compilers have pathological performance cases. Just
repeating "the sky is green" over and over won't make it so. It is well known
and widely accepted that scalc is slower than ghc. You don't have to like it,
or even accept it. But responding with nonsense strawman arguments as if I am
bashing scala is pathetic even by hn standards. You made false claims, I
pointed out that they are false. Quite simple.

>People are also working on fixing many of the problems raised by Paul Philips

Of course they are. Why do you think "people are fixing those problems" is
evidence to support your claim that those problems don't exist?

------
peterashford
I've only ever poked a little at Scala so my opinion isn't worth much, but
what the OP says about operator overloading gels with my C++ coding
experience. Everyone LOVES operator overloading when it's their own code doing
the overloading. When you start dealing with other people's abuses of OOL,
then it gets downright evil.

------
ninjakeyboard
"I call bullshit. I rarely generate code. I rarely write getters and setters."
You must be writing some crazy java.

~~~
RyanZAG
Not at all. Getters and setters are a nasty code smell that generally arises
when the author does not really understand OOP. You delegate to objects (tell,
don't ask). Delegate to objects generally means person.goToWork() and not
person.setIsAtWork(true). If your code is full of getters/setters you can
probably refactor it to be far clearer.

A more non-conventional Java (but very far from crazy) is to use property
accessors (person.name) instead of methods (person.getName()) for "data
objects" (structs, really). Some people are very much against it as they
believe it stops you being able to modify your object later, but I'd say
modifying the access behavior of a struct (eg, O(1) to O(n) access) is even
worse than forcing users to update their use of the object.

Anyway it's a far deeper topic than just "crazy java".

~~~
unclebucknasty
> _A more non-conventional Java (but very far from crazy) is to use property
> accessors (person.name) instead of methods (person.getName()) for "data
> objects" (structs, really)._

Yeah, it's a bit of a fallacy that requiring getters and setters (especially
as simple pass-thrus) for simple properties is required for "good" OO
(particularly that it maintains encapsulation). The bottom line is that
providing both getters and setters makes the property mutable just as it would
be via direct property access. Except now there's a performance penalty, as
you mentioned.

And renaming a property typically means renaming the getters and setters
anyway lest the property name no longer makes sense internally. Any good IDE
will allow you to accommodate either refactoring (property name or accessor
method names) with ease.

Initially, setters were also intended to allow the object to fire an event in
the case that it's Observable or otherwise participating in a listener-style
event system, such as that prescribed by the JavaBeans spec. But, in practice,
that pattern is followed so rarely that it hardly merits forcing all of that
baggage on _every_ value object ever written.

~~~
RyanZAG
The performance penality I'm talking about is far more tricky than just the
little bit of overhead on a method vs a property. Take this simple data object
as an example:

    
    
      class Person {
        public int age;
      }
    

Now a 'best practice' is to create getters and setters:

    
    
      class Person {
        private int age;
        public void setAge(int age) { this.age = age; }
        public int getAge() { return this.age; }
      }
    

This obviously makes the code uglier. This is done because maybe in the future
you'd want to change the implementation of how age is stored inside the
object. However, I think this is exactly where nasty performance bugs can slip
in. Accessing 'age' or 'getAge()' are currently both O(1) operations with
'age' being slightly faster. However, 'age' will always be O(1) as guaranteed
by the language, so using it inside a tight loop is fine. However, what
happens if we modified our getAge() to be O(n) because we wanted to store age
differently? eg:

    
    
      class Person {
        private List<Integer> subAges = ...;
        public void setAge(int age) { ... }
        public int getAge() { 
          int age = 0;
          for (int subAge : subAges) {
            age += subAge;
          }
          return age;
        }
      }
    

What we've done here is utilize our ability to change our getAge method
without impacting anybody who is using our class. However, we've turned our
getAge from O(1) to O(n) with absolutely no warning to anybody using our
function. We've caused far more harm than simply requiring other developers to
update their code - we've sabotaged the performance of all the users of all
the software that uses our library.

So imo the 'benefit' you get from getters/setters is more of a danger than
anything. If the implementation of a library changes enough that you need to
change your data access objects, you should just release a completely new API
anyway as all the assumptions made by users of your library are now right out
the window.

------
istvandobai
> I’ve been developing software professionally for a whopping 3 years.

So much experience! Scala isn't for the beginners.

> I’ve given irrefutable scientific evidence on why Scala will make you less
> productive.

Yeah, science! Those are just your opinions not scientific evidences. You're
just don't know how to program in other languages(only in simple languages as
java, javascript and python).

~~~
primelens
While you might not agree with his account of Scala, saying that folks who
only know "simple languages" like "Java, JavaScript and Python" are
unqualified to comment on Scala is just bizarre. Pray tell what you consider
to be a language that would make a programmer worthy of Scala.

