
The state of the Scala website and documentation - 0xmohit
https://groups.google.com/forum/#!topic/scala-internals/r2GnzCFc3TY
======
danpalmer
This pull request showed me just how much the Scala community values good
documentation:
[https://github.com/playframework/playframework/pull/6545](https://github.com/playframework/playframework/pull/6545)
– tldr: not much.

I work a lot with Django, and the documentation is amazing. It's up to date,
cross-referenced, everything is linked to everything else, code is executable,
etc.

Here, rather than a 2 line fix to make the code in the examples executable and
explain how some data is being used, the maintainers opt to keep the code
examples non-executable, and obfuscate the code, expanding explanations in
text to make up for it.

Documentation is important. If someone doesn't understand it, the project
should make a sincere attempt to understand why, take on feedback, instead of
shutting down discussion and dismissing someones lack of understanding.

~~~
dozzie
> This pull request showed me just how much the Scala community values good
> documentation:
> [https://github.com/playframework/playframework/pull/6545](https://github.com/playframework/playframework/pull/6545)
> – tldr: not much.

Erm... But the change was shitty. How would _that_ make good documentation?
The phrase just before said "Here's example JSON", and the JSON got changed to
Scala code. How is that indication of appreciation or not of good
documentation?

~~~
smallnamespace
Not to mention the same doc page already showed how to convert JSON into a
Scala value earlier.

------
philipkglass
Scala was my first serious use of a JVM language and I kept hitting little
rough patches that people were assumed to understand from a prior Java
background. One example: a month or so into my use I started getting a
puzzling failure when sbt was trying to download a dependency. Everybody
already knows about Java's security certificate handling, Ivy, and Maven,
right? I didn't. I kept on Googling the wrong terms because I was searching
for Scala and sbt. The problem turned out (IIRC) to be a dependency download
attempt that started from a URL whose certificate was trusted and then got 302
redirected to a mirror whose certificate was not yet trusted by Java. The
error messages that actually showed up in my console were not at all helpful
and I ended up using tcpflow and a Java-savvy colleague to figure out what was
actually happening. Would it be so hard for (e.g.) sbt to provide an
interactive security prompt for if you want to trust a remote source's
security cert, rather than expecting you to figure out the error message and
solve it the Java way with plain Java tools? (Maybe it would be hard. Maybe
that's why it doesn't do that. I don't know because I _didn 't use Java before
Scala_.)

I don't have concrete examples to hand for the other rough spots but I recall
hitting other areas of knowledge that are explained via Java instead of
standing on their own. "The Scala Bar is like Java's Foo, but with these
improvements..." I never learned the Java Foo and I don't really want to have
to acquire a working Java developer's knowledge to use Scala. I'm using Scala
and not Java. If you're writing docs for Scala and the reader needs to know
something important about either Java-the-ecosystem or Java-the-language,
please inline that knowledge.

~~~
lmm
I wouldn't recommend SBT, especially for beginners (Maven is much better
documented), but no, it can't give you a prompt because programs don't have
access to modify the keystore by design. The JVM is one of the few platforms
that actually has a decent go at security, which sometimes means usability
suffers.

~~~
jackcviers3
To use scala effectively, you must use SBT. Almost every scala library and
framework is built using it. There are tons of productivity enhancing tools
wrapped in plug-ins for it. It is java, scala and scalajs aware, and
incrementally compiles large projects if you use it. The documentation for it
is good from version 0.12 on. You can learn 90% of what you need to do scala
builds in SBT in 4 hours by reading the documentation and the walk-through
tutorial. Eventually you may need to write your own tasks, but 90% of those
tasks are covered by the existing plug-ins available, and you can easily
modify or create a new task by writing some simple scala function on your
first day using the tool without having to publish a plug-in to some repo for
it to work.

I absolutely would reccommend SBT for beginner scala users. It's a must to use
and understand it, as much a part of understanding scala as understanding for
comprehensions, case classes, and if/else expressions.

~~~
denis1
Using SBT with Scala is certainly encouraged, but you can use other build
tools. At work we're successfully using gradle without too many problems. The
only things that are slightly weird are the not-so-perfect plugins for gradle,
but that is understandable considering they are mostly community driven
(sometimes only a one person even).

~~~
vorg
> the not-so-perfect plugins for gradle

Could be because Gradle up to version 2.x provided only Groovy for writing
plugins and build scripts. Gradle 3.0 was released a few months ago, and
provides both Kotlin and Groovy for plugins and builds, and even prefers
Kotlin for writing plugins. Perhaps the "not-so-perfect" situation will change
as plugin providers switch over.

I recently looked into Groovy's apparent popularity at #17 on the TIOBE
ranking and found Baidu was giving a result 12 times too high and Yahoo a
result 20 times too high, both of which would skew the ranking. Groovy's real
ranking is somewhere below that of #50 ranked Clojure. These results are being
used to promote Groovy as successful to the Apache Software Foundation
directorship. I can understand Gradleware wanting to switch to a language with
a seemingly more honest approach to promotion.

------
0xmohit

      We are basically filtering our audience down to people who can
      either invest plenty of time (to wade through the
      documentation/ask for help on the mailing lists and gitter),
      money (to pay for training or attend conferences) or both.
    
      ..
    
      I think it wouldn't be charitable to think that the state of
      documentation is a result of the involved parties' massive
      conflict of interest, as Lightbend (has partners that sell
      training), EPFL and ScalaCenter (receive money from commercial
      Coursera courses) all profit from the current situation
      financially.
    

This hits the nail on the head.

~~~
partycoder
Linus said once that if the only benefit of using C for Linux was excluding
C++ programmers, that was enough of a benefit.

Sounds really negative, but to be honest, sometimes if the only benefit of
Scala is excluding people that are not comfortable with advanced programming,
for a project that requires it, then great. You saved your recruiters the job
of looking over a lot of resumes that you didn't want anyways.

Scala is not incredibly hard. I am not gifted and I managed to learn it to an
extent in which I could solve practical problems.

That being said, I think learning Scala comes out more naturally when you have
some exposure to Java. Since many Scala constructs are really shorthands for
longer Java code.

I have to accept though that some people go really hardcore on the functional
side (like the typelevel/scalaz folks) and that can be really intimidating.

~~~
the_af
> _I think learning Scala comes out more naturally when you have some exposure
> to Java._

My experience at the office is different. I come from Java, but I've seen
people who literally _never_ programmed in Java or any other Java-like
language succeed with Scala (and then they get horrified when they find out
what Java looks like). They have none of the bad habits that come from years
of writing Java code. It's enlightening, really. A few years ago this
experiment wasn't possible -- _of course_ everyone doing Scala was a Java
expat. Not anymore, though!

I couldn't disagree more with you about excluding people. Excluding newcomers
is always bad, but also, don't people "comfortable with advanced programming"
deserve good documentation? Of course they can and will succeed in the absence
of it, but only after wasting valuable time.

Linus' statement is controversial and shouldn't be quoted as gospel. In any
case, he argued against C++ programmers because he thinks they -- and their
chosen language -- _suck_ , not because of advanced programming or whatever
(note: not my opinion!).

~~~
partycoder
(That's why I started saying "I think", to emphasize it's an opinion rather
than a fact.)

My personal experience has been that it is easier to explain people Scala when
you can explain it in Java construct terms... But I can see how someone coming
from, let's say, Swift, can have an easier time writing idiomatic Scala.

I am against excluding people for the sake of excluding people but you need to
consider that communities have some core values, and the core values behind
the Scala community are different to that of, let's say, PHP. You know what I
mean.

~~~
the_af
I fully agree about the community values, but how is having no good
documentation helpful for building said community?

Also, it'd be VERY disappointing if the reason for this lack of documentation
was the explanation from the root comment in this thread.

~~~
adriaanm
As the Scala team lead at Lightbend, I'm truly saddened to see posts like
this. It couldn't be farther from our intentions and interests! We absolutely
want outstanding Scala documentation, and would never stand in the way of
improving them in any way.

My whole team has worked extremely hard this year to bring you the best 2.12
compiler we can. We also spend as much time as possible helping out with
polishing documentation, but we feel a coordinated push for better
documentation belongs under the umbrella of the Scala Center (whose mission is
to "Independently guide and support the Scala community" and to "Provide deep,
and quality, educational materials for Scala"). We'll be thrilled to
collaborate, but we (as veteran Scala users) are not the best placed to write
getting started guides.

EDIT: It was brought to my attention that my comment about the Scala Center
could be misinterpreted. I meant to say I would support a proposal to the
Scala Center advisory board about improving Scala's documentation, with a
focus on the getting started experience.

~~~
thisone
Let me give you a 'fer instance' (this may be the only one that exists, but
it's one that had me WTFing until I found the correct documentation to read
via stack overflow)

Calling grouped on a Seq.

I've been playing around with some API requests, and needed to batch a long
Seq to make reasonable sized GET requests.

So I called grouped on a Seq, then to sanity check I called .length on the
grouping.

Then suddenly I had an empty iterator.

Maybe I should have known better, yeah, but the documentation I was reading
[http://www.scala-lang.org/docu/files/collections-
api/collect...](http://www.scala-lang.org/docu/files/collections-
api/collections_4.html) doesn't mention this fact about iterators. Again,
maybe I'm the only person in the world who didn't realise the problem with
calling .length on what I thought of as a regular old batched set.

It wasn't until I hit on the right google combination that I found
[http://www.scala-
lang.org/api/current/#scala.collection.Iter...](http://www.scala-
lang.org/api/current/#scala.collection.Iterator) from a stack overflow
reference, and the lightbulb finally went on.

~~~
adriaanm
Thanks for the example. We agree that this is a tricky part in the
collections. For Scala 2.13, our headline feature will be simplifying/refining
the collections API. One of the areas we'd like to improve is to make the
transitions from eager to lazy more clear. Also, we'd like to keep immutable
(more) separate from mutable collections. Once we switch gears from 2.12.0 to
2.13 milestones, we'll be sure to provide a convenient way to share gotchas
like this, so we can see how to prevent them.

------
alyandon
I think the author hit upon some pretty good points. Several years ago when I
started poking around Scala I really had to push myself to work with it and
especially with respect to simple thigns like do I download SBT or Scala. One
of the more personally frustrating things I found as a newbie is that the bulk
of the documentation seemed to be written as a reference. Compounding that was
the un-googlable nature of some of the operators like ":<" which really made
things more difficult than I felt that they needed to be.

Regardless, although it was not what I would describe as a pleasant
experience, after working with Scala for a few months I definitely found
languages like Haskell a lot easier to comprehend. So, I obviously managed to
internalize something. :-D

~~~
Fiahil
> Compounding that was the un-googlable nature of some of the operators like
> ":<"

Ah! _souvenirs_

"\- [..] Oh, but you have to use the _epaulette_ function!

\- The what?

\- The epaulette! (>>>) it's like the zigouigoui, but you don't have to lift
anything. Just flatMap that shit and you're good."

~~~
saosebastiao
My biggest technical complaint about Scalaz. You can't effectively communicate
concepts that involve nameless symbolic constructs, and slang as a replacement
is inherently exclusionary.

~~~
znpy
This reminds me of that short time I've been working with scala... I honestly
think Scala is Perl on the JVM. I mean, the write-only unreadable-code part of
Perl, but on the JVM.

~~~
the_af
Can you provide examples? There's a lot to criticize in Scala, but I can't
find many examples of symbol soup, especially in user-written code. There is
_some_ , sure (most languages suffer from this to a degree), but so many you
consider the language write-only? I just don't see it.

Keep in mind Scalaz is not Scala.

------
1_800_UNICORN
Interesting discussion. Thanks for posting.

As I've gotten to learn many different languages (PHP, Ruby, Go, Java, Python,
etc) over the last 10 years, it has been really interesting to see how
different languages and communities can vary so wildly in their quality of
documentation.

As it relates to programming languages, Go's "Tour of Go"
([https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1)) is an
excellent introduction to the language. I wish every language had an intro
guide as good.

In terms of frameworks, I absolutely love the Ruby on Rails guides. They
strike the right balance between staying high level enough for me to build a
mental model of how the framework is working under the hood, while getting
deep enough to be useful to solve individual problems I have.

Overall, I think the Ruby community has done a great job of documenting their
libraries and frameworks. Whether it's Rails or Sinatra, or it's a library
like Devise, Ruby OSS projects seem to tend towards thorough documentation.

On the flip side, Spring's documentation (and most Java library documentation)
is absolutely atrocious. Spring in particular only seems to give you 2 flavors
of documentation: a 10-minute tutorial, or a 1000-page deep dive in all of the
corners of the framework. And Java libraries in general seem to have
miserable, out-of-date, incomplete documentation.

~~~
heartsucker
Since this is all about docs, having gone from Java/Scala to Rust, I cannot
emphasize enough how much better Rust is at this. With `cargo doc` I get a
local set of static files for the exact version of the libraries I'm using.
Why can't everything be this easy?

~~~
agentgt
It is that easy with Java/Scala... if... you are using an IDE.

Eclipse through the maven plugin (m2e) will auto download the source code and
will show doc as you code (along with drilling into the code. Intellij does
something comparable as well. Racer can do this as well (and I admit far nicer
in that it is editor agnostic).

The problem is the tools for Java/Scala are all over the place so developers
have different experience with the language that probably have very little to
do with the language itself (syntax and libraries) but rather the tools.

I would agree Rust is not the norm and IMO perhaps even the gold standard of
what modern language organization and tooling should be.

Java/Scala should probably have better builtin tools (or atleast mutually
agreed on tools like auto formatting, editor agnostic completion /refactoring
(ala racer), package management (Java is actually decent on this as maven is
the standard), etc).

------
Fiahil
I write Scala code professionally, and the language documentation is the worst
I've encountered. Luckily, I've leveled-up to the point where I don't need it
anymore and can just lookup prototypes and comments directly in the source
code when I need it (thing almost everyone is doing after a certain time,
btw). I understand the frustration of beginners, and I've even began to host
talks/presentations, inside my company, for a few coworkers. I hope to get
them past, at least, past the few interesting concepts and the shitload of
symbols/operators/random-combinations-of-chars-on-my-keyboard that you
encounter on a day-to-day basis.

~~~
cle
This is not an excuse for poor documentation, but I've found that not relying
on documentation in general vastly improves my productivity. It requires being
comfortable digging into the innards of the libraries and frameworks I use,
which helps me understand performance characteristics, extension points,
understand stack traces, understand failures when they happen, find bugs,
learn language idioms, etc.

------
runeblaze
The website of Scala.js is devoid of some of the problems mentioned. It has an
in-browser playground, a getting started guide that uses sbt and follows
development conventions, and a useful list of libraries. Maybe Scala can learn
a bit from Scala.js?

EDIT: small grammar error

------
geodel
It could be the case that Scala language and docs are really done from
perspective of maintainers. When I look at commits this year on github [1],
there are about half dozen people making significant contribution and most of
them seems to be associated with Lightbend. Other popular languages e.g
Java/Rust/Swift/Go have very vibrant commit activity from lots of contributors

[https://github.com/scala/scala/graphs/contributors?from=2016...](https://github.com/scala/scala/graphs/contributors?from=2016-01-03&to=2016-10-15&type=c)

------
allengeorge
I am completely unsurprised. I've been pretty negative on Scala in the past,
and this is one of those reasons. The community does not feel inclusive and,
my perception is that as a beginner you're simply expected to deal with the
lack of documentation, the odd behavior of the tools, etc. And that (frankly)
makes me fairly uninterested in contributing back to it.

I wonder if it's because many people who stay with Scala are more interested
in the many advanced language features it offers, as opposed to building
libraries to be used by day-to-day practitioners (who have very different
metrics for deciding if a library is worthwhile or not).

~~~
runT1ME
I'm not sure what you mean by building libraries to be used 'day-to-day'. If
you mean that the Scala community is in general more interested in building
libraries/tools used by professionals than hobbyists I'd agree, but I can't
think of any popular libraries that aren't used day to day by all of the
developers on our very very large scala team.

~~~
allengeorge
Out of curiosity, which libraries does your team use?

~~~
runT1ME
Scalaz, Scalaz-Stream and http4s constantly. Doobie, Spray, Shapeless,
Monocle, and others less often but still definitely more than rarely.

------
cutler
Scala's poor documentation stems from a much more fundamental problem - the
absence of a Clojars/Rubygems/PyPI for Scala libraries. It's in the process of
being fixed now, I believe, but why did it take so long? The Clojure community
has a much lower profile in industry than Scala yet right from the beginning
they really valued their community and produced an excellent repository for
Clojure libraries and an easy-to-use build tool - Leiningen. The Scala
community, by contrast, comes across to outsiders as just not that interested
in community. Maybe it's the Java legacy.

------
bigredhdl
Personally this is interesting to see after I just recently tried to learn a
little Scala to see if I could realize the promise of a fluid front-end to to
back-end experience between Scala and Scala.js. I eventually gave up in defeat
because the documentation and tools just didn't make for a smooth enough
jumpstart for me. Maybe people coming from Java just already have enough
prerequisite knowledge to get past that but for me I just wasn't progressing
very fast. I had a much easier time progressing in Elixir/Phoenix and Elm
recently and to a lesser extent F#. Just my two cents...

~~~
sotojuan
Elixir shines by how easy it makes it to write good documentation.

The Markdown-renderd docstrings for modules and functions can be converted
into nice websites[1] or are available in the command line[2].

[1] [http://elixir-lang.org/docs/stable/elixir/Enum.html#map/2](http://elixir-
lang.org/docs/stable/elixir/Enum.html#map/2)

[2] [https://i.imgur.com/RhS283f.png](https://i.imgur.com/RhS283f.png)

------
bsder
Excellent. I can now point to this for a good objective reason to not use
Scala.

Actually, I'm really sad. I used Scala back in 2005 (Edit: Corrected from
2001?) (God, I'm old) for it's Actors model to do peer-to-peer networking
protocols. It was SOOOOOO much better than C/C++ and I could deploy stuff
_without installation_ across multiple architectures.

I'm especially sad because it seems like Scala always needed just a little
more sustained effort on the community front to move into the big time and it
never really got it.

~~~
hocuspocus
Scala came out in early 2004, Scala 2.0 in 2006 and I'm not sure about actors
but probably not before 2007.

In 2001 Martin's lab was probably working on Pizza / Java generics :)

~~~
bsder
You are quite correct, I just looked at one of the domains I registered for
that and the date was 2005.

As for actors, I was _definitely_ using alpha level stuff. So, your dates jibe
with that.

Apparently I'm getting old enough that my memory is getting faulty. :)

Now, if I could only figure out how to do strikethrough for edits...

------
philipkglass
I remembered another thing that Java users already know but surprised me in
Scala in a bad way: null. I read a lot about Scala's type system in the week
between I was hired to write Scala and when I actually started writing code.
Most of it was about how great Scala's type system was and how much safety it
provided; the company even called itself Typesafe then. I read many paeans to
the virtues of Scala's type system that would turn runtime errors into compile
time errors, but they didn't highlight that it can't prevent that most common
and annoying of Java runtime errors, the NullPointerException. Due to a lack
of prominent mentions in the Scala docs and tutorials I read, I thought that
Scala authors either didn't have to think about Java's Billion Dollar Mistake
or that the compiler would guide them to safety before the code could blow up
at runtime.

Maybe manually dealing with nulls is supposed to just be assumed by anyone
using the JVM... But I'd used Jython a little in the past and I didn't have to
explicitly deal with null-checking then. Jython converts null to None. In the
absence of prominent warnings to the contrary I had thought that Scala would
provide at least as much automatic safety as Python-on-JVM does.

~~~
aianus
The correct way to handle this in Scala is to wrap the possibly-null reference
(which I assume you're getting as a return value from some Java library) in
Option(), not manually checking for null.

~~~
philipkglass
By "manually checking" I mean that I have to use my own brainpower to notice
places where null can leak in to code I'm writing; the compiler doesn't
actually enforce the type safety I thought I had. I do use Option to handle
sometimes-nulls after I notice them.

EDIT: since Jython doesn't allow raw nulls to leak in from Java libraries, and
Kotlin prevents accidental use of nullable values at compile time, it naively
_seems like_ Scala could prevent accidental null introduction despite living
on the JVM. Or as a distant second-best, prominently warn about the perils of
null whenever introducing its type system to beginners.

~~~
yawaramin
Aren't Jython `None` values essentially `null`s? But, Kotlin, Swift, and
others are starting to get it right. Scala will follow suit--the plan is for
'Dotty', the next major version of the Scala compiler, to represent nullable
types explicitly as `A | Null` (`A` or `Null`). Without that explicit type
there will be no way for a type to hold `null`.

Until that happens, in Scala we continue to work through in the presence of
potential nulls by wrapping stuff that comes from Java APIs in `Option`s and
never explicitly returning `null` from any Scala APIs.

------
horusthecat
I really wanted to pursue Scala. It looked promising: runs on the JVM, is far
saner than Java, has features that keep the "Java 1.4 was the last real Java"
crowd away, has a mixed-paradigm OO/FP approach, lots of features... things
like all the FUD over compile times and performance didn't really bother me
(if I cared about resource usage/performance, I wouldn't use the JVM, duh).

I found two classes of problems.

The first was the lack of practical guides. How do I access a database? Should
I use a Java lib for that? What about a rudimentary CRUD app? What if i need
something Java-EE-ish, like a message queue/IPC? I kept finding myself in
scenarios where I had to reach out to Java, which I was deliberately trying to
migrate away from.

Second, there's the fact that Scala has full OO along with the ML-style FP,
which makes it hard to figure out if I was doing things the "right" way. Do i
use traits and composition and case classes? Should methods go on classes?
What's up with the Object pattern? Do I store state on classes or should I
prefer case class/record types? When is it a judgment call... and if it is a
judgment call... how do I make it without much experience in the language or
having any experienced Scala users to guide me?

I'm not averse to spending $100 on books and working through them. I tried
that with Scala, but somewhere around page 200 of Programming Scala, gave up.

Then there's the scare factor, there are so many "we're switching from Scala
to Java 8" or "we already use Grails" that it was looking like it was turning
into a dead end professionally very quickly, especially outside of
DC/NY/SF/Chicago. One job I was looking at told me they were moving _all_
their Scala work into Java because of client pressure.

The bigger irony being that I started using OCaml instead, a language where
the documentation is usually just an interface file and type signatures.

------
partycoder
Scala documentation is a bit hard to understand, some articles do not have a
good balance in their level of detail... e.g: documentation for Futures and
Promises. I use text-to-speech to read it since it can be a bit dense.

Scala.js is great, but it is different (numeric primitives, threads, to start
with).

------
petetnt
I dove deep into Scala a short while back and I can concur with those that
thought the documentation was sub-par almost all around, from Scala-Lang site
itself, to big things like Play Framework to across small userland libraries.
The saddest thing was that I wanted to improve those docs, but I didn't know
how. When I finally got to the point through tedious trial and error, I
couldn't even remember where to start. It doesn't help that there's 10 ways in
Scala to do everything, but no way to find out which is the best one, or the
worst, or one that even just works with your current version. Surely this the
tone of this post is quite whiny, but it really did make Scala hard as hell to
approach.

------
pm24601
I find this incredibly sad. Plenty great products/languages have died because
of poor documentation, poor respect for beginners.

Yet... here the Scala community is... repeating the past and justifying with
the same reasons.

I personally only spend time learning a new language when:

1\. I can get employed because I know it. (example: python)

2\. It is easy to pick up and learn. (example: arduino )

3\. It solves a problem I must solve ( perl/bash scripting )

Scala doesn't meet any of the above criteria.

~~~
tormeh
If you can program Java you can program Scala. You can't write _good_ Scala
code, but that (hopefully) comes with time. Scala solves the same problems
Java does, just better. And there are lots of jobs for Scala. Not as many as
there are for Java or Python, but maybe as many as for Ruby? I'm not sure
exactly.

~~~
bsder
> If you can program Java you can program Scala.

Clojure would probably be my choice nowadays rather than Scala.

Clojure has a great community and is a good counter example to the Lisper's
whining that the syntax is what keeps people away.

If I truly needed Actor stuff for performance, I'm probably going leave the
JVM and reach for Erlang anyway.

~~~
the_af
Clojure is great, but the more natural progression is from Java to Scala, not
to Clojure, if only because you can program in Scala as if it were Java++. You
won't write the best Scala, but it will work and you can look at it as "Java
with weird syntax".

Going from Java to Clojure requires a major mental shift :)

~~~
bsder
> Clojure is great, but the more natural progression is from Java to Scala,
> not to Clojure, if only because you can program in Scala as if it were
> Java++.

The problem is that I can program _Java_ as Java++.

Java 1.8 still has its warts, but are they worth the shift to Scala? Maybe?
But it would really have to be a compelling reason.

For example, people _still_ often don't know about java.util.concurrent. 99%
of their concurrency problems could be solved simply by grabbing the correct
data structure out of there.

If they can't be bother to know something as easy as that, what real hope do I
have of them really using Scala well?

~~~
the_af
> _Java 1.8 still has its warts, but are they worth the shift to Scala?_

Oh, yes. Few who've had to deal with both a Java 8 and a Scala codebase are
going to tell you otherwise. Java 8 is like Scala through blurred glass.

Another thing is that Java 8 is Java++ only _now_ , after many of us have
already adopted Scala. In other words, "too little, too late" :)

Regardless, are we discussing whether it's good idea to adopt Scala coming
from Java (I think it is!) or whether the transition from Java to Scala is
easy? I thought it was the latter, and if so, it's unarguably easier than the
transition from Java to Clojure. Scala "looks like" Java in a way Clojure
doesn't.

~~~
bsder
> Regardless, are we discussing whether it's good idea to adopt Scala coming
> from Java (I think it is!) or whether the transition from Java to Scala is
> easy? I thought it was the latter, and if so, it's unarguably easier than
> the transition from Java to Clojure. Scala "looks like" Java in a way
> Clojure doesn't.

A bit of both. How's that for a hedge? :)

Admittedly, I'm coming back into Java with 1.8+ and don't have a legacy
codebase to deal with. So, my calculation as to whether Scala is worth the
cost is quite skewed from someone who has been doing it since Java 1.4.

Is it easier to transition from Java to Scala than to Clojure? Maybe. But the
people who can make the Scala transition also seem to be the same people who
can make the Clojure transition.

And, I think _that 's_ the core problem for Scala. The features that make
Scala compelling aren't a nice, slow, logical evolution from Java.

------
ape4
How about the speed of the compiler? Last I used Scala, that was the deal
breaker for me.

------
Noseshine
That's interesting. Just a few days ago with great regret I decided to drop
the (free) Scala course on Coursera after almost finishing week #3 (of 5 I
think). I'm actually already pretty familiar at least with the essentials of
functional programming but would like to go even deeper.

However, I found the step too steep between the easy to understand lectures
and the exercises, and the latter not as useful as they could be. It felt like
I was suddenly dropped off and left to my own devices with no guidance. "Now
implement this!" Uhm... what? Sure, that's easy, I've been implementing much
more complicated things for decades. The problem is I have no idea how to
approach it "the right way" as far as Scala is concerned, that's why I'm
taking the course!

Looking at the forum - extremely sparsely populated even after over 4 months -
showed that I could also expect no guidance from there. That meant that even
when I finished a task I was unable to find out if what I had done was the
right (functional) way. For one and most importantly, there is hardly anyone
to respond, but also since the only exercises are the homework assignments you
can't just post your code, that's an "honor code violation". There also is no
"solution", i.e. you can't see how the course author(s) would have implemented
it.

Another example, people in the forum complained about extreme differences in
performance for very minor differences in the way you wrote something, and you
had to find all of this out completely for yourself, again no guidance at all.

Another point is that I found the problems too academic. Sure, I can walk a
list of head.tail or a tree of left.element.right tuples. But overall the
problems were all from what I did a long time ago at university and it felt
very, very far from what I deal with now - and I don't just do CRUD or other
boring stuff and actually _do_ have interesting algorithms to implement. The
course feels like being made for university students - in a negative way.

Overall I found the course more frustration than it was worth. I could have
solved the programming challenges easily enough in a way I already knew, but
what's the point? I wanted to learn the _new_ (Scala) way, but felt all alone
in trying to do that.

The course was like a good violin player demonstrating a piece and then giving
me some sheet music and shoving me out the door "come back when you can play
that". It's hard to complain about "free", but if course forum participation
is a guide, both total numbers as well as the steep drop-off after week 1 and
2, it isn't very successful.

The course:
[https://www.coursera.org/learn/progfun1](https://www.coursera.org/learn/progfun1)

Note: Enrolling in the courses individually is possible for free, going
through the "specialization" page at
[https://www.coursera.org/specializations/scala](https://www.coursera.org/specializations/scala)
only shows the for-pay option.

~~~
the_af
I actually liked the progfun1 course, which I took a few years ago. It's one
of the cleanest courses I've taken on Coursera. It's true that it's slightly
"academic", but that's what many introductions to functional programming often
feel like.

However, the follow-up courses, Reactive Programming (retired) and Functional
Program Design, are a total let down. They are a rip-off, especially if you
paid for them: a complete mess, no relation between lectures and assignments,
no introduction of new concepts in relation to a greater context, the slides
are not proof-read, constant mentions to non-existent slides and lectures,
repeat material from previous courses (a side-effect of the courses being
mash-ups of previous material), and example code that doesn't type-check or
compile. It's not any single mistake, but the aggregation of them all, and the
feeling that the authors just don't care enough. Thankfully I didn't pay for
this.

In my opinion, the gold standard for Coursera is Dan Grossman's excellent
Programming Languages, which I fully recommend.

~~~
davnn
I share the exact same story. Progfun is a really smooth introdu tion to FP in
my opinion, no crazy syntax and only the core concepts. For any deeper
concepts and if you don't understand what FP really means you should check out
a purely functional language.

~~~
Noseshine
Just to clarify my opinion on progfun: The lectures are good.

The coding tasks _could_ have been okay - if there was _any_ guidance. I don't
even get to see any sample solutions. So even if I make it work, I don't know
if that is a good way to do it, the "functional", the "Scala way". And the
performance issue I mentioned, it was a major one, the difference between the
code even being usable for more than a thousand elements in the list or
getting a stack overflow, and the difference was extremely minor, in one case
the order in which you called "union" on sets. All of that had to be found out
by the _students_ , and even after they found out nobody really had a good
idea or explanation for _why_ it was so.

Also, there only was one (small!) opportunity to actually practice what you
just learned per week - and that came without any feedback apart from
"works/doesn't". Since the course was about a particular programming _style_
that really wasn't enough.

------
jomamaxx
A production is only as good as it's training and docs.

I would go a step further: 'Training and Docs ARE the Product'.

Having bad docs is like selling a car without wheels -> It's not a car :),
rather, not a thing that 'solves the problem of getting people from point A to
point B'.

My experience with Scala has generally led me to concur with the overall
assessment that Scala information and communication is pretty weak.

Hope they can improve it, it's a pretty cool language.

