Another Scala rant on HN

17,118 views
Skip to first unread message

martin odersky

unread,
Dec 2, 2013, 4:32:15 AM12/2/13
to scala-debate, scala-internals
Seems hardly a weekend goes by these days without another Scala rant that makes the Hacker news frontpage. 


This week-end's edition is called "Scala - 1 Star - would not program again", and it's by someone who from reading his post seems to have written Scala all of two weeks after coming form Javascript. I think the interesting bit is not so much that these posts are written, but that they are upvoted so much. 

There certainly seems to be a grand coalition of people who want to attack Scala. Since this has been going on for a while, and the points of critique are usually somewhere between unbalanced and ridiculous, I have been curious why this is. I mean you can find things that suck (by some definition of "suck") in any language, why is everybody attacking Scala? Why do you not see articles of Rubyists attacking Python or of Haskellers attacking Clojure? 

For me the main reason is that programming languages are incredibly tribal and Scala has no traditional community - the functional/object-oriented programming "tribe" is still in its formation state. People are coming to Scala from all sorts of communities: Java, Ruby, Haskell, you name it. 

Scala's generality makes it both a threat because it *can* do tasks that are traditionally the domain of these other communities and an easy target because every community finds something that is foreign from their point of view. Java people will bitch about how academic FP is, JS and Ruby people complain about the types. Haskell people complain about the objects and that the types are not strong enough. And even though those communities would normally never mix, they find common ground in the opinion that Scala is a horrible language. 

What can we do about it? Not that much I fear, but there are some bits that are useful nevertheless.

 - Work on the things people tend complain about, as long as this makes sense. 

     + we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this
        is no longer that much of an issue.
     + we are working on compile times and expect to have significant progress to announce for 2.11
     + we are working on making binary compatibility less of a problem
     + we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.

 - Work out the simple parts of Scala. Show that Scala hangs together rather well, that it has a fairly modest footprint, and that it is definitely not twice the complexity of C++ as one poster on the thread claimed.

 - Work more on forming the community. Make it clear that Scala is a third way, it wants to be neither a Java with semicolons nor a Haskell on the JVM. 

 - Work on giving more guidance what good Scala code should look like. For instance, develop a detailed, type based lint tool with configurable complexity. Or think about what useful design patterns in Scala are.

 - Last, but not least, engage in these discussions on HN and elsewhere in a polite but firm way. State where your experience differs from the other posters. When somebody complains about long compile times, state that incremental compilation works well for you (if it does, that is, it certainly works well for me by now!). But don't attack the other poster even if you find their arguments lacking, that usually just leads to a mud-fight.

If you think of other constructive things we could do I would be interested in reading them!

[Follow-ups to scala-debate, please]

Cheers

 - Martin

Dennis Haupt

unread,
Dec 2, 2013, 5:23:57 AM12/2/13
to martin odersky, scala-debate, scala-internals
is kotlin experiencing any of this, considering it is, at least from my viewpoint, scala without implicits?
given that it is "intellij idea only" for now, shouldn't it be bashed even more?
 
what i would do if i invented scala and wanted to protect it is to prepare a few pages containing "hard numbers" or statements from happy companies and simply putting links the prepared pages into every discussion where "scala sucks" is mentioned, and tell my minions to do the same
 
 
Gesendet: Montag, 02. Dezember 2013 um 10:32 Uhr
Von: "martin odersky" <martin....@epfl.ch>
An: scala-debate <scala-...@googlegroups.com>
Cc: scala-internals <scala-i...@googlegroups.com>
Betreff: [scala-debate] Another Scala rant on HN
--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

martin odersky

unread,
Dec 2, 2013, 5:46:36 AM12/2/13
to Dennis Haupt, scala-debate, scala-internals
On Mon, Dec 2, 2013 at 11:23 AM, Dennis Haupt <h-s...@gmx.de> wrote:
is kotlin experiencing any of this, considering it is, at least from my viewpoint, scala without implicits?
given that it is "intellij idea only" for now, shouldn't it be bashed even more?
 

It's not bashed, because it is not a threat to other communities. First, it's very young so does not see widespread usage yet. Also, it is more focussed on being a better Java than a bridge between OOP and FP, so at least the FP community would simply ignore it rather than bashing it.

Cheers

 - Martin



--
Prof. Martin Odersky
LAMP/IC, EPFL
Station 14, 1015 Lausanne, Switzerland
Tel: +41 21 693 6863

Mushtaq Ahmed

unread,
Dec 2, 2013, 6:01:59 AM12/2/13
to martin odersky, scala-debate, scala-internals
I also work in the same company as the poster. We are currently running a huge Scala/Play project where the team is a mix of many young developers (< 5 yrs) and a few seniors. Overall it is a very pleasant experience. There are multiple other projects using Scala which share this positive feeling.

It is difficult to explain these reactions, but they are common among my colleagues. These are senior programmers who are generally very good with any programming language/task. They will pickup something new and be productive in just a few days. They usually end up liking Ruby, Javascript, Clojure and for good reasons.

Scala on the other hand requires a lot of attention and work to get mastery. One can get started in days but to exploit the real power and appreciate design choices takes months if not years. In my opinion this is an important factor why these smart developers react so badly to Scala which for them is just another tool which takes too much time to grasp.

There is little Scala can do. Maybe it should become less ambitious. No macros, no compiler plugins, do not challenge FP etc. But then it will not be the Scala we all loved :) Also, it is important to note the blog post does not criticise Scala in isolation. It used Spray DSL for routes and Gradle as a build tool, maybe that particular combination increases the pain.


--

Erik Post

unread,
Dec 2, 2013, 7:55:11 AM12/2/13
to scala-...@googlegroups.com, martin odersky, scala-internals
Hi,

On Monday, December 2, 2013 12:01:59 PM UTC+1, Mushtaq Ahmed wrote:
I also work in the same company as the poster. We are currently running a huge Scala/Play project where the team is a mix of many young developers (< 5 yrs) and a few seniors. Overall it is a very pleasant experience. There are multiple other projects using Scala which share this positive feeling.

It is difficult to explain these reactions, but they are common among my colleagues. These are senior programmers who are generally very good with any programming language/task. They will pickup something new and be productive in just a few days. They usually end up liking Ruby, Javascript, Clojure and for good reasons.

For what it's worth, I've noticed the same correlation wrt programmer seniority. My sample space is pretty small though. Also, I don't mean to suggest that certain criticisms are invalid, but it does seem as though it becomes difficult to shake off a certain approach to programming after having been at it for years and years. I'm thinking statefulness, mutability, towering inheritance, if-statements and instanceOf checks all over the place, etc.

Cheers,
Erik

Dennis Haupt

unread,
Dec 2, 2013, 8:03:30 AM12/2/13
to Erik Post, scala-...@googlegroups.com, martin odersky, scala-internals
my experience is "this is too close to a scripting language, too unreadable, unmaintainable". without ever having used scala, of course.
 
Gesendet: Montag, 02. Dezember 2013 um 13:55 Uhr
Von: "Erik Post" <eriks...@gmail.com>
An: scala-...@googlegroups.com
Cc: "martin odersky" <martin....@epfl.ch>, scala-internals <scala-i...@googlegroups.com>
Betreff: Re: [scala-debate] Another Scala rant on HN
--

Paul Hudson

unread,
Dec 2, 2013, 8:44:04 AM12/2/13
to Erik Post, scala-debate, martin odersky, scala-internals
Also, I don't mean to suggest that certain criticisms are invalid, but it does seem as though it becomes difficult to shake off a certain approach to programming after having been at it for years and years. I'm thinking statefulness, mutability, towering inheritance, if-statements and instanceOf checks all over the place, etc.

I can't see how this is doing anything other than suggesting their criticisms are invalid.

But  I think the idea that you're not doing Scala properly unless you're knowingly doing stateless, immutable, programming with typeclasses, monad. monoids etc is basically wrong, in any case.  Although just as wrong is the idea that there's something wrong with Scala because it does let you do that.

To pick up on Mushtaq's point above, using Scala to its full does require a lot of attention and work. But there's no reason that you have to use it to the full. You can continue with your own way of working and move to the 'better' way as and when it seems justified to you. However, I do think that the Scala community does tend to over-emphasise the 'master' level way of using it sometimes, with the result that code (and just the discussions) are ofte inpentratable to those not already familiar with Scala, and functional-programming theory too.

Too many (for me) Scala  examples remind me of the anecdote of the professor who is presenting a lecture and says "it is obvious..." , pauses, writes furiously on his lectern for 30 minutes, and resumes saying "yes, it is obvious".... "Clever" code, reasonably obvious once you've been through it in detail, but difficult for the casual/inexperienced user to work out what is going on.  

I like using Scala, it's just a better more productive way for me to get stuff done. I didn't start with it because I wanted to do FP, and I think we should recognise that's true for many/most people out there too.


--

Simon Schäfer

unread,
Dec 2, 2013, 9:23:41 AM12/2/13
to scala-...@googlegroups.com

On 12/02/2013 10:32 AM, martin odersky wrote:
> For me the main reason is that programming languages are incredibly
> tribal and Scala has no traditional community - the
> functional/object-oriented programming "tribe" is still in its
> formation state. People are coming to Scala from all sorts of
> communities: Java, Ruby, Haskell, you name it.
I think more important than that is that Scala is not yet divided into
smaller subgroups that survive more or less on their own (there are some
exceptions like the Scala Android group as I recently discovered).

In contrast, languages like Java or C++ are split up into many small
groups and all of them I met so far are bashing each other. But because
they are so small and exist only for a specific technology or a country
it is unlikely that their bashing reaches hackernews or reddit.

When I look today on StackOverflow, nearly half of all questions tagged
with 'scala' are only secondary related to Scala but more to play, lift
or some other frameworks. The same counts for scala-user. Two years ago
this was not the case. As long as all people with different needs try to
solve their problems on the same platform with the same solutions there
will be clashes.

I assume when Scala continues to grow, its community will split up in
smaller groups by itself - and with that the critique will move to the
part of the community that can handle it. And hopefully only the
constructive parts of critiques will move to the top and the rest will
be filtered out.

I don't know if its possible or even a good idea to interfere into that
process. I think it would be a good idea when the top page of
scala-lang.org already points out the different parts of the community
and helps to find the right one - there are frameworks like play, lift,
akka, libraries like shapeless, scalaz, language specific parts like
macros, fp, oo and beginner related stuff like tutorials, introductions.
Currently all of these parts have their own places but you get all of
this stuff at the same time. For people already familiar with Scala it
is not a problem because they have developed large filter mechanisms to
get only the stuff they are interested in, but I can understand that
beginners will be lost in that soup.

For me rants about bad IDEs, long compilation times, missing
documentation and so on are not the cause, they are just symptoms
because people find the wrong stuff at the wrong time and are therefore
frustrated because they don't understand how to compose all these parts
together.

David Riccitelli

unread,
Dec 2, 2013, 9:52:55 AM12/2/13
to scala-...@googlegroups.com, scala-internals
Hello,

First of all I would like to thank Martin Odersky and all the people that are contributing everyday to Scala and its ecosystem, like Typesafe, Mathias Doenitz, Endre Sándor Varga, the IntelliJ team their IDE and the sbt autoimport plugin by Pavel Fatin... (these are just a few of the names I crossed in my journey with Scala).

I started being "contaminated" by Scala about a year ago and I was immediately attracted by it, therefore spending plenty of my spare time to study and make practice with it, following the Coursera lessons, reading the few blogs around, watching recorded sessions on YT, participating to live screencasts or meetups.

I felt that Scala, bridging the worlds of OOP and FP, could and can solve some of the issues I lived while coordinating and participating in the development of complex systems, both from the stability and scalability point of view. The development paradigms expressed by Akka and Spray would help write decoupled code which is clean, stable, performant and scalable.

I was also impressed to see Spray climbing the score of the TechEmpower framework analysis (http://www.techempower.com/benchmarks/) and Scala being in the Adopt list of Radar (http://www.thoughtworks.com/radar).

I had and I still have the best of the intentions when I read blog posts, manuals, code samples and every word Martin writes on the Web (Martin, you have all of my admiration for being present and available to everyone, on StackOverflow, on Hacker News, on personal blog posts, ...) to grasp what's the right state of mind of a 'Scala' adopter.

I also published my own open source contributions (https://github.com/insideout10/open-street-map-importer - had no knowledge of Cake at the time) and looked for feedback from the community (https://twitter.com/ziodave/status/359216863005663232).

Indeed, reading the post by Giles Alexander just happened when I was getting somewhat frustrated and I am not sure what is the cause of this frustration. All I know is that I need to solve my frustration and either reach a new level with Scala (and related libraries) or take some distance (at least for a while).

I'd like therefore to provide my own (positive) feedback, probably you could imagine of me as an average developer wishing to take a step forward, available to spend his own energies and time, but loosing confidence about being "the right guy" for Scala.

Of the points you cited, I think this is one of the most important:
Work on giving more guidance what good Scala code should look like. For instance, develop a detailed, type based lint tool with configurable complexity. Or think about what useful design patterns in Scala are.

Things like your post about the Scala levels, http://www.scala-lang.org/old/node/8610, also feel very positive, providing a clear roadmap in progressing Scala among its vast amount of features.

When people talk about Scala, they don't talk only about the language itself but about its entire ecosytem (Akka, Spray, Slick, ...): I think that some effort must be put also in libraries design, development and publication. Developers (in the A level) must be able to use libraries and therefore these libraries should use understandable interfaces, maybe agree to some common guidelines (or at least clear guidelines consumers understand). A positive example is Akka actors, the ! and ? methods are straight and clear, like speech. Some more effort is indeed required with database frameworks where equality and inequality are getting replaced by === and =!= (IMHO this creates confusion and errors).

The API documentation should also be readable by level-A developers, maybe providing simplified views and advanced views according to the audience would help.

Martin, don't feel discomforted by the posts being written about Scala: I remember participating many years ago at an OSCON conference which was basically split in two non-osmotic worlds: the Java developers and Ruby/Rails developers. The Java community was seen as a monolithic corpus marching straight on its path. I believe Scala managed to crack this corpus like never before and is spreading fast. People are interrogating themselves about which direction to take.

All the best,
David

Dickon Field

unread,
Dec 2, 2013, 10:46:13 AM12/2/13
to scala-...@googlegroups.com
It may be useful to compare Scala, and its functional programming platform, with the recent history of OO. OO as of early 90s itself even then was not regarded entirely mainstream and attracted a lot of criticism. OO programming environments pre-Java came down pretty much to C++, Delphi and Smalltalk. C++ remained relatively hard work and fraught with platform details and niceties. Smalltalk was decidedly niche. Delphi consigned itself to become a rich client tool. Java made OO development easy enough and benefited from strong marketing from Sun. Then it benefited from a proliferation of freely available libraries, many of which were well designed.

Scala is a strong offering in the way that it layers functional programming on top of OO, builds on the Java runtime, and has some really nice libraries associated with it such as Akka, and abstractions around concurrency and failure such as Futures and Promises. Yes, there is a price to pay in terms of learning curve to access those benefits, but probably no greater than was the initial learning curve for OO. 

The 'threat' if one were to see it that way, is that Java 8 will offer enough of those benefits in an easy-to-swallow package that the majority will just stick with it, so once people have access to the benefit of function values, higher order functions and closures will they be motivated to seek the benefits of implicits, monads, partial functions, and combinators? The power of the compiler, macros etc will not be of interest to the majority of developers, although they may appreciate the benefits of having easy to use features integral to the language.

Given the installed base of Java and the potential of the Oracle marketing effort I am afraid the outcome looks stacked in favour of Java 8 at the moment, much as I love working with Scala. The sweet spot for Scala from my perception so far is real time asynchronous, message-processing, its difficult to argue with that - I'd make the most out of that in the short term, and that seems to be the tack with the current emphasis on 'reactive programming'.

Simon Ochsenreither

unread,
Dec 2, 2013, 10:52:03 AM12/2/13
to scala-...@googlegroups.com, scala-internals
Don't let yourself down.

It's the price of success. We are the only JVM language which manages to ship rock-solid update, minor and major releases together with IDE support and tons of eco-system and libraries on a impressive pace.
The language you designed has proven all the naysayers who claimed that it was impossible to combine FP and OOP in a useful way, or to achieve the productivity of untyped languages with the expressivity and safety of static languages wrong.

Haters gonna hate, but we will keep shipping software instead.

Andy R

unread,
Dec 2, 2013, 10:57:15 AM12/2/13
to scala-...@googlegroups.com, scala-internals
Hi Martin,

I'm quite new to Scala and am taking the reactive course. I love everything about the language and also the direction where its headed. However, maybe I can contribute with some criticism from a "new user" standpoint without any bashing:

1. Promote the improved incremental compile times better:
From what I've read online on HN etc, you've lost many enterprise users since those are the ones that tend to work on large code bases and could not deal with the long compile times. They left maybe 1-3 years ago from what I can tell. I've only ever used sbt 0.13 and my compile times are incredibly fast. I think it would help if there was an in-depth (blog?) post on scala-lang.org showing that the compile times have massively improved. Right now, many people (including me) simply reply to comments regarding compile times with "check out the latest version". It would be much better if there was a link-able post showing the recent improvements.

2. Documentation / Spec.
Let's say I want to know more about implicit in scala: I google "scala implicits", what shows up for me in America is these hits:
This is not good at all. The first post is dated 2008. This just makes users think that the scala documentation hasn't been updated. Yes I notice the huge banner on the top saying that this is old documentation (thought it could be more eye-catchy), so let's click on it:
ok, we're on the main page now. I guess I'll click my way through to the documentation, where it gives me:
- "Getting started" - surly don't want this. I want something specific
- "API" - nope, implicits are a language feature
- "Cheatsheets" - let's see... nope, nothing about implicits
- "Overviews/Guides" - let's see... nope, only implicit classes and macros.. :(
- "Specification" - hmm pdf, I don't want to write a scala compiler, moving on
- "Tutorials" - let's see: yes there is some about implicit parameters, but not too much. I guess it just touches the surface since it's a tutorial. No links to more details :(
- "Glossary" & "Common Questions" - No.
This was painful to find. The most comprehensive documentation would be in Chapter 7 of the spec PDF. But most people won't open a pdf. And how am I supposed to link to a section in the PDF? That's not practical at all. I wish there was a HTML spec like golang has:
This page is great. The entire golang.org page has great easy to remember URLs and you can find documentation about go really easily. And then, go is an easy language but scala is much more difficult so scala really needs this IMO....

If you look around stackoverflow, many scala questions are answered with links to blog posts. This should be an indication that there is documentation missing or that it can't be linked (pdf). On the golang google group you'll see most questions answered by very specific links which is really helpful.

In general, there is many many resources out there that let's you learn scala. Videos, books etc. But once you want to write code and want to know something specific about x or y it can be pretty painful to find out more.


I hope this helps
Cheers

Marius Danciu

unread,
Dec 2, 2013, 11:09:22 AM12/2/13
to martin odersky, scala-debate, scala-internals
To me, such rants along with things like http://vimeo.com/64716826 lack technical substance in so many points, and it is a sign that Scala threats their worlds and fear that they will be forced in working on Scala by their companies ... and they are simply not willing to learn it ... they may not like syntax, they may simply not like functional programming ... the list is endless and largely biased. There is no perfect language and people really like prejudices.

Marius


--

Simon Ochsenreither

unread,
Dec 2, 2013, 11:10:20 AM12/2/13
to scala-...@googlegroups.com, scala-internals
I think Andy is spot on. I have also mentioned it a few times in the past, but progress is pretty slow because everyone is busy with dozens of other important tasks.

Currently, we are just not where we should be in terms of beginner-friendly documentation, short articles about specific topic, blog posts on scala-lang.org etc.
I think it is the major, non-technical obstacle to wider adoption and I'm surprised that Typesafe doesn't see any benefit of having a dedicated person which would solely focus on improving documentation on all fronts, day in, day out. That would, imho, be a amazingly good investment and a major win for Typesafe, its customers, the community and people interested in learning the language.

Grzegorz Kossakowski

unread,
Dec 2, 2013, 11:22:05 AM12/2/13
to Andy R, scala-debate, scala-internals
On 2 December 2013 16:57, Andy R <andre...@gmail.com> wrote:
Hi Martin,

I'm quite new to Scala and am taking the reactive course. I love everything about the language and also the direction where its headed. However, maybe I can contribute with some criticism from a "new user" standpoint without any bashing:

1. Promote the improved incremental compile times better:
From what I've read online on HN etc, you've lost many enterprise users since those are the ones that tend to work on large code bases and could not deal with the long compile times. They left maybe 1-3 years ago from what I can tell. I've only ever used sbt 0.13 and my compile times are incredibly fast. I think it would help if there was an in-depth (blog?) post on scala-lang.org showing that the compile times have massively improved. Right now, many people (including me) simply reply to comments regarding compile times with "check out the latest version". It would be much better if there was a link-able post showing the recent improvements.

Hi Andy!

That's an excellent suggestion. I was planning to write an article showing how incremental compilation has improved in sbt 0.12.x and sbt 0.13.0, 0.13.1. Another major improvement will be experienced once name hashing algorithm is merged back to sbt.

I agree with you that we should be doing better job at telling people about improvements we make to Scala compiler and tools surrounding it. I'll make sure to bump the priority of writing the article so it should happen shortly after I'm done merging improvements to incremental compiler.

--
Grzegorz Kossakowski
Scalac hacker at Typesafe
twitter: @gkossakowski

Grzegorz Kossakowski

unread,
Dec 2, 2013, 11:34:21 AM12/2/13
to scala-internals, Andy R, scala-debate

On 2 December 2013 17:30, Martin Grigorov <martin....@gmail.com> wrote:
Grzegorz,

If Maven/Gradle can benefit from these improvements thru Zinc then make sure you emphasize on this too.
This will attract many Java developers right away!

Good point! Yes, those benefits will propagate to zinc and thus will be visible in Maven, Gradle, Eclipse and IntelliJ or any other client that uses zinc.

David Landis

unread,
Dec 2, 2013, 11:53:16 AM12/2/13
to Simon Ochsenreither, scala-debate
On Mon, Dec 2, 2013 at 8:10 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
I think it is the major, non-technical obstacle to wider adoption and I'm surprised that Typesafe doesn't see any benefit of having a dedicated person which would solely focus on improving documentation on all fronts, day in, day out. That would, imho, be a amazingly good investment and a major win for Typesafe, its customers, the community and people interested in learning the language.

+1. I wish more people saw it this way. 

atomly

unread,
Dec 2, 2013, 12:02:13 PM12/2/13
to martin odersky, scala-debate, scala-internals
With posts like this, it's not even worth it for you to get worked up about it at all, much less to try replying rationally. Sadly, this is just a product of the success of Scala and there's not much you can do about it other than just keep working on making Scala as good as you can possibly make it. As somebody above said, "haters gonna hate."

Sure, it's worth noting the valid criticisms and trying to fix them, but if you let yourself get caught up in any of these "debates" you end up in a lose-lose situation where you come out looking defensive, arrogant, resistant to change, etc... 

I started programming in Java professionally in 1998 and I remember going through very much this same sort of crap. Sure, Java had its warts, but it was leaps and bounds better than most of the other options out there. I still had to listen to people trying to tell me that Perl was a better solution to build a webapp or something.

There are still people on the internet who try to bash Java as being slow, just because they heard that once or maybe tried writing an applet 8 years ago and had problems with it. People just like to bash things, especially things that aren't whatever they've chosen to be their favorite tool and/or things they don't understand.

Scala is an awesome language and I've seen a lot of people make the transition from various languages (Java, Ruby, Python) and almost all of them like it better because it manages to combine the best of these worlds. I could never imagine going back to Java and, in fact, I've turned down a few very interesting job prospects simply because they were Java shops and didn't seem open to going to Scala.

There are a lot of things that could be fixed about Scala, but you know the vast majority of them and a good portion of them are being actively worked on. The best response to anything like this is just to rise above it and be as awesome as possible.

:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...


--

David Landis

unread,
Dec 2, 2013, 12:04:10 PM12/2/13
to martin odersky, scala-debate
On Mon, Dec 2, 2013 at 1:32 AM, martin odersky <martin....@epfl.ch> wrote:

If you think of other constructive things we could do I would be interested in reading them!

First of all, I have noticed that more and more these types of rants *are* drowned out in a "polite but firm way".  

As for constructive suggestions, the actual quantifiable measurable core to these criticisms does seem to usually relate to compile times. I feel like the other parts of the rants are often just filler -- exaggerated minor annoyances and misunderstandings. In the case of this current rant, I think it was clearly the compile times that pushed the author "over the edge" into the land of frustration. 

Lastly:

" - Work more on forming the community. Make it clear that Scala is a third way, it wants to be neither a Java with semicolons nor a Haskell on the JVM. "

+1 to that.

Vlad Patryshev

unread,
Dec 2, 2013, 1:11:53 PM12/2/13
to martin odersky, scala-debate, scala-internals
There's one thing in that post that left the reader guessing - now what? What language had he switched to? Java? Good luck. JavaScript? It's a different universe; while the language is beautiful, so far nobody yet has built anything large enough using just JavaScript. What else? Haskell? He would tell right away.

But I think it's plain Java, judging by the copyright (© COPYRIGHT MARTIN FOWLER — 2010) under his pic on http://overwatering.org/about/

Thanks,
-Vlad


On Mon, Dec 2, 2013 at 1:32 AM, martin odersky <martin....@epfl.ch> wrote:

--

Ashwin Rajeev

unread,
Dec 2, 2013, 1:18:11 PM12/2/13
to scala-...@googlegroups.com, scala-internals
I used to work in the same company as the author of the article, I agree that the developers there are very smart , but they also seem to have a deeply entrenched opinion on what constitutes "good code" or a "good language" . It was very common to hear people harping on and on about Java vs X and Ruby vs X, even emacs vs Vi, Hell! I have even heard discussions around how many lines a method should have in order for the code to be readable. To me this rant is similar to "java is slow/sucks" or "XYZ does not scale" kind of statements without a solid argument to back it up and I won't make much of it.

In my case, I recently rewrote an entire log crunching susbsystem at my workplace in Scala and we have had great success with it, even the junior developers love the flexibility which Scala provides, and we mix in Java as and when necessary.

--
Ashwin

Ken Scambler

unread,
Dec 2, 2013, 2:56:40 PM12/2/13
to Marius Danciu, scala-debate, scala-i...@googlegroups.com, martin odersky

If only we had Hindley Milner type inference to enable our monads, then they'd come across!

Juha Heljoranta

unread,
Dec 2, 2013, 3:02:14 PM12/2/13
to scala-...@googlegroups.com
On Monday, December 02, 2013 10:32:15 martin odersky wrote:
> Seems hardly a weekend goes by these days without another Scala rant that
> makes the Hacker news frontpage.

Any publicity is good publicity.

> why is everybody attacking Scala?

Attacks coming from all directions kinda confirms that Scala is gaining
friction on many fronts.

My guess is that some dive in too fast with really understanding the big
picture (or even part of the details). If expectations are too high or wrong
then one might get frustrated and post a rant or two about it.

It might be easier to put out fires if we could point out to some page which
documents common known problems/issues with Scala. e.g. compile time can be an
issue so document it with possible workarounds/solutions.
I'd expect this this to give less reason for people to rant about Scala in
first place.

My point is: help people to reason about Scala and its pros and cons so that
they could have have sensible expectations about it.

Cheers,
Juha

martin odersky

unread,
Dec 2, 2013, 4:55:34 PM12/2/13
to Simon Ochsenreither, scala-debate, scala-internals
Agreed that better documentation would be great. There is a problem in finding the right person to do it. Engineers are often not very good at documenting, or do not like it so much, and technical writers are quickly out of their depth. We'd need to find a knowledgeable person who likes to do these kinds of things. Who would be able to fund this is another question, but given the right person we can think about that next.

Cheers

 - Martin
 
--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--

martin odersky

unread,
Dec 2, 2013, 5:01:52 PM12/2/13
to atomly, scala-debate, scala-internals
On Mon, Dec 2, 2013 at 6:02 PM, atomly <ato...@gmail.com> wrote:
With posts like this, it's not even worth it for you to get worked up about it at all, much less to try replying rationally. Sadly, this is just a product of the success of Scala and there's not much you can do about it other than just keep working on making Scala as good as you can possibly make it. As somebody above said, "haters gonna hate."

Sure, it's worth noting the valid criticisms and trying to fix them, but if you let yourself get caught up in any of these "debates" you end up in a lose-lose situation where you come out looking defensive, arrogant, resistant to change, etc... 

I started programming in Java professionally in 1998 and I remember going through very much this same sort of crap. Sure, Java had its warts, but it was leaps and bounds better than most of the other options out there. I still had to listen to people trying to tell me that Perl was a better solution to build a webapp or something.

There are still people on the internet who try to bash Java as being slow, just because they heard that once or maybe tried writing an applet 8 years ago and had problems with it. People just like to bash things, especially things that aren't whatever they've chosen to be their favorite tool and/or things they don't understand.

Scala is an awesome language and I've seen a lot of people make the transition from various languages (Java, Ruby, Python) and almost all of them like it better because it manages to combine the best of these worlds. I could never imagine going back to Java and, in fact, I've turned down a few very interesting job prospects simply because they were Java shops and didn't seem open to going to Scala.

There are a lot of things that could be fixed about Scala, but you know the vast majority of them and a good portion of them are being actively worked on. The best response to anything like this is just to rise above it and be as awesome as possible.


No, in fact I am not getting worked up about this, and certainly do not intend to enter the debate :-) The reason I wrote the post on this mailing list is not the specific blog post but the fact that there's s series of them and that they all got upvoted vigorously. That's interesting, because other languages do not get the same "attention". I was speculating what might be the reason, that's all. 

Cheers

 - Martin

Eric Harney

unread,
Dec 2, 2013, 5:25:36 PM12/2/13
to scala-...@googlegroups.com, scala-internals
Wow, I just lost a lot of respect for you right there @MartinOdersky...

Of course I'm nobody, so there's little reason why you should care about me personally .. but please do take the time to contrast your reaction to that of other well-known language creators.

Bjarne Stroustrup, (you know, the guy who actually created the language that Scala is being compared to) had enough modesty to admit that given the constraints, the way C++ evolved was the best he could do, by saying things like "There are only two kinds of languages: the ones people complain about and the ones nobody uses" and "Within C++, there is a much smaller and cleaner language struggling to get out. "

Rich Hickey had enough decency to advise the Clojure community not to engage in language wars by saying "I would very much like to discourage the bashing of other languages
here." and trying to keep the discussion on properties of Clojure.

Guido van Rossum has appealed to his community to try and work together with the Ruby people, rather than look down on them. (You see, contrary to your beliefs, there's quite a bit of bashing going on between Ruby and Python people.)

Unlike their reactions (targeted at trying to calm their communities down), your post is pretty much a call to arms.. That does seem an awful lot immature. I expected better from the creator of Scala.


> And even though those communities would normally never mix, they find common ground in the opinion that Scala is a horrible language

Yeah, it's not like there's generally a broad group of programmers (across various languages) to be found to hate on one particular language .. like say for PHP or Java or JavaScript .. or, you know,  C++ ..

Stop victimizing yourself, stop blaming others, and man up. Because in contrast to all those other languages in that list above, Scala seems to be proving Bjarne wrong, as it is a language that people both complain about and don't use.

Hanns Holger Rutz

unread,
Dec 2, 2013, 5:36:44 PM12/2/13
to Eric Harney, scala-...@googlegroups.com, scala-internals
Which message are you responding to? Because you seem to assume that
Martin was implying to look down to other or to bash other languages.
Not only is he never saying anything like that in his post, it is also
well known from his past stance that he very much respect other
languages, just as the people you were mentioning.

The question he asks is very valid: Why is it that Scala seems to
particularly attract the hatred from a group of people? It is correct to
advise Scala users to speak up in these kind of threads in a reasonable
and argumentative way. To interpret this as a "call to arms" is
absolutely ridiculous. This is part of the hygiene that Scala obviously
needs to be not buried in FUD.

In contrast, the style of your post is not too far away from the kind of
Reddit or HN posts that were the subject of this debate.

Best, .h.h.

Alois Cochard

unread,
Dec 2, 2013, 5:41:06 PM12/2/13
to scala-...@googlegroups.com, scala-internals
Hi Eric,

I didn't read a "call for arms" personally.
You don't have to believe in conspiracy theory to mention that it's popular to bash Scala... it's just a fact.

ARKBAN

unread,
Dec 2, 2013, 5:48:34 PM12/2/13
to scala-...@googlegroups.com
Any thoughts of adding such a position to http://typesafe.com/company/careers ? That seems like the first step; see what kind of people you might attract. I am one of those atypically developer types that likes documenting and considers good documentation as important as the code it accompanies.

ARKBAN

atomly

unread,
Dec 2, 2013, 5:52:02 PM12/2/13
to martin odersky, scala-debate, scala-internals

On Mon, Dec 2, 2013 at 5:01 PM, martin odersky <martin....@epfl.ch> wrote:
No, in fact I am not getting worked up about this, and certainly do not intend to enter the debate :-) The reason I wrote the post on this mailing list is not the specific blog post but the fact that there's s series of them and that they all got upvoted vigorously. That's interesting, because other languages do not get the same "attention". I was speculating what might be the reason, that's all. 

I certainly didn't think you'd get worked up-- you hardly seem the type-- but I'm glad that you don't have any intention of entering the debate either. I still firmly believe that these sorts of "discussions" really go nowhere and, as we all know, when people argue on the internet, there are no winners. The best thing to do is just make Scala a better language with better documentation, etc...

I don't agree with you, however, that other languages don't get this sort of attention. Right now Scala might be the language of choice for these sorts of rants, but at one time it was Ruby, Python, Java, C++, etc...  A funny coincidence is that these are also the most "successful" languages, which is obviously no coincidence at all. Being in the spotlight makes you a target and there will always be FUD...

Simon Ochsenreither

unread,
Dec 2, 2013, 5:53:38 PM12/2/13
to scala-...@googlegroups.com, scala-internals
In case you are unfamiliar with the Code of Conduct, which covers these mailing lists, here is the link again: http://docs.scala-lang.org/conduct.html

I think people are happy to help if you have any questions about how to improve your behavior to conform to the standards of our community.

Jed Wesley-Smith

unread,
Dec 2, 2013, 6:00:35 PM12/2/13
to martin odersky, scala-debate, scala-internals
People are scared of the unfamiliar – really, viscerally scared. Scared people lash out. Scala represents a whole bunch of things that can put people well outside their familiarity and comfort zone.

Scala is a big, serious language. It isn't a language that yields easily to a weekend or two's hacking projects. It takes time to learn, and it takes experience to understand why you need it in the first place. The people who _do_ use Scala, and are interested in Scala are generally serious and experienced programmers. And there are plenty of them. ScalaSyd* is the biggest language group by a long way after the JS group, and it continues to grow.

Don't get too caught in pandering to the needs of those who are not likely to want to join in anyway, focus on making the lives of those who are already using it better, and they'll continue to proselytise!

And as for them, if they want to use non-alpha operators, or program in a Haskellish way, that's fine too, because in Scala you can! And that is awesome.

cheers,
jed.



On 2 December 2013 20:32, martin odersky <martin....@epfl.ch> wrote:
Seems hardly a weekend goes by these days without another Scala rant that makes the Hacker news frontpage. 


This week-end's edition is called "Scala - 1 Star - would not program again", and it's by someone who from reading his post seems to have written Scala all of two weeks after coming form Javascript. I think the interesting bit is not so much that these posts are written, but that they are upvoted so much. 

There certainly seems to be a grand coalition of people who want to attack Scala. Since this has been going on for a while, and the points of critique are usually somewhere between unbalanced and ridiculous, I have been curious why this is. I mean you can find things that suck (by some definition of "suck") in any language, why is everybody attacking Scala? Why do you not see articles of Rubyists attacking Python or of Haskellers attacking Clojure? 

For me the main reason is that programming languages are incredibly tribal and Scala has no traditional community - the functional/object-oriented programming "tribe" is still in its formation state. People are coming to Scala from all sorts of communities: Java, Ruby, Haskell, you name it. 

Scala's generality makes it both a threat because it *can* do tasks that are traditionally the domain of these other communities and an easy target because every community finds something that is foreign from their point of view. Java people will bitch about how academic FP is, JS and Ruby people complain about the types. Haskell people complain about the objects and that the types are not strong enough. And even though those communities would normally never mix, they find common ground in the opinion that Scala is a horrible language. 

What can we do about it? Not that much I fear, but there are some bits that are useful nevertheless.

 - Work on the things people tend complain about, as long as this makes sense. 

     + we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this
        is no longer that much of an issue.
     + we are working on compile times and expect to have significant progress to announce for 2.11
     + we are working on making binary compatibility less of a problem
     + we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.

 - Work out the simple parts of Scala. Show that Scala hangs together rather well, that it has a fairly modest footprint, and that it is definitely not twice the complexity of C++ as one poster on the thread claimed.

 - Work more on forming the community. Make it clear that Scala is a third way, it wants to be neither a Java with semicolons nor a Haskell on the JVM. 

 - Work on giving more guidance what good Scala code should look like. For instance, develop a detailed, type based lint tool with configurable complexity. Or think about what useful design patterns in Scala are.

 - Last, but not least, engage in these discussions on HN and elsewhere in a polite but firm way. State where your experience differs from the other posters. When somebody complains about long compile times, state that incremental compilation works well for you (if it does, that is, it certainly works well for me by now!). But don't attack the other poster even if you find their arguments lacking, that usually just leads to a mud-fight.

If you think of other constructive things we could do I would be interested in reading them!

[Follow-ups to scala-debate, please]

Cheers

 - Martin

Russ Paielli

unread,
Dec 2, 2013, 6:08:08 PM12/2/13
to Eric Harney, scala-debate, scala-internals
I never got the impression that Martin was denigrating any other language.

As for Stroustrup, had I inflicted the name "C++" on the world, I would be humble too. It's the sort of thing that makes ordinary people consider geeks to be strange -- even though most geeks are completely unaware. 8^)


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Rich Oliver

unread,
Dec 2, 2013, 6:16:57 PM12/2/13
to scala-...@googlegroups.com, scala-internals
On Monday, December 2, 2013 10:25:36 PM UTC, Eric Harney wrote:

Unlike their reactions (targeted at trying to calm their communities down), your post is pretty much a call to arms..

What on earth are you talking about- a call to arms? This is a debate about programming languages, its not a precarious ceasefire in a civil war.
 
That does seem an awful lot immature. I expected better from the creator of Scala.

Your comment seems awfully rude.

Yeah, it's not like there's generally a broad group of programmers (across various languages) to be found to hate on one particular language .. like say for PHP or Java or JavaScript .. or, you know,  C++ ..

Stop victimizing yourself, stop blaming others, and man up. Because in contrast to all those other languages in that list above, Scala seems to be proving Bjarne wrong, as it is a language that people both complain about and don't use.

We'll complain and consider ourselves victimised as much as we want and not ask permission from you. As others of different persuasion are similarly free. When did you become internet commissar?

martin odersky

unread,
Dec 2, 2013, 6:26:08 PM12/2/13
to scala-internals, scala-debate



On Tue, Dec 3, 2013 at 12:23 AM, Scott Carey <scott...@gmail.com> wrote:
What I see, trying to teach Scala to a medium sized team of Java developers (20) and learn more myself from some Scala and Functional Programming experts:


" we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this
        is no longer that much of an issue."

Yes, things are better!  No, this is not done, keep up the good work and keep making the IDE and compiler faster.  A few battles have been won, but the war is not over.  The poor performance and bugs in ScalaIDE have lead almost half the developers here to IntelliJ from Eclipse (but it has other issues).  I'll leave the details of that for the appropriate mailing list.

I did not want to imply that the work is done. It clearly isn't. But we should also appreciate what has been achieved. Even getting to a semi-decent IDE is really hard.

Cheers

 - Martin

Simon Schäfer

unread,
Dec 2, 2013, 6:37:49 PM12/2/13
to scala-i...@googlegroups.com, scala-debate

On 12/02/2013 10:55 PM, martin odersky wrote:



On Mon, Dec 2, 2013 at 5:10 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
I think Andy is spot on. I have also mentioned it a few times in the past, but progress is pretty slow because everyone is busy with dozens of other important tasks.

Currently, we are just not where we should be in terms of beginner-friendly documentation, short articles about specific topic, blog posts on scala-lang.org etc.
I think it is the major, non-technical obstacle to wider adoption and I'm surprised that Typesafe doesn't see any benefit of having a dedicated person which would solely focus on improving documentation on all fronts, day in, day out. That would, imho, be a amazingly good investment and a major win for Typesafe, its customers, the community and people interested in learning the language.
Agreed that better documentation would be great. There is a problem in finding the right person to do it. Engineers are often not very good at documenting, or do not like it so much, and technical writers are quickly out of their depth. We'd need to find a knowledgeable person who likes to do these kinds of things. Who would be able to fund this is another question, but given the right person we can think about that next.
I don't think this can be handled by a single person. It is not just that some introductions need to be written for the language - a lot of people nowadays start learning a language by using a framework. It is impossible for a single person to know all of the available frameworks and about their pitfalls, even if it would only be the most popular.

Instead, I'm more in favor of a platform that makes contribution easy. StackOverflow is such a platform because it makes writing documentation enjoyable - everything that is needed to succeed with good documentation in my opinion. Live edit everywhere if you are a trusted user, a reputation system that shows you that people like your work, all answers are linked together and it is completely (or nearly) self managed by the community.

docs.scala-lang.org and scala-lang.org itself were nice ideas but I would never contribute to them - they just fail in every point mentioned above. Writing a patch is difficult because it needs to be done locally on my computer, sending a PR and even worse - waiting on its acceptance - robs motivation. There is no way to find out if the written documentation is read or if people like it due to the missing reputation system. This also contributes to the fact that an editor feels wasting time - why should someone write documentation when there is no way to check if it is adding value? And pay is probably not enough to bridge that gap of motivation at least if it should be for a longer time (and why paying at all? StackOverflow and GitHub work well without). That both sites are confusing as hell - when looking at the navigation - is only one further point. I use bookmarks for all important stuff because otherwise it would take at least a minute just to find the right location of a site.

Documentation must be maintainable as well as code does - when there is no way to do that it will only hardly be done. Hell, how would I like just to click into the Scaladoc view of my IDE, edit its content, press save and have it available to the world. But that can't be done without the right platform.

If there is funding, I would invest it in the creation of such a platform. And btw, I would like to see a package system integrated as well (such a thing like hackage).

Peter Pnin

unread,
Dec 2, 2013, 6:44:32 PM12/2/13
to scala-...@googlegroups.com, scala-internals
Dear Eric,

There's more than one way to "look down on" a language.


Peter

Simon Ochsenreither

unread,
Dec 2, 2013, 7:01:39 PM12/2/13
to scala-...@googlegroups.com, Simon Ochsenreither, scala-internals

Agreed that better documentation would be great. There is a problem in finding the right person to do it. Engineers are often not very good at documenting, or do not like it so much, and technical writers are quickly out of their depth. We'd need to find a knowledgeable person who likes to do these kinds of things. Who would be able to fund this is another question, but given the right person we can think about that next.

If the internship thing works out, I'm happy to spend my three months on nothing but writing documentation.

Simon Ochsenreither

unread,
Dec 2, 2013, 7:26:09 PM12/2/13
to scala-...@googlegroups.com, scala-internals
Even if it hard to accept, especially for educators like you Martin, I think the best thing is to not participate in such threads.

There is a huge difference between the people from e. g. the Coursera courses and those on HN/Reddit/whatever.
The people who signed up for Coursera are eager to learn while those on HN are happy with slinging mud around. Trying to reason with them means just giving them more ammunition for the next round of FUD.

What I have seen is also—mostly among people who consider them “$language senior developers”—is some kind of reverse-engineered dislike of Scala. What I mean by this is that they don't have much reason/experience with Scala to dislike the language itself, but are worried by what the perceive as the growing popularity of Scala, which they feel threatens their “senior developer” status.
But because saying “I dislike Scala because it could devalue my current job position” they try to “reverse-engineer” reason why Scala is bad. Here are a few examples which triggers this impression for me: http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html, http://beust.com/weblog/2011/02/, http://alblue.bandlem.com/2013/08/will-scala-ever-be-enterprise-ready.html, http://beust.com/weblog/2011/08/15/scalas-parallel-collections/. There is just no benefit in arguing here, because their complaints come from a completely different point of view. They pick arbitrary complaints (http://blog.joda.org/2011/07/reversed-type-declarations_4524.html) and if they become indefensible, they move on to the next (“Yet, the fact remains that I *really* dislike Scala. It rubs me up the wrong way far more than any other comparable language.”).

In the end, I think the reasonable thing is to choose our battles carefully. We are good at shipping great software, and need to improve at writing documentation. Let's concentrate on that.

Xuefeng Wu

unread,
Dec 2, 2013, 7:30:56 PM12/2/13
to scala-i...@googlegroups.com, martin odersky, scala-debate
+1

Review three or four years ago, there is few said Scala is complex in communication , and today, there are so many said. 

I don't think Scala became more complex, but the communication become larger. 
 


Yours, Xuefeng Wu 吴雪峰 敬上
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

Kostya Golikov

unread,
Dec 2, 2013, 7:34:57 PM12/2/13
to scala-...@googlegroups.com, martin odersky, scala-internals
Nope, it is Clojure as far as I can see from his github account. And nope, it is not a call for an arms and not invitation to discuss how Scala is superior to the Clojure or vise versa. Probably this is really a sign that some clojure guys just feel themselves uncomfortable looking at the rise of Scala, probably some people are out of sync with the current state of scala.

atomly

unread,
Dec 2, 2013, 8:41:22 PM12/2/13
to Simon Ochsenreither, scala-debate, scala-internals
One problem that I will agree exists is the non-obviousness of some code written with Scala when one mixes regular and point-free notation, multiple libraries that define their own DSLs and when people try to be too clever by a half with their symbolic method names. I was using a library recently and it took me quite a while to figure out that I needed to use ~+ to concatenate objects-- very much non-obvious.  I've also seen code where it's very difficult to reason about what's a class, a method, an argument, etc, because of a chaining of calls and a mixing of syntax styles.  Unfortunately, I can't think of a good solution to this other than discipline and coding standards, because I certainly wouldn't want to give up any of this power, either.

I see a lot of hand waving in these posts about how Scala is such a big and complicated language, but honestly it's not at all-- I think people have a tendency to confuse the language with the library, and I can see where they have a problem there. I know it's been talked about before, but I think a really big problem is that newbies opening up the API docs for anything in the collections are bound to be pretty quickly overwhelmed by the method signatures. Obviously the "complexity" is necessary and it's pretty damn impressive how well Scala does at giving you back the right type, etc., but perhaps something could be done to make them less intimidating to newcomers, since this is certainly one of the first things they will encounter. Maybe a way to show a simpler signature by default with an expand button that shows the full thing or something?

More than anything, though, I think good examples are the best thing to have, or at least that's how I've always learned. This situation is getting better every day, and hopefully this will help with people coming to the language-- they can just open up something like Play and look at how it does things for a reference, for example.

I get really frustrated when I read posts like Guido's where he talks about all these "over-complicated" things like for-comprehensions, variance annotations, existential types, polymorphic method types, etc. as if just because he makes a list of things he doesn't normally use or possibly doesn't understand, they're instantly bad. None of those are terribly advanced concepts and I'm sure I'm not the only one who has used all of these things in actual code consistently and to great effect. It's just like how people who don't understand Haskell just say "monad," as if the fact that it's a non-familiar concept instantly makes it bad.


:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...


--

Simon Ochsenreither

unread,
Dec 2, 2013, 9:00:18 PM12/2/13
to scala-i...@googlegroups.com, Simon Ochsenreither, scala-debate
I agree, but I'm wondering why the people who can't tell a def from a val are always those who encounter use-cases which require them to use dozens of different symbol-heavy APIs at the same time.

Jon Pretty

unread,
Dec 2, 2013, 9:01:38 PM12/2/13
to scala-...@googlegroups.com, scala-internals
Hi Martin,

Here are a few specific points:


On Monday, 2 December 2013 09:32:15 UTC, Martin wrote:
     + we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this
        is no longer that much of an issue.

I think the IDE support is vastly improved, but it will suffer from comparison to Java IDE support, and it's still playing catchup. I have actually discussed some particular pain-points in Eclipse with Iulian earlier today...
 
     + we are working on compile times and expect to have significant progress to announce for 2.11

Compilation times in Java (or interpreted languages) are small enough that they're irrelevant, so they're a new experience if you arrive at Scala from one of these languages. I think it's easy to overstate the significance of long compilation times, as "thinking time" will almost always dominate compiling time, but the compilation times are very obvious when they're new. I don't see any better way than deal with them than to keep nibbling away at them.
 
     + we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.

I don't like this idea so much. If a method's name changes from symbolic to alphabetic, then it's not strictly an alias in the sense that you can substitute one for the other, because you lose the variable precedence that applies to symbolic operators (and which is so useful). I think this feature of symbolic operators is too often overlooked in the regular symbolic vs alphanumeric name debates.

A lesser criticism is that it might introduce more questions about why there is more than one way of doing the same thing. If, as a naive beginner learning Akka, I see someone writing `actor ! Message` and someone else writing `actor.bang(Message)` or `actor bang Message`, then I would question whether these are the same thing or not. I might not even associate the two, and if I saw both in the same code, I would question what the motivation was for using different versions.

I would prefer the pronunciation of a method name to be in the human-readable documentation.
 
 - Work out the simple parts of Scala. Show that Scala hangs together rather well, that it has a fairly modest footprint, and that it is definitely not twice the complexity of C++ as one poster on the thread claimed.

Simplicity is such a difficult thing to quantify. It can be horribly skewed by past experience, context and expectations. There is a degree of choice in how a particular set of features is described, and the anti-Scala rants I've seen tend to demonstrate a different interpretation of the "rules".

For example, in Guido van Rossum's blogpost (which Peter Pnin pointed to), he talks about for-loop semicolon inference in parentheses differing from braces, and that you have an arbitrary choice of which style you use. That's one way of looking at it. Another is that braces and parentheses have consistent behaviour throughout the language (with respect to semicolon-inference), and the choice of which style to use is just as flexible for for-loops as everywhere else.

Or consider the underscore: You could list the half-dozen different specific meanings in has. Or you can describe it as a placeholder; everything, nothing, anything; "whatever". The latter is an easier way to think about it.

Having a good feeling for the core features of the language syntax is very important for giving a programmer confidence in the language. Having in innate trust in certain invariants means you can direct brainpower away from questioning them, and focus on more relevant problems, though unfortunately that's something which comes best with experience. Better documentation along the lines of "how to read Scala for beginners" would be useful.

Scala does have a few warts which have always seemed irrelevant enough not to matter. For example, in this import

   import scala.collection.mutable.{HashSet => _, _}

the use of braces to contain a list of things is not consistent with braces elsewhere, and the use of the => operator is different from anywhere else you might see it. And the underscores (notwithstanding my earlier comment) are less intuitive than they could be.

Inconsistencies like these, which are really minor for me, should maybe be viewed as more significant problems which undermine a new Scala programmer's confidence in the language. But before we start thinking about ways of fixing them, we should decide what our most fundamentally invariant and universal syntax "rules" should be.

Thanks,
Jon

Vlad Patryshev

unread,
Dec 2, 2013, 9:09:17 PM12/2/13
to Kostya Golikov, scala-debate, martin odersky, scala-internals
Clojure deserves respect of course.

Thanks,
-Vlad

Oleg Galako

unread,
Dec 3, 2013, 1:53:04 AM12/3/13
to scala-i...@googlegroups.com, scala-debate
For me the reason is quite obvious. Basic psychology: you don't want to spend your thoughts/energy/time on something so you need to find excuses. And if you publicly share your excuses you even get some nice attention as a bonus.

David Riccitelli

unread,
Dec 3, 2013, 1:55:12 AM12/3/13
to atomly, Simon Ochsenreither, scala-debate, scala-internals
+1



══════════════════════════════════════════════
► Twitter: @ziodave                                      
---                                              
 InsideOut10 s.r.l. (IT-11381771002)
══════════════════════════════════════════════


--
You received this message because you are subscribed to a topic in the Google Groups "scala-debate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-debate/153H3Ya4Nxk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-debate...@googlegroups.com.

s...@sksamuel.com

unread,
Dec 3, 2013, 3:23:31 AM12/3/13
to scala-i...@googlegroups.com, scala-...@googlegroups.com
Just a quick response from me.

Agree with Jon Pretty. If you're coming from an interpreted language to Java, the fact you have to compile is just a slight oddity. It takes a few seconds. If you're coming to Scala then your compile times are minutes. I have a relatively small greenfield project at work that is now taking 2 minutes to compile changes in intellij. I could imagine that would put a few people off. But you know, Java used to take ages to compile. Things will improve, starting with 2.11 of course.

Also is the wider use of symbols. Even the collections library can be a bit off putting to people from a non-FP background at first with its :: and ++=.  It's soon picked up but I think if aliases were promoted as well, that would make a big difference.

Haoyi Li

unread,
Dec 3, 2013, 3:24:51 AM12/3/13
to David Riccitelli, atomly, Simon Ochsenreither, scala-debate, scala-internals
A lesser criticism is that it might introduce more questions about why there is more than one way of doing the same thing

I don't think that's a lesser criticism; having multiple ways to do the same thing is a big source of confusion for new people, both from a "what does this do" PoV, as well as from a "so... which one should I use?" PoV.

Personally I would prefer having to annotate the symbolic name with an @name("...") annotation, then both names will always be in the same place, the "convention" can be enforced and relied upon by both IDE and programmer. #bikeshedding

Another is that braces and parentheses have consistent behaviour throughout the language (with respect to semicolon-inference), and the choice of which style to use is just as flexible for for-loops as everywhere else.

But it's not, though! You can't do println(123; "i am cow"); it just fails. I agree with Guido that it's weird that parens and braces have arbitrary syntactic restrictions. A less confusing (to me) distinction would be having paren not allow multiple "statements" at all, since that's the way parens work elsewhere.

In general, for-comprehensions need some syntactic cleanup. "_ = println(...)" should *not* be an acceptable state of affairs! That's the type of thing makes people go WTF at first glance!

Inconsistencies like these, which are really minor for me, should maybe be viewed as more significant problems which undermine a new Scala programmer's confidence in the language. But before we start thinking about ways of fixing them, we should decide what our most fundamentally invariant and universal syntax "rules" should be.

+1. Although I use Scala a lot, and think the middleware/core is really awesome, I feel the superficial syntax is full of odd cruft. 

- for comprehension braces/parens
- bare statements (e.g. println) in for comprehensions needing _ = println()
- def x = {} v.s. def x{} (thanks @soc for championing this deprecation!)
- m1.map(x => x + 1), but m2.map{case (x, y) => (x+1, y+2)}.
- def f() = ... methods being called via just "f". That introduces a bunch of inconsistency where "a method defined with N parameter lists is called with M=N parameter lists, except when N = 1 then M=0 or M=1 and you need to put _ after the name (???) to not immediately eval it". 
- If I def f(i: Int)(j: Int): Int and call f(10), the compiler should know very well I'll get a (Int => Int) back; why should I need to put a _ after? Target typing fixes this in some cases, but it also makes the situations where I *have* to put the _ unpredictable and seemingly random.

Other languages have far more rigid "this is the way to write things" philosophy, so even if the language grammar ranges from bigger (e.g. Java) to ridiculously complicated (C#) to weirdly rigid (Python) the code is far more "predictable" at first glance. 

I remember asking Nine ways to define a method in Scala when I was learning it two years ago. It wasn't so much the "flexibility to add braces or define anonymous functions anywhere" thing that tripped me up, but the x = {} vs x{}, and def f() being called with just "f" features. These turned what could have been a predictable pattern of behavior into a seemingly random jumble. I totally can imagine people being scared off, I know I almost was.

martin odersky

unread,
Dec 3, 2013, 4:00:18 AM12/3/13
to Simon Ochsenreither, scala-debate, scala-internals
Good points, and could not agree more. 

Thanks

 - Martin


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--

Oleg Galako

unread,
Dec 3, 2013, 4:10:45 AM12/3/13
to scala-i...@googlegroups.com, scala-...@googlegroups.com
Yes, that's what i meant to say. Fear of losing their value + need of excuses to not learn Scala. Psychological defense.

It's also easy to see the difference between such cases and others - when people really have problems with Scala and asking for advice how to overcome those (or at least accepting those advices in comments).

Vassili van der Mersch

unread,
Dec 3, 2013, 6:36:15 AM12/3/13
to scala-...@googlegroups.com, scala-internals
I'm an entrepreneur bootstrapping my first startup. We are using Scala and Play and love both. I have been a Java programmer for a number of years and have only started using FP earlier this year. The way we use Scala is very straightforward - we mostly use case classes/pattern matching, map, flatMap and filter on collections (mostly just Lists and Maps), Options and Futures. Our code reads like a children's book. Together with Play (just starting to use Akka explicitly now) and a couple of plugins, that covers 90% of our needs. 

What I think could be done is to put more focus on Scala-related success stories in well-known technology companies. There is a page on the Typesafe website that lists some of them: http://typesafe.com/company/casestudies, but they leave out most major companies using Scala (even if they don't use the entire Typesafe stack): Twitter, Foursquare, LinkedIn, Tumblr, Klout... These are companies that needed both great scalability and expressiveness and in several cases they switched from another language/stack to scala.

Twitter has done a great job of explaining how they use Scala and to give back to the open source community with things like Finagle, but I think it would be great to have a series on how each of these companies tackled their specific problems and how Scala has helped them get there. It would certainly strike a chord with the HN audience.


On Monday, December 2, 2013 10:32:15 AM UTC+1, Martin wrote:
Seems hardly a weekend goes by these days without another Scala rant that makes the Hacker news frontpage. 


This week-end's edition is called "Scala - 1 Star - would not program again", and it's by someone who from reading his post seems to have written Scala all of two weeks after coming form Javascript. I think the interesting bit is not so much that these posts are written, but that they are upvoted so much. 

There certainly seems to be a grand coalition of people who want to attack Scala. Since this has been going on for a while, and the points of critique are usually somewhere between unbalanced and ridiculous, I have been curious why this is. I mean you can find things that suck (by some definition of "suck") in any language, why is everybody attacking Scala? Why do you not see articles of Rubyists attacking Python or of Haskellers attacking Clojure? 

For me the main reason is that programming languages are incredibly tribal and Scala has no traditional community - the functional/object-oriented programming "tribe" is still in its formation state. People are coming to Scala from all sorts of communities: Java, Ruby, Haskell, you name it. 

Scala's generality makes it both a threat because it *can* do tasks that are traditionally the domain of these other communities and an easy target because every community finds something that is foreign from their point of view. Java people will bitch about how academic FP is, JS and Ruby people complain about the types. Haskell people complain about the objects and that the types are not strong enough. And even though those communities would normally never mix, they find common ground in the opinion that Scala is a horrible language. 

What can we do about it? Not that much I fear, but there are some bits that are useful nevertheless.

 - Work on the things people tend complain about, as long as this makes sense. 

     + we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this
        is no longer that much of an issue.
     + we are working on compile times and expect to have significant progress to announce for 2.11
     + we are working on making binary compatibility less of a problem
     + we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.

 - Work out the simple parts of Scala. Show that Scala hangs together rather well, that it has a fairly modest footprint, and that it is definitely not twice the complexity of C++ as one poster on the thread claimed.

Jonathan Merritt

unread,
Dec 3, 2013, 6:49:37 AM12/3/13
to Vassili van der Mersch, scala-debate, scala-internals
On Tue, Dec 3, 2013 at 10:36 PM, Vassili van der Mersch <vas...@gmail.com> wrote:
(snip) 
Twitter has done a great job of explaining how they use Scala and to give back to the open source community with things like Finagle, but I think it would be great to have a series on how each of these companies tackled their specific problems and how Scala has helped them get there. It would certainly strike a chord with the HN audience.

I think this is a great idea.

I'd also like to hear more success / background stories from entities who aren't just developing web services with Scala.  Occasionally news and conference presentations pop up from fascinating groups at places like NASA, Autodesk and Sony Imageworks (and the quants of course :-), but the majority of success stories I come across seem to come from web companies.  It would be good to hear some cheering from people using Scala in more diverse applications.

Jonathan Merritt.

Boris Steiner

unread,
Dec 3, 2013, 6:49:46 AM12/3/13
to scala-...@googlegroups.com, scala-internals
Hi Martin,

2cents from a scala noob: I think to improve the perception of scala there should be more effort put into documentation. The scala doc is nice compared to javadoc and the search  is really cool. What I miss though, are comments or examples from the community and/or simple cookbook in the style  'how I do...' , ideally referenced from docs site  (the comments do not need to  downloadable though)  . As an example: how do I modify a an attribute value in XML ? I had to look in the docs, but that did not  reveal a clue , finally found some examples at stackoverflow. It's a simple thing to do, but for noobs like me it's not clear and and it's a thing I won't remember. (well, I gave up then  and wrote xslt script)

I also like python's doc site full site search where it's easy to find  by keywords and at least get an idea what I should be looking for (try to look for process). Sencha has excellent documentation for ExtJS with community comments and sometimes help to understand how to use some features.
It's needles to say that comments and cookbook should be reviewed and kept relevant for scala versions, otherwise it leads to confusion and despair.

If the docs could be looked up from IDEs that would be awesome

B




Dňa pondelok, 2. decembra 2013 10:32:15 UTC+1 Martin napísal(-a):

Jason Zaugg

unread,
Dec 3, 2013, 6:52:06 AM12/3/13
to Vassili van der Mersch, scala-debate, scala-internals
On Tue, Dec 3, 2013 at 12:36 PM, Vassili van der Mersch <vas...@gmail.com> wrote:
I'm an entrepreneur bootstrapping my first startup. We are using Scala and Play and love both. I have been a Java programmer for a number of years and have only started using FP earlier this year. The way we use Scala is very straightforward - we mostly use case classes/pattern matching, map, flatMap and filter on collections (mostly just Lists and Maps), Options and Futures. Our code reads like a children's book. Together with Play (just starting to use Akka explicitly now) and a couple of plugins, that covers 90% of our needs. 

What I think could be done is to put more focus on Scala-related success stories in well-known technology companies. There is a page on the Typesafe website that lists some of them: http://typesafe.com/company/casestudies, but they leave out most major companies using Scala (even if they don't use the entire Typesafe stack): Twitter, Foursquare, LinkedIn, Tumblr, Klout... These are companies that needed both great scalability and expressiveness and in several cases they switched from another language/stack to scala.

Twitter has done a great job of explaining how they use Scala and to give back to the open source community with things like Finagle, but I think it would be great to have a series on how each of these companies tackled their specific problems and how Scala has helped them get there. It would certainly strike a chord with the HN audience.

I think that success stories like yours are just as important. You don't need to have Twitter-sized problems, nor engineering teams, to benefit from moving to a higher level language like Scala with a nice stack of tools to help you be productive and ship great software.

-jason


Jason Zaugg
Software Engineer

Typesafe – Build reactive apps!
Twitter: @retronym

nicerobot

unread,
Dec 3, 2013, 6:57:12 AM12/3/13
to scala-...@googlegroups.com, scala-internals
I would like to add another thing on which to focus:

SBT - Learn from the simplicity of Go and npm, not from Maven. Learn from the syntax of Gradle. Build automation shouldn't require learning another language (DSL) nor understanding _details_ of Scala (operators, generics, ...) for the _simple_ things. It should be, at most, a simple version of the language's syntax without any obscure additional rules (required blank spaces?!). Build tools are often one of the first experiences people have with a language. It should be a joy to use and simple and obvious to understand by a novice. Note the words i'm using, simple and obvious. SBT is currently neither. Simple things should be simple and obvious and the complexities should be obvious extensions of the simplicity.
Message has been deleted

Stéphane Épardaud

unread,
Dec 3, 2013, 9:20:30 AM12/3/13
to scala-...@googlegroups.com
Hi,

I work on Ceylon, and I can tell you other languages get the same fanatical reactions for the same invalid reasons, and way more frivolous ones as well, such as whether or not the language author wears jeans (this is unfortunately a true story). 

When you say Scala doesn't have "Scala has no traditional community" I'm not sure what you mean, but I can tell you that the first wave of trolls that bashed on Ceylon where advocating Scala, but not in a reasoned, reasonable way such as compare pros/cons, which would of course be fair and acceptable. I suppose it is sort of a sign of a large community to have trolls within it attacking other languages, and trolls of other languages attacking from outside ;)

Trolls are trolls, no matter what language they defend this month, because it's likely to change the next month. Just don't pay attention, or respond to the false claims where there are even any claims besides hand waving, as you said in a polite way.

What I find reassuring is that behind the scenes, I regularly have very nice conversations with TypeSafe employees, like Joshua, as well as with the guys behind Groovy or Golo, and those sorts of interactions are a lot more interesting than trolls trolling ;)

Cheers!

On Monday, 2 December 2013 23:01:52 UTC+1, Martin wrote:
No, in fact I am not getting worked up about this, and certainly do not intend to enter the debate :-) The reason I wrote the post on this mailing list is not the specific blog post but the fact that there's s series of them and that they all got upvoted vigorously. That's interesting, because other languages do not get the same "attention". I was speculating what might be the reason, that's all. 

Cheers

 - Martin

martin odersky

unread,
Dec 3, 2013, 9:32:30 AM12/3/13
to Stéphane Épardaud, scala-debate
On Tue, Dec 3, 2013 at 3:20 PM, Stéphane Épardaud <stephane...@gmail.com> wrote:
Hi,

I work on Ceylon, and I can tell you other languages get the same fanatical reactions for the same invalid reasons, and way more frivolous ones as well, such as whether or not the language author wears jeans (this is unfortunately a true story). 

When you say Scala doesn't have "Scala has no traditional community" I'm not sure what you mean, but I can tell you that the first wave of trolls that bashed on Ceylon where advocating Scala, but not in a reasoned, reasonable way such as compare pros/cons, which would of course be fair and acceptable. I suppose it is sort of a sign of a large community to have trolls within it attacking other languages, and trolls of other languages attacking from outside ;)

I am very sorry for that! I hope that things have calmed down by now. 

Trolls are trolls, no matter what language they defend this month, because it's likely to change the next month. Just don't pay attention, or respond to the false claims where there are even any claims besides hand waving, as you said in a polite way.

What I find reassuring is that behind the scenes, I regularly have very nice conversations with TypeSafe employees, like Joshua, as well as with the guys behind Groovy or Golo, and those sorts of interactions are a lot more interesting than trolls trolling ;)

That's good to know. Thanks for speaking up here,

 - Martin
 
Cheers!

On Monday, 2 December 2013 23:01:52 UTC+1, Martin wrote:
No, in fact I am not getting worked up about this, and certainly do not intend to enter the debate :-) The reason I wrote the post on this mailing list is not the specific blog post but the fact that there's s series of them and that they all got upvoted vigorously. That's interesting, because other languages do not get the same "attention". I was speculating what might be the reason, that's all. 

Cheers

 - Martin

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Stéphane Épardaud

unread,
Dec 3, 2013, 9:36:33 AM12/3/13
to scala-...@googlegroups.com, Stéphane Épardaud


On Tuesday, 3 December 2013 15:32:30 UTC+1, Martin wrote:
I am very sorry for that! I hope that things have calmed down by now. 

They have a bit, and in part because we started to participate in the hackernews/slashdot/reddit posts to defuse the trolls and myths, and in every case the discussion turned very fast away from trolling and into constructive discussions and questions and useful feedback. I suggest you try the same.

Don't worry about Scala trolls, I know this is not something TypeSafe encourages, rather the opposite, nothing to be sorry about. I can't say I'm looking forward to Ceylon trolls going to troll other languages…

pagoda_5b

unread,
Dec 3, 2013, 10:03:51 AM12/3/13
to scala-...@googlegroups.com, scala-internals
You have not been visiting the docs page for a while, it seems.

On Tuesday, December 3, 2013 2:41:22 AM UTC+1, atomly wrote:
I know it's been talked about before, but I think a really big problem is that newbies opening up the API docs for anything in the collections are bound to be pretty quickly overwhelmed by the method signatures. Obviously the "complexity" is necessary and it's pretty damn impressive how well Scala does at giving you back the right type, etc., but perhaps something could be done to make them less intimidating to newcomers, since this is certainly one of the first things they will encounter. Maybe a way to show a simpler signature by default with an expand button that shows the full thing or something?



bye
Ivano 

Aleksey Izmailov

unread,
Dec 3, 2013, 10:13:58 AM12/3/13
to scala-...@googlegroups.com, scala-internals
I think the reason for attacks on Scala is similar to why ugly girls bash good looking girls - they feel endangered and need to put competition down.

Scala is such a cool language that almost every other older language seems inferior to it. Programmers invest years to master a programming language and they don't want to feel like their effort was wasted because now there is something available that is much better. Javas status has gone down after Scala became popular.

On the other hand all great inventions that challenge status quo always faced opposition from conservative minds.

All in all it's a good sign that Scala gets attacked. It means it's really a game changing thing. I'm sure Scala can survive such little rants and make those people look dumb in the end.

Thanks to Martin and all others working on Scala and related libraries to make programming experience better!

Hanns Holger Rutz

unread,
Dec 3, 2013, 10:22:30 AM12/3/13
to Aleksey Izmailov, scala-...@googlegroups.com
what kind of machista sh*t is this?

Erik Osheim

unread,
Dec 3, 2013, 10:31:15 AM12/3/13
to Aleksey Izmailov, scala-...@googlegroups.com
On Tue, Dec 03, 2013 at 07:13:58AM -0800, Aleksey Izmailov wrote:
> I think the reason for attacks on Scala is similar to why ugly girls bash
> good looking girls

Please don't say things like this--it can alienate women using Scala.

Thanks,

-- Erik

pagoda_5b

unread,
Dec 3, 2013, 10:52:48 AM12/3/13
to scala-...@googlegroups.com, scala-internals
Nice and useful comment.

I must admit that coming from java I don't remember a better experience there.
Java newbies can learn fast from one of the many free resources available, but it won't get them anywhere wrt delivering an enterprise-grade solution.

Certainly senior guidance helps there, and probably scala is till too young to hope that most companies has a couple of such experienced figures.

Scala is not spread enough to have fast answers without recurring to the internet or a good book. And it's possible that there's more answers needed than in other languages, just because of the available flexibility. This could be frustrating for experienced programmers and confusing to newcomers.

Back to the documentation issue, I still find that javadocs are not enough for many tasks (don't take this as an attack). You usually need to refer to tutorials and similar, especially when dealing with frameworks like Swing or JavaFx or JEE.
I also firmly believe that java generics are not fully understood by the majority of java developers. They just use the feature from external libraries but don't put them to good use in their own code, and I probably should include myself in this category too.

I also believe that the scala documentation effort is a daunting task but the scala team is already on the right track with the site (http://docs.scala-lang.org/): 
there's lot of resources, and decently organized.

What is possibly missing is a new release of the "official book" (Programming in Scala), and, even more important in my opinion, some sort of organized knowledge book taking a stab at the basics of the language usage, a Scala Rulebook where details and examples of single features is clearly organized and exposed. A reference book that newcomers and experts alike can refer to when you don't remember the exact syntax of some functionality or you need a rarely used feature that eludes you.
This book should not be targeted on teaching the language, but as a structured reference, complete as the specification but easier to approach. And it should be focused on the language itself and the standard library only.

As for the task of documenting external libraries (popular as they may be), it rests on the library developers themselves.

On Tuesday, December 3, 2013 12:49:46 PM UTC+1, Boris Steiner wrote:
Hi Martin,

2cents from a scala noob: I think to improve the perception of scala there should be more effort put into documentation. The scala doc is nice compared to javadoc and the search  is really cool. What I miss though, are comments or examples from the community and/or simple cookbook in the style  'how I do...' , ideally referenced from docs site  (the comments do not need to  downloadable though)  . As an example: how do I modify a an attribute value in XML ? I had to look in the docs, but that did not  reveal a clue , finally found some examples at stackoverflow. It's a simple thing to do, but for noobs like me it's not clear and and it's a thing I won't remember. (well, I gave up then  and wrote xslt script)

I also like python's doc site full site search where it's easy to find  by keywords and at least get an idea what I should be looking for (try to look for process). Sencha has excellent documentation for ExtJS with community comments and sometimes help to understand how to use some features.
It's needles to say that comments and cookbook should be reviewed and kept relevant for scala versions, otherwise it leads to confusion and despair.

If the docs could be looked up from IDEs that would be awesome

B

Ivano 

B H

unread,
Dec 3, 2013, 10:55:41 AM12/3/13
to scala-...@googlegroups.com, scala-internals
Martin and folks,

There is a lot of great discussion here, and I'm late to the thread. But I'd like to add some support for BOTH the "Scala Is Hard" folks and the "Scala Is Great" folks. Since I think both are true in some sense.

In one context or another, I've programmed since around 1974, and I learned more than a dozen languages and used at least 9 extensively on the job. (I've even programmed Forth for money! :-)

My general approach is to learn enough of a language to get started with solving a problem, and then get more into the details - the nooks and crannies as it were - as I use the language over time. So when I heard about Scala a couple of years ago, I took the same approach. I read a good chunk of Martin's book, and I loved what I found, so I used Scala to write a new version of a problematic production subsystem, and integrated it with the rest of our Java code. I used the basic language syntax, and Actors, and some of the functional programming features of the language. I liked the language, I liked the efficiency of the syntax, I liked the result, and it worked like a charm. But, I must admit, I did not read ALL of Martin's book, or all of the other book I bought. Looking around the web I saw some complicated looking Scala code, and basically just ignored it. Anyway, I was a Scala convert. And started telling good developers I knew about my experience.

I got distracted by non-coding stuff and iOS programming right after that.

A short time later I ran into a "Scala is Hard" post. My first reaction was something along the lines of "Really? That's weird, I didn't think it was so hard..." But that prompted me to get back to Scala and look at the bits I had not gotten around to before. And then I had my "Holy Cow!" moment. There is some complicated stuff in there! And after working on better understanding and making more extensive use of the type system and the like, I did get the feeling that, relatively speaking, Scala was more "complex" and "harder" in some sense then the other languages I had used.

The point is that even though I really liked Scala, I had sympathy for those who felt is was hard - or perhaps even too hard or not worth it. The conclusion I came to was that:

- I wanted to use it
- I would not worry about the "harder stuff", which I would learn over time or not at all
- I would not ask less capable folks on the team to use it

Now it is a couple of jobs later, and we are starting with some greenfield development. We have a team of mixed skill levels. So I've been starting to mull over my Scala strategy. 

- Use it and try to get everyone on board? 
- Encourage the really awesome dude we just hired to use it, and give other folks the option? 
- Not use it and wait for Java to get hip? 
- Maybe it's time to get back into Groovy...

Honestly, I'm not sure at this point, but I've got to make a decision soon. So...

This is a very timely discussion, I must say! I appreciate everyone taking the time to give their intelligent and carefully considered opinions.

Brian

martin odersky

unread,
Dec 3, 2013, 11:46:05 AM12/3/13
to B H, scala-debate, scala-internals
On Tue, Dec 3, 2013 at 4:55 PM, B H <spag...@gmail.com> wrote:
Martin and folks,

There is a lot of great discussion here, and I'm late to the thread. But I'd like to add some support for BOTH the "Scala Is Hard" folks and the "Scala Is Great" folks. Since I think both are true in some sense.

In one context or another, I've programmed since around 1974, and I learned more than a dozen languages and used at least 9 extensively on the job. (I've even programmed Forth for money! :-)

My general approach is to learn enough of a language to get started with solving a problem, and then get more into the details - the nooks and crannies as it were - as I use the language over time. So when I heard about Scala a couple of years ago, I took the same approach. I read a good chunk of Martin's book, and I loved what I found, so I used Scala to write a new version of a problematic production subsystem, and integrated it with the rest of our Java code. I used the basic language syntax, and Actors, and some of the functional programming features of the language. I liked the language, I liked the efficiency of the syntax, I liked the result, and it worked like a charm. But, I must admit, I did not read ALL of Martin's book, or all of the other book I bought. Looking around the web I saw some complicated looking Scala code, and basically just ignored it. Anyway, I was a Scala convert. And started telling good developers I knew about my experience.

I got distracted by non-coding stuff and iOS programming right after that.

A short time later I ran into a "Scala is Hard" post. My first reaction was something along the lines of "Really? That's weird, I didn't think it was so hard..." But that prompted me to get back to Scala and look at the bits I had not gotten around to before. And then I had my "Holy Cow!" moment. There is some complicated stuff in there! And after working on better understanding and making more extensive use of the type system and the like, I did get the feeling that, relatively speaking, Scala was more "complex" and "harder" in some sense then the other languages I had used.

It would be a pity to let the "hard" parts distract you from using the language as a whole. We can try to soften up the hard parts, either by better explaining what they are, or by clearly labelling them as specialized (as we did with SIP 18). But to do this, we have to first know what they are. So, I am always interested in getting concrete examples about what people find hard. Here, I do not mean small syntactic quirks (every language has them and everyone can live with them), and I do not mean programming paradigms (i.e. sure functional programming is hard for someone who has never seen it, but that does not mean you should not learn it!). I mean more the things in between. For instance, people might find structural types hard (or not). I know many find existential types hard. If we have better data about what people find hard we can think about how to simplify, and I think this would be a very worthwhile undertaking. 

Best,

 - Martin


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

atomly

unread,
Dec 3, 2013, 12:15:42 PM12/3/13
to pagoda_5b, scala-debate, scala-internals
I've been thinking about this a lot overnight and I realized that a language that has had a disproportionately soft landing in this regard is Go, and I started thinking about why that is. I was very excited about Go early on until I realized that the Go team had created their language in isolation and were basically unwilling to change it once it was released (I spent a lot of time petitioning for polymorphism, exceptions, etc. early on to no avail), but now I realize that's part of why a lot of people like the language.

What I see as crippling a lot of people see as simplicity. The language has generic support, for example, but only for the built-in types (lists/slices, maps, channels). These types also have their own special syntax and the compiler and runtime are built to support them directly. This essentially means that any user-defined collection is a second-class citizen-- seriously, the experience of using a built-in collection versus a user-created one is shockingly disparate. For a lot of users, though, the language provides enough of what they need and they don't see any of this as a shortcoming, but rather simplicity.

Scala, on the other hand, does this in a completely opposite manner. Lists are not built into the language-- even :: is code that a user can view or edit if they want to! This means that Scala's internals are out there for everybody to see, hence the "cryptic" type signatures that seem to scare newcomers to the language. In the end, this to my view obviously makes Scala  more powerful and uniform experience, but it makes the ramp-up much more significant.

Another huge thing, obviously, is that Go has the backing of an entity with bottomless pockets like Google and have used some of that to build incredible documentation. [ http://golang.org/doc/ ] They have a ton of tutorials, guides, FAQs, etc., that make it very easy to come to the language.

Perhaps if there were an Effective Scala guide to parallel Effective Go [ http://golang.org/doc/effective_go.html ] it would go a long way to assuaging the fear and uncertainty of people trying to learn the language. It is quite nice to have a canonical resource that you can point to that answers almost any of the basic questions about the language.

I would certainly be willing to help contribute to an Effective Scala guide-- is anybody else interested in this? If I have some time in the next day or two, maybe I'll start a PR for this...

atomly

unread,
Dec 3, 2013, 12:28:14 PM12/3/13
to B H, scala-debate, scala-internals
On Tue, Dec 3, 2013 at 10:55 AM, B H <spag...@gmail.com> wrote:
Now it is a couple of jobs later, and we are starting with some greenfield development. We have a team of mixed skill levels. So I've been starting to mull over my Scala strategy. 

- Use it and try to get everyone on board? 
- Encourage the really awesome dude we just hired to use it, and give other folks the option? 
- Not use it and wait for Java to get hip? 
- Maybe it's time to get back into Groovy...

Honestly, I'm not sure at this point, but I've got to make a decision soon. So...

This will come as no surprise, but I highly recommend you give Scala try, and by that I mean fully go for it. I talked about it a little bit on here before, but I've worked at three different companies now that have made the transition to Scala and it has been a resounding success at each of them. 

The first was an Alexa top 10 website written in PHP where I and a few others were brought in to rewrite the stack in Java and a couple years down the road we made the transition to Scala, with virtually no problems, though this was a very small dev team. 

The second was a huge ecommerce site originally written in Rails, then transitioned to Java and eventually Scala, which has been such a success there that they're now major sponsors of Scala conferences and such. 

The third, where I currently work, is a large news site owned by a huge media company-- it was originally written in Rails, but they did a full rewrite in Scala with great success and they did it with the very same teams of Ruby developers who now, thanks mostly to in-house training, are all competent and very happy Scala developers. There was almost no attrition due to the changeover, which might surprise a lot of people since most people think the Java to Scala transition is the obvious one, but I think Ruby to Scala is actually a fairly easy transition to make as well (especially if you're going Rails to Play).

Obviously, I'm biased toward Scala and I push for it everywhere I work, but in all of these places, I believe I've only run into one or two people who said that if they had the chance to do it over, they wouldn't have made the change to Scala. 

Bienlein

unread,
Dec 3, 2013, 1:12:45 PM12/3/13
to scala-...@googlegroups.com, scala-internals
I can also make some constructive contributions. At least, this is an attempt to do so. One idea that struck my mind is to define several layers in Scala to provide a smoother introduction into the language:

Scala I: Java done right + advanced OOP (traits, higher-order functions, Option, etc.)
--> Scala for the masses that just want to get work done, similar to Kotlin

Scala II: Scala I + FP + Scala collections + advanced implicits
--> Scala I + the stuff from FP that is also useful in imperative programming. I think the Rust guys did this really well.

Scala III: Scala II + all the heavy lifting and heavy FP stuff like monads + whatever

Those 3 Scala layers are just a sketch to explain the idea. But the point is that everyone can chose the Scala layer appropriate for his/her interest/kind of application/background/believes/whatever without any preaching into something. I'm quite sure people would feel much more comfortable with Scala to begin with if f.ex. the "Programming in Scala" book were organized in sections where every section is about one of those Scala layers. People are free to stop reading after the section describing the layer they are interested in.

With a layered approach there will be people that say they really like Scala I and that's what they do in their spare time or in their current Scala project at work. So far they don't have a need for Scala II or Scala III. Maybe later when implementing some heavily concurrent application. My impression is that this "100% Scala or nothing" thinking puts people off. The result is some counter reaction and they inevitably turn their back to Scala, because with this "100% or nothing" thinking there is no other choice left.

Regards, Bienlein

Juha Heljoranta

unread,
Dec 3, 2013, 1:28:18 PM12/3/13
to scala-...@googlegroups.com
On Tuesday, December 03, 2013 12:15:42 atomly wrote:
> I would certainly be willing to help contribute to an Effective Scala
> guide-- is anybody else interested in this? If I have some time in the next
> day or two, maybe I'll start a PR for this...

I'd like to contribute too but would prefer wiki for this. There is
https://wiki.scala-lang.org/
which is effectively dead. Then there is
http://docs.scala-lang.org/
but, IMHO, casual/spontaneous contributions to there are effectively
impossible (clone, edit, compile, PR). But I do understand that documentation
in there is considered to be official and therefore expected be high quality.

Would it make sense to revive wiki.scala-lang.org for more casual
contributions?

For example, look how Drupal handles this:
https://drupal.org/node/266622

Cheers,
Juha

Paul Phillips

unread,
Dec 3, 2013, 1:34:33 PM12/3/13
to scala-i...@googlegroups.com, B H, scala-debate

On Tue, Dec 3, 2013 at 8:46 AM, martin odersky <martin....@epfl.ch> wrote:
For instance, people might find structural types hard (or not).

There are people who find structural types hard (sometimes this is phrased "useless") and there are people who don't use them. I'm not aware of any third category. I was reminded of this again recently when I re-encountered the inability to write trivial signatures:

scala> type Mappable[A] = AnyRef { def map[B](f: A => B): Mappable[B] }
<console>:7: error: recursive method map needs result type
       type Mappable[A] = AnyRef { def map[B](f: A => B): Mappable[B] }
                                                          ^
That's only a modest bonus for the amazing wontfix


The language demands unsatisfiable conditions in its structural type signatures. This is considered to be a feature. You would surely be better off removing structural types entirely than you are offering this variety of "hard" to the unwary.

(Some other good variations on the below are "length", "close", "flush", ...)

scala> type HasSize = { def size: Int } ; def f(xs: HasSize) = xs.size ; f(null: List[Int]) -> f(null: java.util.List[Int])
<console>:11: error: type mismatch;
 found   : java.util.List[Int]
 required: HasSize
    (which expands to)  AnyRef{def size: Int}
        f(null: List[Int]) -> f(null: java.util.List[Int])
                                    ^

scala> type HasSize = { def size(): Int } ; def f(xs: HasSize) = xs.size ; f(null: List[Int]) -> f(null: java.util.List[Int])
<console>:11: error: type mismatch;
 found   : List[Int]
 required: HasSize
    (which expands to)  AnyRef{def size(): Int}
        f(null: List[Int]) -> f(null: java.util.List[Int])
              ^

scala> type HasSize = { def size: Int ; def size(): Int } ; def f(xs: HasSize) = xs.size ; f(null: List[Int]) -> f(null: java.util.List[Int])
<console>:11: error: type mismatch;
 found   : List[Int]
 required: HasSize
    (which expands to)  AnyRef{def size: Int; def size(): Int}
        f(null: List[Int]) -> f(null: java.util.List[Int])
              ^
<console>:11: error: type mismatch;
 found   : java.util.List[Int]
 required: HasSize
    (which expands to)  AnyRef{def size: Int; def size(): Int}
        f(null: List[Int]) -> f(null: java.util.List[Int])
                                    ^
<console>:9: error: method size is defined twice
  conflicting symbols both originated in file '<console>'
              type HasSize = { def size: Int ; def size(): Int } ; def f(xs: HasSize) = xs.size ;;
                                                   ^

Levi Notik

unread,
Dec 3, 2013, 2:16:15 PM12/3/13
to scala-...@googlegroups.com, scala-i...@googlegroups.com, B H
There is a considerable shift in one's mental model that is required in order to become productive using Scala that is simply not required for other languages. It seems to me that a lot of the people who are bashing Scala simply do not want to challenge their existing beliefs and are not interested in the discomfort of feeling stupid all over again. They have a view of how things should work and languages are judged by them based on how pleasantly the language caters to their notions of what programming should feel like. 

Some FP concepts can be difficult to grasp, but spending the little bit of mental energy to try to assimilate a basic FP concept such monads can yield huge, tangible rewards; code is easier to reason about and business logic shines through. But people who come to Scala with strong opinions about how things ought to work and/or an expectation of immediate gratification (typically in the form of feeling like the smartest person) will never see this. I've noticed a common profile among many people who have embraced Scala and are using it very productively: they tend to be humble, not too set in their ways, and genuinely excited about being made to feel they know very little and are being given a chance to "keep up" as opposed to having everything dumbed down for them.

It's important to be open to the idea that things can be improved in Scala and in the community, but we must first be able to distinguish between constructive/valid criticism and ignorance/haughtiness. Bashers are generally disingenuous quasi-onlookers who have not spent any time extending themselves by even the tiniest amount in order to consider functional concepts which are foreign to them. 

Many of the bashers I've heard from seem to prefer an intrinsic and immediate sense of competence in the language/framework of their choosing. Having to drastically shift one's mental model doesn't jive very well with this. To some, it may sound like a defense mechanism to say that Scala just isn't for everybody and that a certain mental flexibility may be required, but we have to be open to the fact that there's some truth in this.

If we try to dumb down the language, the way its presented, and the community in order to cater to stubborn minds, we'll end up with neither a smart language nor a thoughtful community.

CCs

unread,
Dec 3, 2013, 2:18:31 PM12/3/13
to scala-...@googlegroups.com, scala-internals
Martin,

Let me reframe the issue:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." ~Bjarne Stroustrup

So congratulations, Scala matters! :)

I love Scala, yet sometimes I do up-vote the Scala rants on Hacker News:
1. Most of the rants are about a specific library, not Scala.
2. Mostly it is about DSL, which is powerful and easy to abuse.
3. Scala can evolve only if enough people use and criticize it. I'm happy you (Martin) are listening. :)

For me it boils down to DSL. I do see the benefits and sometimes it might be a great tool.
And most of the time it is used in truly awful ways.

Having to remember what %% means in 5 different libraries is just way too much.
Add to it some string explicits and it becomes hopeless.

I know what + should mean and I'm not happy when somebody innovates on this front.
Some ideas in the Scalaz lib are good, but my main goal is to write business logic, not to figure out what  <|*|> |^| or ?|? means for yet another library.

Cheers,
Csaba



Raoul Duke

unread,
Dec 3, 2013, 2:22:23 PM12/3/13
to scala-debate
> Some ideas in the Scalaz lib are good, but my main goal is to write business
> logic, not to figure out what <|*|> |^| or ?|? means for yet another
> library.

do such glyphs appear in weird ways in core scala? or just in 3rd party libs?

CCs

unread,
Dec 3, 2013, 2:34:59 PM12/3/13
to scala-...@googlegroups.com
In core Scala only the built-in XML is weird.
But Martin said he would leave XML out if he could do the decision again. :)

Csaba

Simon Ochsenreither

unread,
Dec 3, 2013, 2:39:09 PM12/3/13
to scala-...@googlegroups.com, scala-i...@googlegroups.com, B H

If we try to dumb down the language, the way its presented, and the community in order to cater to stubborn minds, we'll end up with neither a smart language nor a thoughtful community.

+1

Hanns Holger Rutz

unread,
Dec 3, 2013, 2:40:53 PM12/3/13
to Raoul Duke, scala-debate
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

i think people have generally become very cautious with symbolic
method names. the rants about their (ab)use usually rotate around the
same three or four examples, often referring to older versions of
libraries or tools (sbt, dispatch, ...)

in the scala standard library there are rather few symbolic names. for
example, in collections you will find `+` to add an element, `++` to
add all elements of a collection, `:+` to append, `+:` to prepend, and
cons lists use `::` and `:::` for prepend. these things are very easy
to remember. there is also the arrow association `->` which is often
the easiest way to create a tuple of arity 2 (a pair). and there are a
few symbols which relate to type constraints, e.g. `A <:< B`
constructs a value that says "I know that A is a sub type of B"
(similar to the type declaration `A <: B`). Given the hundreds of
classes and probably thousands of methods of the standard library,
these cases amount to a very small fraction, and it shouldn't be too
difficult to learn them. For some there are useful mnemonics, for
example (x /: xs) is a fold-left (you can write `foldLeft` if you
like) and is easy remembered if you think of "dominos falling to the
right. Also it helps to remember colon `:` is always on the side of
the collection argument. Some symbols are pretty easy to remember,
e.g. `???` literally meaning what-the-heck-i-don't-know. You put it as
a placeholder for a piece of code not yet implemented. It is just a
method that throws a non-implemented exception.

Scalaz is a separate library. The operators are modelled after the
Haskell equivalents, and thus the symbols are often not invented but
just imported from Haskell which in turn emulates some mathematical
operators.

The use of symbolic names in DSLs is mostly domain specific and makes
sense when you want to express something concisely. Example: parser
combinators. Like any API you need to learn those methods, and not
always are symbolic names more difficult to remember than alphabetic
names, especially when abstract concepts are represented.

Best, .h.h.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSnjPFAAoJEKZFmaPaYk6Qp74P/2/IiIrOp3v7gQwYSoedY1WH
4Py/QshlPaplZdbK0WgN0PaLddoH2bhVisZEUy4EzsFpUU2wmPylVD1lK36Mk/ah
7C7U7udELVzRmMdbaBs0VDxYxb7fLamoDwIpajyc7DLQjIiSrnubaYXoupomWYYC
+KJ3X+8ATGGKnK+pBf16oQs/36SVpVTKdRlTyVwQuZZ5xXVMn540vmQ3uKbuaMPm
MVenIG/d7jUEN5bzegYt1SRpB2dYBehs6NeB/n3PYaHba8lbCuDWk+VJstIvJnmH
MTqpm8ghvlPI97Ze988ydltcG0LBazxk8WCUDmZ7j/E+4isLhAZXfzzFliFl54wN
hIcl89gAjKfxtFom9NnyVsnOUHqICTZ2jxZSVX7ZhNJE4e4hKV/fy7iNme7Ttl9V
Tl33Wjz8GRm8kKHR6c4oqXWax5bssSOBCVDtZ52OhC3DR+cXiBXqvtULvgKx0cdB
GidKeAb5fXsnycxYWUGgA2slpA0MLb7b2UliTl4HyyLp1RPFKuXyRKpf0hnZygZK
p7ajb+ihdZc6WIBVG0B+zJ30S03c+S82dOdYoK/r4hwZdl2ywfd3KfbJ+A/co3hU
IYsU364MVXroWBCkJvo8yFwDFGQXcMDYO7/CX/6leTl49qNvOB9lsjnbX6O1uv/0
n2ZV4WD2EgPxXNgkggLV
=wVEN
-----END PGP SIGNATURE-----

Christian Helmbold

unread,
Dec 3, 2013, 3:56:50 PM12/3/13
to scala-...@googlegroups.com, scala-internals
Hi Martin,

I think the reason for this sort of Scala rants is the result of initial frustration. Go, which seems popular on hacker news, is a really simple language. If you know any C-style language you can be productive with Go in a few days. You can be productive in Scala very fast, too, but Scala has much more concepts than Go. So you have to make a much bigger upfront investment. It seems like most people complaining about Scala stumbled on their first steps and decided to prefer bashing over learning.

However there is one thing that I really dislike about Scala: the ability to create methods like %% or #>. With great power comes great responsibility, but many developers (even framework creators) are not responsible enough. Such method names should be banned! They should at least be removed from APIs of the Typesafe stack (SBT for example). I'm not aware of another language with so many unreadable APIs.

Perhaps something like http://www.scalastyle.org/ should be improved and promoted. There is a bit too much variance in Scala code, what could be reduced for better readability.

I think that there is one aspect of programming languages not getting enough attention: usability. Most languages are shaped by the preference of their authors. Why not make programming language usability tests? That would be the ultimate way to make programming languages usable! See: http://quorumlanguage.com/ Maybe Scala could be improved with such tests.

Regards
Christian

CCs

unread,
Dec 3, 2013, 4:08:29 PM12/3/13
to scala-...@googlegroups.com, Raoul Duke
Hanns,

It's never a question if somebody could learn it.
The question is: why?

Here is a copy&paste from a popular library:

"* ^^"._? #> (a.!?(1, Get())) must be_==(Full(Answer(1))) ?~! eventually

Can you explain what it means? If you take it item by item it all makes sense.
Now if you use 10-15 libraries, all of them start to "innovate" like this, when do you write actual code?

Now compare the DSL with a random Finagle code:

      val lastForums = ann match {
        case a: ProxyAnnouncement => a.forums
        case _ => Nil
      }

If you know Scala, you understand what it means.
No need to look for "right falling domino sign" or "Admiral Ackbar operator"; you can actually be productive.

Csaba

Hanns Holger Rutz

unread,
Dec 3, 2013, 4:19:42 PM12/3/13
to CCs, scala-...@googlegroups.com, Raoul Duke
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/12/2013 22:08, CCs wrote:
> Here is a copy&paste from a popular library:
>
> "* ^^"._? #> (a.!?(1, Get())) must be_==(Full(Answer(1))) ?~!
> eventually
>
> Can you explain what it means? If you take it item by item it all
> makes sense. Now if you use 10-15 libraries, all of them start to
> "innovate" like this, when do you write actual code?
>

I don't know that library, and I can't tell if this is an actual
example or an exaggerated one. In any case, I wouldn't use this
library if this was the only way to express things.

I use dozens of libraries, in fact I have written dozens of libraries
myself. I have not come across a single project which requires several
libraries with excessive symbolic notation.

So in my experience, this is a non problem, but perhaps there are
scenarios where you come across them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSnkruAAoJEKZFmaPaYk6QWvAQAJA1XuQn1I7PnkY/AuBpOHxy
8B5MpmuLU7AZj5V1ned7n5MLeNFgqa8W9fMXbXL1wYAq24g20bmobr3VvGTJh4rf
gkz4NUQelBIge8FLPmAWM8x9ELaJUgW1zwoYLEbgpCCBt2nt9C+x3zEVa6qaKCJ/
t8J3JshCOJturcH1K3oHcKuOC5/BUHKI/Oks/2eo3l/gxutmSGPikLtFvvzb1CD0
Ko8aVcc+U7fDhi6CBzWLvkU0921V8ZxnshV7oNuOtzme+mUeNPhDCg7GDN8LLtsZ
XAHX1Gmpf887NxN5Yk6pcjFhZ9GVCvc6coalwqsiG7VDswcfQCEBvXMYwBm5WHZd
JXgaZIgvSN19LUxU4BD3t1O/ETpnFVQSBEwNIPg1Ow1k1EKuUCGCPyTKcTXyvR0K
lqzxk2qy0IkIZjp/3xXm7w5kCYZCM0+auDR2DYTtw1G1GzPy97WJIRFNLUfDyuCG
MR2Kl6JuwNqbazmftPAMNwjZrqV+36G2sfZ+WxRQAN2rKZ8BtN1HQjYaq+NzAVp/
CKSHL1Anejh3Hka/Lb9qQYBehY+TeY2elfppXDVEZs6m64s9knTMnn3clxcr3xGz
JazqqSvSe1henAHl44WAtVP6OL+fGfEbYKo3IVePFYsmbCTCozoU3J0Fauleo4yW
UHc9Q5vfxSn1OHRzdL32
=f3/l
-----END PGP SIGNATURE-----

Rich Oliver

unread,
Dec 3, 2013, 4:49:34 PM12/3/13
to scala-...@googlegroups.com, scala-internals
On Monday, December 2, 2013 9:32:15 AM UTC, Martin wrote:

For me the main reason is that programming languages are incredibly tribal and Scala has no traditional community - the functional/object-oriented programming "tribe" is still in its formation state.

 - Martin

I still don't feel you've fully defined your fundamental view of software and programming languages. Functional/Object-oriented gives a rough idea but what are the limits. Are actors and pure functional sufficient or is their a place for conventional mutability of objects and collections. Do you think C++ object orientation has a useful place for certain domains? What are the limits of garbage collection? Perhaps more could be said about GUI's as this was supposedly the driver of OO, yet Scala doesn't really have a proper GUI API. I think most of all it would be great to have a clear view of what is in Scala, because you really want it in, what's in Scala to fit the JVM, what's in Scala for compatibility with Java, each way and what's in Scala because of legacy?

I'm just an individual of no particular importance, but personaly I would describe my outlook as powerful strongly typed, static, multi-paradigm Object-Oriented and hence I would see myself as part of the Scala / C++ community. But perhaps I'm alone in this? Anyway I'd love also love to hear the perspective of other leading Scala people or just Scala people. Do they consider themsleves of the Functional/Object-oriented school? Do they have another slant? What's most important to them OO, traits, Functional, the option to write imperative code, static, the JVM, the ability to use Java libraries etc?

Russ Paielli

unread,
Dec 3, 2013, 4:54:17 PM12/3/13
to CCs, scala-debate, Raoul Duke
On Tue, Dec 3, 2013 at 1:08 PM, CCs <csaba...@gmail.com> wrote:
Hanns,

It's never a question if somebody could learn it.
The question is: why?

Here is a copy&paste from a popular library:

"* ^^"._? #> (a.!?(1, Get())) must be_==(Full(Answer(1))) ?~! eventually

I'll bet someone is proud of that line.
 

Can you explain what it means? If you take it item by item it all makes sense.
Now if you use 10-15 libraries, all of them start to "innovate" like this, when do you write actual code?

Now compare the DSL with a random Finagle code:

      val lastForums = ann match {
        case a: ProxyAnnouncement => a.forums
        case _ => Nil
      }

If you know Scala, you understand what it means.
No need to look for "right falling domino sign" or "Admiral Ackbar operator"; you can actually be productive.

Csaba

 
Human readability is obviously important for critical software that needs to be maintained. If I did not believe that Scala can be used to write very readable code, I wouldn't be using it. However, no general-purpose language can force all code written in the language to be readable. We need to be careful not to blame a language for poor use of the language. (I'm not saying you did that here, but I have seen it done many times.)

In fact, some language features can enhance readability if used well or degrade readability if not used well or if used in combination with too many other features. Implicits and operators are a classic example of that. They can be used to write elegant, readable code, and they can also be abused to write unreadable junk that will have you scratching your head all day over one line. What Scala needs more of, in my opinion, is guidance on how to write readable software, not just for trivial tutorial examples, but also for larger, real-world problems.

--
http://RussP.us

Daniel Sobral

unread,
Dec 3, 2013, 4:55:10 PM12/3/13
to scala-debate
I'm briefly interrupting my sabbatical to wonder at how big Scala grew that it can draw such heat! Why, five years ago, when I first started reading about it, I wondered if it was ever going to be more than a toy language outside academy, and never could I foresee it reaching the spread and importance it has today!

Now, while any comparison to C++ is laughable (it's not even C++ 2.0's size, and it is *coherent*, mixed paradigm and all, which C++ never was), Scala has a certain level of complexity. It just suffers from doing things no one has seen before at the popularity levels Scala has reached (or at all), so it's a complexity that's unique.

I think you have done everything right regarding that crowd, that the current direction seems reasonable, and that you can no more avoid them that OO could avoid its frothing-at-the-mouth detractors. 



On 2 December 2013 07:32, martin odersky <martin....@epfl.ch> wrote:
Seems hardly a weekend goes by these days without another Scala rant that makes the Hacker news frontpage. 


This week-end's edition is called "Scala - 1 Star - would not program again", and it's by someone who from reading his post seems to have written Scala all of two weeks after coming form Javascript. I think the interesting bit is not so much that these posts are written, but that they are upvoted so much. 

There certainly seems to be a grand coalition of people who want to attack Scala. Since this has been going on for a while, and the points of critique are usually somewhere between unbalanced and ridiculous, I have been curious why this is. I mean you can find things that suck (by some definition of "suck") in any language, why is everybody attacking Scala? Why do you not see articles of Rubyists attacking Python or of Haskellers attacking Clojure? 

For me the main reason is that programming languages are incredibly tribal and Scala has no traditional community - the functional/object-oriented programming "tribe" is still in its formation state. People are coming to Scala from all sorts of communities: Java, Ruby, Haskell, you name it. 

Scala's generality makes it both a threat because it *can* do tasks that are traditionally the domain of these other communities and an easy target because every community finds something that is foreign from their point of view. Java people will bitch about how academic FP is, JS and Ruby people complain about the types. Haskell people complain about the objects and that the types are not strong enough. And even though those communities would normally never mix, they find common ground in the opinion that Scala is a horrible language. 

What can we do about it? Not that much I fear, but there are some bits that are useful nevertheless.

 - Work on the things people tend complain about, as long as this makes sense. 

     + we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this
        is no longer that much of an issue.
     + we are working on compile times and expect to have significant progress to announce for 2.11
     + we are working on making binary compatibility less of a problem
     + we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.

 - Work out the simple parts of Scala. Show that Scala hangs together rather well, that it has a fairly modest footprint, and that it is definitely not twice the complexity of C++ as one poster on the thread claimed.

 - Work more on forming the community. Make it clear that Scala is a third way, it wants to be neither a Java with semicolons nor a Haskell on the JVM. 

 - Work on giving more guidance what good Scala code should look like. For instance, develop a detailed, type based lint tool with configurable complexity. Or think about what useful design patterns in Scala are.

 - Last, but not least, engage in these discussions on HN and elsewhere in a polite but firm way. State where your experience differs from the other posters. When somebody complains about long compile times, state that incremental compilation works well for you (if it does, that is, it certainly works well for me by now!). But don't attack the other poster even if you find their arguments lacking, that usually just leads to a mud-fight.

If you think of other constructive things we could do I would be interested in reading them!

[Follow-ups to scala-debate, please]

Cheers

 - Martin

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.



--
Daniel C. Sobral

I travel to the future all the time.

Rex Kerr

unread,
Dec 3, 2013, 6:30:27 PM12/3/13
to CCs, scala-debate, Raoul Duke
On Tue, Dec 3, 2013 at 1:08 PM, CCs <csaba...@gmail.com> wrote:
Hanns,

It's never a question if somebody could learn it.
The question is: why?

Here is a copy&paste from a popular library:

"* ^^"._? #> (a.!?(1, Get())) must be_==(Full(Answer(1))) ?~! eventually

Can you explain what it means?

So don't use this library.

Symbolic operators are extremely useful when used properly.  There are many ways to use them properly.  There are many ways to misuse them.

The best way to encourage proper use of symbolic operators is to avoid using libraries that expect you to write symbol soup without good reason.

The best way is not to insist that the language not support symbolic operators and therefore make it excruciating to write vector mathematics and grammars and all sorts of other things for which symbols are really useful.

I do think it's valuable to give feedback to developers of popular libraries when it seems that they have gone overboard with symbols.  For example, although <<= is somewhat mnemonic, I am not sure it was a good choice for SBT to rely upon this for setting a new key, especially since the exact same symbol means "bit shift left in place".

On the other hand, having ++ and +: and :+ available for all collections is just amazing because it lets the structure of your code match the intent:

  "first" +: rest        // Exactly the way it looks!
  rest.prepend("first")  // Oh boy, mental gymnastics!

  --Rex
 

Vlad Patryshev

unread,
Dec 3, 2013, 6:33:08 PM12/3/13
to Rex Kerr, CCs, scala-debate, Raoul Duke
With one traditional non-commutativity of +:

"a"+Set("b","c") != Set("b", "c") + "a"

Thanks,
-Vlad


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.

Rex Kerr

unread,
Dec 3, 2013, 6:37:49 PM12/3/13
to Vlad Patryshev, CCs, scala-debate, Raoul Duke
I do so wish + would not turn into a world-eating monster whenever it got so much as a whiff of a string.

  --Rex

√iktor Ҡlang

unread,
Dec 3, 2013, 6:40:00 PM12/3/13
to Rex Kerr, Vlad Patryshev, CCs, Raoul Duke, scala-debate

Would be interesting to explore a SIP-18 addition for Java semantics.

Import language.javacompat.stringAdd etc

Bill Venners

unread,
Dec 3, 2013, 7:35:56 PM12/3/13
to scala-...@googlegroups.com, scala-internals
Hi All,


On Monday, December 2, 2013 9:32:15 AM UTC, Martin wrote:
     + we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.

I would be OK with providing an annotation people could optionally use to give a name to a symbol, which could pop up in IDEs when someone hovers the mouse over the symbol. But I wouldn't mandate it and certainly wouldn't recommend people make aliases. My take is that if the meaning a symbol is obvious to your users, it just adds clutter to the design to also provide an alphabetic alias. Otherwise, the symbol is non-obvious, and you should probably *only* provide an alphabetic name and not use a symbol.

There's a four minute segment of my Simplicity in Scala Design talk on this subject that starts here:


Bill

Simon Ochsenreither

unread,
Dec 3, 2013, 7:42:09 PM12/3/13
to scala-...@googlegroups.com, Rex Kerr, Vlad Patryshev, CCs, Raoul Duke

Would be interesting to explore a SIP-18 addition for Java semantics.

Import language.javacompat.stringAdd etc

Agree. I think we could encourage developers more actively to migrate to string interpolation (maybe even provide some automatic refactoring in Scala IDE) and plan for a long-term removal.
Same thing with dangerous implicit widening conversions.

Simon Ochsenreither

unread,
Dec 3, 2013, 7:44:35 PM12/3/13
to scala-i...@googlegroups.com, scala-...@googlegroups.com

I would be OK with providing an annotation people could optionally use to give a name to a symbol, which could pop up in IDEs when someone hovers the mouse over the symbol. But I wouldn't mandate it and certainly wouldn't recommend people make aliases. My take is that if the meaning a symbol is obvious to your users, it just adds clutter to the design to also provide an alphabetic alias. Otherwise, the symbol is non-obvious, and you should probably *only* provide an alphabetic name and not use a symbol.

Totally agree on that. I think what's mostly needed is actually talking to library developers where one fells like symbols are used in non-obvious ways. Imho this has a pretty good track record (dispatch, sbt) of working.

Rich Oliver

unread,
Dec 3, 2013, 7:51:20 PM12/3/13
to scala-...@googlegroups.com, Vlad Patryshev, CCs, Raoul Duke
On Tue, Dec 3, 2013 at 3:33 PM, Vlad Patryshev <vpatr...@gmail.com> wrote:
With one traditional non-commutativity of +:

"a"+Set("b","c") != Set("b", "c") + "a"

Thanks,
-Vlad

On Tuesday, December 3, 2013 11:37:49 PM UTC, Rex Kerr wrote:
I do so wish + would not turn into a world-eating monster whenever it got so much as a whiff of a string.

  --Rex

StringAdd is an abomination. It doesn't exist in C, C++, Pascal, or C#. How it can be justified in Scala which is supposed to be a stronger typed language is quite beyond me. One of my interests is teaching Scala to absolute beginners. I haven't tried it with children yet but I'm interested in trying it with children maybe as young as 8. I always start off with:

2 + 2
res0:Int = 4

That's it you're programming Scala. What could be simpler? You can already program Scala as a simple calculator. I then go to on show them doubles (decimal numbers) and ints (whole numbers), vars and vals. The fact that an int can be a double, but a Double is not an Int is fairly straight forward. I then want to bring in Strings so we've got a basic idea of types. A String is not an Int. A string is not a Double. but StringAdd actually complicates things.

2 + "two"

is wrong. It should give an error because they are different types. After that I would go on to create a simple case class.

StringAdd is really, really unhelpful. Anywhere you want a + method eg 2d /3 d vectors. Particularly now we have macros. Convert Println etc into a Macro. Within the Macro parameter, do what ever crazy type inference you want, just don't pollute the whole global name-space. StringAdd is global warming, Three Mile Island and the BP Gulf Spill all rolled into one.

Rex Kerr

unread,
Dec 3, 2013, 11:51:45 PM12/3/13
to Simon Ochsenreither, scala-debate, Vlad Patryshev, CCs, Raoul Duke
Incidentally, there at least used to be a sizable performance penalty for string interpolation (2-4x IIRC).  Not a big deal if you're formatting some text for the screen, but not so hot if you're writing big data files.  I suppose one can always resort to
  "foo" concat "bar"
and manual StringBuilder usage if it's really important.

  --Rex

martin odersky

unread,
Dec 4, 2013, 3:04:40 AM12/4/13
to √iktor Ҡlang, Rex Kerr, Vlad Patryshev, CCs, Raoul Duke, scala-debate
On Wed, Dec 4, 2013 at 12:40 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Would be interesting to explore a SIP-18 addition for Java semantics.

Import language.javacompat.stringAdd etc

Unfortunately, Javascript seems to have the same operator. So it would have to be:

   import language.javaOrJavaScriptOrCSharpCompat.stringAdd

Seriously, String + is a sore, and it would be great of we could get rid of it. But that looks like a Scala 3 feature, because the best way to get there is by automatic program rewriting, and that's something we postulate to have only for an eventual Scala 2->3 transition. To require a language import without automatic rewriting would create a huge pile of busywork for everybody given how ubiquitous String + still is.  Not to speak from most Scala documentation which would become outdated.

Cheers

 - Martin



--
Prof. Martin Odersky
LAMP/IC, EPFL
Station 14, 1015 Lausanne, Switzerland
Tel: +41 21 693 6863

pagoda_5b

unread,
Dec 4, 2013, 3:50:38 AM12/4/13
to scala-...@googlegroups.com
I would find useful to propose an official poll, coming from the scala staff, asking to categorize the language features.
Do you find the following feature: a) pretty usable; b) somewhat hard; c)  really complicated

I 'd hope such kind of initiative would be positively met from the programming community as a token of the interest that scala designers have for the community.
It would be easier also for people to choose from an already populated list, rather than take the time and figure out by themselves which features are the most critical. Everybody know that people are lazy, and would spend their time only if it could mean some significant return relative to the investment.

My own list of what I think could be considered hard or confusing ([H] [C] should we distinguish?) stuff, from a quick mind survey:
implicits [HC]
lambda syntax [C]
existentials [H]
enumerations [C]
path dependent types [HC]
selftypes + mixin inheritance [C] (in fact I finally understood how the whole modular composition fits together by reading a 2005 paper fomr you and Zenger titled "Scalable Component Abstractions". It would be great to have some documentation page explaining the logic behind scala modular composition in those terms but with a less technical approach)
type variance [H]
for-comprehensions [HC]

It takes time to come to terms with this features, so it would be great if some effort could go into explaining how to use them, when to use them and when _not_ to use them.

Thanks for your interest
It's really appreciated

Good day
Ivano

On Tuesday, December 3, 2013 5:46:05 PM UTC+1, Martin wrote:


It would be a pity to let the "hard" parts distract you from using the language as a whole. We can try to soften up the hard parts, either by better explaining what they are, or by clearly labelling them as specialized (as we did with SIP 18). But to do this, we have to first know what they are. So, I am always interested in getting concrete examples about what people find hard. Here, I do not mean small syntactic quirks (every language has them and everyone can live with them), and I do not mean programming paradigms (i.e. sure functional programming is hard for someone who has never seen it, but that does not mean you should not learn it!). I mean more the things in between. For instance, people might find structural types hard (or not). I know many find existential types hard. If we have better data about what people find hard we can think about how to simplify, and I think this would be a very worthwhile undertaking. 

Best,

-- 

Michal Politowski

unread,
Dec 4, 2013, 4:14:29 AM12/4/13
to scala-...@googlegroups.com
On Tue, 3 Dec 2013 13:08:29 -0800, CCs wrote:
> Hanns,
>
> It's never a question if somebody could learn it.
> The question is: why?
>
> Here is a copy&paste from a popular library:
>
> "* ^^"._? #> (a.!?(1, Get())) must be_==(Full(Answer(1))) ?~! eventually
>
> Can you explain what it means? If you take it item by item it all makes
> sense.

Yup. Not exactly readable this one. At least without knowing the libraries
involved.

> Now if you use 10-15 libraries, all of them start to "innovate" like this,
> when do you write actual code?
>
> Now compare the DSL with a random Finagle code:
>
> val lastForums = ann match {
> case a: ProxyAnnouncement => a.forums
> case _ => Nil
> }
>

Still, for a fairer comparison it would be good to see the exact previous example
rewritten to some more letter-heavy API.
This one does so little it could probably be almost as readable if 'match'
(and 'case'?) were replaced in Scala with some symbolic keywords.

--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

Hanns Holger Rutz

unread,
Dec 4, 2013, 4:18:31 AM12/4/13
to Vlad Patryshev, Rex Kerr, CCs, scala-debate, Raoul Duke
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think removing `Predef.any2stringadd` or moving it somewhere so that
you need to explicitly import it, is high on the wish list of many
people...

On 04/12/2013 00:33, Vlad Patryshev wrote:
> With one traditional non-commutativity of +:
>
> *"a"+Set("b","c") != Set("b", "c") + "a"*
>
> Thanks, -Vlad


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSnvNnAAoJEKZFmaPaYk6QX3IP/jr+eWpBSAsJMoizt4LWYC9b
oPJmjidKG2YOWfbUj753xQG5oafQa5YNV1ZRi6F20DRIbK6cE5qbmZBDP+qkGlCO
hW0S7s6cAYFHmCV9Y9CpOeUYhk3vWUC41/nvBilDKsa7dM2MmCCjj5tkOY2dXUAQ
a42Hjkr79R1FeL9SCan6cOiq3jGCEtIs9iqirqkTiQb0/oP1qXuTg/VY0923fPrj
relQJqX72LmKyX0rAXlLj9Kyjc/Bl77eEMcvIfRunwL+1gh/fCSQ9Lm3NZXrikNe
hSZibJstHj+r3W2lSzAkJwt8RGBCxBInUu8v1xuUBHSjxWgF05FupowBK/TvA3qa
LSuo/TsjhZXg5cGNCWOZItiHKPV+31Sa3tsvwxcN188Sa8piiyJQYCX/7eUKiRsz
l6z9OY/fVQ2TrNiZtOysOEqn5q0YzjQL/hgzMeKPq598yDb4q1pZU8T/OiT4C99l
cywL/r5nwrLyvpZ4Kb7UdYh+PsZR/T/haE5W7hwXl1pSgTlTlaQ5FfYo2/fc1c6k
vvrMgwNiNxYx0sZnUsd2sj4+lFjt3UrylKaXwVasT8VhbPlJbPC4tJEbNBw3SAob
Nw5jcASRPNm0NRY2pb7jAPVaJMLmw6rLIEejdLow74BwQF72a7fluRYkXfsOzXBz
TfCd8RDqoZ7mLhTdq72Q
=i2g1
-----END PGP SIGNATURE-----

Neil Carrier

unread,
Dec 4, 2013, 9:29:22 AM12/4/13
to scala-...@googlegroups.com, scala-internals

“Every great scientific truth goes through three stages. First, people say it conflicts with the Bible. Next they say it has been discovered before. Lastly they say they always believed it.” – Louis Agassiz


At the risk of showing my age, I can remember when C++ and OOP were at the same point Scala is at. All attempts to introduce C++ and OOP at the company where I worked got a smackdown from the management. “Too new, too academic, etc...” You know the rest of the story: within two years they were a “C++ shop.”

Cristian

unread,
Dec 4, 2013, 9:39:12 AM12/4/13
to scala-...@googlegroups.com, scala-internals
I would like to second this comment. The advertised USP of Scala seems to be that is a OO/FP language, but it's not clear what benefit one would get from that.

I've been doing Scala professionally for 1.5 years, I was very excited about it in the beginning and I am thankful to it for introducing me to Haskell (I did a lot of Java before)

I understand the notion of a bridge between OO and FP but the problem with that is that a bridge is for crossing, not to dwell on.

C# added the most obviously useful FP features packaged nicely in delegates , LINQ and Async to not trouble the OO world view.

Scala seems like Java and Haskell smashed together and one needs to pick the pieces that fit their mental model, and ignore the rest as bloat.

Dickon Field

unread,
Dec 4, 2013, 9:40:29 AM12/4/13
to scala-...@googlegroups.com, scala-internals
I entirely agree with Neil here, and have experienced the same period of history with similar outcomes, as I perhaps poorly expressed in an earlier post. Functional programming techniques are already more widely accepted as being beneficial and will become common place and widely used in time. Once Java 8 is released and gets past the inevitable lead time for corporations to deem it an acceptable risk to adopt it, then they will become extremely widespread.

Probably like most people on this thread I think Scala has a lot more to offer than Java 8, but it will become more difficult to justify the decision to adopt it rather than Java unless the beneficial argument is really clear. The Principles of Reactive Programming course has at least partially built my understanding of what that argument is in terms of the ease with which you can almost transparently incorporate mitigations for concerns such as failure and latency into your code. The challenge for Scala is differentiate itself by articulate what these sweet spots are and popularizing programming approaches such as monads etc without blowing people's minds.
It is loading more messages.
0 new messages