Another Scala rant on HN

Showing 1-243 of 243 messages
Another Scala rant on HN Martin 12/2/13 1:32 AM
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
Aw: [scala-debate] Another Scala rant on HN Dennis Haupt 12/2/13 2:23 AM
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.
Re: [scala-debate] Another Scala rant on HN Martin 12/2/13 2:46 AM



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

Re: [scala-debate] Another Scala rant on HN Mushtaq Ahmed 12/2/13 3:01 AM
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.


--
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.

Re: [scala-debate] Another Scala rant on HN Erik Post 12/2/13 4:55 AM
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
Aw: Re: [scala-debate] Another Scala rant on HN Dennis Haupt 12/2/13 5:03 AM
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
--

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.
Re: [scala-debate] Another Scala rant on HN Paul 12/2/13 5:44 AM
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.


--
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.

Re: [scala-debate] Another Scala rant on HN Simon Schäfer 12/2/13 6:23 AM

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.
Re: Another Scala rant on HN David Riccitelli 12/2/13 6:52 AM
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
Re: [scala-debate] Another Scala rant on HN Dickon Field 12/2/13 7:46 AM
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'.
Re: Another Scala rant on HN Simon Ochsenreither 12/2/13 7:52 AM
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.
Re: Another Scala rant on HN Andy R 12/2/13 7:57 AM
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
Re: [scala-debate] Another Scala rant on HN Marius Danciu 12/2/13 8:09 AM
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


--
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.

Re: Another Scala rant on HN Simon Ochsenreither 12/2/13 8:10 AM
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.
Re: [scala-debate] Re: Another Scala rant on HN Grzegorz Kossakowski 12/2/13 8:22 AM
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

Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Grzegorz Kossakowski 12/2/13 8:34 AM

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.


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

Re: [scala-debate] Re: Another Scala rant on HN Ðavîd L 12/2/13 8:53 AM
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. 

Re: [scala-debate] Another Scala rant on HN atomly 12/2/13 9:02 AM
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 ...


--
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.

Re: [scala-debate] Another Scala rant on HN Ðavîd L 12/2/13 9:04 AM
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.

Re: [scala-debate] Another Scala rant on HN Vlad Patryshev 12/2/13 10:11 AM
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:

--
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.

Re: Another Scala rant on HN Ashwin Rajeev 12/2/13 10:18 AM
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
Re: [scala-debate] Another Scala rant on HN Ken Scambler 12/2/13 11:56 AM

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

Re: [scala-debate] Another Scala rant on HN Juha Heljoranta 12/2/13 12:02 PM
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

Re: [scala-debate] Re: Another Scala rant on HN Martin 12/2/13 1:55 PM



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.



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

Re: [scala-debate] Another Scala rant on HN Martin 12/2/13 2:01 PM



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



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

Re: Another Scala rant on HN Eric Harney 12/2/13 2:25 PM
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.

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.

 - 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
Re: [scala-debate] Re: Another Scala rant on HN Hanns Holger Rutz 12/2/13 2:36 PM
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.
> --
> 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.
Re: Another Scala rant on HN Alois Cochard 12/2/13 2:41 PM
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.
Re: [scala-debate] Re: Another Scala rant on HN ARKBAN 12/2/13 2:48 PM
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

On 12/2/13 4: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.

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.



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

--
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.

Re: [scala-debate] Another Scala rant on HN atomly 12/2/13 2:52 PM

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...

:: 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 ...
Re: Another Scala rant on HN Simon Ochsenreither 12/2/13 2:53 PM
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.
Re: [scala-debate] Another Scala rant on HN Jed Wesley-Smith 12/2/13 3:00 PM
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

--
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.

Re: [scala-debate] Re: Another Scala rant on HN Russ P. 12/2/13 3:08 PM
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.



--
http://RussP.us
Re: Another Scala rant on HN Rich Oliver 12/2/13 3:16 PM
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?
Re: [scala-internals] Re: Another Scala rant on HN Martin 12/2/13 3:26 PM



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

Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/2/13 3:37 PM

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).
Re: Another Scala rant on HN Peter Pnin 12/2/13 3:44 PM
Dear Eric,

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


Peter
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/2/13 4:01 PM

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.
Re: Another Scala rant on HN Simon Ochsenreither 12/2/13 4:26 PM
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.
Re: [scala-internals] Re: [scala-debate] Another Scala rant on HN Xuefeng Wu 12/2/13 4:30 PM
+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.

For more options, visit https://groups.google.com/groups/opt_out.
Re: [scala-debate] Another Scala rant on HN Kostya Golikov 12/2/13 4:34 PM
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.

On Monday, December 2, 2013 10:11:53 PM UTC+4, Vlad Patryshev wrote:
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:
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-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.

Re: [scala-debate] Re: Another Scala rant on HN atomly 12/2/13 5:41 PM
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 ...


--
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.

Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/2/13 6:00 PM
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.
Re: Another Scala rant on HN Jon Pretty 12/2/13 6:01 PM
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
Re: [scala-debate] Another Scala rant on HN Vlad Patryshev 12/2/13 6:09 PM
Clojure deserves respect of course.

Thanks,
-Vlad
Re: Another Scala rant on HN Oleg Galako 12/2/13 10:53 PM
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.


On Monday, December 2, 2013 4:32:15 PM UTC+7, 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.

 - 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
Re: [scala-debate] Re: Another Scala rant on HN David Riccitelli 12/2/13 10:55 PM
+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.

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

Re: Another Scala rant on HN Stephen Samuel 12/3/13 12:23 AM
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.
Re: [scala-debate] Re: Another Scala rant on HN Haoyi Li 12/3/13 12:24 AM
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.
Re: [scala-debate] Re: Another Scala rant on HN Martin 12/3/13 1:00 AM



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.



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

Re: Another Scala rant on HN Oleg Galako 12/3/13 1:10 AM
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).
Re: Another Scala rant on HN Vassili van der Mersch 12/3/13 3:36 AM
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.

 - 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
Re: [scala-debate] Re: Another Scala rant on HN Jonathan Merritt 12/3/13 3:49 AM
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.
Re: Another Scala rant on HN Boris Steiner 12/3/13 3:49 AM
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):
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
Re: [scala-debate] Re: Another Scala rant on HN Jason Zaugg 12/3/13 3:52 AM
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

Re: Another Scala rant on HN nicerobot 12/3/13 3:57 AM
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.


On Monday, December 2, 2013 4:32:15 AM UTC-5, 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.

 - 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
unk...@googlegroups.com 12/3/13 5:18 AM <This message has been deleted.>
Re: [scala-debate] Another Scala rant on HN Stéphane Épardaud 12/3/13 6:20 AM
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
Re: [scala-debate] Another Scala rant on HN Martin 12/3/13 6:32 AM



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.



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

Re: [scala-debate] Another Scala rant on HN Stéphane Épardaud 12/3/13 6:36 AM


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…

Re: [scala-debate] Re: Another Scala rant on HN pagoda_5b 12/3/13 7:03 AM
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 
Re: Another Scala rant on HN Aleksey Izmailov 12/3/13 7:13 AM
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!


On Monday, December 2, 2013 4:32:15 AM UTC-5, 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.

 - 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
Re: [scala-debate] Re: Another Scala rant on HN Hanns Holger Rutz 12/3/13 7:22 AM
what kind of machista sh*t is this?
Re: [scala-debate] Re: Another Scala rant on HN Erik Osheim 12/3/13 7:31 AM
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
Re: Another Scala rant on HN pagoda_5b 12/3/13 7:52 AM
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 
Re: Another Scala rant on HN B H 12/3/13 7:55 AM
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


On Monday, December 2, 2013 2:32:15 AM UTC-7, 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.

 - 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
Re: [scala-debate] Re: Another Scala rant on HN Martin 12/3/13 8:46 AM



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.



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

Re: [scala-debate] Re: Another Scala rant on HN atomly 12/3/13 9:15 AM
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 ::

[ 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 ...
Re: [scala-debate] Re: Another Scala rant on HN atomly 12/3/13 9:28 AM
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. 


:: 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 ...
Re: Another Scala rant on HN Bienlein 12/3/13 10:12 AM
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
Re: Re: [scala-debate] Re: Another Scala rant on HN Juha Heljoranta 12/3/13 10:28 AM
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

Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Paul Phillips 12/3/13 10:34 AM

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 ;;
                                                   ^

Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Levi Notik 12/3/13 11:16 AM
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.
Re: Another Scala rant on HN CCs 12/3/13 11:18 AM
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



Re: [scala-debate] Re: Another Scala rant on HN raould 12/3/13 11:22 AM
> 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?
Re: [scala-debate] Re: Another Scala rant on HN CCs 12/3/13 11:34 AM
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
Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/3/13 11:39 AM

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
Re: [scala-debate] Re: Another Scala rant on HN Hanns Holger Rutz 12/3/13 11:40 AM
-----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-----
Re: Another Scala rant on HN Christian Helmbold 12/3/13 12:56 PM
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
Re: [scala-debate] Re: Another Scala rant on HN CCs 12/3/13 1:08 PM
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
Re: [scala-debate] Re: Another Scala rant on HN Hanns Holger Rutz 12/3/13 1:19 PM
-----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-----
Re: Another Scala rant on HN Rich Oliver 12/3/13 1:49 PM
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?
Re: [scala-debate] Re: Another Scala rant on HN Russ P. 12/3/13 1:54 PM
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
Re: [scala-internals] Another Scala rant on HN Daniel Sobral 12/3/13 1:55 PM
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.
Re: [scala-debate] Re: Another Scala rant on HN Rex Kerr 12/3/13 3:30 PM

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
 
Re: [scala-debate] Re: Another Scala rant on HN Vlad Patryshev 12/3/13 3:33 PM
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.

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

Re: [scala-debate] Re: Another Scala rant on HN Rex Kerr 12/3/13 3:37 PM
I do so wish + would not turn into a world-eating monster whenever it got so much as a whiff of a string.

  --Rex
Re: [scala-debate] Re: Another Scala rant on HN √iktor Klang 12/3/13 3:40 PM

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

Import language.javacompat.stringAdd etc

Re: Another Scala rant on HN Bill Venners 12/3/13 4:35 PM
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
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/3/13 4:42 PM

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.
Re: Another Scala rant on HN Simon Ochsenreither 12/3/13 4:44 PM

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.
Re: [scala-debate] Re: Another Scala rant on HN Rich Oliver 12/3/13 4:51 PM
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.
Re: [scala-debate] Re: Another Scala rant on HN Rex Kerr 12/3/13 8:51 PM
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
Re: [scala-debate] Re: Another Scala rant on HN Martin 12/4/13 12:04 AM


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

Re: [scala-debate] Re: Another Scala rant on HN pagoda_5b 12/4/13 12:50 AM
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,

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

Re: [scala-debate] Re: Another Scala rant on HN Michal Politowski 12/4/13 1:14 AM
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.
Re: [scala-debate] Re: Another Scala rant on HN Hanns Holger Rutz 12/4/13 1:18 AM
-----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-----
Re: Another Scala rant on HN Neil Carrier 12/4/13 6:29 AM

“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.”

Re: Another Scala rant on HN Cristian 12/4/13 6:39 AM
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.
Re: Another Scala rant on HN Dickon Field 12/4/13 6:40 AM
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.


On Wednesday, December 4, 2013 2:29:22 PM UTC, Neil Carrier wrote:

“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.”

Re: Another Scala rant on HN Alan Johnson 12/4/13 8:06 AM
For context, I'm a newcomer to the language. I just took the Functional Coursera course and I'm halfway through Reactive. I have programmed a few dozen languages in my day.

I think atomly nailed it with his comments.

As for my thoughts, what Scala is really missing for me is syntactic regularity in the punctuation. I'm constantly tripping on what needs a colon, a brace, an _, backticks, an extra set of parentheses, a =>, a ->, a semicolon, def/val, etc. Maybe this is because I live in other language domains by day, so I'm constantly having to reteach myself Scala punctuation. I also spend a lot of my time figuring out where to put the extra type incantation that will make my code work or how (and why) to refactor my arguments list. The complexities of setting up tooling, long delays in compiles, unhelpful error messages, and IDE sluggishness just add to this perception of friction.

Maybe this is a bit against the grain of the criticism, but I actually find Scala easier to read than to write, because the code I read is usually already correct and looks fine upon first glance (in depth examination might be a different story, though).

I've heard a lot of people say things to the effect of "yes, the syntactic flexibility is abused all the time, but I wouldn't trade in the power!" Well, this, in my opinion, is exactly what's creating the perception that Scala is difficult to work with. We don't need all of these variations and options. Other languages have followed a different path and avoided criticism of complexity because they've been far more conservative about making sure every new piece added to the language is completely justified and jibes with existing pieces. It seems like it's going to be far harder to pare Scala back to something more regular and learnable, without ticking off the expert community.

On the positive side, I can't seem to stop myself from digging further into the language. I just have this feeling that past all the rough corners I get snagged on, there is a vision of the future of programming, and I want to be ready when that future arrives. I'm really hoping that the Scala community pulls a Python and uses Scala 3 as the opportunity to reform.



On Monday, December 2, 2013 4:32:15 AM UTC-5, 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.

 - 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
Re: Another Scala rant on HN Joost de Vries 12/4/13 8:08 AM
I commented in a way that happens to be just like you suggest. (just search for my first name in that ycombinator post)

While defending the qualities that I like in Scala I quoted a video by Erik Meijer where he praises the side effects for 'getting stuff done'. Unfortunately that apparently caused so much outrage with some Haskell minded readers that they started this not very nice post on Reddit http://www.reddit.com/r/haskell/comments/1rx7mk/whats_the_deal_with_erik_meijer/

By the way; I want to say that I tremendously appreciated that RxScala and Erik Meijer were part of the Coursera Reactive Programming course. Both courses are wonderful.


On Monday, 2 December 2013 10:32:15 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.

 - 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
unk...@googlegroups.com 12/4/13 8:10 AM <This message has been deleted.>
Re: [scala-debate] Re: Another Scala rant on HN rklaehn 12/4/13 8:13 AM
On Wed, Dec 4, 2013 at 3:39 PM, Cristian <cristian...@googlemail.com> wrote:
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.

There are a lot of successful projects that mix OO and FP. If in order to use scala you would have to understand the concepts behind shapeless or scalaz, we would not have this discussion since nobody would care enough to bash scala. It is precisely because scala allows everything from "java with less verbose syntax" to "A monad is just a monoid in the category of endofunctors" that it has become popular enough to get bashed.
 
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.

I think that C# took some things out of the FP toolbox without considering the implications. For example, C# makes it really painful to work with immutable objects. But it has a lot of constructs that will be a lot of pain when you use them in the presence of mutable objects. For example if you do something like message passing in C#, and don't want to type boilerplate until your fingers bleed, you will end up with "immutability by convention". Look at the strange things they had to do in WPF to get usable immutable objects.

Also, there are so many parts of C# that just don't fit together, it's mindboggling that people can compare it favorably with scala.

Methods that return void are fundamentally different than methods that return something. So if you do generics, everything has to be duplicated for "functions" and "procedures".
Delegates don't work with: Operators, Properties, Constructors
Operators and other static methods don't work with type constraints
Dynamic is an entire universe of fail of its own
LINQ does not fit in to the rest of the language at all

I could go on and on, but doing so would bring back many painful memories so I would rather not.
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 8:34 AM
I think you might be missing my point. C# has it's warts but it at least has a clear goal in mind which is to be a good OO language with a sprinkle of FP features. Similarly F# is has a goal of being an FP language.

Martin says there's something good in have a full blown, kitchen sink OO/FP language. But it's never quite explained why.

I like both Haskell and Java for their purity and constraint of design in their respective worlds.

Why is it a good idea to throw inheritance (subclassing), implicits, variance and type classes in the same language ? These things clash together in nightmarish ways.

To put it another way, Scala seems like Android 1.0 compared to IOS 1.0 :)
Re: [scala-debate] Re: Another Scala rant on HN Rich Oliver 12/4/13 8:36 AM
On Wednesday, December 4, 2013 8:04:40 AM UTC, Martin wrote:


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

In the meantime could we just have a compiler option to switich it off? Then it could be live and let live.
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/4/13 9:12 AM

Martin says there's something good in have a full blown, kitchen sink OO/FP language. But it's never quite explained why.

Imho, the difference between C# and F# is that the Scala is content with having a good OOP/mediocre FP language (C#) or a mediocre OOP/good FP language (F#). There is just no reason why better OOP has to mean worse FP, or the other way around and I think Scala has already shown that it hasn't to be this way.

I think the “why” is just “why settle with bad parts if you can make all parts work well?”.

Regarding “kitchen sink” ... I think this just unnecessarily devalues the valid points you are raising. I think no one which has ever used C#/F# a bit and looked at the spec seriously claims that Scala is in any way bigger than C# or F#.
Re: [scala-debate] Re: Another Scala rant on HN nafg 12/4/13 9:48 AM
On Tue, Dec 3, 2013 at 4:08 PM, CCs <csaba...@gmail.com> 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?


That seems to be Lift + specs. However it doesn't make too much sense. Where did you "copy&paste" that from exactly?
1. I never saw ._?. Lift does borrow the Ruby convention of ending boolean method names with _?, as in entity.saved_?. But there's no "string"._? that I'm aware of. In any case it certainly doesn't go together with #>.
2. !? means send a message to an actor and get the reply if one is available within the timeout in a Box (like Option, Full is like Some).
3. ?~! lets you tag a Box with a failure message (Box is also like Try). So the `eventually` makes no sense there --- `eventually` tells specs that if the test (must be_==) fails, it should keep trying it because "eventually" it is supposed to pass the test (unless `eventually` is some locally defined string).
4. In any case, "* ^^" and #> are part of Lift's CSS selectors DSL (apparently CSS didn't have enough symbols for them). A CSS selector expression ("a" #> b) defines a transformation on x/html: a NodeSeq => NodeSeq. (The string is a code for what elements to select, and the right hand side of #> is something that gets applied to those nodes.) So it would never be_== to a Full Box.

In short: "string"._?; ?~! eventually; and CssSel must_be_== Box; are all indications that there's a bit more cutting and pasting going on here than you would have us think... :)

I do agree that the string code part of css selectors has gotten to be a really arbitrary kitchen sink. But it's a lot worse than operator overloading. It's a completely different subject: using string DSLs rather than something the compiler can check. (Although in theory macros could buy some safety back...)

But I must warn you: the Lift community does not exactly tolerate criticism too well...
 
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/4/13 9:59 AM
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/4/13 10:01 AM
But I must warn you: the Lift community does not exactly tolerate criticism too well...

In my experience, the Lift community is quite pleasant to talk to, even if I'm completely disagreeing with their API design/method naming/not-invented-here syndrome. Maybe it's more precise to say “there is one person in the Lift community who does not exactly tolerate criticism too well.”? :-)
Re: [scala-debate] Re: Another Scala rant on HN nafg 12/4/13 10:11 AM
On Wed, Dec 4, 2013 at 11:34 AM, Cristian <cristian...@googlemail.com> wrote:
Martin says there's something good in have a full blown, kitchen sink OO/FP language. But it's never quite explained why.

I like both Haskell and Java for their purity and constraint of design in their respective worlds.

Why is it a good idea to throw inheritance (subclassing), implicits, variance and type classes in the same language ? These things clash together in nightmarish ways.

 
It sounds like you understand that some times OO might be preferable for a given task, and at other times FP might be more advantageous. So your question is not why would one want to have both tools available.

Is your question why one would want to have both tools in one language? Would you prefer to write your project in several languages?

Or perhaps it's not that you don't have an explanation of "why," but you feel that despite the reason, it's not worth it because as you stated, things clash together. If that's the case, please elaborate specifically what clashes and how.

Re: [scala-debate] Re: Another Scala rant on HN nafg 12/4/13 10:18 AM
On Wed, Dec 4, 2013 at 1:01 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
But I must warn you: the Lift community does not exactly tolerate criticism too well...

In my experience, the Lift community is quite pleasant to talk to, even if I'm completely disagreeing with their API design/method naming/not-invented-here syndrome. Maybe it's more precise to say “there is one person in the Lift community who does not exactly tolerate criticism too well.”? :-)

As long as you are a very good communicator and don't break any rules, then it's very pleasant. On the other hand if you give certain people room to distort your words as intentionally insulting something about Lift, or as being impatient, etc. etc., it can be a quite unpleasant.

In any case what I meant to say was, your membership in that community will not last very long if you question too many things about Lift. So it's mostly one person, but it's the person that counts.


--
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.

Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 10:18 AM


Martin says there's something good in have a full blown, kitchen sink OO/FP language. But it's never quite explained why.

Imho, the difference between C# and F# is that the Scala is content with having a good OOP/mediocre FP language (C#) or a mediocre OOP/good FP language (F#). There is just no reason why better OOP has to mean worse FP, or the other way around and I think Scala has already shown that it hasn't to be this way.


You're right should have not used  F# as an example, as that has subclassing as well.  In my (relatively non-specialist view) a lot of the disjointness in Scala comes from the nice little FP language hiding in there clashing with inheritance and variance. 

Basically I just want Haskell on JVM with strictness by default and possibly limited, local mutability to allow for non-observable determinism.

I don't need all the OO abstract classes/partially implemented traits/layer cake monstrosities, and no one actually manages to explain why they are a good idea particularly when combined with a nice clean FP language that's struggling to get out.


Re: [scala-debate] Re: Another Scala rant on HN nafg 12/4/13 10:21 AM
Oh oh, now I understand your question. :)
You mean scala does not do a good enough job explaining to FPers what's so great about OO.
Perhaps you are right, I think they try harder to reach OOers and introduce them to FP.

So your question is not why one would want the combination; your question is what value is OO when you have FP --- is that correct? Or am I still not understanding you?



--
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.

Re: [scala-debate] Re: Another Scala rant on HN rklaehn 12/4/13 10:52 AM
On Wed, Dec 4, 2013 at 5:34 PM, Cristian <cristian...@googlemail.com> wrote:
I think you might be missing my point. C# has it's warts but it at least has a clear goal in mind which is to be a good OO language with a sprinkle of FP features. Similarly F# is has a goal of being an FP language.

I did not get the impression that C# wants to be "just a good OO language". It seems that they want to be whatever is the buzzword of the day. Hence the "dynamic" stuff (which was added back when dynamic languages like ruby and python were all the rage) and now async. I don't mind dynamic and async as a feature, but I much prefer this being done as a macro like in scala instead of putting lots of features into the core language before it is clear that they pull their weight.

They even have a special feature called "indexed properties" that was introduced specifically for better office interop. http://msdn.microsoft.com/en-us/library/ee310208(v=vs.110).aspx .
Re: [scala-debate] Re: Another Scala rant on HN Eric Kolotyluk 12/4/13 10:53 AM
I have only been following this discussion loosely, but it is a common
debate around Scala.

I personally think that the fact Scala generates so much controversy is
good, because it means people are paying attention to Scala.

Over my 40 years plus of computer programming, I personally think Scala
is one of the most ambitious programming languages, software platforms I
have ever experienced. I too had many doubts and personal rants around
Scala, but I now embrace it.

Could things be improved, sure, but that is better than the alternative:
the glacial pace at which new capabilities are coming to Java.

Cheers, Eric
Re: [scala-debate] Re: Another Scala rant on HN rklaehn 12/4/13 11:01 AM
On Wed, Dec 4, 2013 at 7:18 PM, Cristian <cristian...@googlemail.com> wrote:


Martin says there's something good in have a full blown, kitchen sink OO/FP language. But it's never quite explained why.

Imho, the difference between C# and F# is that the Scala is content with having a good OOP/mediocre FP language (C#) or a mediocre OOP/good FP language (F#). There is just no reason why better OOP has to mean worse FP, or the other way around and I think Scala has already shown that it hasn't to be this way.


You're right should have not used  F# as an example, as that has subclassing as well.  In my (relatively non-specialist view) a lot of the disjointness in Scala comes from the nice little FP language hiding in there clashing with inheritance and variance. 

F# seems like two languages that are only joined a little bit. In scala the FP and OO subsets are much better integrated.
 
Basically I just want Haskell on JVM with strictness by default and possibly limited, local mutability to allow for non-observable determinism.

 
I don't need all the OO abstract classes/partially implemented traits/layer cake monstrosities, and no one actually manages to explain why they are a good idea particularly when combined with a nice clean FP language that's struggling to get out.

Look at akka. It uses OO for creating the actors but immutable case classes and collections for constructing messages. It is fundamentally very OO (objects with identity and state), but it also needs the FP part.
Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Paul Phillips 12/4/13 11:02 AM

On Wed, Dec 4, 2013 at 10:52 AM, Rüdiger Klaehn <rkl...@gmail.com> wrote:
I don't mind dynamic and async as a feature, but I much prefer this being done as a macro like in scala instead of putting lots of features into the core language before it is clear that they pull their weight.

Dynamic isn't a macro, it's embedded in the compiler. You couldn't implement it as a macro because there are no untyped macros.
Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN rklaehn 12/4/13 11:14 AM
You are right. I was thinking about async. I think Dynamic in scala is less obtrusive than in C#. Personally I would not be sad if it was removed completely.
Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Sébastien Doeraene aka sjrd 12/4/13 11:21 AM
Hi,

I would be very sad if Dynamic was removed! And along with me, all Scala.js users. This is a crucial feature for Scala.js.

Cheers,
Sébastien


--
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.

Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/4/13 11:25 AM

You're right should have not used  F# as an example, as that has subclassing as well.  In my (relatively non-specialist view) a lot of the disjointness in Scala comes from the nice little FP language hiding in there clashing with inheritance and variance. 

I think F# is a good example. Just have a look at the monstrosities they commited by dumping large parts of C# into the language. Imho, Scala did a much better job here in deciding that smaller is better.
E. g. Generics: ... generics are hard enough ... how the hell did the F# developers get the idea that adding TWO kinds of Generics to the language is a good thing? Again, much better solved in Scala.
E. g. F#'s static keyword ... let's not even start talking about that mess.
 
Basically I just want Haskell on JVM with strictness by default and possibly limited, local mutability to allow for non-observable determinism.

Did you have a look at Frege?
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/4/13 11:26 AM

On 12/04/2013 09:50 AM, pagoda_5b wrote:
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 don't think this would give any meaningful result. Scala is used by lots of - probably mostly - people enjoying these features, they don't fear to learn them. These people couldn't really respond in such a survey.

For me, it would be far more interesting to know how much of Scalas users have chosen the language because of these features. This would also clarify the question which people should give Scala a try and which one shouldn't mind. At the moment the early adopters and enthusiasts are the ones who build libraries and tools and thus giving the direction in which Scala moves.

Just look at play: The idea of how to build webapps with this framework goes more or less in the opposite direction than a typical JEE-stack does. If it would turn out that play is chosen because of exactly this fact, all people, which enjoy JEE, could be warned of giving it a try - it'll just not work for them. And it would also prevent lots of ranting blog posts.


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,

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

--
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.

Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 11:30 AM

Can someone explain why we need implementation inheritance in Scala ? I did 15 years of Java and learned that's the worst part of it.

Marrying the OO and FP world essentially means shoving subclassing in the nice clean FP world view ? What's the point of this ?

I had high hopes for Scala but I don't understand this insistence on traditional OO being a good thing. I thought everyone agreed by now that it's a good idea to separate interface and implementation.

I know about Frege, Akka, all that. My question is exactly this: while it's possible to marry OO and FP, no one manages to explain why is it seen as good idea in the first place ?
Re: [scala-debate] Re: Another Scala rant on HN Hanns Holger Rutz 12/4/13 11:46 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You mean like extending a trait? It's one of the most fundamental
building blocks I am using in 97.8% of the projects.

How would you any useful work in Scala without mixing in traits? Sure
you can write `Cons` and `Nil` without combining functionality, but
that's about where it ends.


On 04/12/2013 20:30, Cristian wrote:
> Can someone explain why we need implementation inheritance in Scala
> ? I did 15 years of Java and learned that's the worst part of it.

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

iQIcBAEBAgAGBQJSn4aiAAoJEKZFmaPaYk6Qu/cQAJI1dlW3aCR2KCbtIELS+K9V
lMSAlq2GFvttP6QyyUM3NKWivCy9zN8V8XUa6+v2QstqYotELX/OP48OgrOc4NVM
V66Ani3FolfdYatEC2T7hqCmr7OIq8KN6uFUPX2F4vPrI1wHsAYcruKDPrKmItgX
0fYYilu6cnF1d1ONNfzP722P/UbItJTr7B1CyvjbZp4L9aEOn/joqnLhfKM/BV0s
IyBRSsgee5QS0WqbZ0IHlHBgZG5VM3F12gFBoxDW9Fg8oO6TRqxDJFDDuTZfHQT8
SWe8wyZFjFv9ysLsfmm4rEdaudxgTzfpEAKRV67u7EhKOikrACLmWOV9yBYUdz5E
Av8S9OvpOGhqTU5034HwqQNYWqigMCSxQyqfFSm3hSB0VvxAvAurCSXG6wYm2HNY
fffeUX7WTWFU/NYixVXUMV6x1VGl075rbbOCzJTkVG4kI8KRmK7DPAvnSN2kJ63P
nJ5FtN5j2jP5Q+TGUEfBSg9xYlX/xzGtgPL8KZk83eG/FUGntUbj4DmwWGYCHPi3
lK8OXPZmfWtqw1Eq4+yR8YaCITdir5Qn8I5bZhccW4pEBQCEeyjqGSn2RPvt/I6R
4LijZDMFNQp69qDrpmAZrYuvi8+izswhSHpY/z5NDpCDTlCEtNJHVF5VLTPao2Ba
VkCkIWQuB05bLVzA/Ld4
=9M4a
-----END PGP SIGNATURE-----
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 11:50 AM


How would you any useful work in Scala without mixing in traits? 

Higher-order functions, ADTs, type classes. You know, modern FP
Re: [scala-debate] Re: Another Scala rant on HN CCs 12/4/13 12:01 PM

In the meantime could we just have a compiler option to switich it off? Then it could be live and let live.


This was my first thought and Martin was open to the suggestion when I mentioned this to him a couple months back.

Then I saw Christian's suggestion on this thread about using Scalastyle.org or similar validator, and I realized this is one of the things I really liked in Google Go.

Go comes with a build-in formatter (gofmt) which will take out the effort of fiddling with the code and ensures a standard look.
Also Javascript has fixjsstyle and gjslint, CSS has recess, Visual Studio a key shortcut (Ctrl-E,D) etc.

So how about a Scala style formatter that comes with a white list of commonly accepted DSL and throws warning on "&^^&" operators? The library developers would have no doubt if this is a meaningful name. Internal DSL projects could add their own items to the white list. Larger teams could collaborate easier, just add the formatting to the pre-commit hook.

Csaba

Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/4/13 12:07 PM
They are useful, but are not solving the issue which traits solve. Sometimes implementation inheritance is just the less error-prone way to share code than alternatives, even when considering how dangerous and hard to understand inheritance is.
Re: [scala-debate] Re: Another Scala rant on HN Paul 12/4/13 12:18 PM
Frege not what you wanted?
Sent from my BlackBerry® wireless device

From: Cristian <cristian...@googlemail.com>
Date: Wed, 4 Dec 2013 10:18:45 -0800 (PST)
Subject: Re: [scala-debate] Re: 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.
Re: [scala-debate] Re: Another Scala rant on HN Martin 12/4/13 12:25 PM
Hi Cristian,

I think it's a good question to ask. I'll prepare a more complete answer once I have the time, but just a couple of words here:

 Objects in Scala are intended to be a very flexible module system, of the kind OCaml and SML have. Haskell does not have such a module system, but has type classes instead. I see that many of the functionalities of traditional classes and type classes are analogous. Implementation inheritance, for instance, is called "default method implementation" in Haskell. Abstract type members are called associated types, and so on. Sure there are differences in details and emphasis (e.g. I believe default methods in Haskell are used less than overridding in OO languages), but if you look at the feature set, there are lots of commonalities. 

That's the basic premise. I have to expand on this sometimes soon.

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.



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

Re: [scala-debate] Re: Another Scala rant on HN Hanns Holger Rutz 12/4/13 12:26 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scala is made for component abstractions, trait mixin is a fundamental
block on which it is designed (scalable-language). If you don't want
that, you don't want `receiver.message`, then you want a completely
different language. I suggest you look at the Haskell-for-JVM kind of
languages (Frege).

Best, .h.h.


On 04/12/2013 20:50, Cristian wrote:
>
>
> How would you any useful work in Scala without mixing in traits?
>
>
> Higher-order functions, ADTs, type classes. You know, modern FP
>
> -- 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSn4/gAAoJEKZFmaPaYk6Qz4cQAIieko2EQ8JCESVbLizyGesQ
lwRVpBSzInomHu3KC2sSXmLVTCf+ji/IGPLPcPr1yQdhOAE9LXBkfPRmRs4zLeqQ
DA8rBCiOB6PJrY7yerD4byR6pKNPsax44q3fHZuqAvpyGzFV4equjBrIBeJdgqdI
Oo1Fa62R81OJV9o2SE9qjwpO9sfHNvcGVFLK0TYXpEdxO8fIUa9Gue34Oo99ZZOU
9z+WSrJ1PuBdGeo0TmOA2bd+5SSGEmrhFSs5kdVo2ersRr9oZiUuSO65vjFZJohG
Yl204AUZTypVRR4f+c/zOY8/CoWG9nxlrOht8LGLH7wl5wwCguY10wwheb7bmkLR
ACbEwyekI06Z3JmPzoGSyVOrjXe5fGZLkomHiJSrNSq8scoLB44vQYyIVSheL2sj
waLGYriOrIlDrARl5LY2TfcXiQMOaJQeDIH90NPhlxvS5hspjFe5rlvNW1bLSwYJ
CAIRFSugR3PDGb/iywHcW6lMuS+QNyN8tUnJXCmWNijYLmGEJq1ya2qzA2cHxZgd
2Jz7Cy6X5ArA5RHRH9JLFayty+EK486P8koBh7O/wkYMR/+w4UH7V+AeqYiTmhfB
KEAc/vrVJj8f+cl2wZZlipVoEQezgbhJyqKVc2lok8Im1L1KF9vPWVZ3b4wfXyQ+
ixRHHo2wXzj1k3Z+teAE
=+tG3
-----END PGP SIGNATURE-----
Re: [scala-debate] Re: Another Scala rant on HN rklaehn 12/4/13 12:36 PM
Scalaz uses quite a bit of mixin composition. It is used in a different way than is common in typical OO. But it seems that mixin compostion is useful even for a library that is considered "modern FP" by most people.



On Wed, Dec 4, 2013 at 8:50 PM, Cristian <cristian...@googlemail.com> wrote:


How would you any useful work in Scala without mixing in traits? 

Higher-order functions, ADTs, type classes. You know, modern FP

--
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.

Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 1:06 PM
I think those are type classes (but didn't look in detail) Looks the same, but a different beast.

What I'm talking about is traits with abstract and defined methods being overridden/called by from subclasses. 

The template pattern in OO-speak.
Re: [scala-debate] Re: Another Scala rant on HN Rex Kerr 12/4/13 1:08 PM
On Wed, Dec 4, 2013 at 8:06 AM, Alan Johnson <lla...@gmail.com> wrote:
As for my thoughts, what Scala is really missing for me is syntactic regularity in the punctuation. I'm constantly tripping on what needs a colon, a brace, an _, backticks, an extra set of parentheses, a =>, a ->, a semicolon, def/val, etc.

There is a lot of self-consistency in the punctuation.  I think you'll find as you use Scala more that what seems to you now like tripping on syntax is either tripping on differences between Scala syntax and some other language you're using, or tripping on concepts that manifests itself as you typing the wrong symbol.  As you get more familiar with the concepts used in Scala (or just with the syntax), I bet the difficulty will fade.  There are a *few* things that could be more regular, but the list is pretty short.

For example:
  - Type ascription needs a colon.  That's the only time you use a single colon.
  - Braces go anywhere you have multiple statements.  (Irregularity: you can use parens for a for-comprehension instead.)
  - _ goes anywhere you mean "whatever", whether it's an unnamed function argument, an unspecified type, an import of everything, or arguments you'll fill in later.
  - Backticks are only needed when you're trying to use a reserved word as an identifier.  That's the only time you use it.
  - You never need to use an extra set of parentheses.  (Irregularity: sometimes you can omit parens and sometimes you can't.)
  - => means a function, both with types (TypeA => TypeB) and values (x => f(x)).  (Exception: imports use => for renaming.)
  - -> is an alternate builder for Tuple2.  That's the only time you use it.
  - Semicolons are only used when you need to separate statements on the same line.  (Rare exception: occasionally semicolon inference gets confused.  It's been a year since it last did for me.)
  - def creates a method; val creates an un-reassignable value.  Always.  (Exception: case classes let you omit the val in the constructor.)

You need a lot of the distinctions here because such distinctions are important for the functioning of your code and for error-checking; most of the exceptions are there so you can focus on the important bits of the code without getting distracted by syntax.  If we could remove the few genuine irregularities (e.g. for-parens, => meaning "rename") it would be better yet.

  --Rex
 
Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Paul Phillips 12/4/13 1:17 PM

On Wed, Dec 4, 2013 at 12:36 PM, Rüdiger Klaehn <rkl...@gmail.com> wrote:
Scalaz uses quite a bit of mixin composition. It is used in a different way than is common in typical OO. But it seems that mixin compostion is useful even for a library that is considered "modern FP" by most people.

Jason can correct me if I'm wrong, but I posit that the usage of mixin composition in scalaz is driven to an enormous extent by the desire to see the correct types inferred. To cite such usage as evidence that people find mixin composition useful is like Soviet Russia citing a 100% voter turnout as evidence of a well-functioning democracy.

Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 1:17 PM
Thank you Martin, I really appreciate your answer. 

While my knowledge of Haskell type classes is limited, I realise there's a clear analogy between the two. 

However I do wonder why in Haskell this approach seems to lead to particularly elegant abstractions while in Scala it ends up being 

BankAccountBusinessService (is-a) HttpServer (is-a) DBConnection (is-a) Logger

And what's even more odd is that this is not only allowed but actively encouraged and a design goal for the language, apparently.

Another question is ok, we like OO, so we like inheritance. But why do we need implicits and type classes then ? And in the same core library, nevertheless (collections).

Apologies if this seems a bit like bashing, but it's not,  is a genuine question that has puzzled me for a while. While I hugely prefer doing Scala over Java, I struggle to understand what its underlying design theme and goal is.

To put this in context, if I would go and look for (another) Scala job, I would have to ask: what kind of shop are you, the Scala FP kind, or the Scala OO kind ?

Thanks again for taking the time to answer 
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/4/13 1:19 PM
Hi Haoyi,

On 3 December 2013 08:24, Haoyi Li <haoy...@gmail.com> wrote:
> 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.

You're right, of course - I think I was optimistically overstating the
consistency there...

> 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!

It's confusing, but consistent in some frame of reference, albeit
maybe one that may only be obvious later. I wouldn't want to make the
for-comprehension look too much like normal imperative code - I think
the visual clues like this which indicate you are inside a
for-comprehension are useful.

Cheers,
Jon
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/4/13 1:23 PM
Hi Cristian,

On 4 December 2013 21:17, Cristian <cristian...@googlemail.com> wrote:
> Another question is ok, we like OO, so we like inheritance. But why do we
> need implicits and type classes then ? And in the same core library,
> nevertheless (collections).

I gave a talk at Scala eXchange on Monday about almost exactly this.
I'm planning to give it again some time next week at work - you should
come along!

Cheers,
Jon
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 1:57 PM

Thanks, but perhaps you'd like to share the gist of it on this thread ? Other people might want to know too..
Re: [scala-debate] Re: Another Scala rant on HN Rich Oliver 12/4/13 2:06 PM
On Wednesday, December 4, 2013 7:30:30 PM UTC, Cristian wrote:

Can someone explain why we need implementation inheritance in Scala ? I did 15 years of Java and learned that's the worst part of it.

Well I can only speak for myself but that's the best part of it. I need implementation inheritance in order to have implementation inheritance.


Marrying the OO and FP world essentially means shoving subclassing in the nice clean FP world view ? What's the point of this ?
 
I had high hopes for Scala but I don't understand this insistence on traditional OO being a good thing.

I'm not quite sure what these high hopes were based on. If Martin was seeking to get rid off OO, then introducing traits was a very funny way of going about it.

I thought everyone agreed by now that it's a good idea to separate interface and implementation.

You thought wrong. Not everyone agrees on that.
 

I know about Frege, Akka, all that. My question is exactly this: while it's possible to marry OO and FP, no one manages to explain why is it seen as good idea in the first place ?

Well for me the number one reason for switching to Scala was because it had traits. I very much liked the fact that it was multi paradigm. I think the single paradigm nature of Eiffel contributed to its failure.

Now Scala doesn't just attempt to marry OO and FP. It attempts to marry OO, FP, Imperative programming, the JVM, call Java and call from Java and it attempts to upgrade OO from its pathetic implementation in Java and C# to boot. Now in my ideal world Scala would become popular enough to divorce from the JVM and Java. But everything we've learn from Scala seems to point to the fact that marrying OO and FP was a thoroughly good idea.
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/4/13 2:09 PM
Sure, my slides are available at http://rapture.io/scalax2013/, and
you can watch the video here:

http://skillsmatter.com/podcast/scala/how-to-please-everyone-all-the-time-lessons-in-scala-api-design

Cristian, however, will get a better rendition for several reasons,
not least because my laptop screen won't keep going blank, and I won't
be so time-constrained at the end. The last few slides go a bit
quickly in the video...

Cheers,
Jon
--
Jon Pretty | Director

Propensive | forward-thinking design
+44 7974 771045 | propensive.com | @propensive
The Black Barn, Cliddesden, Hampshire, RG25 2JL.

Propensive Ltd is registered in England no 6873445.
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/4/13 2:14 PM
Cheers, will have a look
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/4/13 3:00 PM
Hi Rex, Martin, et al,

I like this overview, and I was thinking of writing something similar
myself. I normally find it very easy to dismiss other users' claims
that the syntax is overly complicated because a) I know all the
irregularities, and I don't have to think about them, and b) when I do
think about them, I know the good reasons why they exist, and c) Scala
is a damn good compromise of versatility and syntactic consistency.
But, like Rex, I thought I'd step back and try document some of the
issues which probably concern new users.

As I said before, having syntax which is consistent helps a reader
trust and feel confident about what the code means and does, and is
often more important than conciseness. Each irregularity might seem
like a minor blemish which doesn't matter hugely, but they quickly add
up, and it undermines the great efforts Martin (with much input and
consideration from many others over many years) has gone to to
reconcile different ideas into a concise grammar. I eagerly await the
results of his grammar-size quiz...

The goal here is to be able to make, bold assertions about the
language syntax which apply everywhere, without exceptions. As Rex
demonstrated, there are many assertions that can be made, but often
there's some additional qualification required.

So, here are a few more, in no particular order (and making no claims
about their significance, merely their existence):

1. Qualified modifiers:

  private[this] val foo = 1

Why are square brackets used here? Every other occurrence of square
brackets contains types, not values. Why is this different? Could we
use parentheses instead?

2. Self types:

  class Foo() { foo: Bar => ... }

This looks a lot like a lambda, but it's not; it's a self-type.

We used to write this as

  class Foo() requires Bar { ... }

and, if I remember correctly, before that we wrote it as

  class Foo(): Bar { ... }

None of these is particularly satisfactory.

3. Underscores in lambdas:

An underscore always expands to a lambda in its nearest surrounding
parentheses. Irregularity: except when the underscore is the only
thing inside those parentheses.

4. Match looks like an infix method, but doesn't behave like one. You
can't write this, for example:

  Some(0) match { case Some(0) => Some('a') } match { case Some('a')
=> Some("A") }

even though you can write this:

  Some(0) map { case 0 => 'a' } map { case 'a' => "A" }

They look structurally very similar, but an extra set of parentheses
is required to make the first version compile.

5. For comprehensions. These are a little troublesome because they
look quite a lot like a method called `for` which takes a slightly
special looking thing as an argument. Obviously, it can't be treated
like an object because it introduces new identifiers. Furthermore (I
think) it's the only occurrence when a new identifier can be
introduced which can be referred to, unqualified, outside of the
parentheses/braces it's defined within.

I could find more of these, but the reluctant programmer need only
find a few of these in the first week of learning to conclude that the
language is inelegant and too complicated.

To be clear, I'm not looking for explanations for all of the above - I
know why things have been done the way they have! I would be more
interested in hearing suggestions about how they might be fixed (and
ideas about the unforeseen consequences of doing so...).

I remember the same question was raised a few years ago by Martin
(someone with more patience than me is welcome to hunt this down on
the archives), and after some debate, a few changes were made, but
most proposed changes were argued away on the basis that they would
just make unnecessary work for people. In light of the
lowering-of-the-bar implied by the existence of SIP-12[1] (even though
it's not been accepted), perhaps some of these could be revisited, and
perhaps (given the recent discussion) we could spend a little
verbosity and buy a little more consistency.

Cheers,
Jon

[1] http://docs.scala-lang.org/sips/pending/uncluttering-control.html
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/4/13 7:14 PM

BankAccountBusinessService (is-a) HttpServer (is-a) DBConnection (is-a) Logger

I think the thing here is that in Scala those things are really traits. Traits don't form an is-a relationship in the strict sense, but really signify that in A extends B with C, has the traits of B and C.
The way traits are commonly used in Scala is very different from e. g. interfaces in Java.
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/4/13 7:18 PM
Hi Jon,

thanks for this list! This is highly interesting and I think worth more than a deeper look!

Bye,

Simon
Re: [scala-debate] Re: Another Scala rant on HN Alan Johnson 12/4/13 8:15 PM
Thanks Jon, I think you completely get where I'm coming from. 

To Rex, the situation really isn't as simple as you describe it. I don't know the language all that well, so I could be wrong on some of these points, but many of the things you point out actually do have additional wrinkles that you don't have to dig too far to encounter. Or if there is a consistency to be found, it can still be rather subtle or surprising, perhaps due to lack of analogy with similar looking languages. The sum total of these is a feeling of unpredictability.

  - Type ascription needs a colon.  That's the only time you use a single colon.

Sure, but it's not always intuitive to know when you actually need to use type ascription. A lot of times, I realize I'm missing a necessary colon (and attached type annotation) after being signaled by a IDE error highlight.

  - Braces go anywhere you have multiple statements.  (Irregularity: you can use parens for a for-comprehension instead.)

Yet sometimes they are also used to group things that aren't statements, like case statements and for clauses. And I don't really know if I'm interpreting this correctly, but it seems like they can also double as parentheses, to make it look like a thunk is simply setting next to a method? Like Future { 5 }

  - _ goes anywhere you mean "whatever", whether it's an unnamed function argument, an unspecified type, an import of everything, or arguments you'll fill in later.

Underscore is waaay overloaded. Plus it's rather strangely used to for partial application of functions.

  - Backticks are only needed when you're trying to use a reserved word as an identifier.  That's the only time you use it.

And also needed to defeat magical interpretation of case clauses when it's not the desired effect.

  - You never need to use an extra set of parentheses.  (Irregularity: sometimes you can omit parens and sometimes you can't.)

Because a tuple and argument list are two different things, sometimes, it feels like you do. And when the norm is to omit the parentheses, it makes it feel like using them is in fact the special case. This also applies to method invocation.

  - => means a function, both with types (TypeA => TypeB) and values (x => f(x)).  (Exception: imports use => for renaming.)

=> is also used for call-by-name parameters. Speaking of which, since call-by-name isn't necessarily visible at the place-of-call (if you're not looking at an inline method signature), it can make unfamiliar code behave in counterintuitive ways.

  - -> is an alternate builder for Tuple2.  That's the only time you use it.

I would question whether this actually adds to the usefulness of the language versus the regularity of leaving out this special case. And I when I wrote it, I also had in mind <-, which is obviously a different token, but has a totally unrelated use.

  - Semicolons are only used when you need to separate statements on the same line.  (Rare exception: occasionally semicolon inference gets confused.  It's been a year since it last did for me.)

I'll grant you that one. I just threw semicolon in the mix to make it seem more overwhelming :)

  - def creates a method; val creates an un-reassignable value.  Always.  (Exception: case classes let you omit the val in the constructor.)

Plenty of examples I've seen declare vals in traits, but implement them as defs

Also, I forgot the . and how you can leave it off to get infix syntax. As cool as that is, I find I usually end up having to just use typical dot notation to get things correct. Some might consider the implicit "this." within class scope to be another place where context is implied. I realize of course that Java shares this usage.

I'm probably factually wrong on a couple of these points, but I know I'm not wrong on all of them. My overall point is that we're not taking crazy pills, those of us who find these issues vexing and productivity-sapping. I think there's a real and significant but totally addressable problem here. But it's only addressable if experts are willing to give up some of the slickness they've obviously grown to love.
Re: [scala-debate] Re: Another Scala rant on HN Haoyi Li 12/4/13 8:35 PM
And also needed to defeat magical interpretation of case clauses when it's not the desired effect.

+1. I find the "check case of first letter in identifier" rule of finding out whether something in a pattern-match is an extractor (Capital) or a name-to-be-bound (small) to be exceedingly weird. Nowhere else in the language do we muck around inside identifiers! One extremely common invariant in a ton of languages is that identifiers are purely identifiers: it doesn't matter what's inside, only that it matches exactly. Forcing people to pick small vs Capital does not fit in Scala (or any other language, except maybe Go, which cares about these things) at all.

- def creates a method; val creates an un-reassignable value.  Always.  (Exception: case classes let you omit the val in the constructor.) 

Don't forget in for-comprehensions too! Where the `val` is optional and deprecated, kinda like case classes.

I would question whether this actually adds to the usefulness of the language versus the regularity of leaving out this special case. And I when I wrote it, I also had in mind <-, which is obviously a different token, but has a totally unrelated use.

+100. If 

<- and -> were keywords and 
<= and => were library-methods

then I would have been much less confused.

<- and => as keywords and 
<= and -> as library methods

took me a long time to get over.


--
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.

Re: [scala-debate] Re: Another Scala rant on HN Dennis Haupt 12/4/13 10:25 PM
since i read "infix notiation", i always *want* to write 1 to 50
<chained collection methods here> but i always end up changing it to
(1 to 50).<chained collection methods here> because there is often a
problem and i need to clarify what i mean

for example this works fine:
1 to 10 map {_ * 5} filter {_ % 5 == 0}

but this doesn't:

1 to 10 fold(0){(a:Int, b:Int) => a + b}

i start with infix, but how can i "cleanly switch to dot-mode again"?

Am 05.12.2013 05:15, schrieb Alan Johnson:
> Thanks Jon, I think you completely get where I'm coming from.
>
> To Rex, the situation really isn't as simple as you describe it. I don't
> know the language all that well, so I could be wrong on some of these
> points, but many of the things you point out actually do have additional
> wrinkles that you don't have to dig too far to encounter. Or if there is
> a consistency to be found, it can still be rather subtle or surprising,
> perhaps due to lack of analogy with similar looking languages. The sum
> total of these is a feeling of unpredictability.
>
> /  - Type ascription needs a colon.  That's the only time you use a
> single colon./
>
> Sure, but it's not always intuitive to know when you actually /need/ to
> use type ascription. A lot of times, I realize I'm missing a necessary
> colon (and attached type annotation) after being signaled by a IDE error
> highlight.
>
> /  - Braces go anywhere you have multiple statements.  (Irregularity:
> you can use parens for a for-comprehension instead.)/
>
> Yet sometimes they are also used to group things that aren't statements,
> like case statements and for clauses. And I don't really know if I'm
> interpreting this correctly, but it seems like they can also double as
> parentheses, to make it look like a thunk is simply setting next to a
> method? Like Future { 5 }
>
> /  - _ goes anywhere you mean "whatever", whether it's an unnamed
> function argument, an unspecified type, an import of everything, or
> arguments you'll fill in later./
>
> Underscore is waaay overloaded. Plus it's rather strangely used to for
> partial application of functions.
>
> /  - Backticks are only needed when you're trying to use a reserved word
> as an identifier.  That's the only time you use it./
>
> And also needed to defeat magical interpretation of case clauses when
> it's not the desired effect.
>
> /  - You never need to use an extra set of parentheses.  (Irregularity:
> sometimes you can omit parens and sometimes you can't.)/
>
> Because a tuple and argument list are two different things, sometimes,
> it feels like you do. And when the norm is to omit the parentheses, it
> makes it feel like using them is in fact the special case. This also
> applies to method invocation.
>
> /  - => means a function, both with types (TypeA => TypeB) and values (x
> => f(x)).  (Exception: imports use => for renaming.)/
>
> => is also used for call-by-name parameters. Speaking of which, since
> call-by-name isn't necessarily visible at the place-of-call (if you're
> not looking at an inline method signature), it can make unfamiliar code
> behave in counterintuitive ways.
>
> /  - -> is an alternate builder for Tuple2.  That's the only time you
> use it./
>
> I would question whether this actually adds to the usefulness of the
> language versus the regularity of leaving out this special case. And I
> when I wrote it, I also had in mind <-, which is obviously a different
> token, but has a totally unrelated use.
>
> /  - Semicolons are only used when you need to separate statements on
> the same line.  (Rare exception: occasionally semicolon inference gets
> confused.  It's been a year since it last did for me.)/
>
> I'll grant you that one. I just threw semicolon in the mix to make it
> seem more overwhelming :)
>
> /  - def creates a method; val creates an un-reassignable value.
> Always.  (Exception: case classes let you omit the val in the constructor.)/
>
> Plenty of examples I've seen declare vals in traits, but implement them
> as defs
>
> Also, I forgot the . and how you can leave it off to get infix syntax.
> As cool as that is, I find I usually end up having to just use typical
> dot notation to get things correct. Some might consider the implicit
> "this." within class scope to be another place where context is implied.
> I realize of course that Java shares this usage.
>
> I'm probably factually wrong on a couple of these points, but I know I'm
> not wrong on all of them. My overall point is that we're not taking
> crazy pills, those of us who find these issues vexing and
> productivity-sapping. I think there's a real and significant but totally
> addressable problem here. But it's only addressable if experts are
> willing to give up some of the slickness they've obviously grown to love.
>
>
> On Dec 4, 2013, at 6:00 PM, Jon Pretty <jon.p...@propensive.com
> --
> 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.

--

Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/4/13 10:56 PM
As Simon says, the "is a" relationship is too narrow a view to take of
traits, but the naming of the traits in that example doesn't help.
DBConnection and Logger here sound like the names of things which are
database connections and loggers, but actually they're traits which
contain members which are a database connection (or some abstraction
thereof) and a logger.

If the person who implemented the traits isn't treating the trait
contract as an "is a" relationship in their naming choice, then the
user of those traits has no chance, really. So, apart from similar
examples in the Standard Library, this isn't really Scala's fault.

Cheers,
Jon
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/4/13 11:31 PM
Hi Haoyi,

The upper-/lower-case rule in pattern matching is weird because it's only seen in pattern matching, and it appears to elevate something which is otherwise only a convention (capitalization of type names, lower-case for value identifiers) to a strict feature, in just this isolated case.

A language feature which maybe falls into the same category is sealed-trait scope; nowhere else in the Scala language does the file have such relevance.

But they're both obvious pragmatic choices because they support the useful cases so well. Being able to write concise pattern matches is very neat feature, and this actually entrenches the capitalization convention. In fact, it drives the convention, as a desire to pattern match on an identifier is often the motivation for breaking the usual convention and naming it with a capital letter.

So, I'd ask the question: Would the language be more consistent if, instead of removing the "quirk", it were to proliferate into other aspects of Scala? For example, could we make it illegal to name a type with a lower-case letter or a value with a capital letter, unless you annotate them in some way to indicate it's a deliberate choice? I'm not sure I'd like this, but I'm the wrong person to ask, because I'm already too familiar with Scala to give an unbiased opinion.

I'm not sure there are many other places where this feature is relevant, but with most of these supposed warts, removing them is not the only option.

Cheers,
Jon

Re: [scala-debate] Re: Another Scala rant on HN Haoyi Li 12/4/13 11:57 PM
So, I'd ask the question: Would the language be more consistent if, instead of removing the "quirk", it were to proliferate into other aspects of Scala? For example, could we make it illegal to name a type with a lower-case letter or a value with a capital letter, unless you annotate them in some way to indicate it's a deliberate choice? I'm not sure I'd like this, but I'm the wrong person to ask, because I'm already too familiar with Scala to give an unbiased opinion.

I'm also pretty familiar with Scala. My gut says sure, making types *have* to start with capital letters works fine. On the other hand, I don't think it solves the problem here. The problem is if i have:

val a = ...
val b = ...
b match{
  case a => ...
}

We simply do not have any way of properly distinguishing whether we want to:

- match against the value of `a`
- or bind a value to the identifier `a` and shadow the old one. 

In my opinion, what we actually want is a slightly-more-syntax-rich pattern matcher. Although more syntax is generally a bad thing, shoving multiple cases into the same syntax distinguished by some arbitrary thing (i.e. capitalization) is terrible. One idea is to have "@" be a syntax to check against values, so you could do:

b match{ // check against the value of a
  case @a => ...
}
b match{ // bind value for a
  case a => ...
}
b match{ // check against the value of a and bind value to a
  case a @ a => ...
}

which is kinda-sorta an extension of the existing `a @ a()` syntax. Maybe even have capital-variables check against value for default, and let something like `A@` explicitly bind a value to the name `A`. Then even if the default behavior has some cruft, at least you can force the behavior either way if you want, and it'll be backwards-compatible.






--
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.

Re: [scala-debate] Re: Another Scala rant on HN Paul 12/5/13 12:17 AM
>We simply do not have any way of properly distinguishing whether we want to:

> - match against the value of `a`
>- or bind a value to the identifier `a` and shadow the old one. 

Could this also be solved by having two keywords - case for the first, bind for the second, maybe?

Paul
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 12:21 AM
On Thursday, 5 December 2013 08:17:34 UTC, Paul wrote:
Could this also be solved by having two keywords - case for the first, bind for the second, maybe?

No, it's not that simple, unfortunately. Sometimes you want to do both...

  List(1) match {
    case a :: Nil => println(a)
  }

Jon
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 12:28 AM


On Thursday, 5 December 2013 07:57:06 UTC, Haoyi Li wrote:
 
I'm also pretty familiar with Scala. My gut says sure, making types *have* to start with capital letters works fine. On the other hand, I don't think it solves the problem here. The problem is if i have:

That was half of it. The other half was "values have to start with lower-case letters". But either way, it doesn't solve the problem!

Shadowing warnings are something that's often been mooted, but which I've never seen implemented (this is the cue for someone to tell me it's in trunk, behind an -X parameter...).

- or bind a value to the identifier `a` and shadow the old one. 


You can currently use backticks around the identifier, for example:

  val a = 1
  List(1, 2) map {
    case `a` => println("It's 1!")
    case a => println("It's not 1...")
  }

but you could argue this is an extra quirk of backticks that's not obvious...

Your suggestion of using @ is interesting, though I think you would want the @ after the identifier, for consistency with current behaviour.

Cheers,
Jon
Re: [scala-debate] Re: Another Scala rant on HN Kevin Wright 12/5/13 1:13 AM

Shadowing warnings are something that's often been mooted, but which I've never seen implemented (this is the cue for someone to tell me it's in trunk, behind an -X parameter...).

Honestly... That's something that really should have been behind -Xlint.  Though I'm tempted to think it could go under SIP-18 nowadays (depending on complexity and/or overhead)
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/5/13 2:21 AM

On 12/05/2013 10:13 AM, Kevin Wright wrote:

Shadowing warnings are something that's often been mooted, but which I've never seen implemented (this is the cue for someone to tell me it's in trunk, behind an -X parameter...).

Honestly... That's something that really should have been behind -Xlint.  Though I'm tempted to think it could go under SIP-18 nowadays (depending on complexity and/or overhead)
Name shadowing is one of the most awesome features of Scala - in 99% of all cases when I do it I will do it.

A always write code like

xs map { xs =>
  xs map { xs =>
    xs.reverse
  }
}

where xs is a list of nested lists or something similar. In the innermost scope I'm not interested what the meaning of the same identifier is, in fact I want to be unable to access outer variables because the contain only values I'll not operate with. Beside from that, the naming thing is the hardest thing developers have to solve each day (as a survey found out, don't have a link anymore though). Introducing a rule to redeclare identifiers easily, like in Haskell with the trailing ' in xs and xs', only partially fixes that problem.


--
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.

Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/5/13 2:24 AM

On 12/05/2013 05:15 AM, Alan Johnson wrote:

  - def creates a method; val creates an un-reassignable value.  Always.  (Exception: case classes let you omit the val in the constructor.)

Plenty of examples I've seen declare vals in traits, but implement them as defs
Just for reference, it is not possible to implement a val as a def. A def has a getter and a setter, a val only a getter.
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/5/13 2:34 AM

On 12/05/2013 07:25 AM, Dennis Haupt wrote:
> since i read "infix notiation", i always *want* to write 1 to 50
> <chained collection methods here> but i always end up changing it to
> (1 to 50).<chained collection methods here> because there is often a
> problem and i need to clarify what i mean
>
> for example this works fine:
> 1 to 10 map {_ * 5} filter {_ % 5 == 0}
>
> but this doesn't:
>
> 1 to 10 fold(0){(a:Int, b:Int) => a + b}
>
> i start with infix, but how can i "cleanly switch to dot-mode again"?
I agree, this problem reaches me each day either. IDEs may help in
future on providing such a conversion, but that is not a solution of the
problem. Infix notation is a nice feature but it doesn't work the way in
Scala it could work.

Even worse in my opinion is postfix notation. I never understood why it
is possible to write `xs toList`. It is a nightmare to be refactored, in
most cases one have to introduce parentheses when something should be
changed. And not to mention all the problems that a arise when an
existing argument list is adapted in the following line.

I would remove this notation from the grammar and not just hide it
behind a flag - especially because I have never seen a single case where
this notation was useful.
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/5/13 2:43 AM
Introducing syntax just to handle this case is fighting against a symptom, not against the cause. It is always possible to forget about syntax, no matter how it looks. I neither like `a` nor @a to match against an identifier, the compiler should semantically be able to resolve what I want to do. But I have no idea on how to achieve that, maybe when identifiers are embedded in different contexts. But I have to clue to achieve that either. ;)
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/5/13 3:04 AM

On 12/05/2013 08:31 AM, Jon Pretty wrote:
> Hi Haoyi,
>
> The upper-/lower-case rule in pattern matching is weird because it's
> only seen in pattern matching, and it appears to elevate something
> which is otherwise only a convention (capitalization of type names,
> lower-case for value identifiers) to a strict feature, in just this
> isolated case.
Conventions are poor people compilers. I can't accept that there is a
convention to start a class names with an upper case letter but no
compiler that enforces it. In Java I would immediately introduce that
feature to the compiler. There, I don't see cases where it would
introduce large problems.

Sadly, in Scala it is not that easy, thanks to the uniform access
principle. If is often very useful to write `object scope` or `def
Factory()` and not to mention constants like `val Const = 0`. A lot of
freedom which makes live easy on the first sight but just introduces
dozens of irregularities on a more in depth sight.

I like the idea to simplify all theses keywords further. Why is there a
difference between `object`, `class`, `abstract class`, `trait`,
`package`, `val`, `def`, `var` or `lazy val`? There is a different
context which has to be semantically available, in Scala and most other
languages it is done by keywords. I like the idea of simplification
behind Lisp but not the parens and prefix notation.

Uniformity in these cases would also mean to be able to allow write

class X(a: A, b: B) = {
}

and

def x(a: A, b: B) = {
}
new x(a, b)

a nice thought...

>
> A language feature which maybe falls into the same category is
> sealed-trait scope; nowhere else in the Scala language does the file
> have such relevance.
>
> But they're both obvious pragmatic choices because they support the
> useful cases so well. Being able to write concise pattern matches is
> very neat feature, and this actually entrenches the capitalization
> convention. In fact, it drives the convention, as a desire to pattern
> match on an identifier is often the motivation for breaking the usual
> convention and naming it with a capital letter.
>
> So, I'd ask the question: Would the language be more consistent if,
> instead of removing the "quirk", it were to proliferate into other
> aspects of Scala? For example, could we make it illegal to name a type
> with a lower-case letter or a value with a capital letter, unless you
> annotate them in some way to indicate it's a deliberate choice? I'm
> not sure I'd like this, but I'm the wrong person to ask, because I'm
> already too familiar with Scala to give an unbiased opinion.
>
> I'm not sure there are many other places where this feature is
> relevant, but with most of these supposed warts, removing them is not
> the only option.
>
> Cheers,
> Jon
>
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 3:14 AM
On Thursday, 5 December 2013 10:21:55 UTC, Simon Schäfer wrote:
Name shadowing is one of the most awesome features of Scala - in 99% of all cases when I do it I will do it.

Shadowing is indeed sometimes useful. You can also use it to mask implicits.

But when it bites you, it can bite you disproportionately badly.

Jon
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 3:17 AM
On Thursday, 5 December 2013 10:34:55 UTC, Simon Schäfer wrote:
> for example this works fine:
> 1 to 10 map {_ * 5} filter {_ % 5 == 0} 

One useful consequence of having both styles available to you is that you can mix and match them, and get the benefit of different precedence.

  List(1, 2, 3) foreach Console.println

Jon 
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/5/13 3:48 AM


On Thursday, December 5, 2013 3:14:32 AM UTC, Simon Ochsenreither wrote:

BankAccountBusinessService (is-a) HttpServer (is-a) DBConnection (is-a) Logger

I think the thing here is that in Scala those things are really traits. 

Surely I'm not the only one who sees the problem with BankAccountBusinessService being able to *override* HttpServer.send , DBConnection open/close, Logger.log, etc.

And if you think "why would anyone do that ", all I can say is this: http://www.youtube.com/watch?v=nIDlTGd7Y9U



 
The way traits are commonly used in Scala is very different from e. g. interfaces in Java.

Yes they are, unfortunately... 
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 4:10 AM
On Thursday, 5 December 2013 11:48:29 UTC, Cristian wrote:
Surely I'm not the only one who sees the problem with BankAccountBusinessService being able to *override* HttpServer.send , DBConnection open/close, Logger.log, etc.

But that's a conscious decision you make, surely? If you wanted to (for example) log all HttpServer.sends, you could just write

  override def send(whatever: Any) = {
    log.info("Doing an HTTP send")
    super.send(whatever)
  }

That just happens to be an implementation which is useful - I think you were suggesting examples which weren't useful, or at least undermined reasonable expectations, though correct me if I misinterpreted you.

But what's to stop you implementing an interface in Java with methods which do things that bear no relation to their name or documentation? Unless I'm missing your point, I don't think what you've described is unique to traits or Scala...
 
The way traits are commonly used in Scala is very different from e. g. interfaces in Java.

Yes they are, unfortunately... 

I do actually disagree with Simon very slightly here (unusually!). Usage of traits in Scala isn't that much different from interfaces in Java, there are just a few additional uses of traits in Scala which arise from their flexibility that wouldn't make sense in Java.

Cheers,
Jon
 
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/5/13 4:27 AM


But that's a conscious decision you make, surely? If you wanted to (for example) log all HttpServer.sends, you could just write

  override def send(whatever: Any) = {
    log.info("Doing an HTTP send")
    super.send(whatever)
  }


Yes, you could very well write that, but it violates everything that the OO community has learned over the years, like, separation of concerns for one.

The fact that is so easy to do that and in fact, actively encouraged by the Scala community  is what baffles me.
 
  Yes they are, unfortunately... 

I do actually disagree with Simon very slightly here (unusually!). Usage of traits in Scala isn't that much different from interfaces in Java, there are just a few additional uses of traits in Scala which arise from their flexibility that wouldn't make sense in Java.


Their flexibility just seems to make the wrong things easy. And people use it and it ends up being the 10 deep multiple inheritance hierarchy with 100 methods all public that call up and down across the hierarchy. 

 
Re: [scala-debate] Re: Another Scala rant on HN Matthew Pocock 12/5/13 4:43 AM
The more I code, the more I find inheritance to be a bane. It has very specific situations where it is exactly the right tool for the job, but it is usually the wrong hammer. Once you throw in type parameters and type parameter refinement as you track through an inheritance hierarchy, you generally don't even have inheritance that tracks substitutability. Particularly when I find myself writing Java code, I end up defining APIs in interfaces with limited interface hierarchy and then having class hierarchies which are extremely shallow, usually just the one class. These classes don't so much 'implement' the interfaces as 'realise' them.

Scala's traits are really wonderfully efficient tools for expressing inheritance hierarchies. They are a vast improvement over java's interfaces. However, they do encourage inheritance-heavy spaghetti (see the collections API) that sets to concrete where type-class approaches would, I contend, provide much cleaner and clearer abstraction. I am very pleased that 2.10 gained syntax to make type classes easier to work with (implicit classes etc.) and hope the scaladoc catches up.

OK, that's my contribution over.

Matthew


--
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.



--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143
Re: [scala-debate] Re: Another Scala rant on HN Rex Kerr 12/5/13 4:54 AM
On Wed, Dec 4, 2013 at 8:15 PM, Alan Johnson <lla...@gmail.com> wrote:

To Rex, the situation really isn't as simple as you describe it.

You're right; I'd forgotten some additional special cases.  Neither is it as complex as you describe it, but I agree that you and Jon have pointed out plenty of wrinkles that could use some ironing.
 

  - Type ascription needs a colon.  That's the only time you use a single colon.

Sure, but it's not always intuitive to know when you actually need to use type ascription.

Agreed.  But this isn't the colon's fault.  It's not related to the language syntax at all, but rather the capabilities of type inference.  Put another way: there is no possible way you could change the syntax of ascribing a type that would make this any better.  It's a deeper issue, alas.
 

  - Braces go anywhere you have multiple statements.  (Irregularity: you can use parens for a for-comprehension instead.)

Yet sometimes they are also used to group things that aren't statements, like case statements and for clauses. And I don't really know if I'm interpreting this correctly, but it seems like they can also double as parentheses, to make it look like a thunk is simply setting next to a method? Like Future { 5 }

I view this as "case statements act like multiple statements", but I agree that's also an irregularity.  Braces work anywhere you _could_ have multiple statements, and Scala lets you omit parens if you use braces (since ({ blah }) doesn't really clarify anything) so rather than being a special case, I think it's actually very consistent...but it's consistently flexible.  Having more than one way to do something typically makes it harder for a newcomer until they are comfortable enough with the language to appreciate when the different styles help clarify rather than confuse matters.  It's definitely a tradeoff.
 

  - _ goes anywhere you mean "whatever", whether it's an unnamed function argument, an unspecified type, an import of everything, or arguments you'll fill in later.

Underscore is waaay overloaded. Plus it's rather strangely used to for partial application of functions.

The details are tricky, but the "whatever-everything" meme works surprisingly well.  Partial application of functions _is_ a kind of "whatever-everything" that you do to a function.
 

  - Backticks are only needed when you're trying to use a reserved word as an identifier.  That's the only time you use it.

And also needed to defeat magical interpretation of case clauses when it's not the desired effect.

Oops.  I'd forgotten about that.  Agreed, that is a bit of a jarring overload.  I almost never use this for that reason.
 

  - You never need to use an extra set of parentheses.  (Irregularity: sometimes you can omit parens and sometimes you can't.)

Because a tuple and argument list are two different things, sometimes, it feels like you do.

Agreed.  One way or another it's irregular.
 

  - => means a function, both with types (TypeA => TypeB) and values (x => f(x)).  (Exception: imports use => for renaming.)

=> is also used for call-by-name parameters

Which are just Function0 with some syntactic sugar to make them look like they aren't.  I've never gotten any mileage out of thinking of call-by-name parameters as anything other than Function0s.  To avoid surprises, an IDE that highlights them appropriately can be useful.
 

  - -> is an alternate builder for Tuple2.  That's the only time you use it.

I would question whether this actually adds to the usefulness of the language versus the regularity of leaving out this special case.

I use it all the time when creating maps.  I used to not, but then I noticed that it really clarifies where my key-value pairs are.
 
And I when I wrote it, I also had in mind <-, which is obviously a different token, but has a totally unrelated use.

I agree this is bad--in particular that <- and => are in some sense opposites of each other.  Of course <= means something else, but I think the more consistent usage would be <- and ->.  I'd be willing to give up the map-pair functionality for that (or use a different symbol like <>).
 

  - def creates a method; val creates an un-reassignable value.  Always.  (Exception: case classes let you omit the val in the constructor.)

Plenty of examples I've seen declare vals in traits, but implement them as defs

Other way around; a val can stand in for a def since that's one perfectly reasonable way to get the result of a no-argument function: just read a value.  This isn't a syntactic issue.
 

Also, I forgot the . and how you can leave it off to get infix syntax.

Like with { 5 } vs. (5), this is flexibility not inconsistency (in that you can choose to do it either way, rather than being forced to sometimes do it one way and sometimes the other).

It took me some time to develop the intuition for where point-free syntax looks cleaner and still works.  There is more to say about this than I have time to write right now, but in a sense it's a price (or opportunity?) we pay for having minimal distinctions between operators and methods.  I agree that it is not beneficial for ease of learning.

  --Rex
 
Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Matthew Pocock 12/5/13 5:06 AM



On 5 December 2013 12:54, Rex Kerr <ich...@gmail.com> wrote:
On Wed, Dec 4, 2013 at 8:15 PM, Alan Johnson <lla...@gmail.com> wrote:
  - -> is an alternate builder for Tuple2.  That's the only time you use it.

I would question whether this actually adds to the usefulness of the language versus the regularity of leaving out this special case.

I use it all the time when creating maps.  I used to not, but then I noticed that it really clarifies where my key-value pairs are.
 
And I when I wrote it, I also had in mind <-, which is obviously a different token, but has a totally unrelated use.

I agree this is bad--in particular that <- and => are in some sense opposites of each other.  Of course <= means something else, but I think the more consistent usage would be <- and ->.  I'd be willing to give up the map-pair functionality for that (or use a different symbol like <>).

This lack of symmetry bugs me constantly and is one of the sources of WTF?!? from colleagues looking over my shoulder. We should either be using -> and <- or => and <=. The standard mathematical notation would be ->, but the standard logical inference notation would be =>. Pick one or the other for Scala 3, I don't care, but pick one of the two forms throughout and be consistent (I'd prefer <- and ->, as that leaves <= and => open for type-level programming). The special syntax for Tuple2 that we use in map literals would be |-> () in standard maths notation. 

Matthew


--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143
Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 5:15 AM
On Thursday, 5 December 2013 13:06:56 UTC, Matthew Pocock wrote:
I agree this is bad--in particular that <- and => are in some sense opposites of each other.  Of course <= means something else, but I think the more consistent usage would be <- and ->.  I'd be willing to give up the map-pair functionality for that (or use a different symbol like <>).

I'm not sure that's right. A => B is quite a different thing from B <- A, and A -> B is different again, so it's perhaps more jarring that these last two should look like they're saying the same thing.

Jon
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/5/13 5:30 AM



I'm just going to add this and go back to my day job :) There's a lot of debate around minor syntax quirks. Also I noticed Martin quiz on syntax size.

I think this misses the point entirely of what people mean by complexity. It's not complexity of syntax, it's complexity of concepts.

The tyranny of choice if you like. Even this discussion about traits is relevant: is it an interface, an abstract class, a mixin, all of that and more ?

A good programming language in my view is one that encourages good abstractions. When I sit down and model the world I want to implement I'm now faced with the options: is this a interface trait, a mixin trait, an abstract, an actual class, maybe a type class ?

That's what scares people off, not whether to type semicolons or not.

On Thursday, December 5, 2013 12:43:44 PM UTC, Matthew Pocock wrote:
 I am very pleased that 2.10 gained syntax to make type classes easier to work with (implicit classes etc.) and hope the scaladoc catches up.


So based on this, here's my suggestion to make Scala 3.0 the true language of the future (and allow it to have a chance to compete with Java 8)

- create a typeclass (or type class) a first class concept - i.e. make it a keyword
- make type class type function parameters behave like implicit parameters  
- deprecate implicits entirely

Eventually get rid of inheritance completely, when the above becomes popular enough
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 5:47 AM
On Thursday, 5 December 2013 12:27:58 UTC, Cristian wrote:

Yes, you could very well write that, but it violates everything that the OO community has learned over the years, like, separation of concerns for one.

I don't understand! What's wrong with what I wrote? I'm using inheritance for its intended purpose, and I'm tightly binding calls to the HTTP send method to a logger, in a single place, writing very little code, and not risking forgetting any occurrences (which might happen if I added the log statement before every instance of HTTP.send that I found when doing a search for it). This is precisely what makes OOP so useful.

Over the years, Latin taught us never to split infinitives, but that doesn't mean that one has "to go boldly" rather than "to boldly go" in English. There's always some context to claims like this, and we shouldn't assume that context never changes.
 
The fact that is so easy to do that and in fact, actively encouraged by the Scala community  is what baffles me.

The extent that it is actively encouraged (and I'd challenge this idea, given that at least three talks at the Scala eXchange this week - in addition to my own which covered little else - make strong points of type classes being a better way of abstracting), I think is appropriate. Subtyping is great for modelling many things, which is why it has been used so successfully in so many places for so many years. Type classes and subtyping do actually interact very well. See my Quaternions example for evidence of this: I'm subtying complex numbers, and I'm using a Field type class which itself subtypes other more general concepts.

It's a fundamentally hard problem to anticipate users' needs in advance of them existing, and inheritance does have a tendency to attempt this, but I don't think that's any more true in Scala or Java.
 
Their flexibility just seems to make the wrong things easy. And people use it and it ends up being the 10 deep multiple inheritance hierarchy with 100 methods all public that call up and down across the hierarchy.

I can't help but feel like this sounds a bit like saying something like "multi-parameter methods are dangerous, because people end up adding more and more parameters". The job of a programmer is to model real-world concepts in a domain a machine can understand. As long as our domain remains sufficient for modelling, we're good. A massive hierarchy of multiply-inherited traits doesn't sound like a good model, though I wouldn't want to prejudge: modelling all known flora and fauna might actually work quite well using subtyping, for example.

But I'd rather be able to use type classes in addition...

Cheers,
Jon
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/5/13 6:06 AM

In my opinion, what we actually want is a slightly-more-syntax-rich pattern matcher. Although more syntax is generally a bad thing, shoving multiple cases into the same syntax distinguished by some arbitrary thing (i.e. capitalization) is terrible. One idea is to have "@" be a syntax to check against values, so you could do:

I think the syntax is nice, but would it actually solve our problem? The issue seems to be that some people expect that a in a pattern match refers to an a identifier outside. They would still encounter the same issue with @, right?
Maybe it would be more helpful to have a bind syntax like $a and a means referring to an identifier?
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/5/13 6:16 AM


On Thursday, December 5, 2013 1:47:06 PM UTC, Jon Pretty wrote:
On Thursday, 5 December 2013 12:27:58 UTC, Cristian wrote:

Yes, you could very well write that, but it violates everything that the OO community has learned over the years, like, separation of concerns for one.

I don't understand! What's wrong with what I wrote? 

I took your example to mean the the overridden send method would be in the BankAccount class, because that's the risk I was trying to point out.

So then:
- why should a BankAccount ever know or care about how to send stuff with Http
- why should HttpServer ever do a virtual call into BankAccount to find out how to send stuff over the wire
- if I decide to change my BankAccount to work over carrier pigeons now I have to take care not to break all the overridden send stuff
- if I pass BankAccounts around why should clients of that be able to send arbitrary Http stuff over the wire and open/close DBConnections
- requires non-local reasoning to get any idea why the code really does 
- need I say more ?
 

But I'd rather be able to use type classes in addition...

Well, me too. The problem is Scala makes very easy to build this tower-of-hell go-up-and mixin abstract traits structures, and incredibly hard to work with 
type classes because you have to deal with all the arcane implicits priority rules non-sense.

But... it seems the Scala community follows Martin in believing that traditional OO (which for me boils down to inheritance) is a really good thing. I hope we will be able to understand what the reasoning behind this is. I'm not saying you/he/they must be wrong, as a Scala developer and long time Java developer I just don't *know* why.


Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN Matthew Pocock 12/5/13 6:19 AM

The capitalization flag in pattern matching is truly awful. It forces you to make decisions about how a value is to be *used* at the point at which it is *declared*. It is no-obvious for a poor dyslexic like me what things within any realistically complex case statement are being bound and what things are part of the pattern. Some explicit flag, like $x for all values x to be bound, would be wonderful, and would have symmetry with string interpolation.

Matthew

--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143
Re: [scala-debate] Re: Another Scala rant on HN Jon Pretty 12/5/13 6:24 AM
On Thursday, 5 December 2013 13:30:52 UTC, Cristian wrote:
I'm just going to add this and go back to my day job :) There's a lot of debate around minor syntax quirks. Also I noticed Martin quiz on syntax size.

I'll do that in a bit too. ;)

Martin's quiz (I'm assuming he will reveal Scala to have one of the smallest three grammars) is maybe a little unfair because the syntax is just one part of what you have to understand, and (notwithstanding that I haven't seen the results yet) a language like Haskell has a more complex type system than Java.

The tyranny of choice if you like. Even this discussion about traits is relevant: is it an interface, an abstract class, a mixin, all of that and more ?

I think I've said this before, but it's a trait... it's called a trait, it looks like a trait, it does trait-like things, people use them like traits... It's a bit unfair to try to view traits in terms of old or similar concepts because those ideas carry historical baggage with them.
 
A good programming language in my view is one that encourages good abstractions. When I sit down and model the world I want to implement I'm now faced with the options: is this a interface trait, a mixin trait, an abstract, an actual class, maybe a type class ?

That's what scares people off, not whether to type semicolons or not.

It may be one thing that scares people off, but many of the citations in users' complaints refer to syntax, and Rex and I had no trouble finding several of these last night. But it's worth discussing either way.

So based on this, here's my suggestion to make Scala 3.0 the true language of the future (and allow it to have a chance to compete with Java 8)

- create a typeclass (or type class) a first class concept - i.e. make it a keyword
- make type class type function parameters behave like implicit parameters  
- deprecate implicits entirely

Eventually get rid of inheritance completely, when the above becomes popular enough

I think this is a mixture of reasonable suggestions (in the interests of increasing users' understanding), and some misunderstanding. What is the thing you annotate as a type class? Is it the interface you program to? Because at the moment we just use traits and classes to represent these, so creating a new thing called a "type class" would add nothing, except ambiguity. Is it the implementation of the type class interface? Well, we already model them using implicits (vals, vars, defs, objects). So why add a new thing called a type class? Again, it adds nothing but ambiguity. Isn't bolting on this "type class" idea just the epitome of kitchen-sink design? Anyway, so then we remove implicits. But wouldn't everyone just rewrite their implicits in the new type class syntax, and we'd be back where we were before, under a different name. Or were you proposing to get rid of the pimp-my-library pattern too?

I'm ranting now... ;)

But things have evolved to be the way they are because they have been shown to work well for enough people that they've become part of the language, and stayed part of the language. We can keep tweaking the ideas, and there's a lot of benefit to doing so, but the hours and days and weeks of thought the designers of Scala have put into the language are being undermined by the suggestion that things like implicits are an inherently terrible idea...

Cheers,
Jon
Re: [scala-debate] Re: Another Scala rant on HN Matthew Pocock 12/5/13 6:46 AM



On 5 December 2013 14:24, Jon Pretty <googl...@accounts.propensive.com> wrote:

But things have evolved to be the way they are because they have been shown to work well for enough people that they've become part of the language, and stayed part of the language. We can keep tweaking the ideas, and there's a lot of benefit to doing so, but the hours and days and weeks of thought the designers of Scala have put into the language are being undermined by the suggestion that things like implicits are an inherently terrible idea...

I love implicits! They are the first thing beyond compact syntax that I miss when I go back to Java or js or python. I've just written a pickling combinator library in Java to turn objects in our business domain into RDF, and both the lack of implicits to assemble nested strategies from types and to convert instances between types makes everything much more verbose and error-prone. IMHO, it is the ability for implicits to depend upon other implicits that makes them useful rather than just neat.

On the flip side, I've seen implicits used as a way to thread an environment or configuration or state through a call-stack. This really sucks. If you want to avoid (scoped) globals then some form of State or Reader monad is much cleaner for this.

Sorry - I will go back to arguing on facebook and coding in real-life and leave this thread to itself.

Matthew
 

Cheers,
Jon

--
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.



--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/5/13 6:48 AM
It should be clear that I'm expressing an idea because the whole thread is about Martin asking for feedback. 
I am not expressing definitive truths, just my reasoned opinion. But maybe I'm exceeding my welcome given some replies I got here :)

In any case just to clarify:

So based on this, here's my suggestion to make Scala 3.0 the true language of the future (and allow it to have a chance to compete with Java 8)

- create a typeclass (or type class) a first class concept - i.e. make it a keyword
- make type class type function parameters behave like implicit parameters  
- deprecate implicits entirely

Eventually get rid of inheritance completely, when the above becomes popular enough

 So why add a new thing called a type class? Again, it adds nothing but ambiguity. Isn't bolting on this "type class" idea just the epitome of kitchen-sink design? Anyway, so then we remove implicits. But wouldn't everyone just rewrite their implicits in the new type class syntax, and we'd be back where we were before, under a different name. Or were you proposing to get rid of the pimp-my-library pattern too?


I didn't think this through and I'm not a language designer. The suggestion I was trying to convey is to make it easy for people to use type classes and deprecate subclassing.

And yes, implicits seem to do more harm then good given their, again, massive "flexibility" There are whole chapters in Scala books (the Suereth one) dedicated to describing priority rules for implicits. They also clash incredibly badly with variance (well, everything clashes with variance)
Find better directly expressible syntax for some of the useful patterns like type classes and deprecate implicits

Why this insistence on type classes ? Because as an OO programmer I was always annoyed that I can't easily (without much boilerplate) separate the concepts
of "is-a thing" from "has-a behaviour"

An HttpServer is not a HttpServer. It behaves like one. There's no reason for a BankAccount to behave like an HttpServer.

Type classes try to solve this problem. Scala can innovate in making this approach easy to use and hence best practice. Maybe it can find a better express type classes than even Haskell has! That would be innovation, not gimmicks like Pimp-my-library

 
 We can keep tweaking the ideas, and there's a lot of benefit to doing so, but the hours and days and weeks of thought the designers of Scala have put into the language are being undermined by the suggestion that things like implicits are an inherently terrible idea...

I'm sure there will continue to be a Scala community. The question is will it ever significantly grow beyond people who have already been converted if it doesn't make bold decisions ?
Re: [scala-debate] Re: Another Scala rant on HN ARKBAN 12/5/13 7:15 AM
Scala supports unicode for identifiers, hence it can support identifiers
in other languages, how does this work for other alphabets which do not
have have upper and lower case letters?

ARKBAN

On 12/5/13 2:31 AM, Jon Pretty wrote:
> Hi Haoyi,
>
> The upper-/lower-case rule in pattern matching is weird because it's
> only seen in pattern matching, and it appears to elevate something
> which is otherwise only a convention (capitalization of type names,
> lower-case for value identifiers) to a strict feature, in just this
> isolated case.
>
> A language feature which maybe falls into the same category is
> sealed-trait scope; nowhere else in the Scala language does the file
> have such relevance.
>
> But they're both obvious pragmatic choices because they support the
> useful cases so well. Being able to write concise pattern matches is
> very neat feature, and this actually entrenches the capitalization
> convention. In fact, it drives the convention, as a desire to pattern
> match on an identifier is often the motivation for breaking the usual
> convention and naming it with a capital letter.
>
> So, I'd ask the question: Would the language be more consistent if,
> instead of removing the "quirk", it were to proliferate into other
> aspects of Scala? For example, could we make it illegal to name a type
> with a lower-case letter or a value with a capital letter, unless you
> annotate them in some way to indicate it's a deliberate choice? I'm
> not sure I'd like this, but I'm the wrong person to ask, because I'm
> already too familiar with Scala to give an unbiased opinion.
>
> I'm not sure there are many other places where this feature is
> relevant, but with most of these supposed warts, removing them is not
> the only option.
>
Re: [scala-debate] Re: Another Scala rant on HN Tomas Mikula 12/5/13 7:19 AM


On Thursday, December 5, 2013 11:34:55 AM UTC+1, Simon Schäfer wrote:

Even worse in my opinion is postfix notation. I never understood why it
is possible to write `xs toList`. It is a nightmare to be refactored, in
most cases one have to introduce parentheses when something should be
changed. And not to mention all the problems that a arise when an
existing argument list is adapted in the following line.

I would remove this notation from the grammar and not just hide it
behind a flag - especially because I have never seen a single case where
this notation was useful.

For one, I find it useful to use * for repetition and ? for option in parser combinators, as in

def block = "{" ~> (statement*) <~ "}"

Tomas
Re: [scala-debate] Re: Another Scala rant on HN Haoyi Li 12/5/13 7:24 AM
I think the syntax is nice, but would it actually solve our problem? The issue seems to be that some people expect that a in a pattern match refers to an a identifier outside. They would still encounter the same issue with @, right?

The idea is that currently we already have the syntax:

case list @ List(1, 2, 3) => ...

Which means "bind the name `list` to the thing matching the value/extractor `List(1, 2, 3)`. My proposal would be to extend the syntax slightly to allow:

case list @ => ... // bind the name `list`
case @ List(1, 2, 3) => ... // match the value/extractor `List(1, 2, 3)`

This is basically a straightforward extension of the current syntax. The last thing would be to allow:

case list @ list => ... // bind the name `list` to the thing matching the value of the (external) `list`
case @ list => ... // match the value of the variable `list`

These are non-trivial changes to the semantics, but I think that it makes sense: the thing on the left of an `@` is a name being bound, the thing on the right of an @ is a value/extractor to match against. The second already works when the value/extractor is Uppercase, and I think re-using the existing semantics of @ is a pretty nice way of explicitly declaring it. 

I think it does solve the problem, unless I'm missing something obvious.

In a way, parametrized extractors would render this whole thing moot as you could write something like `case Val(list) =>` and be done with it. Anyone know what happened to those? I remember seeing them on the 2.11 roadmap sometime long ago
Re: [scala-debate] Re: Another Scala rant on HN Haoyi Li 12/5/13 7:25 AM
I'd agree if you did not have to always put () around the `statement*` because of precedence reasons. The fact that you have to do it kinda breaks the regex-like elegance, and makes it no nicer/cleaner/lessverbose than

def block = "{" ~> statement.* <~ "}"


--
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.

Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/5/13 8:03 AM

On 12/05/2013 04:25 PM, Haoyi Li wrote:
I'd agree if you did not have to always put () around the `statement*` because of precedence reasons. The fact that you have to do it kinda breaks the regex-like elegance, and makes it no nicer/cleaner/lessverbose than

def block = "{" ~> statement.* <~ "}"
+1
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/5/13 8:09 AM

On 12/05/2013 03:48 PM, Cristian wrote:
> I didn't think this through and I'm not a language designer. The
> suggestion I was trying to convey is to make it easy for people to use
> type classes and deprecate subclassing.
How do you want to do a dynamic dispatch just with type classes?
Re: [scala-internals] Another Scala rant on HN Paul Phillips 12/5/13 9:09 AM
> Shadowing warnings are something that's often been mooted, but which I've never seen implemented (this is the cue for someone to tell me it's in trunk, behind an -X parameter...). 

I've done it. The problem is that it is unusably noisy out of the box, and I never completed the long slog through Heuristica. You don't realize until you see the warnings how often you use shadowing. Especially "case x" and "map (x =>" and suchlike.

I have observed before that the huge payoff will be had when the compiler habitually compares the last known good ast with the current one. With shadowing what is crucial to know is when it changes - especially when a non local member suddenly appears in scope because you renamed or removed the member which used to shadow it. This will be out of reach until the compiler records something against which it can compare. 

On Thursday, December 5, 2013, Jon Pretty wrote:


On Thursday, 5 December 2013 07:57:06 UTC, Haoyi Li wrote:
 
I'm also pretty familiar with Scala. My gut says sure, making types *have* to start with capital letters works fine. On the other hand, I don't think it solves the problem here. The problem is if i have:

That was half of it. The other half was "values have to start with lower-case letters". But either way, it doesn't solve the problem!

Shadowing warnings are something that's often been mooted, but which I've never seen implemented (this is the cue for someone to tell me it's in trunk, behind an -X parameter...).

- or bind a value to the identifier `a` and shadow the old one. 


You can currently use backticks around the identifier, for example:

  val a = 1
  List(1, 2) map {
    case `a` => println("It's 1!")
    case a => println("It's not 1...")
  }

but you could argue this is an extra quirk of backticks that's not obvious...

Your suggestion of using @ is interesting, though I think you would want the @ after the identifier, for consistency with current behaviour.

Cheers,
Jon

--
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-internals+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
Re: [scala-debate] Re: Another Scala rant on HN pagoda_5b 12/5/13 9:14 AM
I'd prefer to simply substitute backticks syntax with your proposed @

case list @ List(1, 2, 3) => ... // match the right pattern and bind to 'list'
case list => ... // bind the name `list` to every passed value

This would work as before, with a lighter syntax for arguably the most frequent use

case @list => ... // match the value of the variable `list` (as opposed to the `list` => syntax)

This shares the same "unintuitive" behaviour as right now, but gains us some syntactic consistency with the other cases.

Ivano
Re: [scala-debate] Re: Another Scala rant on HN Cristian 12/5/13 9:49 AM


On Thursday, December 5, 2013 4:09:53 PM UTC, Simon Schäfer wrote:

How do you want to do a dynamic dispatch just with type classes?

1. I don't
2. If you really think you need it, seems to be possible: http://www.haskell.org/haskellwiki/Existential_type#Dynamic_dispatch_mechanism_of_OOP
 
Re: [scala-debate] Re: Another Scala rant on HN Simon Ochsenreither 12/5/13 10:00 AM

case @list => ... // match the value of the variable `list` (as opposed to the `list` => syntax)

This looks really nice! I just can't decide if it's more appropriate to use it for referring to an identifier or creating a bind. :-)
Re: Another Scala rant on HN Joost de Vries 12/5/13 10:19 AM
Some things that I find sometimes hard to analyse:

Re Implicits: Personally I like about implicits that they prevent api users from providing contextual objects by hand. That's the kind of code that gets tedious very fast. And contextual objects are essential since threadlocals don't cut it anymore.
But I do find the implicit effects somewhat hard to analyse. One way to address that would be for the IDE show (on hover f.i.) through what rules of implicitness a certain implicit parameter is resolved. That would help people in understanding existing code. Similarly you could show (using highlighting or lines in the margin) which implicit objects are in scope somewhere.
Similarly the compiler could guess the intent of the coder who either declares implicit variables or calls apis that have implicits. This is already working for ExecutionContexts where the compiler suggests what kind of import you may need. But it would also be possible f.i. when an implicit jsonForrmat val is declared in a companion object to check whether the type of the formatter matches the apply and unapply method and give helpful positive feedback (giving the user the impression that the construction 'clicked into place' as required) or constructive suggestions. Ideally I'd like to see looking at my case class that according to the compiler it is f.i. Play json writable/readable. Instead of having to go the my calling code and see whether 'the magic' works.
Maybe the IDE/compiler can fulfill a role in educating people in a friendly everyday way about how things work in scala code. Instead of having to google for a weblog post.

For me the apply - unapply methods in companion objects feel a bit opaque. And the relationship between a class and its companion object also feels a bit like indirect.
Regarding the name apply-unapply: I think about them as constructor and extractor (or other inverse of constructor). But their syntax is very different from an OO class. Maybe apply & unapply in companion objects with return values that match the case class could be sugared as a function with the name of the case class. That way the special nature of those apply methods and their relationship to constructors would be more intuitive and not be only 'hidden' in the type.

I notice that I when I'm working on some piece of code I tend to create intermediate vals to be able to see on hover what type the compiler gives the subexpression. And then I often remove them again. It would be easier for me to analyse code if I could select a composite expression and do a right click or something to see what type the selected expression evaluates to.

SBT is something that every noob will encounter quickly. So I think it's really important to make that 'baby code'; really obvious.
Some specific experiences of mine:
In the beginning I spent many frustrating hours in getting my dependencies to work. The difference between %% and % is not intuitive and the error messages do not point towards a solution. Helpful messages could be "the library XXX was not found for your scala version x.y.z. But the library _is_ available for scala version x.y.z-1. Also a newer snapshot version of the library is available at well know repository blabla. You may want to change the scala version in build.properties or add the repository to ..." Similarly for ivy style vs maven style dependencies.
Also I lost a lot of time due to build files working somewhat on root level and within the project directory. (I think that has been sanitised somewhat in recent versions)
It would be nice if Eclipse would help with editing and analysing the build files.
When I set up configuration settings for an sbt pluging I'm using it has felt to me that the compiling/testing/running the application failed silently. I don't think I ever had feedback like "you're including sbt plugin x in project y but plugin x requires configurations y and z that were not found or have unlikely values. The result is that setting up a somewhat more involved build script felt like trial and error, seeing which construction from googled examples would work and I wound up analysing the code for the sbt plugin every time. A lot of people will give up before that.
I think that a build script would feel more intuitive if if seemed more object oriented (even though it may be implemented in a completely functional way) and/or scoped using blocks. Now sbt scripts feel like an java properties file on steroids. Maybe a form that looks a bit like a specs 2 dsl with blocks with expressive words in between would be more approachable..?  Or maybe the scala configuration files could be an inspiration (too).
The current sbt file format with the empty lines in between feels not quite optimal. The downside to me of the sbt files is that they're a bit like scala, but not quite. So I can't use what I know about scala in understanding them. And I can't use scala editors...

Anyhow; you're all doing an awesome job in listening to the community about this. It's like a UI usability lab for coders. :-)

Oh, and about the strange vehemence of the reactions: in psychology there's the notion of the narcissism of the small difference. Narcissism as in 'wanting to feel special'. In society people often want to make clear that they aren't part of the class or group that they see as just below them.
Similarly I get the feeling that there are alpha geeks that are looking for the superior tool. Especially when it's conceptually different and challenging. Especially the startup hot shots who are going to disrupt everything. They invest a significant part of their life in this technology. So if there is a technology that has similar 'cutting edge' qualities but has also qualities of the incumbent old school tech (i.e. java) that threatens their being different and the validity of their investment.
I have really no idea what you can do about that. Apart form, as suggested above, clearly stating the value of the mixed paradigm from a CS perspective. Apart from "being accessible to java developers" that is (which is valuable as well).

On Monday, 2 December 2013 10:32:15 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.

 - 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
Re: [scala-debate] Re: Another Scala rant on HN nafg 12/6/13 4:38 AM


On Dec 5, 2013 6:04 AM, "Simon Schäfer" <ma...@antoras.de> wrote:


>
>
> On 12/05/2013 08:31 AM, Jon Pretty wrote:
>>
>> Hi Haoyi,
>>
>> The upper-/lower-case rule in pattern matching is weird because it's only seen in pattern matching, and it appears to elevate something which is otherwise only a convention (capitalization of type names, lower-case for value identifiers) to a strict feature, in just this isolated case.
>
> Conventions are poor people compilers. I can't accept that there is a convention to start a class names with an upper case letter but no compiler that enforces it. In Java I would immediately introduce that feature to the compiler. There, I don't see cases where it would introduce large problems.
>
> Sadly, in Scala it is not that easy, thanks to the uniform access principle. If is often very useful to write `object scope` or `def Factory()` and not to mention constants like `val Const = 0`. A lot of freedom which makes live easy on the first sight but just introduces dozens of irregularities on a more in depth sight.
>
> I like the idea to simplify all theses keywords further. Why is there a difference between `object`, `class`, `abstract class`, `trait`, `package`, `val`, `def`, `var` or `lazy val`? There is a different context which has to be semantically available, in Scala and most other languages it is done by keywords. I like the idea of simplification behind Lisp but not the parens and prefix notation.
>
> Uniformity in these cases would also mean to be able to allow write
>
> class X(a: A, b: B) = {
> }

Hmm, that would go together with the alternative self-type syntax mentioned earlier:
trait A: B = { ...

On the the other hand, once you draw classes and constructors on the same line as methods, maybe leaving out the = for Unit method makes a bit more sense...

>
> and
>
> def x(a: A, b: B) = {
> }
> new x(a, b)

What would that do?

>
> a nice thought...


>
>
>>
>> A language feature which maybe falls into the same category is sealed-trait scope; nowhere else in the Scala language does the file have such relevance.
>>
>> But they're both obvious pragmatic choices because they support the useful cases so well. Being able to write concise pattern matches is very neat feature, and this actually entrenches the capitalization convention. In fact, it drives the convention, as a desire to pattern match on an identifier is often the motivation for breaking the usual convention and naming it with a capital letter.
>>
>> So, I'd ask the question: Would the language be more consistent if, instead of removing the "quirk", it were to proliferate into other aspects of Scala? For example, could we make it illegal to name a type with a lower-case letter or a value with a capital letter, unless you annotate them in some way to indicate it's a deliberate choice? I'm not sure I'd like this, but I'm the wrong person to ask, because I'm already too familiar with Scala to give an unbiased opinion.
>>
>> I'm not sure there are many other places where this feature is relevant, but with most of these supposed warts, removing them is not the only option.
>>
>> Cheers,
>> Jon
>>
>> --
>> 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.
>
>
> --
> 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.

Re: [scala-debate] Re: Another Scala rant on HN nafg 12/6/13 4:47 AM

Scaladoc has caught up--you just have to pass it the right options.

Re: [scala-debate] Re: Another Scala rant on HN nafg 12/6/13 4:52 AM


On Dec 5, 2013 7:54 AM, "Rex Kerr" <ich...@gmail.com> wrote:
>
> On Wed, Dec 4, 2013 at 8:15 PM, Alan Johnson <lla...@gmail.com> wrote:
>>
>>
>> To Rex, the situation really isn't as simple as you describe it.
>
>
> You're right; I'd forgotten some additional special cases.  Neither is it as complex as you describe it, but I agree that you and Jon have pointed out plenty of wrinkles that could use some ironing.
>  
>>
>>
>>   - Type ascription needs a colon.  That's the only time you use a single colon.
>>
>> Sure, but it's not always intuitive to know when you actually need to use type ascription.
>
>
> Agreed.  But this isn't the colon's fault.  It's not related to the language syntax at all, but rather the capabilities of type inference.  Put another way: there is no possible way you could change the syntax of ascribing a type that would make this any better.  It's a deeper issue, alas.
>  
>>
>>
>>   - Braces go anywhere you have multiple statements.  (Irregularity: you can use parens for a for-comprehension instead.)
>>
>> Yet sometimes they are also used to group things that aren't statements, like case statements and for clauses. And I don't really know if I'm interpreting this correctly, but it seems like they can also double as parentheses, to make it look like a thunk is simply setting next to a method? Like Future { 5 }
>
>
> I view this as "case statements act like multiple statements", but I agree that's also an irregularity.  Braces work anywhere you _could_ have multiple statements, and Scala lets you omit parens if you use braces (since ({ blah }) doesn't really clarify anything) so rather than being a special case, I think it's actually very consistent...but it's consistently flexible.  Having more than one way to do something typically makes it harder for a newcomer until they are comfortable enough with the language to appreciate when the different styles help clarify rather than confuse matters.  It's definitely a tradeoff.
>  
>>
>>
>>   - _ goes anywhere you mean "whatever", whether it's an unnamed function argument, an unspecified type, an import of everything, or arguments you'll fill in later.
>>
>> Underscore is waaay overloaded. Plus it's rather strangely used to for partial application of functions.
>
>
> The details are tricky, but the "whatever-everything" meme works surprisingly well.  Partial application of functions _is_ a kind of "whatever-everything" that you do to a function.
>  
>>
>>
>>   - Backticks are only needed when you're trying to use a reserved word as an identifier.  That's the only time you use it.
>>
>> And also needed to defeat magical interpretation of case clauses when it's not the desired effect.
>
>
> Oops.  I'd forgotten about that.  Agreed, that is a bit of a jarring overload.  I almost never use this for that reason

I don't see it as an overload -- backticks mean "force this text to be seen as an identifier." Not parsed otherwise, and not a bind variable.
Well maybe I'm wrong because
val `yield` = 1
doesn't act like a pattern match, even though you can have a pattern in that position.

>  
>>
>>
>>   - You never need to use an extra set of parentheses.  (Irregularity: sometimes you can omit parens and sometimes you can't.)
>>
>> Because a tuple and argument list are two different things, sometimes, it feels like you do.
>
>
> Agreed.  One way or another it's irregular.
>  
>>
>>
>>   - => means a function, both with types (TypeA => TypeB) and values (x => f(x)).  (Exception: imports use => for renaming.)
>>
>> => is also used for call-by-name parameters
>
>
> Which are just Function0 with some syntactic sugar to make them look like they aren't.  I've never gotten any mileage out of thinking of call-by-name parameters as anything other than Function0s.  To avoid surprises, an IDE that highlights them appropriately can be useful.
>  
>>
>>
>>   - -> is an alternate builder for Tuple2.  That's the only time you use it.
>>
>> I would question whether this actually adds to the usefulness of the language versus the regularity of leaving out this special case.
>
>
> I use it all the time when creating maps.  I used to not, but then I noticed that it really clarifies where my key-value pairs are.
>  
>>
>> And I when I wrote it, I also had in mind <-, which is obviously a different token, but has a totally unrelated use.
>
>
> I agree this is bad--in particular that <- and => are in some sense opposites of each other.  Of course <= means something else, but I think the more consistent usage would be <- and ->.  I'd be willing to give up the map-pair functionality for that (or use a different symbol like <>).
>  
>>
>>
>>   - def creates a method; val creates an un-reassignable value.  Always.  (Exception: case classes let you omit the val in the constructor.)
>>
>>
>> Plenty of examples I've seen declare vals in traits, but implement them as defs
>
>
> Other way around; a val can stand in for a def since that's one perfectly reasonable way to get the result of a no-argument function: just read a value.  This isn't a syntactic issue.
>  
>>
>>
>> Also, I forgot the . and how you can leave it off to get infix syntax.
>
>
> Like with { 5 } vs. (5), this is flexibility not inconsistency (in that you can choose to do it either way, rather than being forced to sometimes do it one way and sometimes the other).
>
> It took me some time to develop the intuition for where point-free syntax looks cleaner and still works.  There is more to say about this than I have time to write right now, but in a sense it's a price (or opportunity?) we pay for having minimal distinctions between operators and methods.  I agree that it is not beneficial for ease of learning.
>
>   --Rex
>  
>
> --
> 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.

Re: [scala-debate] Re: Another Scala rant on HN nafg 12/6/13 4:54 AM


On Dec 5, 2013 7:54 AM, "Rex Kerr" <ich...@gmail.com> wrote:
>

If -> meant function like in Haskell, and => meant making like in php etc., it would take care of all these concerns.

>  
>>
>>
>>   - def creates a method; val creates an un-reassignable value.  Always.  (Exception: case classes let you omit the val in the constructor.)
>>
>>
>> Plenty of examples I've seen declare vals in traits, but implement them as defs
>
>
> Other way around; a val can stand in for a def since that's one perfectly reasonable way to get the result of a no-argument function: just read a value.  This isn't a syntactic issue.
>  
>>
>>
>> Also, I forgot the . and how you can leave it off to get infix syntax.
>
>
> Like with { 5 } vs. (5), this is flexibility not inconsistency (in that you can choose to do it either way, rather than being forced to sometimes do it one way and sometimes the other).
>
> It took me some time to develop the intuition for where point-free syntax looks cleaner and still works.  There is more to say about this than I have time to write right now, but in a sense it's a price (or opportunity?) we pay for having minimal distinctions between operators and methods.  I agree that it is not beneficial for ease of learning.
>
>   --Rex
>  
>
> --
> 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.

Re: [scala-internals] Re: [scala-debate] Re: Another Scala rant on HN nafg 12/6/13 4:55 AM

Not so different. Remember how for comprehension desugar.

--
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.
Re: [scala-debate] Re: Another Scala rant on HN nafg 12/6/13 4:59 AM


On Dec 5, 2013 8:30 AM, "Cristian" <cristian...@googlemail.com> wrote:
>
>
>
>
> I'm just going to add this and go back to my day job :) There's a lot of debate around minor syntax quirks. Also I noticed Martin quiz on syntax size.
>
> I think this misses the point entirely of what people mean by complexity. It's not complexity of syntax, it's complexity of concepts.
>
> The tyranny of choice if you like. Even this discussion about traits is relevant: is it an interface, an abstract class, a mixin, all of that and more ?
>
> A good programming language in my view is one that encourages good abstractions.

The problem is that what's a good selection of abstractions in one person's experience usually turns out to be limiting in other situations. That's the great thing about Scala -- you have much more freedom in choosing appropriate abstractions. But of course that is a huge tradeoff.

When I sit down and model the world I want to implement I'm now faced with the options: is this a interface trait, a mixin trait, an abstract, an actual class, maybe a type class ?
>
> That's what scares people off, not whether to type semicolons or not.
>
> On Thursday, December 5, 2013 12:43:44 PM UTC, Matthew Pocock wrote:
>>
>>  I am very pleased that 2.10 gained syntax to make type classes easier to work with (implicit classes etc.) and hope the scaladoc catches up.
>>
>
> So based on this, here's my suggestion to make Scala 3.0 the true language of the future (and allow it to have a chance to compete with Java 8)
>
> - create a typeclass (or type class) a first class concept - i.e. make it a keyword
> - make type class type function parameters behave like implicit parameters  
> - deprecate implicits entirely
>
> Eventually get rid of inheritance completely, when the above becomes popular enough
>
> --
> 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.

Re: [scala-debate] Re: Another Scala rant on HN Paul Kinsky 12/6/13 8:43 AM
The standard library list/stream builders use some simple glyphs.

    val a: List[Int] = 1 :: 2 :: Nil

    def ints(from: Int): Stream[Int] = from #:: ints(from + 1)

I like them, but I can see how they could cause confusion.

On Tuesday, December 3, 2013 2:22:23 PM UTC-5, raould wrote:
> 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?
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/6/13 9:15 AM

On 12/06/2013 01:38 PM, Naftoli Gugenheim wrote:
>
> Hmm, that would go together with the alternative self-type syntax
> mentioned earlier:
> trait A: B = { ...
>
> On the the other hand, once you draw classes and constructors on the
> same line as methods, maybe leaving out the = for Unit method makes a
> bit more sense...
>
...whose syntax seems to be fully deprecated soon.
>
> >
> > and
> >
> > def x(a: A, b: B) = {
> > }
> > new x(a, b)
>
> What would that do?
>
I don't know. The idea was to point out that I don't fully understand
why there exists so large differences between keywords. That seems to be
related to static typing. In a dynamically typed language it would be no
problem to find out at runtime if a block contains a blueprint for an
object, thus it could be instantiated. With static types this is not
that easy, the compiler need to obtain that information from somewhere.
Re: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/6/13 9:20 AM
I see, but still wondering if the runtime overhead of this solution can be optimized away by the compiler.
Code reuse through subtyping seems not to be on par with this solution either.

 
--
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.

Re: [scala-debate] Re: Another Scala rant on HN Justin du Coeur 12/6/13 1:13 PM
Catching up on this thread, a thought or two:

On Wed, Dec 4, 2013 at 3:50 AM, pagoda_5b <ivano....@gmail.com> wrote:
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
[...]
for-comprehensions [HC]

This is a good illustration of one of my bugbears, which is that many of these topics are not *entirely* complicated.  The problem is the tendency to teach *everything*, all at once.

I mean, basic for comprehensions aren't rocket science any more.  Damned near every language worth its salt has some sort of "foreach" statement nowadays, and people understand those.  You can get a fair ways in explaining for comprehensions simply by saying that they are nested foreach's -- that gets people about halfway to understanding basic usage.  The rest is explaining how the yield gets wrapped up in the original functor, but you can semi-gloss that and still have people understanding the basics, enough to do really common things like nesting a bunch of Options this way.  *Explaining* for in detail is hard, but examples make it much clearer.

*Deeply* understanding for is a more interesting problem.  It takes rather longer to grok enough about Monads to start reaching for for comprehensions constantly.  (Which every Scala programmer eventually gets to, I suspect, but you don't start there.)  In particular, really being comfortable with how different Monads are going to combine in for takes a fair while.

(And of course, learning how to *create* new Monads, so that you can use them in comprehensions, will cause most peoples' heads to explode if you start them on it too fast.)

But the thing is, you don't have to start there.  And that's the point: too much documentation still looks at things too much in terms of big chunks: here is All of Comprehensions (which winds up talking about Monads); there is All of Generics (which winds up talking about variance), and so on.  Even the books that talk about things in a layered way still get horribly complicated-sounding by the second half, which intimidates people.

Seriously: we need a book called something like Everyday Scala, which is *just* the first half.  Intentionally focused on A1/A2/L1 programmers, talking about the stuff that the average application programmer needs, and *very* deliberately glosses over the complicated stuff.  It should probably be recipe-centric, showing how to get started with various examples quickly, and yes, pointing out that the resulting code is half as long and twice as easy to read as the corresponding Java.

Yes, that's a bit unsatisfying, and yes, the book would need tips on how to read the scaladocs and what to not worry about too much.  (And yes, it would have to talk a bit about using implicits, because you pretty much can't use many libraries without them.)  But I'd bet that you could essentially leave out half the language, and produce a book that 75% of programmers would find far more accessible and useful.  (And then you match it with Advanced Scala, for us language geeks and library authors.)


One more note:
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'll be honest -- I tend not to lead with Scala, because that *is* still a tricky sell.  Instead, I've been starting to use Akka as the tail wagging Scala's dog.

Scala is much better than Java, yes, but the counter of, "but how many skilled engineers are there?" is still pretty effective, and every good VP of Engineering will go right to it.  But I can say with complete honesty that, if you're writing any sort of interesting and sophisticated server and you *aren't* using Akka, you're probably asking for a world of unnecessary hurt.  *That* gets peoples' attention.

(And bless the current US healthcare rollout for providing a horribly good illustrative example of what can happen if you don't take scalability seriously enough...)
Re: [scala-debate] Re: Another Scala rant on HN Tobias Roeser 12/5/13 2:38 AM
Am Donnerstag, 5. Dezember 2013, 11:24:38 schrieb Simon Schäfer:
| On 12/05/2013 05:15 AM, Alan Johnson wrote:
| > /  - def creates a method; val creates an un-reassignable value.
| > Always.  (Exception: case classes let you omit the val in the
| > constructor.)/
| >
| > Plenty of examples I've seen declare vals in traits, but implement
| > them as defs
|
| Just for reference, it is not possible to implement a val as a def. A
| def has a getter and a setter, a val only a getter.

Did you mean var instead of def? A def is just a def, but a var can be seen as
two defs, which are a getter and a setter.

Regards,
Tobias
Re: Another Scala rant on HN Amir Karimi 12/7/13 9:08 AM
After more than 10 years of development on .NET, Scala allowed me to have a big migration into another world. I've always liked to be able to develop for non-Microsoft platforms but I couldn't live without type-safety, LINQ, Extension Methods, etc. There was no choice for me except C#. Until I found Scala. Of course now I have also other reasons to prefer Scala over C# than just being cross-platform ;)

Scala itself is really nice and stable. It took about two months (less than 80 hours totally) until I felt better with Scala than C#.

But I think the main problem is about tools. I never get satisfied (even near to satisfied) with Eclipse. Some missing functionalities are surprising! For example; lack of expression evaluation in debug mode. 

Maybe it's because of my background but I believe that we need a significant improvement in this area. Strongly-typed languages are the best for which we can build tools. 

Regards,
Amir

On Monday, December 2, 2013 1:02:15 PM UTC+3:30, 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.

 - 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
Re: [scala-debate] Re: Another Scala rant on HN HamsterofDeath 12/7/13 9:15 AM
try intellij idea
Am 07.12.2013 18:08, schrieb Amir Karimi:
--
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.

Re: [scala-debate] Re: Another Scala rant on HN Dennis Haupt 12/7/13 9:19 AM
i *bought* licenses for intellij idea because otherwise, i am forced to
use eclipse - that is how good i consider it to be. my company won't buy
me any because they do not understand that time is money ;(



Am 07.12.2013 18:15, schrieb HamsterofDeath:
--

Re: [scala-debate] Re: Another Scala rant on HN Amir Karimi 12/7/13 10:07 AM
I want a full featured open-source IDE. IDEA is very nice but when it comes to ecosystem you have to buy the license. Of course there are other reasons but for now I prefer Eclipse.

--
Amir Karimi
(+98) 912 211 9506
(+98) 21 7706 1222

www.dev-frame.com
www.xoqal.com
Re: [scala-debate] Re: Another Scala rant on HN CCs 12/7/13 10:09 AM
IntelliJ Community Edition (free) normally has all you need for Scala.
Re: [scala-debate] Re: Another Scala rant on HN Amir Karimi 12/7/13 10:20 AM
What about Play and others?

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.

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

--
Amir Karimi
(+98) 912 211 9506
(+98) 21 7706 1222

www.dev-frame.com
www.xoqal.com
Re: [scala-debate] Re: Another Scala rant on HN Dennis Haupt 12/7/13 10:51 AM
in my experience, intellij is a lot cheaper than eclipse if you consider
that time == money
i would be 2x slower, if not more, if i would use eclipse.

Am 07.12.2013 19:07, schrieb A. Karimi:
> /Amir Karimi
> (+98) 912 211 9506
> (+98) 21 7706 1222
>
> www.dev-frame.com
> www.xoqal.com
> /
>
> --
> 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.
> .

--

Re: [scala-debate] Re: Another Scala rant on HN Amir Karimi 12/7/13 11:28 AM
You're absolutely right but please consider that I talked about tools not just IDEs (IDE is a good sample though). Plugins (Compiler, Build Tools, IDEs), Translators (Ex. Scala.js), and anything that makes development easier are all tools which need a significant improvement in both quality and quantity.

Re: [scala-debate] Re: Another Scala rant on HN c cygil 12/9/13 1:53 PM
I'm strictly an "A1" or "A2" programmer and I have to agree. "Programming Scala" is a good reference, but not a tutorial. The other problem is I'm having a lot of trouble finding source code at the appropriate level for learning. I learn by reading source code and
have resorted to reading through the scalac source, which is actually the most instructive and reasonably clear code I've been able to find. More easy source code and recipes, please!


On Saturday, December 7, 2013 8:13:38 AM UTC+11, Justin du Coeur wrote:

Seriously: we need a book called something like Everyday Scala, which is *just* the first half.  Intentionally focused on A1/A2/L1 programmers, talking about the stuff that the average application programmer needs, and *very* deliberately glosses over the complicated stuff.  It should probably be recipe-centric, showing how to get started with various examples quickly, and yes, pointing out that the resulting code is half as long and twice as easy to read as the corresponding Java.

Re: Another Scala rant on HN Aleh Aleshka 12/10/13 1:36 AM

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

I'm afraid to say that it's pretty much a lie. There are still tonnes of issues in intellij plugin. Even though it's quite good, people moving from e.g. java might be disappointed.

Thanks, Aleh
Aw: [scala-debate] Re: Another Scala rant on HN Dennis Haupt 12/10/13 2:04 AM
it's not a lie - the java support is just still a lot better
but i still would prefer the ides we have now 10x over a text editor
 
Gesendet: Dienstag, 10. Dezember 2013 um 10:36 Uhr
Von: "Aleh Aleshka" <oleg...@gmail.com>
An: scala-...@googlegroups.com
Cc: scala-internals <scala-i...@googlegroups.com>
Betreff: [scala-debate] Re: 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.
Re: Another Scala rant on HN Jon Pretty 12/10/13 3:00 AM
The IDEs have come a huge way, and they're usable now, which wasn't true five years ago. Java users will still be disappointed, but that's at least partly a consequence of Scala's long build times. I get a fair amount of pain with Eclipse, but it's not clear to me how much of this is the fault of the Scala plugin, Eclipse itself, or other plugins; I suspect a mixture. And despite this, and despite being a devoted Vi user, I prefer Eclipse for working on codebases I'm unfamiliar with. (Though I still use Vim for my own projects.)

Cheers,
Jon
Re: Aw: [scala-debate] Re: Another Scala rant on HN Simon Schäfer 12/10/13 3:01 AM

On 12/10/2013 11:04 AM, Dennis Haupt wrote:
it's not a lie - the java support is just still a lot better
but i still would prefer the ides we have now 10x over a text editor
I wouldn't call it a lie either - but I also wouldn't sell it as "fixed". More as "mature for productive development" which was not the case 3 years ago, where the at least scala-ide for eclipse executed different code than the developer has written.
 
Gesendet: Dienstag, 10. Dezember 2013 um 10:36 Uhr
Von: "Aleh Aleshka" <ole...@gmail.com>

An: scala-...@googlegroups.com
Cc: scala-internals <scala-i...@googlegroups.com>
Betreff: [scala-debate] Re: Another Scala rant on HN
 
     + we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this
        is no longer that much of an issue.
   

I'm afraid to say that it's pretty much a lie. There are still tonnes of issues in intellij plugin. Even though it's quite good, people moving from e.g. java might be disappointed.

Thanks, Aleh

 

--
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.
--
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.

Re: Aw: [scala-debate] Re: Another Scala rant on HN David Barri 12/10/13 3:19 AM
Intellij's Scala support is functional but still has a looong, long way to go.

It doesn't even do syntax highlighting with significant accuracy. A good 10% or so of my project shows up with bogus errors. It really bugs me.
Look at tickets with "good code red", there are hundreds of them.

I don't imagine the plugin authors have an easy task and I'm sure the dudes are working hard, they've made great process, but let's get get ahead of ourselves with quotes like "we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this is no longer that much of an issue."
Re: Aw: [scala-debate] Re: Another Scala rant on HN David Barri 12/10/13 3:21 AM
>but let's get get ahead of ourselves

Wow look how supportive of everything Scala my subconscious is. That was meant to be:
  "[...] let's not get [...]"

Re: Another Scala rant on HN Roman Janusz 12/10/13 12:39 PM
IntelliJ plugin still has a lot of issues with serious performance problems among them, but overall is a pretty good IDE for Scala.

Unfortunately I can't say that about Eclipse. Every time I check out a new version of the Scala IDE, I have a checklist with following points:
  • Is it able to show names of method parameters in completion (sic!) ?
  • Is it able to show javadoc and scaladoc (like when writing Java)?
  • Is it able to do basic inspection of code like displaying type hierarchies, for BOTH project sources and library sources?

As long as Scala IDE is unable to do these very basic things, I cannot consider it usable as an IDE.

W dniu wtorek, 10 grudnia 2013 10:36:38 UTC+1 użytkownik OlegYch napisał:
Re: Another Scala rant on HN Simon Ochsenreither 12/10/13 12:52 PM
  • Is it able to show javadoc and scaladoc (like when writing Java)?
Imho, it is very unfortunate that this is still missing.
 
Re: Aw: [scala-debate] Re: Another Scala rant on HN nafg 12/10/13 1:44 PM

"Fixed" does not mean finished, it means no longer broken.

Re: [scala-internals] Re: Another Scala rant on HN iulian dragos 12/11/13 1:56 PM



On Tue, Dec 10, 2013 at 9:39 PM, Roman Janusz <romeqj...@gmail.com> wrote:
IntelliJ plugin still has a lot of issues with serious performance problems among them, but overall is a pretty good IDE for Scala.

Unfortunately I can't say that about Eclipse. Every time I check out a new version of the Scala IDE, I have a checklist with following points:
  • Is it able to show names of method parameters in completion (sic!) ?
Yes (choosing a completion proposal enters placeholders for each parameter, using the parameter name).
  • Is it able to show javadoc and scaladoc (like when writing Java)?
No, not yet. This proved to be much harder to do than we initially thought (the presentation compiler doesn't yet have this functionality). We think we can do it for Scala 2.11.
 
  • Is it able to do basic inspection of code like displaying type hierarchies, for BOTH project sources and library sources?
I definitely wouldn't call that basic, but there's an additional plugin that can do Type Hierarchy (not for source attachments, true)

As long as Scala IDE is unable to do these very basic things, I cannot consider it usable as an IDE.

That's your right, but I can tell you that the Eclipse Scala IDE is used daily on large projects, like the Scala compiler or the IDE itself. Of course, there are many features we miss, but it's an open-source project: you (anyone) can help and contribute. It's useful to note that the Java Eclipse IDE got where it is today in many (10?) years of development, with a team larger by at least one order of magnitude.

IntelliJ and Eclipse Scala plugins have different strengths: IntelliJ has better integration with the platform, while the Eclipse plugin has true "errors-as-you-type", a much better worksheet. Both are evolving, and way better than a couple of years ago. I'm sure we won't stop here.

cheers,
iulian



 

W dniu wtorek, 10 grudnia 2013 10:36:38 UTC+1 użytkownik OlegYch napisał:

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

I'm afraid to say that it's pretty much a lie. There are still tonnes of issues in intellij plugin. Even though it's quite good, people moving from e.g. java might be disappointed.

Thanks, Aleh

--
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.

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Dennis Haupt 12/11/13 2:54 PM
"choosing a completion enters placeholders"

true, but this is more a hack than a feature - i want to know everything in advance. intellij has a very nice popup, take a took at how they do it. not only do they tell you the parameter names and types by using a popup, they also tell you - if parameters are already entered - which are matching the signature and which have the wrong type, at which parameter your cursor is at. if there are overloaded methods, they show them all.
eclipse itself (the java version) fails completely at this, imho.


2013/12/11 iulian dragos <iulian...@typesafe.com>

--
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.

Re: [scala-internals] Re: Another Scala rant on HN Roman Janusz 12/11/13 3:23 PM
  • Is it able to show names of method parameters in completion (sic!) ?
Yes (choosing a completion proposal enters placeholders for each parameter, using the parameter name).

Then why aren't parameter names displayed in the completion itself? I'd like to choose a completion after I know what the method is doing. Also, I noticed that parameter types in completion are always displayed with fully qualified class names, which is a lot of unnecessary noise.
  • Is it able to show javadoc and scaladoc (like when writing Java)?
No, not yet. This proved to be much harder to do than we initially thought (the presentation compiler doesn't yet have this functionality). We think we can do it for Scala 2.11.

Great! That would be a huge deal. This is really an essential feature.
  • Is it able to do basic inspection of code like displaying type hierarchies, for BOTH project sources and library sources?
I definitely wouldn't call that basic, but there's an additional plugin that can do Type Hierarchy (not for source attachments, true)

What is "basic" is of course a subjective matter. I'm an example of someone who uses the IDE a lot for analyzing third party code. Ability to effectively inspect and browse code of libraries that I use is essential to me when trying to understand better how that library is working and how to use it. Scala IDE is a failure in this regard, while IntelliJ is doing pretty good job at it.

Another painful thing that I just reminded is Eclipse's inability to show inherited members in the outline view (as far as I remember, it can't do it even for Java). With much more finegrained decomposition of classes into traits in Scala, this becomes even more of a problem. When I want to find implementation of some method on some class, I have to manually search its entire type hierarchy.

So overall, I find Scala IDE to be really bad at code inspection, with IntelliJ being much further ahead.
Re: [scala-debate] Another Scala rant on HN Paolo Giarrusso 12/11/13 9:51 PM


On Monday, December 2, 2013 1:55:11 PM UTC+1, Erik Post wrote:
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.

Isn't this the same kind of criticism which is moved against Haskell? Many people to do things the way they are used to, fail, and gets frustrated. The reason is simply that functional programming, like abstract mathematics, happens at a higher level of abstractionl, further away from reality, and that's simply harder to learn as documented in cognitive science. In both cases, going away from reality can be useful, and for the same reasons, but this takes time to appreciate.

And to be sure, I also had the same problems with learning Haskell, even though I am mathematically inclined (though more for different branches of mathematics). I ended up programming Scala instead of Haskell because Scala learning curve is so much smoother — you can range from programming "Java-like" and enjoying some of the improvements to trying to write Haskell-like or even shapeless-like code.
Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Michal Politowski 12/12/13 1:40 AM
On Wed, 11 Dec 2013 15:23:27 -0800, Roman Janusz wrote:
[...]
> Another painful thing that I just reminded is Eclipse's inability to show
> inherited members in the outline view (as far as I remember, it can't do it
> even for Java). With much more finegrained decomposition of classes into
> traits in Scala, this becomes even more of a problem. When I want to find
> implementation of some method on some class, I have to manually search its
> entire type hierarchy.

Interestingly (and possibly usefully) the Quick Outline (under Ctrl+O)
_does_ let you display inherited members (toggled by Ctrl+O).

--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.
Re: Another Scala rant on HN Dickon Field 12/13/13 9:21 AM
Something that would be enormously helpful would be a text along the lines of Grady Booch's "Object Oriented Analysis and Design with Applications". Its a comparatively old textbook that refers to C++, it predates Java, but the basic idea of giving meaning and relevance to programming language constructs through real life situations is powerful. While I really like Scala, I have often stumbled across some feature of the language and it has taken time to work out the answer to the simple question 'why'? For basic features, for Java programmers, the answer is straightforward, and you love what you see. But as you start hitting the more advanced features of the language, even given the quality of 'Programming in Scala' it takes a while. When it clicks its an ephiphany, but it takes perhaps too long for many.

Its more challenging with Scala its true - the value of some features become apparent when you are considering relatively complex problem domains such as text parsing that a lot of programmers rarely tackle in a serious way. Making the power of the language more accessible by relating it to conceptually easy to access problems will pay off though.

Dickon


On Monday, December 2, 2013 9:32:15 AM UTC, 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.

 - 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
Re: [scala-internals] Re: [scala-debate] Another Scala rant on HN nafg 12/15/13 3:48 PM
On Fri, Dec 13, 2013 at 3:22 AM, Vaidotas S <vaido...@gmail.com> wrote:
Hi,

I am rather new here, but would like to give my opinion. To be honest I haven't read all posts here, so maybe this was addressed, but overall I see this pattern that bothers me - scala community tends to explain those rants just by programming paradigm shift (To Functional or to mix of functional with OOP) - "FP is too hard", "people don't wont to change their ways".... IMHO that is just incorrect or at least correct only in some cases.

I and few other colleagues who tried Scala have this other feeling with it. So I'll try to shortly explain where I am coming from. First of all, sorry if I won't be very specific, but keep in mind that I am writing this at my coffee break and have no check list of things to write.
Personally I am fed up with Java and dreaming for a next big thing to jump to. So I tried Scala, I tried really hard to like it, however I just could not do it, because I just feel that I will never be happy developer with Scala.
All this paradigm shift, I am ok with that, its fundamental stuff and I don't see any problem in that. Where I see Scala problems is this (trying to recreate from my head now, so might misss something):
1. Scala is very dirty language! It's not clean, a lot of corner cases, rules with many exceptions, it even feels worse than Java in being not-clean. Java is rather dirty as well in my book, in fact, i strongly believe, that the reason such exams as SCJP were tricky was exactly because Language is dirty. For Scala it was general feeling to me and it had nothing to do with complexities of functional programing. Since I tried Scala a while back, I would not be able to go with specifics, but I remember functions vs. methods, curryng vs. partially applied functions and many other topicks introduced a lot of corner cases that I had to learns just because language is dirty.
2. It does not solve anything what makes Java development burdensome. For me Java development is burdensome mainly not due to a language, but overall environment - constant dev-environment problems, application servers, configuration, modularity, build tools... IMHO Scala does very little here.

I don't understand you. Scala is a language. Why do you expect it to solve problems that are not language-related?
 
3. Compile times. This of course was mentioned a lot, but incremental compilation is not always an option.

So my theory why do a lot of people rant about Scala - because many people put big hopes to it and then had even bigger disappointment when realized that it is not the language/platform they hoped it would be. Its just same burdensome Java with a lot more powerful (but not clean) language.


P.S. Writing this just to explain personal negative feelings, but not to start some wars. I really wish Scala would be better.

--
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.

Re: Another Scala rant on HN Niels 12/23/13 1:40 PM
I realize this thread is some three weeks old by now and has probably run its course, but I'd like to add my two cents.

To be honest, I can't speak from a novice perspective when it comes to Scala. I have been using the language since before the incarnation of Scala 2, writing my first toy application in early 2005. At the time, I came across Scala in a period I investigated many languages and tried to learn many of the things someone with an academic background in CS learns in classes. As a self-taught programmer, I had to figure things out by myself.

At first I was hugely attracted to Haskell, and still consider it a very elegant language, but found the lack of support for interfacing with foreign libraries sub-par and in some cases ill maintained.

In 2005, I learned about this "new" language, Scala, which, due to its ability to run on the JVM, had immediate appeal to me. In Scala-land, inter-operating with mature libraries that are well-maintained is no issue, and in that respect Scala has never let me down.

I also appreciated the OO features of Scala over the functions-only approach of Haskell. I realize  some may disagree with me on that issue, but for me personally, the OO approach matches better with the way my mind works than the functions-only approach.

When I started using Scala, a friend of mine, who also happens to be a programmer asked me: "What is the usage domain of Scala". At the time, I responded that it is a general purpose programming language, so it is usable for almost any domain conceivable.

In hind-site, the question my friend asked was more profound than my superficial answer reflected. Certainly my answer was perfectly correct, but it also reflects a lack of understanding how and why people start using programming languages. My choice to start using Scala was mostly driven by curiosity and a desire to learn concepts that were new to me, with practical considerations coming second.

When we look at popular programming languages of the present and the past, many started out, or at some point gained a specific application domain. Cobol made it easier to write business applications, Fortran made it easier to write numerical applications, C/C++ made it easier to write systems applications, JavaScript made it possible to write applications that run in the browser, Java made it possible to write highly portable application, C#/VB-Net made it easier to write Windows applications, PHP made it easier to write web applications, and Ruby made it easier to write CRUD applications once the on-Rails frame work was created.

For many years, Scala didn't necessarily have such an application domain. Certainly actors were available as a library many versions ago, but it took some time to become a mature solution.

With the maturation of the Typesafe stack, it seems Scala has found its niche in distributed programming, In that sense the reactive manifesto is a great initiative to stress the applicability of Scala in the domain of fault-tolerant, distributed systems.

I hope this focus will remain. In the past many new avenues were tried out: Scala-swing comes to mind and the continuation plug-in, that both have merits, but take away resources from improving the language from growing more rapidly in its main application domain.

For years, Scala has shown to be an academic language, and in that sense is not unlike Haskell. or Modula 2 and Oberon. All interesting languages, and none of them highly used in the software industry.

With the incarnation of Typesafe, it seems Scala is no longer primarily rooted in academics, and that is a good thing. Academics are a great breeding ground for new ideas and for solid theoretical foundations, but it is rarely a place for optimal results when it comes to usability. It's a waste of time for PhD students to spend too much time on such mundane activities as error messages and warnings, or to include great entry-level documentation, yet these are the things that make the difference between a good and a great programming platform.

The criticism Scala is receiving these days, to me, is a sign of maturation. Scala is no longer that attractive new kid on the block that is given some slack. Details as IDE-integration, documentation, error messages matter to make it in the grown-up league.

I believe Scala is on the right course in that respect. IDE-integration has improved significantly (especially when compared to the first Eclipse plug-in I used), Scaladocs is a huge improvement over earlier API documentation, but still could use a lot more detailed explanation of certain methods. Error messages are a lot less cryptic these days than they were when I first started using Scala. Yet, these areas need further improvement. In fact, I would say that these areas should have a higher priority than any new features to the language.

Finally, compiler performance is at times off-putting, and remains an Achilles-heel of a language as computationally complex as Scala. I understand that version 2.11 will see some improvements in that area, and the incremental compilation strategies used through SBT are somewhat of a relief, but much more progress needs to be made for Scala to become optimally usable in that area.

With that, I'd like to end this message with a question whether there exist plans to port the Scala compiler to a distributed platform such as Akka, utilizing more cores, more machines to make the compilation cycle more reactive?






On Monday, December 2, 2013 4:32:15 AM UTC-5, 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.

 - 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
Re: Another Scala rant on HN Simon Ochsenreither 12/24/13 2:09 AM
Hi Nils,

thanks a lot for your insights! You bring up tons of good points which deserve wider attention.


To be honest, I can't speak from a novice perspective when it comes to Scala. I have been using the language since before the incarnation of Scala 2, writing my first toy application in early 2005. At the time, I came across Scala in a period I investigated many languages and tried to learn many of the things someone with an academic background in CS learns in classes. As a self-taught programmer, I had to figure things out by myself.

This could also be one angle from which we got some of the backslash. I didn't think of that before. Scala today is a very different language from Scala 5 years ago. Some people might have had pretty bad impressions with Scala a few years ago. Good to keep that in mind ... maybe we could have a look and see how we can improve the changes-between-versions document.

With the maturation of the Typesafe stack, it seems Scala has found its niche in distributed programming, In that sense the reactive manifesto is a great initiative to stress the applicability of Scala in the domain of fault-tolerant, distributed systems.

I hope this focus will remain. In the past many new avenues were tried out: Scala-swing comes to mind and the continuation plug-in, that both have merits, but take away resources from improving the language from growing more rapidly in its main application domain.

I'm a bit concerned about that. I would really like to see more thought invested into figuring out how we can expand Scala's reach beyond it's current usage domains. In a sense, I want to have a cut from the whole cake, not just a bigger bite from a small slice.

There are some areas where even some minimal focus could probably improve Scala's standing considerably. For instance
  • Android and iOS deployment,
  • Scala as a first-class scripting language,
  • native compilation and
  • usage on resource-constrained systems.

But I can understand that it currently isn't really Typesafe's focus and I'm actually happy that they primarily spend their time working on things their paying customers care about.


With the incarnation of Typesafe, it seems Scala is no longer primarily rooted in academics, and that is a good thing. Academics are a great breeding ground for new ideas and for solid theoretical foundations, but it is rarely a place for optimal results when it comes to usability. It's a waste of time for PhD students to spend too much time on such mundane activities as error messages and warnings, or to include great entry-level documentation, yet these are the things that make the difference between a good and a great programming platform.

I agree, but I'd also like to raise two points which I think are important
  • There are a lot of "non-academic" people out there who care about Scala and will complain loudly if features with lacking usability get introduced.
  • E. g. Eugene's work is very impressive and shows that one can have functionality which is both satisfying from a academic and a usability/documentation/maintainability/... POV.

Imho, the issues you have mentioned have been a problem in the past, but we have payed a lot of our debts in 2.10 and 2.11 to bring the standard library up to a reasonable quality standard. If we manage to enforce that standard for future contributions, I think we have a bright future here.

 
The criticism Scala is receiving these days, to me, is a sign of maturation. Scala is no longer that attractive new kid on the block that is given some slack. Details as IDE-integration, documentation, error messages matter to make it in the grown-up league.

+1.

 
I believe Scala is on the right course in that respect. IDE-integration has improved significantly (especially when compared to the first Eclipse plug-in I used), Scaladocs is a huge improvement over earlier API documentation, but still could use a lot more detailed explanation of certain methods. Error messages are a lot less cryptic these days than they were when I first started using Scala. Yet, these areas need further improvement. In fact, I would say that these areas should have a higher priority than any new features to the language.

+1. I'm planning to add some additional package-level documentation to the standard library¹ to make it easier for people to find their way around, but there is still a lot of work and polish remaining which I can't handle all n my own.


Finally, compiler performance is at times off-putting, and remains an Achilles-heel of a language as computationally complex as Scala. I understand that version 2.11 will see some improvements in that area, and the incremental compilation strategies used through SBT are somewhat of a relief, but much more progress needs to be made for Scala to become optimally usable in that area.

I agree, although I'm also wondering whether this problem will fix itself over time. CPUs don't get huge speed improvements in sequential processing like in the past anymore, but the speed is still increasing considerably while scalac is not getting slower, but faster at the same time.


With that, I'd like to end this message with a question whether there exist plans to port the Scala compiler to a distributed platform such as Akka, utilizing more cores, more machines to make the compilation cycle more reactive?

I think the new backend parallelizes those tasks which can be parallelized, but I'm not sure that distributed computing will help here. As far as I understand many of the actually time-consuming tasks are not those which can be easily moved from machine to machine.

Personally, I'm approaching this issue from the other side. I'm currently working on compiling scalac to native code, which should at least improve startup time.

I'm also thinking about how to improve scripting support together with Pablo, in the sense of not doing most time-consuming operations. E.g. making scalac check whether the .scala files are actually newer than the .class files and skipping compilation completely if that's not the case. Plus, doing the same for the runtime: Not loading/compiling the .class files if the exisiting JIT-compiled, cached artifacts are newer than the .class files.

I think if those things work out, it could improve the experience of working with Scala considerably.

Thanks,

Simon


¹ First part of that is here: https://github.com/scala/scala/pull/3290/files
Re: [scala-internals] Re: Another Scala rant on HN nafg 12/24/13 11:45 AM



Maybe we should encourage people to break their projects into as many small sbt subprojects as possible (for one thing by making that as easy to do as possible in sbt config --- 0.13 is a big improvement). Sbt compiles subprojects in parallel according to their dependencies.

 

Personally, I'm approaching this issue from the other side. I'm currently working on compiling scalac to native code, which should at least improve startup time.

I'm also thinking about how to improve scripting support together with Pablo, in the sense of not doing most time-consuming operations. E.g. making scalac check whether the .scala files are actually newer than the .class files and skipping compilation completely if that's not the case. Plus, doing the same for the runtime: Not loading/compiling the .class files if the exisiting JIT-compiled, cached artifacts are newer than the .class files.

I didn't know Java made that possible.
 

I think if those things work out, it could improve the experience of working with Scala considerably.

Thanks,

Simon


¹ First part of that is here: https://github.com/scala/scala/pull/3290/files

--
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.

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Haoyi Li 12/24/13 11:59 AM
Maybe we should encourage people to break their projects into as many small sbt subprojects as possible (for one thing by making that as easy to do as possible in sbt config --- 0.13 is a big improvement). Sbt compiles subprojects in parallel according to their dependencies.

I would like a better way of enforcing acyclic dependencies on a intra-project level. Multiple SBT sub-projects seems like a really blunt tool to enforce something the compiler already knows, and also duplicates a lot of structure that we already have inside a project: the folder/module hierarchy.

Once you have a good dependency graph inside your project, there's no fundamental reason why different bits of that project can't be compiled in parallel.

It may even make sense to put inter-file cyclic dependencies behind a feature flag like scala.language.cyclic, or to have a scala.language.acyclic flag that you can import into a file or package object to get the compiler to yell at you if there are cyclic dependencies between this file/package and others. 

A lot of the other feature flags hide features that are difficult to mis-use accidentally ("oops I typed implicit def? I didn't mean to!"). A cyclic dependency graph, on the other hand, tends to sneak up on you over time. It is extremely hard to notice that you're creating these cyclic dependencies while working, impossible to spot their creation during code review, and they probably result in a lot more confusion in large code bases than implicits or macros. You'll probably only really start noticing them when new-hires are taking longer and longer to ramp up on your code base, or your incremental compilation gives up on you, and by then it's too late for any quick fix!



--
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.

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Aleh Aleshka 12/24/13 12:27 PM
That's a great idea. Cyclic dependencies currently force sbt to
recompile too much quite frequently, and it would be nice to have a
better way to debug these cases, inspecting compile analysis is such a
hassle.
Aleh
> <nafto...@gmail.com <mailto:nafto...@gmail.com>> wrote:
>
>
>
>
>     On Tue, Dec 24, 2013 at 5:09 AM, Simon Ochsenreither
>     <simon.och...@gmail.com
>           * Android and iOS deployment,
>           * Scala as a first-class scripting language,
>           * native compilation and
>           * usage on resource-constrained systems.
>
>         But I can understand that it currently isn't really Typesafe's
>         focus and I'm actually happy that they primarily spend their
>         time working on things their paying customers care about.
>
>
>             With the incarnation of Typesafe, it seems Scala is no
>             longer primarily rooted in academics, and that is a good
>             thing. Academics are a great breeding ground for new ideas
>             and for solid theoretical foundations, but it is rarely a
>             place for optimal results when it comes to usability. It's
>             a waste of time for PhD students to spend too much time on
>             such mundane activities as error messages and warnings, or
>             to include great entry-level documentation, yet these are
>             the things that make the difference between a good and a
>             great programming platform.
>
>
>         I agree, but I'd also like to raise two points which I think
>         are important
>
>           * There are a lot of "non-academic" people out there who
>             care about Scala and will complain loudly if features with
>             lacking usability get introduced.
>           * E. g. Eugene's work is very impressive and shows that one
>         <mailto:scala-internals%2Bunsubscribe@googlegroups.com>.
>
>         For more options, visit https://groups.google.com/groups/opt_out.
>
>
>     --
>     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
>     <mailto:scala-debate%2Bunsubscribe@googlegroups.com>.
>     For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> 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
Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN nafg 12/24/13 1:12 PM



On Tue, Dec 24, 2013 at 2:59 PM, Haoyi Li <haoy...@gmail.com> wrote:
Maybe we should encourage people to break their projects into as many small sbt subprojects as possible (for one thing by making that as easy to do as possible in sbt config --- 0.13 is a big improvement). Sbt compiles subprojects in parallel according to their dependencies.

I would like a better way of enforcing acyclic dependencies on a intra-project level. Multiple SBT sub-projects seems like a really blunt tool to enforce something the compiler already knows,

Well it only knows it once it starts trying to compile everything, no?
 
and also duplicates a lot of structure that we already have inside a project: the folder/module hierarchy.

I'm wondering whether sbt could be smarter and make this DRY. What do you mean precisely by module though?

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Haoyi Li 12/24/13 1:36 PM
Well it only knows it once it starts trying to compile everything, no?

Yeah, but rather than happily (slowly) compiling everything, it should make a loud noise and fail right there. The problem is that as time goes on, the set of "everything" being compiled grows together with the number dependency cycles, incrementally chipping away at your incremental compilation. It's not like people *like* creating massive webs of cyclic dependencies, it's just that they are extremely hard to notice, and you create them one small cycle at a time until everything is terrible. 

Allowing people to annotate files/packages as acyclic would allow them to control their own cyclic-dependency-ness in a way that is very difficult to otherwise. It would turn the dependency graph and incremental compilation from some abstract, magical thing that mysteriously fails to something tangible they can specify and control. 

For example, if package A depends on B and either of them are marked as acyclic, you would be guaranteed that changes in A will not cause B to be recompiled no matter what. Even better, if you have a massive interwoven project, you could untangle it by sprinkling around acyclic annotations around things which "should' be acyclic and fixing the resultant compilation errors, at the end of which you will *know* that your dependency graph follows some rough shape. This would help both with improving incremental compilation as well as helping any human reasoning about the code base.

Now, this is all possible with subprojects, but that's a blunt tool that brings with it a whole set of unrelated features/baggage when often all you want is a way to have a reasonably-well-formed dependency graph without massive cycles.

What do you mean precisely by module though?

I meant package, sorry.
Re: [scala-internals] Re: Another Scala rant on HN Simon Ochsenreither 12/24/13 2:53 PM

I didn't know Java made that possible.

At least on Avian ... :-)
Re: Another Scala rant on HN Niels 12/24/13 6:47 PM
Hi Simon,
 
Thank you for your thoughtful response.
 
Scala today is a very different language from Scala 5 years ago. Some people might have had pretty bad impressions with Scala a few years ago. Good to keep that in mind ... maybe we could have a look and see how we can improve the changes-between-versions document.
 
Not only the language is very different from years ago, the community itself has changed considerably over the years. When I started using Scala, the community was really helpful trying to make sense of the features of the language and the changes that were being implemented (of which there were many early on).
 
When higher-kinded types were introduced, it lead to a period that attracted some really brilliant minds to the community, people implementing category theoretical constructs in Scala, people proving the Turing completeness of the type system etc. During this phase, the mailing list was not really a welcoming environment. At times, relatively straight forward questions were responded to with deeply theoretical answers, making me often feel to be stupid, instead of learning something new.
 
Fortunately, the language itself kept me on board using Scala, despite the at times uninviting nature of the community. Frankly, my reasons to use Scala (despite a curiosity lead initiation to it), revolve mainly around relatively straight-forward usage. I appreciate the type inference. I love the ability to use functions as arguments and as return types (they especially make working with collections a great experience), and I find pattern-matching a hugely helpful way to write code. In other words, I love Scala mostly for its easy parts, and to a lesser degree for the advanced features it offers.
 
Certainly the advanced features are necessary, and every now and then, I use them when really called for. I wouldn't want those features to go away, but there was a time when too much focus in the community was devoted to these advanced features, and too little emphasis was put on communicating the value of the simpler features. This inadvertently lead to the impression that Scala is a complicated language, instead of a language that makes mundane tasks simple and complex tasks possible.
 
Over the years, I have seen Martin try to push back against too much emphasis on the complicated stuff, but he is, for understandable reasons, not as actively engaged in the community as would be ideal.
 
The situation right now has improved significantly compared to a few ago. More emphasis has been put on community friendliness, but like documentation, IDE-support and error-messages, this requires constant dedication.
I'm a bit concerned about that. I would really like to see more thought invested into figuring out how we can expand Scala's reach beyond it's current usage domains. In a sense, I want to have a cut from the whole cake, not just a bigger bite from a small slice. 
There are some areas where even some minimal focus could probably improve Scala's standing considerably. For instance:
  • Android and iOS deployment,
  • Scala as a first-class scripting language,
  • native compilation and
  • usage on resource-constrained systems.

But I can understand that it currently isn't really Typesafe's focus and I'm actually happy that they primarily spend their time working on things their paying customers care about.

I understand your concern, although I see the issues you mention as eventually being part of growing a distributed fault tolerant system. In the end a first rate distributed system should extend to Android and iOS devices as well as resource constrained systems. Personally I would love to see more attention paid to runtime compilation strategies, like scripting facilities and runtime assembly of traits. Hopefully there will be room for that somewhere down the line.
 
I agree, but I'd also like to raise two points which I think are important 
  • There are a lot of "non-academic" people out there who care about Scala and will complain loudly if features with lacking usability get introduced.
  • E. g. Eugene's work is very impressive and shows that one can have functionality which is both satisfying from a academic and a usability/documentation/maintainability/... POV.

Imho, the issues you have mentioned have been a problem in the past, but we have payed a lot of our debts in 2.10 and 2.11 to bring the standard library up to a reasonable quality standard. If we manage to enforce that standard for future contributions, I think we have a bright future here.

I totally agree there are a lot of "non-academic" people out who care about Scala, and that is a necessity for Scala to become one of the major languages in software engineering.
 
While Eugene's work is impressive, I don't necessarily find it a great example from a usability perspective. This observation has only tangentially to do with the work of Eugene (whose willingness and ability to work with and for the community has been outstanding), but more with the fact that it adds an extra learning curve to the language. Personally, I have not taken the effort to learn, what I perceive as, another language (one that manipulates AST's, instead of objects). Furthermore, the little time I spent looking at macro's has not given me the impression that it is will be an easy learning curve. The latter, has maybe more to do with the reflection library than with the macro implementation itself.
 
Fortunately, macro's are entirely orthogonal to the rest of the language, and not a  necessary requirement to write good software with Scala.
I think the new backend parallelizes those tasks which can be parallelized, but I'm not sure that distributed computing will help here. As far as I understand many of the actually time-consuming tasks are not those which can be easily moved from machine to machine.
 
Personally, I'm approaching this issue from the other side. I'm currently working on compiling scalac to native code, which should at least improve startup time.
 
I'm also thinking about how to improve scripting support together with Pablo, in the sense of not doing most time-consuming operations. E.g. making scalac check whether the .scala files are actually newer than the .class files and skipping compilation completely if that's not the case. Plus, doing the same for the runtime: Not loading/compiling the .class files if the exisiting JIT-compiled, cached artifacts are newer than the .class files.
 
I think if those things work out, it could improve the experience of working with Scala considerably.
 I am looking forward seeing your work come to fruitition. Any improvement towards runtime compilation support, would be greatly welcome.
  
Niels 

 
Re: [scala-internals] Re: Another Scala rant on HN Xuefeng Wu 12/24/13 8:18 PM
Agree community change much now. In early ago, there are many patience people, would wait for new feature, more stable and dig deeper by self without document. But right now, there are many impatient, maybe senior , even master of Java. They want to use Scala in a week or a month. But misfortune Scala is not maturity enough and not a easy language.

Although certification is not a good thing for hacker, and reject by Scala community three years ago.  but I still think it has value for some people want to verify wether could start to do Scala projects.


Yours, Xuefeng Wu 吴雪峰 敬上

> On 2013年12月25日, at 上午10:47, Niels <nielsh...@gmail.com> wrote:
>
> community
Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN nafg 12/26/13 5:02 PM
Not sure if I understand you correctly. It sounds like instead managing dependencies explicitly via build configuration, you want to manage dependencies explicitly via annotations in the source?
Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Paul Phillips 12/26/13 5:04 PM

On Thu, Dec 26, 2013 at 5:02 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:
Not sure if I understand you correctly. It sounds like instead managing dependencies explicitly via build configuration, you want to manage dependencies explicitly via annotations in the source?

He wants to receive feedback during development when new cycles are formed. It's a very good idea.

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN nafg 12/26/13 5:14 PM
For just feedback, perhaps the new incremental implementation by gkossakowski is a starting point --- IIUC it already has options to log what's being triggered by what.
But what will you do with the feedback?



--
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.

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Haoyi Li 12/26/13 6:39 PM
It sounds like instead managing dependencies explicitly via build configuration, you want to manage dependencies explicitly via annotations in the source?

No, I'm not talking about inter-project maven/sbt dependencies. I'm talking about intra-project dependencies, which can themselves easily become a mess when the projects are large. In particular, refactoring intra-project dependencies is much simpler than trying to break something into separate projects, *if* you know when you need to refactor!

But what will you do with the feedback?

Take the opportunity to do the small adjustments and refactors needed to keep the dependency graph more-or-less acyclic, while everything is still fresh and familiar, before you've checked anything in.

Maybe yell at people during code review to put things in the proper place to keep the dependency graph from turning circular.

The alternative is you wait a few months until the whole thing becomes a big ball of string and your incremental compilation dies and you have to start pulling apart the tangled dependency graphs of code you forgot months earlier.


Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN nafg 12/26/13 7:30 PM



On Thu, Dec 26, 2013 at 9:39 PM, Haoyi Li <haoy...@gmail.com> wrote:
It sounds like instead managing dependencies explicitly via build configuration, you want to manage dependencies explicitly via annotations in the source?

No, I'm not talking about inter-project maven/sbt dependencies.

Okay, it's true that currently sbt subprojects each represent a maven artifact with the parent project more as a convenient aggregation. I see your point that that's overkill for this. But I could imagine sbt getting another level of module isolation, in between artifact and package perhaps.
 
I'm talking about intra-project dependencies, which can themselves easily become a mess when the projects are large. In particular, refactoring intra-project dependencies is much simpler than trying to break something into separate projects, *if* you know when you need to refactor!

Right, my point was there could be a more lightweight version of subprojects perhaps.
 

But what will you do with the feedback?

Take the opportunity to do the small adjustments and refactors needed to keep the dependency graph more-or-less acyclic, while everything is still fresh and familiar, before you've checked anything in.

Maybe yell at people during code review to put things in the proper place to keep the dependency graph from turning circular.

Okay, so the above don't need any compiler enhancements, other than the feedback itself.

By the way, while not the identical to what the compiler could tell you, there are quite a few options for visualizing class file interdependencies, like CDA (www.dependency-analyzer.org).



The alternative is you wait a few months until the whole thing becomes a big ball of string and your incremental compilation dies and you have to start pulling apart the tangled dependency graphs of code you forgot months earlier.




On Thu, Dec 26, 2013 at 5:14 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:
For just feedback, perhaps the new incremental implementation by gkossakowski is a starting point --- IIUC it already has options to log what's being triggered by what.
But what will you do with the feedback?



On Thu, Dec 26, 2013 at 8:04 PM, Paul Phillips <pa...@improving.org> wrote:

On Thu, Dec 26, 2013 at 5:02 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:
Not sure if I understand you correctly. It sounds like instead managing dependencies explicitly via build configuration, you want to manage dependencies explicitly via annotations in the source?

He wants to receive feedback during development when new cycles are formed. It's a very good idea.

--
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.



Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Seth Tisue 12/27/13 12:13 PM
On Thu, Dec 26, 2013 at 10:30 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> By the way, while not the identical to what the compiler could tell you,
> there are quite a few options for visualizing class file interdependencies,
> like CDA (www.dependency-analyzer.org).

I'm partial to Classycle for this: http://classycle.sourceforge.net.

I can hardly conceive of keeping a large codebase under control
without a tool like this to help me. (see e.g. the Pants talk at NE
Scala 2013)

Here's an sbt task for running Classycle to produce an HTML report of
dependency structure including cycles. I should plugin-ize it, but
haven't gotten around to it:

val classycle = taskKey[File]("run Classycle and display a dependency report")

classycle := {
  val _ = (compile in Compile).value  // run it, ignore result
  "mkdir -p target/classycle".!
  "cp -f project/classycle/reportXMLtoHTML.xsl target/classycle".!
  "rm -rf target/classycle/images".!
  "cp -rp project/classycle/images target/classycle/images".!
  _root_.classycle.Analyser.main(
    Array(
      "-xmlFile=target/classycle/classycle.xml",
      "-mergeInnerClasses",
      (classDirectory in Compile).value.getAbsolutePath.toString))
  "open -a Safari target/classycle/classycle.xml".!
  baseDirectory.value / "target" / "classycle" / "classycle.xml"
}

(supporting files are in
https://github.com/NetLogo/NetLogo/tree/headless/project/classycle,
plus project/plugins.sbt has
libraryDependencies += "classycle" % "classycle" % "1.4.1" from
"http://ccl.northwestern.edu/devel/classycle-1.4.1.jar"; I don't know
a better source for the jar)

see also https://github.com/NetLogo/NetLogo/blob/headless/project/Depend.scala
for additional code for using Classycle not just to produce a report
for human perusal, but to actually fail the build if forbidden
dependencies between packages are found.
Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Paul Phillips 12/27/13 12:41 PM

On Fri, Dec 27, 2013 at 12:13 PM, Seth Tisue <se...@tisue.net> wrote:
I'm partial to Classycle for this: http://classycle.sourceforge.net.

I want to ride my Classycle
I want to ride my Class
I want to ride my Classycle
I want to ride it where I like

You say head I say peek
You say par I say seq
You say Scala I say hey man
Java was never my scene
And I don't like Haskell

[with deepest apologies to Freddie Mercury]

Also, if anyone wants the bits Seth pointed at (except the last) they're probably a little easier to get at all at once here:

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN nafg 12/28/13 4:16 PM
On Fri, Dec 27, 2013 at 3:13 PM, Seth Tisue <se...@tisue.net> wrote:
On Thu, Dec 26, 2013 at 10:30 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> By the way, while not the identical to what the compiler could tell you,
> there are quite a few options for visualizing class file interdependencies,
> like CDA (www.dependency-analyzer.org).

I'm partial to Classycle for this: http://classycle.sourceforge.net.

What kind of visualization does it generate? How interactive is it? Is there somewhere I can see what it looks like?

Thanks.
 

--
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.

Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Seth Tisue 12/28/13 9:42 PM
On Sat, Dec 28, 2013 at 6:16 PM, Naftoli Gugenheim <nafto...@gmail.com> wrote:
>> I'm partial to Classycle for this: http://classycle.sourceforge.net.
>
> How interactive is it?

Not. (Well, the HTML generated has clickable things that bring up
popups with details on the thing you clicked on. Not sure if this
counts as "interactive" since it's all pre-generated. It's a static
analyzer, after all.)

> Is there
> somewhere I can see what it looks like?

Yes, http://classycle.sourceforge.net/examples.html
Re: [scala-debate] Re: [scala-internals] Re: Another Scala rant on HN Haoyi Li 12/29/13 12:33 PM
Okay, so the above don't need any compiler enhancements, other than the feedback itself.

Agreed it's not a difficult, type-theoretic problem, but I think you're underestimating how important timely, automated, enforced feedback is. 

Being able to declare sections of your program as acyclic would be like declaring an object to be a specified type. Why should I have to CC myself on all code reviews to eternity to ensure that nobody creates a cycle between /helpers and /application, if /helpers should never have any cyclic dependencies with anybody? I should be able to put this information into the code at check-in and have the compiler do all the yelling at people for me. 

The status quo is similar to how Java makes every new type go into its own file, encouraging people to make as few types as possible (because creating/managing new files with <5 lines of code is annoying) resulting in fewer larger files with coarser-grained types with implicit "type" based on their runtime data (e.g. flags). It's an exact analogy to how people now have coarse-grained explicit acyclic dependency graphs (sub-projects) with finer-grained, implicit acyclic dependency graphs buried within. Maintaining these implicit lack-of-cycles is like how people using dynamic languages try to maintain soundness: via code review, and although everyone does their best, eventually everything still turns terrible.

In my various (small) projects, I have a lot of *single files* (i.e. most of them!) that really should have no cyclic dependencies. I feel like splitting them up into a dozen single-file lightweight-sbt-projects for enforcement/documentation of this fact isn't a good approach. 






--
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.

More topics »