Simple or Complicated?

 In my very humble opinion, I think that at least part of the problem here is that the average programmer hasn't seen a discrete math textbook for several years and if like me their memory is fuzzy w.r.t. the mathematical ideas of 'function' and (the more general) 'relation'.  A quick review of en.wikipedia.org/wiki/Function_(mathematics) may (or may not) help, I find myself returning to these wiki's time and time again to keep the ideas fresh in my head when I need to employ FP constructs.  Whether I'm using them in Scala, Ruby (with ActiveSupport) or javascript (with a lib like wu.js or underscore.js).

I think that as more and more people join the FP bandwagon, they will find they can't live without 'maps' and more specialized constructs like 'reductions' and 'filters', just like we can't live without the 'foreach' construct.

(Scala is a very very attractive language and I'm hoping a project comes along where I can push it to heavier use in the near future!)

It is obvious and we keep talking about it: it's almost like there are two flavors of scala: the basic client version and the framework/library builder version.

In an "average" project, you don't want everyone to start using 15 paranthesis and <% %%> /:, of course all via implicits...in a nightmarish version of the "worse C++ code" contests...you would have to deal with many former Java developers and I'd really like them to stick with the basic scala.

How do we do this? How do we define what "basic scala" is? Can we have scala "profiles" where the use of certain constructs generates warnings? Do we have guidelines as to what people can use? Is that even feasible?

That may be a valuable discussion as well...like you said, in fact it's both simpler and more complicated :)

There is a very nice document floating around which sums up good coding-conventions for scala (http://www.codecommit.com/scala-style-guide.pdf), and it should be obeyed for most usecases.

I think it should be enough to tell people not to "over-hype" features like operator overloading, implicit imports, abstract types and complex generic scenarios. In general, nearly all client code should omit these 90% of the time, and all programmers will have a happy time with scala.

Also, the talking about "average programmers" should be dropped. I think this is just hurtful to make scala appealing for the larger audience. Scala is a language which nearly everyone can use, as long as all people in a project use the same style and do not try to be functional at all costs. It IS a strict and imperative language after all, and can be used that way: Even then the code is much nicer and shorter than java code.

Just try to use real names for your methods and avoid too much inheritance (both single and mixin), abstract types and complicated generics and you can create code which is pretty much free of side-effects, yet easily to understand for any programmer who does not dwell in the functional realms. Closures and immutable values / collections are concepts which are so useful that is worth to teach them to any programmer. Most, I think, will even be willing to embrace the change of their style if the reasons for them are explained well.

That should be the route out of the "scala is too complicated" arguments. It is in our hands, after all, to swallow our arrogance for "shorter and better code" and write readable, yet concise, code for the masses. :-)

As someone very new to Scala (just started playing with it last week), but with a long background in modern strongly-typed functional languages, I can say that I'm not convinced that Scala is too complex as a language.  However, I'm also convinced that it needs much better documentation.  Not tutorials or articles, but reference documentation.

I'm convinced that it's the serious lack in this area makes things feel much more complicated than they actually are.

Some of this is in the basics--although that part seems to be because of some documentation regression from the 2.7 scala docs to the 2.8 docs.  (See below.)  But the lack of good reference docs for some of the more complicated pieces of the standard library can make it quite challenging to work out how things work.  Most importantly, the apparent complexity of the API is off-putting, even though the actual use of the API is not so bad.  If someone who's completely comfortable with monadic parser combinators is needing a few days to work out how things go together, a programmer without any PL theory background is going to be going cross-eyed.

Here are some samples of things I've had trouble with, just starting out:

1) Double.  What methods are on Double?  If you go to the current API documentation and search for "Double", you find scala.runtime.Double (an object), and scala.runtime.RichDouble (a proxy class that it's still not clear to me what it's for).  What you don't find is scala.Double.  In fact, when scala.Double does appear (for example, as an argument to RichDouble), it's not a link.  Does RichDouble's interface mirror Double's?  As a new user, I can't tell.  Eventually, I found the 2.7.7 scala API documentation, which does in fact have an entry for scala.Double.

2) While exploring, I came across Numeric, and thought I'd give things a shot.  This isn't so bad, since the whole concept is fairly advanced, but I was also disheartened here by the lack of any documentation in the API docs about what this is for or how to use it.  I found an example and explanation at stackoverflow, but again: this isn't the sort of thing you should have to go to an external site to understand--the standard library API docs should explain how to use it.

Why?  Because a programmer who's advancing in skill is going to occasionally be browsing around through the docs looking at things, and will come across the whole Numeric hierarchy of traits... if there's good documentation, then a new world of possibilities will open up to them.  If there's not, they'll go "Hunh.  Wonder what that is for...  *shrug*"  Not only will they not be making use of the capability in the standard library, but their thinking won't be stretched by the exercise of trying it out... which means that the techniques used will still be opaque to them when they encounter their next advanced piece of the API.

3) The 2.8 collection types.  Wow.  This stuff is seriously powerful, and I'm currently working my way through "Scala 2.8 Collections" in order to understand how what I write should fit into it.  What's my complaint here?  Primarily that there's a real lack of clear documentation (that I've found so far) on how to write a container that fits into the hierarchy.  Specifically, what's required of it, a skeleton for doing it, and so on.  I'm writing some classes to express grid systems, and my first thought was "Oh, this should be the sort of thing you can iterate over, map over, etc.  It should be easy."

And as far as I can tell, it *is* easy... but my first thought upon looking at the documentation was "Holy sh*t!  What is this?"  I even started to doubt that I understood enough about it to *use* the system, much less implement something to fit into it.  Now I'm starting to get things, but again, a new programmer is going to have trouble.  And more, the documentation that does exist (linked above) isn't written as a reference work for someone who says "Okay, bring up the API and let's see about Maps and Sets and such."  It's written as an explanation for people who already know Scala well, as an explanation about "what things are going to be like" (or, now: what things *are* like).

The big missing thing with the collection types is a clear explanation for new implementors, in terms of "this is the minimum you need to do to make your new class act like a proper collection, this is what you need to do to add a bit of functionality, and why you want to do it", and so on.

Of all of these problems, the difficulty of finding the APIs for basic types like scala.Double was the most troubling to me as a new Scala user who is an experienced programmer.  Longer term, things like the new collection system worry me because with something that conceptually complicated you absolutely should have documentation that makes it clear to the API consumer "this is really easy to use", and to the API coder "it's really pretty easy to write to this API, as well".

 There's tons of "here's a book about programming that is written using Scala" and "here's an introduction to the core features of Scala for an experienced programmer" or "here's a cookbook of the basic things" out there.  But the reference material is *awful*.

Maybe I just came in at the worst time, and my experience is extra bad because of the fresh transition to 2.8.  But it's still frustrating.

On the plus side, the language looks great, and I'm really looking forward to digging in and coding on my current project... once I understand the core library enough to stop having to play with it all the time to figure out how it works.

(P.S. I still haven't found a web page that talks about the invocation options of "scalac".)

(P.P.S. I would offer to try to improve the documentation, but as someone who's been using Scala for less than a week, I really don't think I'm the right person for the job.)

I think many people try to put too much emphasis on the "everyone should be able to program" theme.

Scala is a very nice multiparadigm language, and I have doubts that anyone with a proper CS background would had any major issue picking it up. The same goes for C++, F#, Haskell and other languages touted as complex.

Life is complex, many problems are also complex and we need tools that help solve complex problems, while making easy to do so. Like Larry Wall says, when he speaks about Perl.

From my consulting experience the reason many managers like average programmers is that they are easily replaceable.

I don't expect a car to be built by average people, but by people with proper engineering background.

Why should computing be any different?

Thank you all for your comments, they are the comments I'd like to have made.  I'm also in the "wanna learn it" camp.  I have two books to read to see I can get over the hump....  I'm hoping for one of them to encourage using some of the coding style practices that encouarge less tricks, more clarity in your code.

I really think someone needs to emulate what Perl eventually had.  There was the easy, introductory  book on the simple parts of Perl.  Then there was the Perl book that took you beyond that and into some of the bigger concepts of Perl.

One final word along the Perl lines.  I think it's funny that the Scala people are having the same arguments that the Perl people always did.  ie It's too hard for beginner's / just read the docs, it's really easy... or you can get it down to 2 lines just by doing XYZ...

Cheers and ciao :)

I know this topic is a bit stale, but wanted to add my 2 cents.  I believe Scala is complicated. I spent a couple days reading books, doing tuturials and I even started (but gave up) converting my own code.  Here are some reasons why it is complicated:

Scala looked very promising, but then I tried to convert what I thought was very simple Java to generic Scala:

public static double[] abs(double[] r, double[] im) {
  double t[] = new double[r.length];
  for (int i = 0; i < t.length; ++i) {
    t[i] = Math.sqrt(r[i] * r[i] + im[i] * im[i]);
  }
  return t;
}  

I thought, I can make this generic now and it will be efficient, using primitives not boxed objects ... awesome!  However I ran into my first issue:

1.) Scala claims to support imperative programming, but is strongly biased towards functional.  For example, there is no simple for loop. In the books I read I saw no examples of how to do a simple for loop.  I had to to use a clumsy while loop or dig into the library and learn about Range objects and how to create them, etc. This consumed a lot of time.

I got the simple 'equivalent' of this to work after far too much effort (after diggin into documentation to find Arrays have an indices Range object.

    for(i<-a.indices) { ...

That works for this case, but what about when I want to iterate by 2 ... etc.  Then I ran into problem #2

2.) Scala typing is extremely complex.  Scala tries to do typing 'right', which is admirable, but this also comes at the expense of simplicity. Unlike C++ where templating the above would be trivial as templates there are basically just sophisticated C macros, Typing in Scala demands exreme precision.  To overcome this there are 'hacks' (and they definitely appear like hacks to me) like 'implicit'.  Scala takes typing so far that it makes dynamic languages look good (and I'm a strong defender of typed langauges).

I tried to convert this, I gave it a real effort.  I failed, I gave up and went back to Java.

This forum is full of strong supporters and so I'm pretty sure my comments will be dismissed with little thought, but if not, who knows.  Maybe Scala 3.0 will be easier to use.  Seriously I love so many other things about the language, but it is simply too burdensome at the moment.