Another Scala rant on HN

[martin odersky]

Seems hardly a weekend goes by these days without another Scala rant that makes the Hacker news frontpage. 

https://news.ycombinator.com/

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

[Xuefeng Wu]

It is a good news that a topic about Scala makes the Hacker news frontpage. 

It means much people know and care about Scala, even some of them said do not like it or that.

I'm working in the same company as the poster. 

These opinion are stand for some in company, but not most (maybe most of them are watching).

We also have many success Scala projects. 

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

--

~Yours, Xuefeng Wu/吴雪峰  敬上

[martin odersky]

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

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.

--

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

[martin odersky]

On Mon, Dec 2, 2013 at 11:13 AM, Xuefeng Wu <ben...@gmail.com> wrote:

It is a good news that a topic about Scala makes the Hacker news frontpage. 

It means much people know and care about Scala, even some of them said do not like it or that.

I'm working in the same company as the poster. 

These opinion are stand for some in company, but not most (maybe most of them are watching).

We also have many success Scala projects. 

Thanks for the heads up! It would be good to get testimonies like this as responses on the threads. I know that sometimes it's difficult to get permission to do this, but where you can, it would be real helpful.

Thanks!

 - Martin

--

[Mushtaq Ahmed]

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.

[Xuefeng Wu]

Actually, I do not think it's useful to responses. 

It's hard to change people's mind in short time. 

I did response, for people who wondering to know what's happening.

I remember people complain java running too slow as confirmed, even JDK 1.6  was released.

I thought they must read some old books about JDK 1.4, even earlier.

In my mind, Scala is really complex, but it's not Scala, but FP. 

FP concept is hard to master from an OO mindset.

The coursera lectures are really helpful me to understand FP, and Scala deeper.

[Erik Post]

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

[Simon Ochsenreither]

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.

[Simon Ochsenreither]

I think Andy is spot on. I have also mentioned it a few times in the past, but progress is pretty slow because everyone is busy with dozens of other important tasks.

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

[Grzegorz Kossakowski]

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

github: @gkossakowski

[Martin Grigorov]

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!

[Grzegorz Kossakowski]

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.

[atomly]

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.

[Lee Mighdoll]

I don't think we've done enough to define scala in the public mind, so there's a lot of room for each critic to redefine it.  I'd encourage a focus on clarifying the scala message(s) and getting the word out.  

Being at the center of the debate is a great thing.  Let's use that attention to spread the word and to build the tribe.

Cheers,

Lee 

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

[Vlad Patryshev]

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.

[Ken Scambler]

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

On Dec 3, 2013 3:09 AM, "Marius Danciu" <marius...@gmail.com> wrote:

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.

[martin odersky]

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

Cheers

 - Martin

 

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

--

[martin odersky]

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

 

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

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

[martin odersky]

On Mon, Dec 2, 2013 at 7:04 PM, Lee Mighdoll <l...@underneath.ca> wrote:

I don't think we've done enough to define scala in the public mind, so there's a lot of room for each critic to redefine it.  I'd encourage a focus on clarifying the scala message(s) and getting the word out.  

Being at the center of the debate is a great thing.  Let's use that attention to spread the word and to build the tribe.

Thanks for the advice, Lee! I agree wholeheartedly that's what we should do.

Cheers

 - Martin

[Alois Cochard]

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.

On Monday, 2 December 2013 22:25:36 UTC, Eric Harney wrote:

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.

[atomly]

On Mon, Dec 2, 2013 at 5:01 PM, martin odersky <martin....@epfl.ch> wrote:

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

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

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

[Simon Ochsenreither]

In case you are unfamiliar with the Code of Conduct, which covers these mailing lists, here is the link again: http://docs.scala-lang.org/conduct.html

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

[Jed Wesley-Smith]

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.

* http://www.meetup.com/scalasyd/

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

[Rich Oliver]

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?

[Scott Carey]

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.

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

No language is immune to people writing bad code, but Scala does allow many creative and unique ways to do so.  Static analysis tools akin to Java's FindBugs and/or CheckStyle that have strong community support would be great.  Important here is the output of such a tool, ability to browse the results in a GUI, consume them in another tool (e.g. Sonar), and integrate with build systems (e.g. fail a Pull-Request build if the result introduces a new violation of rule X).

[martin odersky]

On Tue, Dec 3, 2013 at 12:23 AM, Scott Carey <scott...@gmail.com> wrote:

What I see, trying to teach Scala to a medium sized team of Java developers (20) and learn more myself from some Scala and Functional Programming experts:

" we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this

        is no longer that much of an issue."

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

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

Cheers

 - Martin

[Simon Schäfer]

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

[Simon Ochsenreither]

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

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

[Simon Ochsenreither]

Even if it hard to accept, especially for educators like you Martin, I think the best thing is to not participate in such threads.

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

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

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

[Xuefeng Wu]

+1

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

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

 

Yours, Xuefeng Wu 吴雪峰 敬上

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

[Kostya Golikov]

Nope, it is Clojure as far as I can see from his github account. And nope, it is not a call for an arms and not invitation to discuss how Scala is superior to the Clojure or vise versa. Probably this is really a sign that some clojure guys just feel themselves uncomfortable looking at the rise of Scala, probably some people are out of sync with the current state of scala.

[atomly]

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

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

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

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

:: atomly ::

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

--

[Simon Ochsenreither]

I agree, but I'm wondering why the people who can't tell a def from a val are always those who encounter use-cases which require them to use dozens of different symbol-heavy APIs at the same time.

[Jon Pretty]

Hi Martin,

Here are a few specific points:

On Monday, 2 December 2013 09:32:15 UTC, Martin wrote:

     + we have fixed the IDEs (thank you IntelliJ and Eclipse teams!) so this

        is no longer that much of an issue.

I think the IDE support is vastly improved, but it will suffer from comparison to Java IDE support, and it's still playing catchup. I have actually discussed some particular pain-points in Eclipse with Iulian earlier today...
 

     + we are working on compile times and expect to have significant progress to announce for 2.11

Compilation times in Java (or interpreted languages) are small enough that they're irrelevant, so they're a new experience if you arrive at Scala from one of these languages. I think it's easy to overstate the significance of long compilation times, as "thinking time" will almost always dominate compiling time, but the compilation times are very obvious when they're new. I don't see any better way than deal with them than to keep nibbling away at them.
 

     + we should do something about operators. I like James Ward's idea to mandate an alphabetic alias for every operator - at least people would know how to pronounce them then.

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

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

I would prefer the pronunciation of a method name to be in the human-readable documentation.
 

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

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

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

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

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

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

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

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

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

Thanks,
Jon

[Vlad Patryshev]

Clojure deserves respect of course.

Thanks,
-Vlad

[Oleg Galako]

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.

[s...@sksamuel.com]

Just a quick response from me.

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

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

[Haoyi Li]

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

On Tue, Dec 3, 2013 at 6:55 AM, David Riccitelli <da...@insideout.io> wrote:

+1

► Helix Cloud online video platform ► WordLift semantic web for WordPress

► RedLink - making sense of your data ► US Export compliance extension for WooCommerce

══════════════════════════════════════════════

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

[martin odersky]

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.

--

[Jason Zaugg]

On Tue, Dec 3, 2013 at 9:24 AM, Haoyi Li <haoy...@gmail.com> wrote:

> 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

I like the idea to use the name as documentation rather than in code. Having multiple ways to do the same thing isn't desirable: it makes things hard to read ("are these actually the same?") and to write ("which one should I use?").

Scala's flexibility already has levied this cost.

  xs map f

  xs.map(f)

  xs.map { (x: Int) => x(f) }

  for(x <- xs) yield f(x)

  for(val x <- xs) yield f(x) // already deprecated

  for{x <- xs} yield f(x)

  def close(): Unit = {}

  def close {}  // this form will be deprecated

  List(1, 2, 3)

  1 :: 2 :: 3 :: Nil

  (xy: Tuple2[A, B]) => xy._1 + xy._2

  { case (x, y) => x + y }`

  // See PR #3202 for help for newcomers

  

  s"$a $b"

  a + " " + b

  %s %s".format(a, b)

Most of these little redundancies appear bad at first sight but then sort of melt away with a bit of practice, as there is often underlying principles that makes what seems like N variations (for a big N) fit neatly into a matrix J*K combinations of orthoganal variations (for small J and K). The "too many ways to write a lambda" criticism is a good example of this.

Some of them are pure redundancy, and we're working to deprecate them.

In other cases, tool support helps, for example better error messages from the compiler, or help from the IDEs (example: format and convert intentions in IntelliJ).

 

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!

I haven't seen that used much myself. I would recommend putting the println in a block in the RHS of the next generator.

for {

  x <- xs

  _ = println(x)

  y <- List(x, x)

} yield (x, y)

for {

  x <- xs

  y <- { println(x); List(x, x)}

} yield (x, y)

 

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

In early versions of Scala, this program would do as you suggested, and lift `println` into a `Function0`. It was a source of bugs, and ever since, eta expansion of methods must be triggered by `_` or by an expected type of `FunctionN`.

{

  System.out.println

  System.out.print("!!!")

}

 

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

The same argument as above applies: say you start out today with this code.

  def foo(a: Int): Unit = println("!")

  {foo(1); 0}

Then tomorrow, you refactor it to

  def foo(a: Int)(b: Int): Unit = println("!")

If you forget to change the caller, it will still still typecheck. These problems can show up quite easily in code that discards results (ie uses statements), and in a language like Scala that has a top type, Any.

 

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.

We need to get better at helping newcomers connect with the underlying rules, and seek to reduce (and not create any more!) gratuitous redundancy.

-jason

[Oleg Galako]

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

[Jason Zaugg]

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

[martin odersky]

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

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. 

https://news.ycombinator.com/

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.

[atomly]

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]

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. 

[Paul Phillips]

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

  https://issues.scala-lang.org/browse/SI-4506

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

                                                   ^

[Simon Ochsenreither]

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

[Rich Oliver]

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?

[Bill Venners]

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:

http://www.youtube.com/watch?v=Pqh_QFFzIlI&t=21m12s

Bill

[Simon Ochsenreither]

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.

[Rüdiger Klaehn]

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.

[Simon Ochsenreither]

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

[Naftoli Gugenheim]

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.

[Naftoli Gugenheim]

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?

On Wed, Dec 4, 2013 at 1: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. 

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.

[Rüdiger Klaehn]

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 .

[Rüdiger Klaehn]

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.

http://en.wikipedia.org/wiki/Frege_(programming_language)

 

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.

[Paul Phillips]

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.

[Rüdiger Klaehn]

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.

[Sébastien Doeraene]

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.

[Simon Ochsenreither]

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?

[Simon Ochsenreither]

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.

[martin odersky]

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

On Wed, Dec 4, 2013 at 8:30 PM, Cristian <cristian...@googlemail.com> 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.

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 ?

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

[Rüdiger Klaehn]

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.

https://github.com/scalaz/scalaz/search?q=with&type=Code

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

[Rex Kerr]

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

 

[Paul Phillips]

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.

[Jon Pretty]

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

[Jon Pretty]

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

[Jason Zaugg]

Scalaz 7 settled on using inheritance to model the hierarchy of type classes (e.g: trait Monoid[A] extends Semigroup[A]). We tried out a composition approach, but it was less appealing. Aside from the abstract methods that define the typeclasses, we also put a bunch of "derived" methods in there with implementation, and these are inherited down the line. That's not essential, but did help make things discoverable ("so, i've got a Cobind[W], now what can I do with it"), and also allowed instances of the typeclasses to override things for efficiency.

In parallel to this hierarchy, we've also got a hierarchy of, roughly speaking, implicit classes, that let you write `x.operation` rather than `TypeClass[X].operation(x)`. That's under scalaz.syntax._. That hierarchy also uses mixin inheritance to add progressively more operations as you walk down to more specific type classes. The entire `syntax` package is, however, just sugar, but it does let you express things in a left-to-right flow that maximises type inference. I think that's what Paul was referring to.

Finally, we also have a bunch of code that we package up in traits and mix together into modules, such as the enormous, old-school "über-importable" object Scalaz, but, since version 7, also into smaller, more focused modules.

-jason

[Rich Oliver]

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.

[Jon Pretty]

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

On 4 December 2013 21:57, Cristian <cristian...@googlemail.com> wrote:
>
> Thanks, but perhaps you'd like to share the gist of it on this thread ?
> Other people might want to know too..

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

[Jon Pretty]

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

[Simon Ochsenreither]

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.

[Simon Ochsenreither]

Hi Jon,

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

Bye,

Simon

[Haoyi Li]

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

On Thu, Dec 5, 2013 at 4:15 AM, Alan Johnson <lla...@gmail.com> wrote:

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.

[Scott Carey]

I've never been a fan of the "is-a" versus "has-a" distinction.   Most "is-a" can be transformed to "has-a" anyway -- sometimes only with significant effort.     When thinking about inheritance versus composition, I follow a simple observation (although Scala's Traits make this  more complicated than single-inheritance languages like Java):
Inheritance can only reasonably abstract over one degree of freedom at a time.  Composition has no bounds.
TShirt
LTShirt, MTShirt, STShirt    -- abstract over sizes.  We could (perhaps should) use composition instead  ("has-a"  Size).  But if this is your entire universe of TShirt, and the subtypes are not publicly visible no harm is done.
However, add in one other dimension -- perhaps color -- and we would need (sizes x colors) subtypes, e.g. LRedTShirt.   Yuck.    Much better off with sizes + colors independent types and composition.   However, in real world problems there is often one major or fundamental dimension where inheritance beats composition even though they can be substituted for one another.

I generally measure abuse of inheritance in terms of the observation above.  How many degrees of freedom are being simultaneously refined in a subtree of types?

Scala gives you better tools (traits) to avoid some of the combinatorial pitfalls like LargeRedTShirt, but traits can be abused and do not necessarily fix the other drawbacks of abstracting over too many things at once in your type signature.
 
 

[Jon Pretty]

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

[Jon Pretty]

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

[Jason Zaugg]

On Thu, Dec 5, 2013 at 8:31 AM, Jon Pretty <googl...@accounts.propensive.com> 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.

It does have an impact on binding precedence (although we think the spec and implementation differ on exactly what that is.)

-jason

[Haoyi Li]

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

[Jon Pretty]

On Thursday, 5 December 2013 07:40:38 UTC, Jason Zaugg wrote:

It does have an impact on binding precedence (although we think the spec and implementation differ on exactly what that is.)

Ah, of course! Subtle ;)

Cheers,
Jon

[Jon Pretty]

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

[Jon Pretty]

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

[Kevin Wright]

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)

[Jon Pretty]

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

 

[Matthew Pocock]

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

On 5 December 2013 12:27, Cristian <cristian...@googlemail.com> wrote:

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. 

 

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

mailto: turingate...@gmail.com

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: matthew...@ncl.ac.uk

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Rex Kerr]

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

 

[Matthew Pocock]

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

[Jon Pretty]

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

[Jon Pretty]

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

[Simon Ochsenreither]

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?

[Matthew Pocock]

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

[Jon Pretty]

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

[Matthew Pocock]

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.

[Paul Phillips]

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

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

[Naftoli Gugenheim]

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

[Naftoli Gugenheim]

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

[Naftoli Gugenheim]

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

[Naftoli Gugenheim]

Not so different. Remember how for comprehension desugar.

--

[Naftoli Gugenheim]

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
>

[Aleh Aleshka]

     + 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