This page is no longer maintained — Please continue to the home page at www.scala-lang.org

problems of scala complexity

101 replies
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: problems of scala complexity


On Sun, Nov 20, 2011 at 9:15 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

>
> - Akka has culled its symbols down to essentially just ! and ?

Worth noting there is that both those methods have a nominal alternative (tell/ask)


As someone who has used (and written :-( ) APIs that attempt to satisfy everyone by providing multiple symbols for the same operation, I disagree rather strongly with this approach. IMHO, Akka should have gone with "tell" and "show".

What language/framework has previously used "show" for Future-based message asynchronous message exchange?
 
Alternatively, if they had gone with "!" and "?", I would have been less happy, but would not consider it a significant problem since these symbols will be omnipresent in Akka-based code, so the the cost of learning them is very low compared to their utility.

You're missing a huge point here. We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka, this means providing method names that make sense in a wider spectrum than just Scala. But because of the niceties of Scala, we are able to offer ! and ? as a complement (that I'd say most people in Scala chooses to use)
 

But providing both unnecessarily increases the amount of info a programmer must know, and more importantly, raises that prospect that a programmer who has used Akka in a "consistent" environment might encounter the other usage occasionally and be temporarily stymied by it.

Why would he? The semantics is exactly the same. When he talks to his fellow programmers he can use "tell" consistently "$bang" and "$qmark" are less useful when speaking to your coworkers.
 

It's not a huge issue, this is not horrible design. But I thing in the net, it's negative.

I'd say the hAkkers beg to differ.


Cheers,

 


Ken



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: problems of scala complexity


On Sun, Nov 20, 2011 at 9:15 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

>
> - Akka has culled its symbols down to essentially just ! and ?

Worth noting there is that both those methods have a nominal alternative (tell/ask)


As someone who has used (and written :-( ) APIs that attempt to satisfy everyone by providing multiple symbols for the same operation, I disagree rather strongly with this approach. IMHO, Akka should have gone with "tell" and "show".

What language/framework has previously used "show" for Future-based message asynchronous message exchange?
 
Alternatively, if they had gone with "!" and "?", I would have been less happy, but would not consider it a significant problem since these symbols will be omnipresent in Akka-based code, so the the cost of learning them is very low compared to their utility.

You're missing a huge point here. We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka, this means providing method names that make sense in a wider spectrum than just Scala. But because of the niceties of Scala, we are able to offer ! and ? as a complement (that I'd say most people in Scala chooses to use)
 

But providing both unnecessarily increases the amount of info a programmer must know, and more importantly, raises that prospect that a programmer who has used Akka in a "consistent" environment might encounter the other usage occasionally and be temporarily stymied by it.

Why would he? The semantics is exactly the same. When he talks to his fellow programmers he can use "tell" consistently "$bang" and "$qmark" are less useful when speaking to your coworkers.
 

It's not a huge issue, this is not horrible design. But I thing in the net, it's negative.

I'd say the hAkkers beg to differ.


Cheers,

 


Ken



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Arif Mustafa
Joined: 2011-11-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity
brilliant points..... "We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka..." and this precisely should be the attitude for Scala, i.e "We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Scala" ... 
cheers
Arif

2011/11/20 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>


On Sun, Nov 20, 2011 at 9:15 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

>
> - Akka has culled its symbols down to essentially just ! and ?

Worth noting there is that both those methods have a nominal alternative (tell/ask)


As someone who has used (and written :-( ) APIs that attempt to satisfy everyone by providing multiple symbols for the same operation, I disagree rather strongly with this approach. IMHO, Akka should have gone with "tell" and "show".

What language/framework has previously used "show" for Future-based message asynchronous message exchange?
 
Alternatively, if they had gone with "!" and "?", I would have been less happy, but would not consider it a significant problem since these symbols will be omnipresent in Akka-based code, so the the cost of learning them is very low compared to their utility.

You're missing a huge point here. We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka, this means providing method names that make sense in a wider spectrum than just Scala. But because of the niceties of Scala, we are able to offer ! and ? as a complement (that I'd say most people in Scala chooses to use)
 

But providing both unnecessarily increases the amount of info a programmer must know, and more importantly, raises that prospect that a programmer who has used Akka in a "consistent" environment might encounter the other usage occasionally and be temporarily stymied by it.

Why would he? The semantics is exactly the same. When he talks to his fellow programmers he can use "tell" consistently "$bang" and "$qmark" are less useful when speaking to your coworkers.
 

It's not a huge issue, this is not horrible design. But I thing in the net, it's negative.

I'd say the hAkkers beg to differ.


Cheers,

 


Ken



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity


On 2011-11-20 12:47 AM, Jesper Nordenberg wrote:
4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">Eric Kolotyluk skrev 2011-11-20 04:16:
However, as far as I am concerned C++ is now a dead language.

Well, the rest of the world don't agree with you.

I am not asking anyone to agree with me - this is solely my concern.

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">C++ is still a commonly used language, and yet to be replaced in many areas. And with C++11 coming around it's still evolving and improving.

I was in car accident once, and the insurance adjuster said "we could pay to have the car fixed, but frankly it will never be the same again and it won't be safe either, I recommend you take the payout and get a new car." I don't mean to insult anyone, but good luck with fixing C++

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">
I'm not saying C++ is a nice language to work with, far from it, but it gets the job done.

And that it totally fine with people who are OK with that. I would not advocate stopping maintenance of our C++ code and applications where I work as there is established investment there - I would just advocate not starting any new projects in C++.

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">
My point is, I do not want to see Scala end up where C++ is now - the
mess that it is. At the time C++ was the state of the art and I even
passionately advocated it for a while. What I truly hope for is that the
Scala community learn from the mistakes that were made with C++ and try
to avoid them. Many of the mistakes that were made with C++ were not
even the language design per se, rather they were the immaturity of the
culture and community that was using and then abusing C++.

Hmmm, kinda hard to control the entire community.

I am not trying to control the entire community, only influence my immediate team and others in my organization who depend on me advocating things responsibly.

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">I mean you can decide what to put in the stdlib (and now the Typesafe stack), but you can't control what developers will use your language for (and that's a good thing IMO).

I cannot always control what the developers on my team do, but I have a fair amount of influence and a commitment to use it wisely.

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">If there is a language feature to use/abuse, developers will do so.

Which is why I am advocating tools we can use in the IDE and continuous integration systems that perform tests, so that people can hopefully realize when something is being abused and decide what action to take.

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">
Btw, what mistakes in the C++ world are you referring to?

And this is purely my opinion, I respect people's opinion who may disagree:

1) the << and >> I/O operators. At first I was amused and found them clever, but over time I found them annoying leading to unreadable code.

2) the over abundance of features which all too frequently required me to have to keep pulling my C++ reference off the shelf to figure out how to do something or what some fragment of code meant that someone else wrote.

3) The culture and mindset that lead to ATL and COM. Sure, you can't blame all that on C++ but I do see ATL and COM as being derived from the mindset that any amount of complexity can be managed.

4) The insanity of layers of header files, macros, and conditional compilation, as well as machine, architecture and O/S specific code to support a so called 'portable' solution.

I could go on, but those are just some eclectic examples.

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">
I feel this argument is reasonable as there are people with valid
concerns about the complexity of Scala and it serves us all well to
address those concerns constructively rather than dismiss or invalidate
them. It may seem to you that some of us are catastrophizing C++, but to
me C++ is a very real catastrophe of what happens when we ignore these
very issues.

I don't see C++ as a catastrophe, it's a result of compromises (for example C compatibility), some good ideas (for example generic programming) and some bad ones (for example templates).

I am not asking other to see C++ as a catastrophe, hopefully the things I am advocating for Scala I can argue without people sharing the same background beliefs as me.

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">Scala is quite similar, but with less bad ideas :)

I totally agree and I am trying to advocate keeping Scala "with less bad ideas" :-)

Those who cannot remember the past are condemned to repeat it. - George Santayana

Cheers, Eric

4EC8BE94 [dot] 2020205 [at] yahoo [dot] com" type="cite">
/Jesper Nordenberg
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: problems of scala complexity


2011/11/20 Arif Mustafa <arifmustafak [at] gmail [dot] com>
brilliant points..... "We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka..." and this precisely should be the attitude for Scala, i.e "We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Scala" ... 

But there's a huge difference between a library and a language.

Cheers,

 

cheers
Arif

2011/11/20 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>


On Sun, Nov 20, 2011 at 9:15 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

>
> - Akka has culled its symbols down to essentially just ! and ?

Worth noting there is that both those methods have a nominal alternative (tell/ask)


As someone who has used (and written :-( ) APIs that attempt to satisfy everyone by providing multiple symbols for the same operation, I disagree rather strongly with this approach. IMHO, Akka should have gone with "tell" and "show".

What language/framework has previously used "show" for Future-based message asynchronous message exchange?
 
Alternatively, if they had gone with "!" and "?", I would have been less happy, but would not consider it a significant problem since these symbols will be omnipresent in Akka-based code, so the the cost of learning them is very low compared to their utility.

You're missing a huge point here. We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka, this means providing method names that make sense in a wider spectrum than just Scala. But because of the niceties of Scala, we are able to offer ! and ? as a complement (that I'd say most people in Scala chooses to use)
 

But providing both unnecessarily increases the amount of info a programmer must know, and more importantly, raises that prospect that a programmer who has used Akka in a "consistent" environment might encounter the other usage occasionally and be temporarily stymied by it.

Why would he? The semantics is exactly the same. When he talks to his fellow programmers he can use "tell" consistently "$bang" and "$qmark" are less useful when speaking to your coworkers.
 

It's not a huge issue, this is not horrible design. But I thing in the net, it's negative.

I'd say the hAkkers beg to differ.


Cheers,

 


Ken



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang




--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: problems of scala complexity


2011/11/20 Arif Mustafa <arifmustafak [at] gmail [dot] com>
brilliant points..... "We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka..." and this precisely should be the attitude for Scala, i.e "We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Scala" ... 

But there's a huge difference between a library and a language.

Cheers,

 

cheers
Arif

2011/11/20 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>


On Sun, Nov 20, 2011 at 9:15 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

>
> - Akka has culled its symbols down to essentially just ! and ?

Worth noting there is that both those methods have a nominal alternative (tell/ask)


As someone who has used (and written :-( ) APIs that attempt to satisfy everyone by providing multiple symbols for the same operation, I disagree rather strongly with this approach. IMHO, Akka should have gone with "tell" and "show".

What language/framework has previously used "show" for Future-based message asynchronous message exchange?
 
Alternatively, if they had gone with "!" and "?", I would have been less happy, but would not consider it a significant problem since these symbols will be omnipresent in Akka-based code, so the the cost of learning them is very low compared to their utility.

You're missing a huge point here. We want people using Java, Groovy, Clojure, JRuby et al, to be able to use Akka, this means providing method names that make sense in a wider spectrum than just Scala. But because of the niceties of Scala, we are able to offer ! and ? as a complement (that I'd say most people in Scala chooses to use)
 

But providing both unnecessarily increases the amount of info a programmer must know, and more importantly, raises that prospect that a programmer who has used Akka in a "consistent" environment might encounter the other usage occasionally and be temporarily stymied by it.

Why would he? The semantics is exactly the same. When he talks to his fellow programmers he can use "tell" consistently "$bang" and "$qmark" are less useful when speaking to your coworkers.
 

It's not a huge issue, this is not horrible design. But I thing in the net, it's negative.

I'd say the hAkkers beg to differ.


Cheers,

 


Ken



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang




--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Re: problems of scala complexity


On Sun, Nov 20, 2011 at 12:15 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

>
> - Akka has culled its symbols down to essentially just ! and ?

Worth noting there is that both those methods have a nominal alternative (tell/ask)


As someone who has used (and written :-( ) APIs that attempt to satisfy everyone by providing multiple symbols for the same operation, I disagree rather strongly with this approach. IMHO, Akka should have gone with "tell" and "show". Alternatively, if they had gone with "!" and "?", I would have been less happy, but would not consider it a significant problem since these symbols will be omnipresent in Akka-based code, so the the cost of learning them is very low compared to their utility.
But providing both unnecessarily increases the amount of info a programmer must know, and more importantly, raises that prospect that a programmer who has used Akka in a "consistent" environment might encounter the other usage occasionally and be temporarily stymied by it.
It's not a huge issue, this is not horrible design. But I thing in the net, it's negative.

I disagree. I consider "tell" preferable to "!" because it is meaningful yet succinct. I don't mind having "!" available for those who prefer cryptic-looking code, but I will not use it myself unless perhaps I am trying to squeeze a statement onto a single line.

Similarly, I have defined my own "not" function:

    def not(b: Boolean) = ! b

For me it's just a matter of basic aesthetics. Also, the mandatory parentheses actually help by eliminating any trace of uncertainty about operator precedence. I think this definition should be put into Predef.

--Russ P.

--
http://RussP.us
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Re: problems of scala complexity


On Sun, Nov 20, 2011 at 12:15 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

>
> - Akka has culled its symbols down to essentially just ! and ?

Worth noting there is that both those methods have a nominal alternative (tell/ask)


As someone who has used (and written :-( ) APIs that attempt to satisfy everyone by providing multiple symbols for the same operation, I disagree rather strongly with this approach. IMHO, Akka should have gone with "tell" and "show". Alternatively, if they had gone with "!" and "?", I would have been less happy, but would not consider it a significant problem since these symbols will be omnipresent in Akka-based code, so the the cost of learning them is very low compared to their utility.
But providing both unnecessarily increases the amount of info a programmer must know, and more importantly, raises that prospect that a programmer who has used Akka in a "consistent" environment might encounter the other usage occasionally and be temporarily stymied by it.
It's not a huge issue, this is not horrible design. But I thing in the net, it's negative.

I disagree. I consider "tell" preferable to "!" because it is meaningful yet succinct. I don't mind having "!" available for those who prefer cryptic-looking code, but I will not use it myself unless perhaps I am trying to squeeze a statement onto a single line.

Similarly, I have defined my own "not" function:

    def not(b: Boolean) = ! b

For me it's just a matter of basic aesthetics. Also, the mandatory parentheses actually help by eliminating any trace of uncertainty about operator precedence. I think this definition should be put into Predef.

--Russ P.

--
http://RussP.us
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity
On 2011-11-20 2:20 AM, martin odersky wrote:
CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">

On Sun, Nov 20, 2011 at 5:55 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-19 6:31 AM, martin odersky wrote:
Some remarks:

First, the thread and many like it seems too negatve to me. Scala is used in a large and growing number of enterprises, some of them with more than 100 devs working with it. These people just get on with the job (and love it for the most part); they don't find Scala's ``complexity'' too daunting.

You are very correct Martin, there have been many threads that negatively criticize the complexity of Scala - and many have been unproductive or counterproductive.

Sorry to read you see this thread as negative - I do not see it that way at all. You are absolutely correct that many people are happy with Scala just the way it is. What I believe this thread is attempting to do is to constructively satisfy those people who do find Scala too daunting and offer solutions to make it less daunting for them.

I am absolutely for discussing the best way to make Scala more approachable for newcomers and large teams.  I just wanted to stress that we should not start with a too negative point of view of the status quo. Scala is already making nice progress among these groups. But of course we should search ways to help it further along.

In that we are in total agreement. To avoid distracting narratives perhaps we should strive to make the distinction more clear that we are not 'bashing' Scala or Scala experts, but trying to make Scala more approachable :-)

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">
Second, I believe we have come to realize that complexity and power are pretty much aligned for Scala.
Take away the complexity and you take away the power. Here I mean power in the sense: "Number of concepts that you can describe precisely using your language". I want to get away from the common argument that all Turing complete languages are equivalent in power anyway.

One good step I have seen lately is moving the narrative away from trying to reduce or take away the complexity of Scala or any of its power. I really like the idea of tools to help us best use the language. In the early days of C the compiler diagnostics were a joke, but someone wrote lint and it helped many people make better use of C. These days I am truly amazed at the quality of the diagnostics of the Java compilers and the IDEs - these automated tools make Java even more accessible to more programmers, and even less complex. I am often amazed at how well Eclipse can guide me into proper use of Java or best practices.

If there are people who are smart enough to invent languages like Scala - there are surely people smart enough to imagine, design and build tools to make Scala more accessible to more people. If you are smart enough and experienced enough to ride Scala 'bareback' so to speak, more power to you, but it does not mean we cannot also invest in better saddles and stirrups for the rest of us.
On the small scale, I believe you are right. I am pretty confident these tools will come for Scala. But on the large scale, I do not see tools criticizing systems architecture just yet.

You are right. It is not clear how far we can go with 'critical thinking' tools without resorting to Artificial Intelligence, Expert Systems or Intelligent Systems - but it may still be a useful point on the horizon to set sail for.

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">


Third, if you look at other languages, there is always a set of "best practices" developed that come with it and that are used as guidelines. Certainly Java has a rich culture of best practices. And that cultures changes over time, as developments in Java EE show.

No disagreement here.


Since Scala's enterprise use is still young, best practices have still a some way to develop and stabilize.

Truly. As we go along can we not find some way to automate the support of those best practices?
Yes, but that's a second step. We need to develop them first!

Totally agree.

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">

This is your chance! If you put out some clean libraries with easy-to use APIs you have a great chance to influence the future best practices for Scala, as long as they are still in flux. I wish we'd concentrate more on these aspects than wringing our hands.

Clean libraries and APIs alone do not solve the problems.

No, but they are important. Not so much from the user perspective but  to set an example to others how code and APIs should be structured and formulated. For instance, you know one thing I have come to regret? That's having put /: and :\ as aliases for foldLeft and foldRight into collections. I thought I had good reasons to do so. In particular
  (zero /: xs) (op)
keeps the relative order of the zero and the list xs in the expansion of the fold:
  zero op x_1... op x_n 
Whereas 
  xs.foldLeft(zero)(op)
reverses them. And, if we talk just about this library, I still think these reasons are valid. But as an example for other libraries it was the wrong choice. It gave an implicit encouragement to use symbolic operators in libraries where they are not necessary. And, I think the current set of core libraries uses too many symbolic operators (and, to be clear, I am not talking about scalaz here, that's on a different planet altogether).

Yes, clean libraries and APIs can be enormously important. When I read Scala code I do not want to have to think in terms of APL ;-)

My rule of thumb is: Phrases are always betters than words, words are always better than acronyms (or Hungarian notation), and acronyms are always better than symbols. There are of course exceptions which is the point of a 'rule of thumb.'

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">  
Also, I do not see us wringing our hands any longer, I think this thread is actually going somewhere productive and should be encouraged.
That's great!

Should we maintain this thread, or find a more representative title of goals to make Scala more accessible and supported by the increasing evolution conventions and best practices, library and API design, and automated tools for critical review of code quality? Should we have a separate discussion representative of what problems to solve to make Scala more accessible? At what point can move from narratives and debate, for some issues, and maybe inventory them in a wiki or some other place when there is sufficient consensus?

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">


Can best practices be influenced by tools, such as style checkers? Maybe. It's certainly something we want to pursue. But it would be silly to delegate responsibility for forming best practices to these tools only.

I totally agree. Airbus tried to over automate the cockpit and the result was the autopilot overrode the real pilots and landed the aircraft in a forest at an airshow. These days there is a lot of effort to further automate things in the cockpit, but it is generally accepted now that the human pilot is ultimately in charge. Rather than making human pilots redundant, we try to make them better pilots.

I am advocating giving the software developers, senior software developers and software architects the tools to monitor and assess the code quality and complexity, and maybe event suggest better ways to do things. I have found findbugs exceedingly useful on many occasions and have even used it to analyze our code base and report back to our team my concerns about some of the dicey practices I found in the code base.

Let's not limit Scala's power and promise by restricting features - rather let's build tools to help us make better use of Scala.

+100 here.

:-))

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">
Cheers
 -- Martin
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity
On 2011-11-20 2:20 AM, martin odersky wrote:
CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">

On Sun, Nov 20, 2011 at 5:55 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-19 6:31 AM, martin odersky wrote:
Some remarks:

First, the thread and many like it seems too negatve to me. Scala is used in a large and growing number of enterprises, some of them with more than 100 devs working with it. These people just get on with the job (and love it for the most part); they don't find Scala's ``complexity'' too daunting.

You are very correct Martin, there have been many threads that negatively criticize the complexity of Scala - and many have been unproductive or counterproductive.

Sorry to read you see this thread as negative - I do not see it that way at all. You are absolutely correct that many people are happy with Scala just the way it is. What I believe this thread is attempting to do is to constructively satisfy those people who do find Scala too daunting and offer solutions to make it less daunting for them.

I am absolutely for discussing the best way to make Scala more approachable for newcomers and large teams.  I just wanted to stress that we should not start with a too negative point of view of the status quo. Scala is already making nice progress among these groups. But of course we should search ways to help it further along.

In that we are in total agreement. To avoid distracting narratives perhaps we should strive to make the distinction more clear that we are not 'bashing' Scala or Scala experts, but trying to make Scala more approachable :-)

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">
Second, I believe we have come to realize that complexity and power are pretty much aligned for Scala.
Take away the complexity and you take away the power. Here I mean power in the sense: "Number of concepts that you can describe precisely using your language". I want to get away from the common argument that all Turing complete languages are equivalent in power anyway.

One good step I have seen lately is moving the narrative away from trying to reduce or take away the complexity of Scala or any of its power. I really like the idea of tools to help us best use the language. In the early days of C the compiler diagnostics were a joke, but someone wrote lint and it helped many people make better use of C. These days I am truly amazed at the quality of the diagnostics of the Java compilers and the IDEs - these automated tools make Java even more accessible to more programmers, and even less complex. I am often amazed at how well Eclipse can guide me into proper use of Java or best practices.

If there are people who are smart enough to invent languages like Scala - there are surely people smart enough to imagine, design and build tools to make Scala more accessible to more people. If you are smart enough and experienced enough to ride Scala 'bareback' so to speak, more power to you, but it does not mean we cannot also invest in better saddles and stirrups for the rest of us.
On the small scale, I believe you are right. I am pretty confident these tools will come for Scala. But on the large scale, I do not see tools criticizing systems architecture just yet.

You are right. It is not clear how far we can go with 'critical thinking' tools without resorting to Artificial Intelligence, Expert Systems or Intelligent Systems - but it may still be a useful point on the horizon to set sail for.

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">


Third, if you look at other languages, there is always a set of "best practices" developed that come with it and that are used as guidelines. Certainly Java has a rich culture of best practices. And that cultures changes over time, as developments in Java EE show.

No disagreement here.


Since Scala's enterprise use is still young, best practices have still a some way to develop and stabilize.

Truly. As we go along can we not find some way to automate the support of those best practices?
Yes, but that's a second step. We need to develop them first!

Totally agree.

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">

This is your chance! If you put out some clean libraries with easy-to use APIs you have a great chance to influence the future best practices for Scala, as long as they are still in flux. I wish we'd concentrate more on these aspects than wringing our hands.

Clean libraries and APIs alone do not solve the problems.

No, but they are important. Not so much from the user perspective but  to set an example to others how code and APIs should be structured and formulated. For instance, you know one thing I have come to regret? That's having put /: and :\ as aliases for foldLeft and foldRight into collections. I thought I had good reasons to do so. In particular
  (zero /: xs) (op)
keeps the relative order of the zero and the list xs in the expansion of the fold:
  zero op x_1... op x_n 
Whereas 
  xs.foldLeft(zero)(op)
reverses them. And, if we talk just about this library, I still think these reasons are valid. But as an example for other libraries it was the wrong choice. It gave an implicit encouragement to use symbolic operators in libraries where they are not necessary. And, I think the current set of core libraries uses too many symbolic operators (and, to be clear, I am not talking about scalaz here, that's on a different planet altogether).

Yes, clean libraries and APIs can be enormously important. When I read Scala code I do not want to have to think in terms of APL ;-)

My rule of thumb is: Phrases are always betters than words, words are always better than acronyms (or Hungarian notation), and acronyms are always better than symbols. There are of course exceptions which is the point of a 'rule of thumb.'

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">  
Also, I do not see us wringing our hands any longer, I think this thread is actually going somewhere productive and should be encouraged.
That's great!

Should we maintain this thread, or find a more representative title of goals to make Scala more accessible and supported by the increasing evolution conventions and best practices, library and API design, and automated tools for critical review of code quality? Should we have a separate discussion representative of what problems to solve to make Scala more accessible? At what point can move from narratives and debate, for some issues, and maybe inventory them in a wiki or some other place when there is sufficient consensus?

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">


Can best practices be influenced by tools, such as style checkers? Maybe. It's certainly something we want to pursue. But it would be silly to delegate responsibility for forming best practices to these tools only.

I totally agree. Airbus tried to over automate the cockpit and the result was the autopilot overrode the real pilots and landed the aircraft in a forest at an airshow. These days there is a lot of effort to further automate things in the cockpit, but it is generally accepted now that the human pilot is ultimately in charge. Rather than making human pilots redundant, we try to make them better pilots.

I am advocating giving the software developers, senior software developers and software architects the tools to monitor and assess the code quality and complexity, and maybe event suggest better ways to do things. I have found findbugs exceedingly useful on many occasions and have even used it to analyze our code base and report back to our team my concerns about some of the dicey practices I found in the code base.

Let's not limit Scala's power and promise by restricting features - rather let's build tools to help us make better use of Scala.

+100 here.

:-))

CAENVNkYPH1mF8cKmm7V83EuiXMMHfV_x8vdfsjnwg+Xs79HXNw [at] mail [dot] gmail [dot] com" type="cite">
Cheers
 -- Martin
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity

While I initially bought into that idea, I now agree that would be more
complex.

I think we just need better ideas on how to make Scala more attractive
and accessible to people who fear the complexity of Scala, rather than
persuade them Scala is not too complex or otherwise invalidate their fears.

On 2011-11-20 10:04 AM, Runar Bjarnason wrote:
> "I seem to recall recently someone suggested some sort of switches to
> control which language features could be enabled."
>
> That sounds pretty complex.
>

Arif Mustafa
Joined: 2011-11-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity
" But there's a huge difference between a library and a language."
may be I am not as smart as you are...but I do understand that there is a huge difference between a library and a language .... there is certain level of arrogance in Scala community, that is beyond me.... my comments were strictly with respect to the kind of attitude that we should have ...and they were not against Scala.  I totally agree with @Russ
cheers
Arif

On Sun, Nov 20, 2011 at 4:44 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-20 2:20 AM, martin odersky wrote:


On Sun, Nov 20, 2011 at 5:55 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-19 6:31 AM, martin odersky wrote:
Some remarks:

First, the thread and many like it seems too negatve to me. Scala is used in a large and growing number of enterprises, some of them with more than 100 devs working with it. These people just get on with the job (and love it for the most part); they don't find Scala's ``complexity'' too daunting.

You are very correct Martin, there have been many threads that negatively criticize the complexity of Scala - and many have been unproductive or counterproductive.

Sorry to read you see this thread as negative - I do not see it that way at all. You are absolutely correct that many people are happy with Scala just the way it is. What I believe this thread is attempting to do is to constructively satisfy those people who do find Scala too daunting and offer solutions to make it less daunting for them.

I am absolutely for discussing the best way to make Scala more approachable for newcomers and large teams.  I just wanted to stress that we should not start with a too negative point of view of the status quo. Scala is already making nice progress among these groups. But of course we should search ways to help it further along.

In that we are in total agreement. To avoid distracting narratives perhaps we should strive to make the distinction more clear that we are not 'bashing' Scala or Scala experts, but trying to make Scala more approachable :-)


Second, I believe we have come to realize that complexity and power are pretty much aligned for Scala.
Take away the complexity and you take away the power. Here I mean power in the sense: "Number of concepts that you can describe precisely using your language". I want to get away from the common argument that all Turing complete languages are equivalent in power anyway.

One good step I have seen lately is moving the narrative away from trying to reduce or take away the complexity of Scala or any of its power. I really like the idea of tools to help us best use the language. In the early days of C the compiler diagnostics were a joke, but someone wrote lint and it helped many people make better use of C. These days I am truly amazed at the quality of the diagnostics of the Java compilers and the IDEs - these automated tools make Java even more accessible to more programmers, and even less complex. I am often amazed at how well Eclipse can guide me into proper use of Java or best practices.

If there are people who are smart enough to invent languages like Scala - there are surely people smart enough to imagine, design and build tools to make Scala more accessible to more people. If you are smart enough and experienced enough to ride Scala 'bareback' so to speak, more power to you, but it does not mean we cannot also invest in better saddles and stirrups for the rest of us.
On the small scale, I believe you are right. I am pretty confident these tools will come for Scala. But on the large scale, I do not see tools criticizing systems architecture just yet.

You are right. It is not clear how far we can go with 'critical thinking' tools without resorting to Artificial Intelligence, Expert Systems or Intelligent Systems - but it may still be a useful point on the horizon to set sail for.



Third, if you look at other languages, there is always a set of "best practices" developed that come with it and that are used as guidelines. Certainly Java has a rich culture of best practices. And that cultures changes over time, as developments in Java EE show.

No disagreement here.


Since Scala's enterprise use is still young, best practices have still a some way to develop and stabilize.

Truly. As we go along can we not find some way to automate the support of those best practices?
Yes, but that's a second step. We need to develop them first!

Totally agree.



This is your chance! If you put out some clean libraries with easy-to use APIs you have a great chance to influence the future best practices for Scala, as long as they are still in flux. I wish we'd concentrate more on these aspects than wringing our hands.

Clean libraries and APIs alone do not solve the problems.

No, but they are important. Not so much from the user perspective but  to set an example to others how code and APIs should be structured and formulated. For instance, you know one thing I have come to regret? That's having put /: and :\ as aliases for foldLeft and foldRight into collections. I thought I had good reasons to do so. In particular
  (zero /: xs) (op)
keeps the relative order of the zero and the list xs in the expansion of the fold:
  zero op x_1... op x_n 
Whereas 
  xs.foldLeft(zero)(op)
reverses them. And, if we talk just about this library, I still think these reasons are valid. But as an example for other libraries it was the wrong choice. It gave an implicit encouragement to use symbolic operators in libraries where they are not necessary. And, I think the current set of core libraries uses too many symbolic operators (and, to be clear, I am not talking about scalaz here, that's on a different planet altogether).

Yes, clean libraries and APIs can be enormously important. When I read Scala code I do not want to have to think in terms of APL ;-)

My rule of thumb is: Phrases are always betters than words, words are always better than acronyms (or Hungarian notation), and acronyms are always better than symbols. There are of course exceptions which is the point of a 'rule of thumb.'

 
Also, I do not see us wringing our hands any longer, I think this thread is actually going somewhere productive and should be encouraged.
That's great!

Should we maintain this thread, or find a more representative title of goals to make Scala more accessible and supported by the increasing evolution conventions and best practices, library and API design, and automated tools for critical review of code quality? Should we have a separate discussion representative of what problems to solve to make Scala more accessible? At what point can move from narratives and debate, for some issues, and maybe inventory them in a wiki or some other place when there is sufficient consensus?




Can best practices be influenced by tools, such as style checkers? Maybe. It's certainly something we want to pursue. But it would be silly to delegate responsibility for forming best practices to these tools only.

I totally agree. Airbus tried to over automate the cockpit and the result was the autopilot overrode the real pilots and landed the aircraft in a forest at an airshow. These days there is a lot of effort to further automate things in the cockpit, but it is generally accepted now that the human pilot is ultimately in charge. Rather than making human pilots redundant, we try to make them better pilots.

I am advocating giving the software developers, senior software developers and software architects the tools to monitor and assess the code quality and complexity, and maybe event suggest better ways to do things. I have found findbugs exceedingly useful on many occasions and have even used it to analyze our code base and report back to our team my concerns about some of the dicey practices I found in the code base.

Let's not limit Scala's power and promise by restricting features - rather let's build tools to help us make better use of Scala.

+100 here.

:-))


Cheers
 -- Martin

Bill Venners
Joined: 2008-12-18,
User offline. Last seen 31 weeks 5 days ago.
Re: problems of scala complexity

Hi Kevin,

I just noticed this thread.

On Nov 20, 5:55 am, Kevin Wright wrote:
> Oh absolutely!  It also doesn't help that many of our current "high
> profile" libraries are particularly heavy on symbolic method names.  Things
> are improving in at least two notable libraries though:
>
> - Akka has culled its symbols down to essentially just ! and ?
> - scalaz is near the end of a rewrite that will make it far easier to use
> non-symbolic equivalents for many concepts
>
Hey, you forgot ScalaTest, which I would point out was designed with
the philosophy of: *avoid any operators that users are not already
experts in.* So ScalaTest originally just had ===, which means
equality, < for less than, > for greater than, <= for less than or
equals, and >= for greater than or equals. At some point I did add one
non-obvious operator, the - in FreeSpec, because after much searching
for a way to avoid it, it was the best solution. In 2.1, which is
coming next year, I'll be adding a few more operators. One is +/- as
an alias for plusOrMinus. This one has been requested by multiple
users over time, and I've done several informal surveys asking people
if they can guess its meaning, and people always have. So I decided to
add that one. I'm also adding &&, ||, and ! for boolean-like
expressions with the triple equals operator, and they will mean
exactly what they look like they mean. Lots of new features are
coming, but no other operators than these few that pass the "obvious
test."

I have been bummed that so many non-obvious operators have been
showing up in Scala APIs. The trouble is that although obvious
operators makes code easier to read (a + b is nicer than a add b), non-
obvious operators makes code harder for casual users to understand,
because they have to look up what all the meanings are. And a lot of
users are casual, in that they don't use your library often enough to
remember the symbols for whatever reason. And to Java programmers, at
least, it makes Scala code look cryptic.

Moreover I would claim that 99% of the time, if you work at it, you
can find a better alternative to a non-obvious operator. Compare Specs
tables to ScalaTest tables. Specs uses lots of operators:

http://etorreborre.github.com/specs2/guide/org.specs2.guide.Matchers.htm...

ScalaTest doesn't use any:

http://www.scalatest.org/user_guide/table_driven_property_checks#testing...

You just don't need non-obvious operators most of the time. There's a
better way if you look for it.

The feeling I get sometimes from all this is that we're a bunch of
really smart, passionate Scala experts designing libraries for each
other, rather than for the mainstream. Because we can certainly learn
and understand each others cryptic operators, and maybe even enjoy the
conciseness of the expressions we can make out of them. But the
mainstream developer is not that interested. It's not to say they
aren't smart. They may be super-smart, but just passionate about
designing airplane wings or getting their startup off the ground or
something else rather than becoming experts in our libraries. They're
just not that into us.

Bill

> Specs2 uses more symbols that specs1, but they're tightly contained and
> well documented, so this isn't a great concern.  I'm not so convinced about
> the mixed identifiers (e.g. be_==), but it does offer alternative notations
> and I'm generally comfortable allowing slightly different rules to apply in
> a test framework.
>
> Lift seems to be using ever more symbols and mixed identifiers (e.g. #> and
> unsafe_!), but the range of web frameworks now available for Scala means
> that developers have alternatives to chose from if they disagree with
> Lift's decisions.
>
> Databinder Dispatch is one of the few libraries remaining that is still
> symbol-heavy, not moving towards a design with at least the *option* of
> fewer symbols, and doesn't really have a viable alternative (for example,
> nothing else I know of can offer OAuth support out of the box).  The saving
> grace of dispatch is that it uses a convention which is internally very
> consistent.  Usage of Dispatch is also likely to be constrained to just a
> small corner of any codebase.
>
> On 20 November 2011 13:06, Oleg Galako wrote:
>
>
>
>
>
>
>
> > I've been using Scala for about 2 years (10 years of Java before that),
> > and i've decided to post here just because of how absolutely precise (in my
> > opinion) Martin's points are.
> > - if you just do your job with Scala instead of looking for reasons why it
> > is complex or something like that, it just starts to work in your hands and
> > you like it more and more
> > - the 'complexity' feeling is mostly the feeling of freedom from (or
> > absence of) 'best practices'
> > - the only thing we need to bust the 'complexity' myth is good
> > libraries/frameworks

Dinesh V
Joined: 2010-11-17,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity
Bill,Absolutely well said.
Usage of non-obvious symbols and operators is one of the most significant factors leading to all this perception of complexity.  Perhaps the single most important aspect holding back Scala adoption in my mind.  Cryptic operators may save key strokes.  The price paid in terms of readability is extremely high and indefensible. I sincerely hope more people adopt your philosophy.  Regards,Dinesh
On Sun, Nov 20, 2011 at 10:58 PM, Bill Venners <bill [at] artima [dot] com> wrote:
Hi Kevin,

I just noticed this thread.

Hey, you forgot ScalaTest, which I would point out was designed with
the philosophy of: *avoid any operators that users are not already
experts in.* So ScalaTest originally just had ===, which means
equality, < for less than, > for greater than, <= for less than or
equals, and >= for greater than or equals. At some point I did add one
non-obvious operator, the - in FreeSpec, because after much searching
for a way to avoid it, it was the best solution. In 2.1, which is
coming next year, I'll be adding a few more operators. One is +/- as
an alias for plusOrMinus. This one has been requested by multiple
users over time, and I've done several informal surveys asking people
if they can guess its meaning, and people always have. So I decided to
add that one. I'm also adding &&, ||, and ! for boolean-like
expressions with the triple equals operator, and they will mean
exactly what they look like they mean. Lots of new features are
coming, but no other operators than these few that pass the "obvious
test."

I have been bummed that so many non-obvious operators have been
showing up in Scala APIs. The trouble is that although obvious
operators makes code easier to read (a + b is nicer than a add b), non-
obvious operators makes code harder for casual users to understand,
because they have to look up what all the meanings are. And a lot of
users are casual, in that they don't use your library often enough to
remember the symbols for whatever reason. And to Java programmers, at
least, it makes Scala code look cryptic.

Moreover I would claim that 99% of the time, if you work at it, you
can find a better alternative to a non-obvious operator. Compare Specs
tables to ScalaTest tables. Specs uses lots of operators:

http://etorreborre.github.com/specs2/guide/org.specs2.guide.Matchers.html#DataTables

ScalaTest doesn't use any:

http://www.scalatest.org/user_guide/table_driven_property_checks#testingMutables

You just don't need non-obvious operators most of the time. There's a
better way if you look for it.

The feeling I get sometimes from all this is that we're a bunch of
really smart, passionate Scala experts designing libraries for each
other, rather than for the mainstream. Because we can certainly learn
and understand each others cryptic operators, and maybe even enjoy the
conciseness of the expressions we can make out of them. But the
mainstream developer is not that interested. It's not to say they
aren't smart. They may be super-smart, but just passionate about
designing airplane wings or getting their startup off the ground or
something else rather than becoming experts in our libraries. They're
just not that into us.

Bill

Jed Wesley-Smith
Joined: 2011-06-24,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity
This is such an overstated straw-man argument.
Any symbol's utility is entirely derived from from its cognitive associativity. If you see a symbol and relate it to a useful concept it is a useful symbol to you. + is useful because almost everyone learns addition at an early age, and the association is obvious. Reusing it for string concatenation complicates matters though as this is not a commutative operation. Note that overloading is the problem here and not the use of a non-ascii symbol.
If I use a different symbol, say "zusatz", have I improved anything? Clearly I have not, unless I am German. For all non-German speakers this has no associativity and is less useful from a universal understandability point of view.
However, there are many things in computing and math that are not so universally understood. Some things that are very specific to certain domains, or even sub-domains. Is it necessary that symbols within these domains adopt a strict latin alpha-numeric symbolic structure?
The answer of course is, it depends. Some things have clear and well understood alphanumeric names. Sometimes they do not at all, and make more sense as "operators". Consider:
(3.some |@| 4.some |@| 5.some) { _ + _ + _ }
what would you call |@| ? it combines arguments into an ApplicativeBuilder, so maybe applicativeBuild?
(3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
This is clearly longer, and I'd argue less readable (some will say less correct as well).
Now, the first time a non-haskell background Scala newbie comes across this they are going to be confused. They are going to wonder what the hell is this |@| thing and they'll spend some time researching it. Later on though they might wonder how they are going to do combine three Option[A]s and an (A, A, A) => B to get an Option[B] and remember that surprisingly useful |@| thing.
The problem isn't the terms themselves – the problem is whether or not they encode something that will be useful later on. Are the abstractions useful – if they are then they will get used and the names will get association due to reuse.
I think Perl has a lot to answer for here though. Everyone automatically says "Perl has symbols, Perl was bad, confusing, unmaintainable – Ergo: Symbols are bad".
I am not saying I agree with indiscriminate usage of symbols, only that usage of symbols is not in itself a bad thing, certainly not "The price paid in terms of readability is extremely high and indefensible.".
On 21 November 2011 15:49, Dinesh V <viswad [at] gmail [dot] com> wrote:

Usage of non-obvious symbols and operators is one of the most significant factors leading to all this perception of complexity.  Perhaps the single most important aspect holding back Scala adoption in my mind.  Cryptic operators may save key strokes.  The price paid in terms of readability is extremely high and indefensible.
Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity

Pfft, you're just afraid of dragging us all down to pre-school
arithmetic, which is where such a complex language like Scala really
should aspire to be.

On 21/11/11 17:55, Jed Wesley-Smith wrote:
> This is such an overstated straw-man argument.
>
> Any symbol's utility is entirely derived from from its cognitive
> associativity. If you see a symbol and relate it to a useful concept it is
> a useful symbol to you. + is useful because almost everyone learns addition
> at an early age, and the association is obvious. Reusing it for string
> concatenation complicates matters though as this is not a commutative
> operation. Note that overloading is the problem here and not the use of a
> non-ascii symbol.
>
> If I use a different symbol, say "zusatz", have I improved anything?
> Clearly I have not, unless I am German. For all non-German speakers this
> has no associativity and is less useful from a universal understandability
> point of view.
>
> However, there are many things in computing and math that are not so
> universally understood. Some things that are very specific to certain
> domains, or even sub-domains. Is it necessary that symbols within these
> domains adopt a strict latin alpha-numeric symbolic structure?
>
> The answer of course is, it depends. Some things have clear and well
> understood alphanumeric names. Sometimes they do not at all, and make more
> sense as "operators". Consider:
>
> (3.some |@| 4.some |@| 5.some) { _ + _ + _ }
>
> what would you call |@| ? it combines arguments into an ApplicativeBuilder,
> so maybe applicativeBuild?
>
> (3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
>
> This is clearly longer, and I'd argue less readable (some will say less
> correct as well).
>
> Now, the first time a non-haskell background Scala newbie comes across this
> they are going to be confused. They are going to wonder what the hell is
> this |@| thing and they'll spend some time researching it. Later on though
> they might wonder how they are going to do combine three Option[A]s and an
> (A, A, A) => B to get an Option[B] and remember that surprisingly useful
> |@| thing.
>
> The problem isn't the terms themselves – the problem is whether or not they
> encode something that will be useful later on. Are the abstractions useful
> – if they are then they will get used and the names will get association
> due to reuse.
>
> I think Perl has a lot to answer for here though. Everyone automatically
> says "Perl has symbols, Perl was bad, confusing, unmaintainable – Ergo:
> Symbols are bad".
>
> I am not saying I agree with indiscriminate usage of symbols, only that
> usage of symbols is not in itself a bad thing, certainly not "The price
> paid in terms of readability is extremely high and indefensible.".
>
> On 21 November 2011 15:49, Dinesh V wrote:
>
>> Usage of non-obvious symbols and operators is one of the most significant
>> factors leading to all this perception of complexity. Perhaps the single
>> most important aspect holding back Scala adoption in my mind.
>>
>> Cryptic operators may save key strokes. The price paid in terms of
>> readability is extremely high and indefensible.
>>
>>

Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: problems of scala complexity
On Mon, Nov 21, 2011 at 8:55 AM, Jed Wesley-Smith <jed [dot] wesleysmith [at] gmail [dot] com> wrote:
This is such an overstated straw-man argument.The answer of course is, it depends. Some things have clear and well understood alphanumeric names. Sometimes they do not at all, and make more sense as "operators". Consider:
(3.some |@| 4.some |@| 5.some) { _ + _ + _ }
what would you call |@| ? it combines arguments into an ApplicativeBuilder, so maybe applicativeBuild?
(3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
This is clearly longer, and I'd argue less readable (some will say less correct as well).

Side note #1: sometimes operators are chosen in part to minimize collisions with existing identifiers. I mean, we'd prefer '+' to  '|+|', but that one is taken. This is all pretty fragile, which is why in scalaz-seven we make it easy to use the library without operators and implicit views, or to create your own syntactic layer with method names of your choosing.
Side note #2: I'd like to get rid of |@| altogether and use an implicit view from TupleN (in the style of SBT)
  (3.some, 4.some, 5.some) ap { _ + _ + _ }
This is trivial to implement for Applicative[Option], but we can't yet infer the types for, say:
  ("fail".failNel[Int], 1.successNel[String]) ap { _ + _ }
We actually get really, really close with Mile's recent discovery that we stole as scalaz.Unapply, but we need a bit more support from Scalac to pull it all together. We're also looking at a HList variation, although this presents a different set of tradeoffs.
cheers,
-jason
Bill Venners
Joined: 2008-12-18,
User offline. Last seen 31 weeks 5 days ago.
Re: problems of scala complexity

Hi Jed,

On Nov 20, 11:55 pm, Jed Wesley-Smith
wrote:
> This is such an overstated straw-man argument.
>
> Any symbol's utility is entirely derived from from its cognitive
> associativity. If you see a symbol and relate it to a useful concept it is
> a useful symbol to you. + is useful because almost everyone learns addition
> at an early age, and the association is obvious. Reusing it for string
> concatenation complicates matters though as this is not a commutative
> operation. Note that overloading is the problem here and not the use of a
> non-ascii symbol.
>
> If I use a different symbol, say "zusatz", have I improved anything?
> Clearly I have not, unless I am German. For all non-German speakers this
> has no associativity and is less useful from a universal understandability
> point of view.
>
> However, there are many things in computing and math that are not so
> universally understood. Some things that are very specific to certain
> domains, or even sub-domains. Is it necessary that symbols within these
> domains adopt a strict latin alpha-numeric symbolic structure?
>
> The answer of course is, it depends. Some things have clear and well
> understood alphanumeric names. Sometimes they do not at all, and make more
> sense as "operators". Consider:
>
> (3.some |@| 4.some |@| 5.some) { _ + _ + _ }
>
> what would you call |@| ? it combines arguments into an ApplicativeBuilder,
> so maybe applicativeBuild?
>
> (3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
>
> This is clearly longer, and I'd argue less readable (some will say less
> correct as well).
>
I'd agree applicativeBuild is less readable than the |@| form once you
learn the meaning, and Haskell programmers probably already recognize
it. But to non-Haskell programmers it will look cryptic until they
learn it (if they learn it). But I'd point out the difference between |
@| and the operators in specs or sbt is that the latter operators are
just made up, invented out of thin air. The operators in specs have no
meaning in the testing domain, just as the operators in sbt have no
meaning in the build domain. To learn those operators, you have to
become an expert in that library and that knowledge does not benefit
you outside the library. To learn |@| by contrast, you need to become
an expert in something larger than scalaz, and you gain more than just
learning how to use scalaz. That's the difference.

Another example is domain-specific libraries for scientists. Say I'm
asked to write a library for a bunch of bio-informaticians who are
working in a certain area. Those folks may have some symbols they use
to communicate precisely. All are familiar with them. They use them in
the papers they write for each other, etc. I think it is likely that
using similar symbols in the API you make for them could make the code
easier for everyone to write and read. Sure, when a new programmer
gets hired who hasn't worked in bio-informatics before, that person
will have some symbols to learn, which at first will look cryptic to
them. But in learning about those, the new programmer isn't just
learning about the API, they are learning about the corner of bio-
informatics they are now working in. They are learning about the
domain, and that's going to help them be productive in that
environment.

The key is, do those symbols already have meaning in some domain and
are your users (or at least most of them) already experts in those
symbols. If not, then try and find a different way to say it that
doesn't use operators. For example, in specs you compose matchers with
^^, which is a made up operator. In ScalaTest you say "compose", which
is longer to type. But that's not actually a ScalaTest method.
ScalaTest matchers are Function1s, and so that's the compose method on
Function1. So if you don't know about compose, you'll need learn that,
but in the process you'll learn about function composition in Scala
(and in functional programming) in general, whereas with ^^ you just
learn something that has meaning only in specs.

Bill

> Now, the first time a non-haskell background Scala newbie comes across this
> they are going to be confused. They are going to wonder what the hell is
> this |@| thing and they'll spend some time researching it. Later on though
> they might wonder how they are going to do combine three Option[A]s and an
> (A, A, A) => B to get an Option[B] and remember that surprisingly useful
> |@| thing.
>
> The problem isn't the terms themselves – the problem is whether or not they
> encode something that will be useful later on. Are the abstractions useful
> – if they are then they will get used and the names will get association
> due to reuse.
>
> I think Perl has a lot to answer for here though. Everyone automatically
> says "Perl has symbols, Perl was bad, confusing, unmaintainable – Ergo:
> Symbols are bad".
>
> I am not saying I agree with indiscriminate usage of symbols, only that
> usage of symbols is not in itself a bad thing, certainly not "The price
> paid in terms of readability is extremely high and indefensible.".
>
> On 21 November 2011 15:49, Dinesh V wrote:
>
>
>
>
>
>
>
>
>
> > Usage of non-obvious symbols and operators is one of the most significant
> > factors leading to all this perception of complexity.  Perhaps the single
> > most important aspect holding back Scala adoption in my mind.
>
> > Cryptic operators may save key strokes.  The price paid in terms of
> > readability is extremely high and indefensible.

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: problems of scala complexity
Not so!  I explicitly left ScalaTest out of that list exactly because it doesn't make any use of symbolic operators :)(other than ===, which I must admit I forgot about)



On 21 November 2011 03:58, Bill Venners <bill [at] artima [dot] com> wrote:
Hi Kevin,

I just noticed this thread.

On Nov 20, 5:55 am, Kevin Wright <kev [dot] lee [dot] wri [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> Oh absolutely!  It also doesn't help that many of our current "high
> profile" libraries are particularly heavy on symbolic method names.  Things
> are improving in at least two notable libraries though:
>
> - Akka has culled its symbols down to essentially just ! and ?
> - scalaz is near the end of a rewrite that will make it far easier to use
> non-symbolic equivalents for many concepts
>
Hey, you forgot ScalaTest, which I would point out was designed with
the philosophy of: *avoid any operators that users are not already
experts in.* So ScalaTest originally just had ===, which means
equality, < for less than, > for greater than, <= for less than or
equals, and >= for greater than or equals. At some point I did add one
non-obvious operator, the - in FreeSpec, because after much searching
for a way to avoid it, it was the best solution. In 2.1, which is
coming next year, I'll be adding a few more operators. One is +/- as
an alias for plusOrMinus. This one has been requested by multiple
users over time, and I've done several informal surveys asking people
if they can guess its meaning, and people always have. So I decided to
add that one. I'm also adding &&, ||, and ! for boolean-like
expressions with the triple equals operator, and they will mean
exactly what they look like they mean. Lots of new features are
coming, but no other operators than these few that pass the "obvious
test."

I have been bummed that so many non-obvious operators have been
showing up in Scala APIs. The trouble is that although obvious
operators makes code easier to read (a + b is nicer than a add b), non-
obvious operators makes code harder for casual users to understand,
because they have to look up what all the meanings are. And a lot of
users are casual, in that they don't use your library often enough to
remember the symbols for whatever reason. And to Java programmers, at
least, it makes Scala code look cryptic.

Moreover I would claim that 99% of the time, if you work at it, you
can find a better alternative to a non-obvious operator. Compare Specs
tables to ScalaTest tables. Specs uses lots of operators:

http://etorreborre.github.com/specs2/guide/org.specs2.guide.Matchers.html#DataTables

ScalaTest doesn't use any:

http://www.scalatest.org/user_guide/table_driven_property_checks#testingMutables

You just don't need non-obvious operators most of the time. There's a
better way if you look for it.

The feeling I get sometimes from all this is that we're a bunch of
really smart, passionate Scala experts designing libraries for each
other, rather than for the mainstream. Because we can certainly learn
and understand each others cryptic operators, and maybe even enjoy the
conciseness of the expressions we can make out of them. But the
mainstream developer is not that interested. It's not to say they
aren't smart. They may be super-smart, but just passionate about
designing airplane wings or getting their startup off the ground or
something else rather than becoming experts in our libraries. They're
just not that into us.

Bill

> Specs2 uses more symbols that specs1, but they're tightly contained and
> well documented, so this isn't a great concern.  I'm not so convinced about
> the mixed identifiers (e.g. be_==), but it does offer alternative notations
> and I'm generally comfortable allowing slightly different rules to apply in
> a test framework.
>
> Lift seems to be using ever more symbols and mixed identifiers (e.g. #> and
> unsafe_!), but the range of web frameworks now available for Scala means
> that developers have alternatives to chose from if they disagree with
> Lift's decisions.
>
> Databinder Dispatch is one of the few libraries remaining that is still
> symbol-heavy, not moving towards a design with at least the *option* of
> fewer symbols, and doesn't really have a viable alternative (for example,
> nothing else I know of can offer OAuth support out of the box).  The saving
> grace of dispatch is that it uses a convention which is internally very
> consistent.  Usage of Dispatch is also likely to be constrained to just a
> small corner of any codebase.
>
> On 20 November 2011 13:06, Oleg Galako <ojo [dot] [dot] [dot] [at] gmail [dot] com> wrote:
>
>
>
>
>
>
>
> > I've been using Scala for about 2 years (10 years of Java before that),
> > and i've decided to post here just because of how absolutely precise (in my
> > opinion) Martin's points are.
> > - if you just do your job with Scala instead of looking for reasons why it
> > is complex or something like that, it just starts to work in your hands and
> > you like it more and more
> > - the 'complexity' feeling is mostly the feeling of freedom from (or
> > absence of) 'best practices'
> > - the only thing we need to bust the 'complexity' myth is good
> > libraries/frameworks




Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: problems of scala complexity


On Mon, Nov 21, 2011 at 12:19 AM, Arif Mustafa <arifmustafak [at] gmail [dot] com> wrote:
" But there's a huge difference between a library and a language."
may be I am not as smart as you are...but I do understand that there is a huge difference between a library and a language .... there is certain level of arrogance in Scala community, that is beyond me.... my comments were strictly with respect to the kind of attitude that we should have ...and they were not against Scala.  I totally agree with @Russ

No, my point was that it's one thing to provide options for being able to call Scala-defined methods from other languages, and another thing to refrain from symbolic names in the language, for people who use that language.

I have no problem with symbolic names, as long as the method is documented and it gives me a name that I can use when I speak to people, not machines.

Cheers,

 

cheers
Arif

On Sun, Nov 20, 2011 at 4:44 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-20 2:20 AM, martin odersky wrote:


On Sun, Nov 20, 2011 at 5:55 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-19 6:31 AM, martin odersky wrote:
Some remarks:

First, the thread and many like it seems too negatve to me. Scala is used in a large and growing number of enterprises, some of them with more than 100 devs working with it. These people just get on with the job (and love it for the most part); they don't find Scala's ``complexity'' too daunting.

You are very correct Martin, there have been many threads that negatively criticize the complexity of Scala - and many have been unproductive or counterproductive.

Sorry to read you see this thread as negative - I do not see it that way at all. You are absolutely correct that many people are happy with Scala just the way it is. What I believe this thread is attempting to do is to constructively satisfy those people who do find Scala too daunting and offer solutions to make it less daunting for them.

I am absolutely for discussing the best way to make Scala more approachable for newcomers and large teams.  I just wanted to stress that we should not start with a too negative point of view of the status quo. Scala is already making nice progress among these groups. But of course we should search ways to help it further along.

In that we are in total agreement. To avoid distracting narratives perhaps we should strive to make the distinction more clear that we are not 'bashing' Scala or Scala experts, but trying to make Scala more approachable :-)


Second, I believe we have come to realize that complexity and power are pretty much aligned for Scala.
Take away the complexity and you take away the power. Here I mean power in the sense: "Number of concepts that you can describe precisely using your language". I want to get away from the common argument that all Turing complete languages are equivalent in power anyway.

One good step I have seen lately is moving the narrative away from trying to reduce or take away the complexity of Scala or any of its power. I really like the idea of tools to help us best use the language. In the early days of C the compiler diagnostics were a joke, but someone wrote lint and it helped many people make better use of C. These days I am truly amazed at the quality of the diagnostics of the Java compilers and the IDEs - these automated tools make Java even more accessible to more programmers, and even less complex. I am often amazed at how well Eclipse can guide me into proper use of Java or best practices.

If there are people who are smart enough to invent languages like Scala - there are surely people smart enough to imagine, design and build tools to make Scala more accessible to more people. If you are smart enough and experienced enough to ride Scala 'bareback' so to speak, more power to you, but it does not mean we cannot also invest in better saddles and stirrups for the rest of us.
On the small scale, I believe you are right. I am pretty confident these tools will come for Scala. But on the large scale, I do not see tools criticizing systems architecture just yet.

You are right. It is not clear how far we can go with 'critical thinking' tools without resorting to Artificial Intelligence, Expert Systems or Intelligent Systems - but it may still be a useful point on the horizon to set sail for.



Third, if you look at other languages, there is always a set of "best practices" developed that come with it and that are used as guidelines. Certainly Java has a rich culture of best practices. And that cultures changes over time, as developments in Java EE show.

No disagreement here.


Since Scala's enterprise use is still young, best practices have still a some way to develop and stabilize.

Truly. As we go along can we not find some way to automate the support of those best practices?
Yes, but that's a second step. We need to develop them first!

Totally agree.



This is your chance! If you put out some clean libraries with easy-to use APIs you have a great chance to influence the future best practices for Scala, as long as they are still in flux. I wish we'd concentrate more on these aspects than wringing our hands.

Clean libraries and APIs alone do not solve the problems.

No, but they are important. Not so much from the user perspective but  to set an example to others how code and APIs should be structured and formulated. For instance, you know one thing I have come to regret? That's having put /: and :\ as aliases for foldLeft and foldRight into collections. I thought I had good reasons to do so. In particular
  (zero /: xs) (op)
keeps the relative order of the zero and the list xs in the expansion of the fold:
  zero op x_1... op x_n 
Whereas 
  xs.foldLeft(zero)(op)
reverses them. And, if we talk just about this library, I still think these reasons are valid. But as an example for other libraries it was the wrong choice. It gave an implicit encouragement to use symbolic operators in libraries where they are not necessary. And, I think the current set of core libraries uses too many symbolic operators (and, to be clear, I am not talking about scalaz here, that's on a different planet altogether).

Yes, clean libraries and APIs can be enormously important. When I read Scala code I do not want to have to think in terms of APL ;-)

My rule of thumb is: Phrases are always betters than words, words are always better than acronyms (or Hungarian notation), and acronyms are always better than symbols. There are of course exceptions which is the point of a 'rule of thumb.'

 
Also, I do not see us wringing our hands any longer, I think this thread is actually going somewhere productive and should be encouraged.
That's great!

Should we maintain this thread, or find a more representative title of goals to make Scala more accessible and supported by the increasing evolution conventions and best practices, library and API design, and automated tools for critical review of code quality? Should we have a separate discussion representative of what problems to solve to make Scala more accessible? At what point can move from narratives and debate, for some issues, and maybe inventory them in a wiki or some other place when there is sufficient consensus?




Can best practices be influenced by tools, such as style checkers? Maybe. It's certainly something we want to pursue. But it would be silly to delegate responsibility for forming best practices to these tools only.

I totally agree. Airbus tried to over automate the cockpit and the result was the autopilot overrode the real pilots and landed the aircraft in a forest at an airshow. These days there is a lot of effort to further automate things in the cockpit, but it is generally accepted now that the human pilot is ultimately in charge. Rather than making human pilots redundant, we try to make them better pilots.

I am advocating giving the software developers, senior software developers and software architects the tools to monitor and assess the code quality and complexity, and maybe event suggest better ways to do things. I have found findbugs exceedingly useful on many occasions and have even used it to analyze our code base and report back to our team my concerns about some of the dicey practices I found in the code base.

Let's not limit Scala's power and promise by restricting features - rather let's build tools to help us make better use of Scala.

+100 here.

:-))


Cheers
 -- Martin




--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: problems of scala complexity


On Mon, Nov 21, 2011 at 12:19 AM, Arif Mustafa <arifmustafak [at] gmail [dot] com> wrote:
" But there's a huge difference between a library and a language."
may be I am not as smart as you are...but I do understand that there is a huge difference between a library and a language .... there is certain level of arrogance in Scala community, that is beyond me.... my comments were strictly with respect to the kind of attitude that we should have ...and they were not against Scala.  I totally agree with @Russ

No, my point was that it's one thing to provide options for being able to call Scala-defined methods from other languages, and another thing to refrain from symbolic names in the language, for people who use that language.

I have no problem with symbolic names, as long as the method is documented and it gives me a name that I can use when I speak to people, not machines.

Cheers,

 

cheers
Arif

On Sun, Nov 20, 2011 at 4:44 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-20 2:20 AM, martin odersky wrote:


On Sun, Nov 20, 2011 at 5:55 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-19 6:31 AM, martin odersky wrote:
Some remarks:

First, the thread and many like it seems too negatve to me. Scala is used in a large and growing number of enterprises, some of them with more than 100 devs working with it. These people just get on with the job (and love it for the most part); they don't find Scala's ``complexity'' too daunting.

You are very correct Martin, there have been many threads that negatively criticize the complexity of Scala - and many have been unproductive or counterproductive.

Sorry to read you see this thread as negative - I do not see it that way at all. You are absolutely correct that many people are happy with Scala just the way it is. What I believe this thread is attempting to do is to constructively satisfy those people who do find Scala too daunting and offer solutions to make it less daunting for them.

I am absolutely for discussing the best way to make Scala more approachable for newcomers and large teams.  I just wanted to stress that we should not start with a too negative point of view of the status quo. Scala is already making nice progress among these groups. But of course we should search ways to help it further along.

In that we are in total agreement. To avoid distracting narratives perhaps we should strive to make the distinction more clear that we are not 'bashing' Scala or Scala experts, but trying to make Scala more approachable :-)


Second, I believe we have come to realize that complexity and power are pretty much aligned for Scala.
Take away the complexity and you take away the power. Here I mean power in the sense: "Number of concepts that you can describe precisely using your language". I want to get away from the common argument that all Turing complete languages are equivalent in power anyway.

One good step I have seen lately is moving the narrative away from trying to reduce or take away the complexity of Scala or any of its power. I really like the idea of tools to help us best use the language. In the early days of C the compiler diagnostics were a joke, but someone wrote lint and it helped many people make better use of C. These days I am truly amazed at the quality of the diagnostics of the Java compilers and the IDEs - these automated tools make Java even more accessible to more programmers, and even less complex. I am often amazed at how well Eclipse can guide me into proper use of Java or best practices.

If there are people who are smart enough to invent languages like Scala - there are surely people smart enough to imagine, design and build tools to make Scala more accessible to more people. If you are smart enough and experienced enough to ride Scala 'bareback' so to speak, more power to you, but it does not mean we cannot also invest in better saddles and stirrups for the rest of us.
On the small scale, I believe you are right. I am pretty confident these tools will come for Scala. But on the large scale, I do not see tools criticizing systems architecture just yet.

You are right. It is not clear how far we can go with 'critical thinking' tools without resorting to Artificial Intelligence, Expert Systems or Intelligent Systems - but it may still be a useful point on the horizon to set sail for.



Third, if you look at other languages, there is always a set of "best practices" developed that come with it and that are used as guidelines. Certainly Java has a rich culture of best practices. And that cultures changes over time, as developments in Java EE show.

No disagreement here.


Since Scala's enterprise use is still young, best practices have still a some way to develop and stabilize.

Truly. As we go along can we not find some way to automate the support of those best practices?
Yes, but that's a second step. We need to develop them first!

Totally agree.



This is your chance! If you put out some clean libraries with easy-to use APIs you have a great chance to influence the future best practices for Scala, as long as they are still in flux. I wish we'd concentrate more on these aspects than wringing our hands.

Clean libraries and APIs alone do not solve the problems.

No, but they are important. Not so much from the user perspective but  to set an example to others how code and APIs should be structured and formulated. For instance, you know one thing I have come to regret? That's having put /: and :\ as aliases for foldLeft and foldRight into collections. I thought I had good reasons to do so. In particular
  (zero /: xs) (op)
keeps the relative order of the zero and the list xs in the expansion of the fold:
  zero op x_1... op x_n 
Whereas 
  xs.foldLeft(zero)(op)
reverses them. And, if we talk just about this library, I still think these reasons are valid. But as an example for other libraries it was the wrong choice. It gave an implicit encouragement to use symbolic operators in libraries where they are not necessary. And, I think the current set of core libraries uses too many symbolic operators (and, to be clear, I am not talking about scalaz here, that's on a different planet altogether).

Yes, clean libraries and APIs can be enormously important. When I read Scala code I do not want to have to think in terms of APL ;-)

My rule of thumb is: Phrases are always betters than words, words are always better than acronyms (or Hungarian notation), and acronyms are always better than symbols. There are of course exceptions which is the point of a 'rule of thumb.'

 
Also, I do not see us wringing our hands any longer, I think this thread is actually going somewhere productive and should be encouraged.
That's great!

Should we maintain this thread, or find a more representative title of goals to make Scala more accessible and supported by the increasing evolution conventions and best practices, library and API design, and automated tools for critical review of code quality? Should we have a separate discussion representative of what problems to solve to make Scala more accessible? At what point can move from narratives and debate, for some issues, and maybe inventory them in a wiki or some other place when there is sufficient consensus?




Can best practices be influenced by tools, such as style checkers? Maybe. It's certainly something we want to pursue. But it would be silly to delegate responsibility for forming best practices to these tools only.

I totally agree. Airbus tried to over automate the cockpit and the result was the autopilot overrode the real pilots and landed the aircraft in a forest at an airshow. These days there is a lot of effort to further automate things in the cockpit, but it is generally accepted now that the human pilot is ultimately in charge. Rather than making human pilots redundant, we try to make them better pilots.

I am advocating giving the software developers, senior software developers and software architects the tools to monitor and assess the code quality and complexity, and maybe event suggest better ways to do things. I have found findbugs exceedingly useful on many occasions and have even used it to analyze our code base and report back to our team my concerns about some of the dicey practices I found in the code base.

Let's not limit Scala's power and promise by restricting features - rather let's build tools to help us make better use of Scala.

+100 here.

:-))


Cheers
 -- Martin




--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
bryan hunt
Joined: 2011-11-09,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity

In Soviet Russia:

The population - Factories build Ladas of questionable quality. Food
production facilities - concoct meat paste, sold anywhere else as dog
food. Infrastructure is crumbling. Afghanistan is a disaster.

The Nomenclatura - We are matching the United States military
capacity, especially in the field of high technology. Any who
criticise us are traitors to the people's revolution. We are the land
of plenty. There will be a socialist victory in the Peoples Republic
of Afghanistan.

In Scala:

Users - Too much complexity. Too many versions. Too many funky bugs.
Why do we have to learn yet another build tool? When will releases
stabilise? Java runtime is backward compatible to 1996 - Scala, 6
months at best. Too academic.

The Elite - Fools, you are stupid, code in Visual Basic. The product
is primed for commercial success. All the contractors love Scala (they
know everything). All the graduates love Scala (they are the future).
Everyone at EPFL loves it (they are really smart and untainted by the
drudgery of manual labour and deadlines).

Geir Hedemark
Joined: 2011-11-01,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity

On 2011, Nov 21, at 11:04 AM, bryan hunt wrote:
> Users - Too much complexity. Too many versions. Too many funky bugs.
> Why do we have to learn yet another build tool? When will releases
> stabilise? Java runtime is backward compatible to 1996 - Scala, 6
> months at best. Too academic.

As a user of scala, I have to say that I mostly do not agree with this. I am not a contractor, a student, or an EPFL employee. I have however used Java the last ten years or so. As a manager of an "enterprise" (whatever that means) scala team, I can tell you that it is fully possible to build a working team. You _do_ need team members who are not afraid to learn to pull it off.

I am perfectly willing to accept that not everyone is able to pull off this feat.

(And yes, I am unhappy about the versioning shenanigans of the past. I am told that is in the past, and further improvements and a hot beverage will mollify me)

Geir

bryan hunt
Joined: 2011-11-09,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity

On Mon, 21 Nov 2011 11:23:55 +0100, Geir Hedemark wrote:
> On 2011, Nov 21, at 11:04 AM, bryan hunt wrote:
> > Users - Too much complexity. Too many versions. Too many funky bugs.
> > Why do we have to learn yet another build tool? When will releases
> > stabilise? Java runtime is backward compatible to 1996 - Scala, 6
> > months at best. Too academic.
>
> As a user of scala, I have to say that I mostly do not agree with this. I am not a contractor, a student, or an EPFL employee. I have however used Java the last ten years or so. As a manager of an "enterprise" (whatever that means) scala team, I can tell you that it is fully possible to build a working team. You _do_ need team members who are not afraid to learn to pull it off.
>
> I am perfectly willing to accept that not everyone is able to pull off this feat.
>
> (And yes, I am unhappy about the versioning shenanigans of the past. I am told that is in the past, and further improvements and a hot beverage will mollify me)
>
> Geir

I built a cometd, multi-user, agent based, real-time, crisis management
system using 6000 Scala LOC.

It probably would have eaten up about 20,000 Java LOC.

It would have been half as difficult - had the runtime been stable, Java
interop worked as advertised, and wierd gotchas not bit me in the ass
half way through the development cycle.

Bryan Hunt

Geir Hedemark
Joined: 2011-11-01,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity

On 2011, Nov 21, at 11:48 AM, Bryan Hunt wrote:
> It would have been half as difficult - had the runtime been stable, Java
> interop worked as advertised, and wierd gotchas not bit me in the ass
> half way through the development cycle.

I remember similar gripes with java 1.1. Not to mention Ant.

Geir

Arif Mustafa
Joined: 2011-11-08,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity
 believe language design should be collaborative effort of linguists and computer scientists.... because in the end it depends who will be the end users of the language and for what purposes it will be used ...a language to build parsers and/or compilers or for machine consumption  or to write domains specific logic that humans (programmers/business analyst) can understand ...of course with Scala you can do both ...however in my opinion, as Russ gave an example, it is better that you wrap Scala's symbolic soup with more understandable  and "meaningful yet succinct"  DSL, if you will. And I don't think that Scala community should think of arguments against complexity as negative ...neither should Scala community look down upon "average Java" developers ....but understand that nothing that we (humans) create is perfect ...the same people who now say how terrible Java is, happily worked with Java, built systems and made their living. I can safely say, after few years there will be cries against Scala also ...and there will be interfaces/wrappers bulit around Scala that would make it appeal to wider user base of "Average Java Developers" ...and perhaps another language with all the power of Scala, yet without "perceived" complexity (by some) of Scala.
cheers
Arif
On Mon, Nov 21, 2011 at 6:06 AM, Geir Hedemark <geir [dot] hedemark [at] gmail [dot] com> wrote:
On 2011, Nov 21, at 11:48 AM, Bryan Hunt wrote:
> It would have been half as difficult - had the runtime been stable, Java
> interop worked as advertised, and wierd gotchas not bit me in the ass
> half way through the development cycle.

I remember similar gripes with java 1.1. Not to mention Ant.

Geir



Seth Tisue
Joined: 2008-12-16,
User offline. Last seen 34 weeks 3 days ago.
Re: Re: problems of scala complexity

Guys, scala-debate, please, NOT scala-user.

Arif Mustafa
Joined: 2011-11-08,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity

believe language design should be collaborative effort of linguists
and computer scientists.... because in the end it depends who will be
the end users of the language and for what purposes it will be
used ...a language to build parsers and/or compilers or for machine
consumption or to write domains specific logic that humans
(programmers/business analyst) can understand ...of course with Scala
you can do both ...however in my opinion, as Russ gave an example, it
is better that you wrap Scala's symbolic soup with more
understandable and "meaningful yet succinct" DSL, if you will. And I
don't think that Scala community should think of arguments against
complexity as negative ...neither should Scala community look down
upon "average Java" developers ....but understand that nothing that we
(humans) create is perfect ...the same people who now say how terrible
Java is, happily worked with Java, built systems and made their
living. I can safely say, after few years there will be cries against
Scala also ...and there will be interfaces/wrappers bulit around Scala
that would make it appeal to wider user base of "Average Java
Developers" ...and perhaps another language with all the power of
Scala, yet without "perceived" complexity (by some) of Scala.

cheers

Arif

On Nov 20, 12:04 am, Adam Jorgensen
wrote:
> Ugh, all this debate about complexity.
>
> Weaker programmers will always find a way to hang themselves.
>
> Nerfing Scala is not going to fix that.
>
> Better to nerf the weak programmers than the language.

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: problems of scala complexity
Right.  I'd love to see some kind of direct compiler support for applicative functors.  If it takes the form of being defined on tuples, that's great.  The concept really is simple enough and powerful enough to be made as ubiquitous as for expressions.


On Mon, Nov 21, 2011 at 3:35 AM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
On Mon, Nov 21, 2011 at 8:55 AM, Jed Wesley-Smith <jed [dot] wesleysmith [at] gmail [dot] com> wrote:
This is such an overstated straw-man argument.The answer of course is, it depends. Some things have clear and well understood alphanumeric names. Sometimes they do not at all, and make more sense as "operators". Consider:
(3.some |@| 4.some |@| 5.some) { _ + _ + _ }
what would you call |@| ? it combines arguments into an ApplicativeBuilder, so maybe applicativeBuild?
(3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
This is clearly longer, and I'd argue less readable (some will say less correct as well).

Side note #1: sometimes operators are chosen in part to minimize collisions with existing identifiers. I mean, we'd prefer '+' to  '|+|', but that one is taken. This is all pretty fragile, which is why in scalaz-seven we make it easy to use the library without operators and implicit views, or to create your own syntactic layer with method names of your choosing.
Side note #2: I'd like to get rid of |@| altogether and use an implicit view from TupleN (in the style of SBT)
  (3.some, 4.some, 5.some) ap { _ + _ + _ }
This is trivial to implement for Applicative[Option], but we can't yet infer the types for, say:
  ("fail".failNel[Int], 1.successNel[String]) ap { _ + _ }
We actually get really, really close with Mile's recent discovery that we stole as scalaz.Unapply, but we need a bit more support from Scalac to pull it all together. We're also looking at a HList variation, although this presents a different set of tradeoffs.
cheers,
-jason

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity
As someone who has dived in to some Scala code before and thought 'WTF?' I know how unsettling cryptic symbolics can be. I often ran into this same problem with C++ because of operator overloading.

Is it possible to build tools into the IDE to help the reader understand what they are seeing?

I mainly use Eclipse and I really like how when I hover the mouse over various parts of the code I get javadoc tool-tips. One thing I really like about these tool-tips is you can click to keep them open, re-size them, click links and go back and forth. The main thing is by integrating the javadoc with the tool-tips it can really lessen the WTF factor considerably.

Can something similar be done in Scala IDEs? Maybe even going beyond the scaladoc to some mechanism the helps people unfamiliar with the domain, or particular library/API style to better fathom what things mean?

Cheers, Eric

On 2011-11-20 11:55 PM, Jed Wesley-Smith wrote:
CAN3nywAicnOnnyzckEXgLT3L7z4jSuEyRcS3LHbc5v4rsffv3A [at] mail [dot] gmail [dot] com" type="cite">This is such an overstated straw-man argument.
Any symbol's utility is entirely derived from from its cognitive associativity. If you see a symbol and relate it to a useful concept it is a useful symbol to you. + is useful because almost everyone learns addition at an early age, and the association is obvious. Reusing it for string concatenation complicates matters though as this is not a commutative operation. Note that overloading is the problem here and not the use of a non-ascii symbol.
If I use a different symbol, say "zusatz", have I improved anything? Clearly I have not, unless I am German. For all non-German speakers this has no associativity and is less useful from a universal understandability point of view.
However, there are many things in computing and math that are not so universally understood. Some things that are very specific to certain domains, or even sub-domains. Is it necessary that symbols within these domains adopt a strict latin alpha-numeric symbolic structure?
The answer of course is, it depends. Some things have clear and well understood alphanumeric names. Sometimes they do not at all, and make more sense as "operators". Consider:
(3.some |@| 4.some |@| 5.some) { _ + _ + _ }
what would you call |@| ? it combines arguments into an ApplicativeBuilder, so maybe applicativeBuild?
(3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
This is clearly longer, and I'd argue less readable (some will say less correct as well).
Now, the first time a non-haskell background Scala newbie comes across this they are going to be confused. They are going to wonder what the hell is this |@| thing and they'll spend some time researching it. Later on though they might wonder how they are going to do combine three Option[A]s and an (A, A, A) => B to get an Option[B] and remember that surprisingly useful |@| thing.
The problem isn't the terms themselves – the problem is whether or not they encode something that will be useful later on. Are the abstractions useful – if they are then they will get used and the names will get association due to reuse.
I think Perl has a lot to answer for here though. Everyone automatically says "Perl has symbols, Perl was bad, confusing, unmaintainable – Ergo: Symbols are bad".
I am not saying I agree with indiscriminate usage of symbols, only that usage of symbols is not in itself a bad thing, certainly not "The price paid in terms of readability is extremely high and indefensible.".
On 21 November 2011 15:49, Dinesh V <viswad [at] gmail [dot] com" rel="nofollow">viswad [at] gmail [dot] com> wrote:

Usage of non-obvious symbols and operators is one of the most significant factors leading to all this perception of complexity.  Perhaps the single most important aspect holding back Scala adoption in my mind.   Cryptic operators may save key strokes.  The price paid in terms of readability is extremely high and indefensible.
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Re: problems of scala complexity

:-)

On 2011-11-21 2:04 AM, bryan hunt wrote:
> In Soviet Russia:
>
> The population - Factories build Ladas of questionable quality. Food
> production facilities - concoct meat paste, sold anywhere else as dog
> food. Infrastructure is crumbling. Afghanistan is a disaster.
>
> The Nomenclatura - We are matching the United States military
> capacity, especially in the field of high technology. Any who
> criticise us are traitors to the people's revolution. We are the land
> of plenty. There will be a socialist victory in the Peoples Republic
> of Afghanistan.
>
> In Scala:
>
> Users - Too much complexity. Too many versions. Too many funky bugs.
> Why do we have to learn yet another build tool? When will releases
> stabilise? Java runtime is backward compatible to 1996 - Scala, 6
> months at best. Too academic.
>
> The Elite - Fools, you are stupid, code in Visual Basic. The product
> is primed for commercial success. All the contractors love Scala (they
> know everything). All the graduates love Scala (they are the future).
> Everyone at EPFL loves it (they are really smart and untainted by the
> drudgery of manual labour and deadlines).

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity

On Mon, Nov 21, 2011 at 8:42 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
As someone who has dived in to some Scala code before and thought 'WTF?' I know how unsettling cryptic symbolics can be. I often ran into this same problem with C++ because of operator overloading.

Note that Scala doesn't have operator overloading, the problem we're discussing is that methods can be named using arbitrary UTF characters.
Is it possible to build tools into the IDE to help the reader understand what they are seeing?

IDE's already support this, it's called Javadoc :-)  
But the problem with symbols is much deeper than this. For example, suppose you come across |@| in Scalaz code and you have never studied Haskell, much less applicatives. Your first reflex will be to google it. Searching for |@| alone yields no result (unsurprisingly) but "scalaz |@|" shows more promise. However, the first two links point to Scalaz' main project page, and none of them even contain "|@|" anywhere.

This result should be obvious if you know how Google search works (it probably simply discarded |@| form the query) but it's one of the main problems with symbols: they're hard to look up.
Google code search is of no help either, by the way.
You're pretty much dead in the water at this point.
So your only hope is to dive into the Scalaz code. Finding the definition of |@| is pretty easy, but take a look at the source... Yup, not a single comment, and a strong warning at the top telling you not to use it directly.
To make things worse, "applicative builders" don't exist in Haskell, so even if you decided to bite the bullet and educate yourself in Haskell (never a bad idea, but not everybody has the time), walking the ladder from functors to applicatives and finally to monads will be a long and arduous climb.
tl;dr: FP concepts can already be daunting in and of themselves, don't make things worse by using symbols in your source.
-- Cédric




I mainly use Eclipse and I really like how when I hover the mouse over various parts of the code I get javadoc tool-tips. One thing I really like about these tool-tips is you can click to keep them open, re-size them, click links and go back and forth. The main thing is by integrating the javadoc with the tool-tips it can really lessen the WTF factor considerably.

Can something similar be done in Scala IDEs? Maybe even going beyond the scaladoc to some mechanism the helps people unfamiliar with the domain, or particular library/API style to better fathom what things mean?

Cheers, Eric

On 2011-11-20 11:55 PM, Jed Wesley-Smith wrote:
This is such an overstated straw-man argument.
Any symbol's utility is entirely derived from from its cognitive associativity. If you see a symbol and relate it to a useful concept it is a useful symbol to you. + is useful because almost everyone learns addition at an early age, and the association is obvious. Reusing it for string concatenation complicates matters though as this is not a commutative operation. Note that overloading is the problem here and not the use of a non-ascii symbol.
If I use a different symbol, say "zusatz", have I improved anything? Clearly I have not, unless I am German. For all non-German speakers this has no associativity and is less useful from a universal understandability point of view.
However, there are many things in computing and math that are not so universally understood. Some things that are very specific to certain domains, or even sub-domains. Is it necessary that symbols within these domains adopt a strict latin alpha-numeric symbolic structure?
The answer of course is, it depends. Some things have clear and well understood alphanumeric names. Sometimes they do not at all, and make more sense as "operators". Consider:
(3.some |@| 4.some |@| 5.some) { _ + _ + _ }
what would you call |@| ? it combines arguments into an ApplicativeBuilder, so maybe applicativeBuild?
(3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
This is clearly longer, and I'd argue less readable (some will say less correct as well).
Now, the first time a non-haskell background Scala newbie comes across this they are going to be confused. They are going to wonder what the hell is this |@| thing and they'll spend some time researching it. Later on though they might wonder how they are going to do combine three Option[A]s and an (A, A, A) => B to get an Option[B] and remember that surprisingly useful |@| thing.
The problem isn't the terms themselves – the problem is whether or not they encode something that will be useful later on. Are the abstractions useful – if they are then they will get used and the names will get association due to reuse.
I think Perl has a lot to answer for here though. Everyone automatically says "Perl has symbols, Perl was bad, confusing, unmaintainable – Ergo: Symbols are bad".
I am not saying I agree with indiscriminate usage of symbols, only that usage of symbols is not in itself a bad thing, certainly not "The price paid in terms of readability is extremely high and indefensible.".
On 21 November 2011 15:49, Dinesh V <viswad [at] gmail [dot] com> wrote:

Usage of non-obvious symbols and operators is one of the most significant factors leading to all this perception of complexity.  Perhaps the single most important aspect holding back Scala adoption in my mind.   Cryptic operators may save key strokes.  The price paid in terms of readability is extremely high and indefensible.

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity
On 2011-11-21 9:06 AM, Cédric Beust ♔ wrote:
6im-71hafR5gW17w [at] mail [dot] gmail [dot] com" type="cite">
On Mon, Nov 21, 2011 at 8:42 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com" rel="nofollow">eric [dot] kolotyluk [at] gmail [dot] com> wrote:
As someone who has dived in to some Scala code before and thought 'WTF?' I know how unsettling cryptic symbolics can be. I often ran into this same problem with C++ because of operator overloading.

Note that Scala doesn't have operator overloading, the problem we're discussing is that methods can be named using arbitrary UTF characters.

Sorry, I should have said "I often ran into similar problems with C++ because of operator overloading." The problem of know knowing what I was seeing.

6im-71hafR5gW17w [at] mail [dot] gmail [dot] com" type="cite">
Is it possible to build tools into the IDE to help the reader understand what they are seeing?

IDE's already support this, it's called Javadoc :-) 

I meant something beyond javadoc.

6im-71hafR5gW17w [at] mail [dot] gmail [dot] com" type="cite">
But the problem with symbols is much deeper than this. For example, suppose you come across |@| in Scalaz code and you have never studied Haskell, much less applicatives. Your first reflex will be to google it. Searching for |@| alone yields no result (unsurprisingly) but "scalaz |@|" shows more promise. However, the first two links point to Scalaz' main project page, and none of them even contain "|@|" anywhere.

This result should be obvious if you know how Google search works (it probably simply discarded |@| form the query) but it's one of the main problems with symbols: they're hard to look up.
Google code search is of no help either, by the way.
You're pretty much dead in the water at this point.
So your only hope is to dive into the Scalaz code. Finding the definition of |@| is pretty easy, but take a look at the source... Yup, not a single comment, and a strong warning at the top telling you not to use it directly.
6im-71hafR5gW17w [at] mail [dot] gmail [dot] com" type="cite">
To make things worse, "applicative builders" don't exist in Haskell, so even if you decided to bite the bullet and educate yourself in Haskell (never a bad idea, but not everybody has the time), walking the ladder from functors to applicatives and finally to monads will be a long and arduous climb.
tl;dr: FP concepts can already be daunting in and of themselves, don't make things worse by using symbols in your source.
--  Cédric




I mainly use Eclipse and I really like how when I hover the mouse over various parts of the code I get javadoc tool-tips. One thing I really like about these tool-tips is you can click to keep them open, re-size them, click links and go back and forth. The main thing is by integrating the javadoc with the tool-tips it can really lessen the WTF factor considerably.

Can something similar be done in Scala IDEs? Maybe even going beyond the scaladoc to some mechanism the helps people unfamiliar with the domain, or particular library/API style to better fathom what things mean?

Cheers, Eric

On 2011-11-20 11:55 PM, Jed Wesley-Smith wrote:
This is such an overstated straw-man argument.
Any symbol's utility is entirely derived from from its cognitive associativity. If you see a symbol and relate it to a useful concept it is a useful symbol to you. + is useful because almost everyone learns addition at an early age, and the association is obvious. Reusing it for string concatenation complicates matters though as this is not a commutative operation. Note that overloading is the problem here and not the use of a non-ascii symbol.
If I use a different symbol, say "zusatz", have I improved anything? Clearly I have not, unless I am German. For all non-German speakers this has no associativity and is less useful from a universal understandability point of view.
However, there are many things in computing and math that are not so universally understood. Some things that are very specific to certain domains, or even sub-domains. Is it necessary that symbols within these domains adopt a strict latin alpha-numeric symbolic structure?
The answer of course is, it depends. Some things have clear and well understood alphanumeric names. Sometimes they do not at all, and make more sense as "operators". Consider:
(3.some |@| 4.some |@| 5.some) { _ + _ + _ }
what would you call |@| ? it combines arguments into an ApplicativeBuilder, so maybe applicativeBuild?
(3.some applicativeBuild 4.some applicativeBuild 5.some) { _ + _ + _ }
This is clearly longer, and I'd argue less readable (some will say less correct as well).
Now, the first time a non-haskell background Scala newbie comes across this they are going to be confused. They are going to wonder what the hell is this |@| thing and they'll spend some time researching it. Later on though they might wonder how they are going to do combine three Option[A]s and an (A, A, A) => B to get an Option[B] and remember that surprisingly useful |@| thing.
The problem isn't the terms themselves – the problem is whether or not they encode something that will be useful later on. Are the abstractions useful – if they are then they will get used and the names will get association due to reuse.
I think Perl has a lot to answer for here though. Everyone automatically says "Perl has symbols, Perl was bad, confusing, unmaintainable – Ergo: Symbols are bad".
I am not saying I agree with indiscriminate usage of symbols, only that usage of symbols is not in itself a bad thing, certainly not "The price paid in terms of readability is extremely high and indefensible.".
On 21 November 2011 15:49, Dinesh V <viswad [at] gmail [dot] com" target="_blank" rel="nofollow">viswad [at] gmail [dot] com> wrote:

Usage of non-obvious symbols and operators is one of the most significant factors leading to all this perception of complexity.  Perhaps the single most important aspect holding back Scala adoption in my mind.   Cryptic operators may save key strokes.  The price paid in terms of readability is extremely high and indefensible.

Gary Pampara
Joined: 2010-09-12,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity

> Note that Scala doesn't have operator overloading, the problem we're
> discussing is that methods can be named using arbitrary UTF characters.

I'm sorry, but how is this a problem? Even remotely? Symbols are used
everywhere, in all kinds of fields. Where does it say that symbols
cannot be used in a coherent manner that will aid the description of
logic or a solution?

This is purely a familiarity problem.

> IDE's already support this, it's called Javadoc :-)
> But the problem with symbols is much deeper than this. For example, suppose
> you come across |@| in Scalaz code and you have never studied Haskell, much
> less applicatives. Your first reflex will be to google it. Searching for |@|
> alone yields no result (unsurprisingly) but "scalaz |@|" shows more promise.
> However, the first two links point to Scalaz' main project page, and none of
> them even contain "|@|" anywhere.
>
> This result should be obvious if you know how Google search works (it
> probably simply discarded |@| form the query) but it's one of the main
> problems with symbols: they're hard to look up.
> Google code search is of no help either, by the way.
> You're pretty much dead in the water at this point.
> So your only hope is to dive into the Scalaz code. Finding the definition of
> |@| is pretty easy, but take a look at the source... Yup, not a single
> comment, and a strong warning at the top telling you not to use it directly.
> To make things worse, "applicative builders" don't exist in Haskell, so even
> if you decided to bite the bullet and educate yourself in Haskell (never a
> bad idea, but not everybody has the time), walking the ladder from functors
> to applicatives and finally to monads will be a long and arduous climb.

It might be a climb, but the end results speak for themselves.
Additionally, there is a "culture" with programming these days that
the IDE seems to do more than the developer. This is truly concerning.

An IDE is nothing more than a tool (as is everything else) you need to
use it correctly. you can be just as productive with Scaladoc and a
text editor. Perhaps the issues are with how things are defined,
rather with how people expect that new and important concepts that
need to be understood require a little effort?

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: problems of scala complexity
2011/11/21 Cédric Beust ♔ <cedric [at] beust [dot] com>

But the problem with symbols is much deeper than this. For example, suppose you come across |@| in Scalaz code and you have never studied Haskell, much less applicatives. Your first reflex will be to google it. Searching for |@| alone yields no result (unsurprisingly) but "scalaz |@|" shows more promise. However, the first two links point to Scalaz' main project page, and none of them even contain "|@|" anywhere.

This is not an argument against well-chosen symbolic methods (i.e. operators), but it is an argument in favor of fanatic efforts at documentation given that some of the usual approaches do not work.  Cryptic anything is bad, not just symbolic method names.  (Thus, poorly-chosen method names are bad, whether it is << instead of print, or dividedBy instead of /.)

|@| is a bit of a questionable case.  In general, I think
  a :: b :: Nil
  x #:: y #:: Stream.Empty
is less clear than
  List(a,b)
  Stream(a,b)
and thus
  a |@| b
would be less ideal than one of
  ApF(a,b)
  (a,b) toApF
in most cases.

On the other hand, mimicing BNF with ~ is so incredibly helpful that it basically makes the difference between me using parser combinators and not.  If one is copying some nontrivial structure from a document that uses the circled star notation, one could be equally desiring of |@|.

Any time one starts writing
  a.plus(b.plus(c),b.times(d))  // a + b + c + b*d
it is a clear indication that symbolic method names are needed.

  --Rex

Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: problems of scala complexity
2011/11/21 Rex Kerr <ichoran [at] gmail [dot] com>
and thus  a |@| b
would be less ideal than one of
  ApF(a,b)
  (a,b) toApF
in most cases.

Actually, it ends up being a choice between:
  (a |@| b)(_ + _)
  ApF[({type l[a]=State[Int, a]})#l](a, b)(_ + _)
  type IntState[a]=State[Int, A]  ApF[IntState](a, b)(_ + _)
As I said earlier, I'm pursuing alternatives, but there are some limitations in scalac that even Miles hasn't been able to dream up a way around. We're pretty close, though, and some small changes we need in scalac are on the horizon.
-jason
hseeberger
Joined: 2008-12-27,
User offline. Last seen 1 year 25 weeks ago.
Re: problems of scala complexity
By the way: I don't believe the "Java Joe is too stupid, all (s)he knows is how to use Google" story. Therefore it does not matter whether it is |@| or , (a tuple).
Heiko

--
Heiko Seeberger
Twitter: hseeberger
Blog: heikoseeberger.name
Company: Typesafe - Enterprise-Grade Scala from the Experts
Author of Durchstarten mit Scala, a German tutorial-style Scala book


On Nov 21, 2011, at 7:08 PM, Jason Zaugg wrote:
2011/11/21 Rex Kerr <ichoran [at] gmail [dot] com>
and thus  a |@| b
would be less ideal than one of
  ApF(a,b)
  (a,b) toApF
in most cases.

Actually, it ends up being a choice between:
  (a |@| b)(_ + _)
  ApF[({type l[a]=State[Int, a]})#l](a, b)(_ + _)
  type IntState[a]=State[Int, A]  ApF[IntState](a, b)(_ + _)
As I said earlier, I'm pursuing alternatives, but there are some limitations in scalac that even Miles hasn't been able to dream up a way around. We're pretty close, though, and some small changes we need in scalac are on the horizon.
-jason

Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: problems of scala complexity

It matters, it matters: for instance (a tuple) doesn’t compile… J J

 

From: scala-debate [at] googlegroups [dot] com [mailto:scala-debate [at] googlegroups [dot] com] On Behalf Of Heiko Seeberger
Sent: November-21-11 2:00 PM
To: scala-debate [at] googlegroups [dot] com
Subject: Re: [scala-debate] problems of scala complexity

 

By the way: I don't believe the "Java Joe is too stupid, all (s)he knows is how to use Google" story. Therefore it does not matter whether it is |@| or , (a tuple).

 

Heiko


--


Heiko Seeberger
Twitter: hseeberger
Blog: heikoseeberger.name
Company: Typesafe - Enterprise-Grade Scala from the Experts
Author of Durchstarten mit Scala, a German tutorial-style Scala book

 

On Nov 21, 2011, at 7:08 PM, Jason Zaugg wrote:



2011/11/21 Rex Kerr <ichoran [at] gmail [dot] com>

and thus

  a |@| b
would be less ideal than one of
  ApF(a,b)
  (a,b) toApF
in most cases.

 

Actually, it ends up being a choice between:

 

  (a |@| b)(_ + _)

 

  ApF[({type l[a]=State[Int, a]})#l](a, b)(_ + _)

 

  type IntState[a]=State[Int, A]

  ApF[IntState](a, b)(_ + _)

 

As I said earlier, I'm pursuing alternatives, but there are some limitations in scalac that even Miles hasn't been able to dream up a way around. We're pretty close, though, and some small changes we need in scalac are on the horizon.

 

-jason

 

Tony Morris
Joined: 2008-12-19,
User offline. Last seen 30 weeks 4 days ago.
Re: problems of scala complexity


On Nov 22, 2011 3:54 AM, "Rex Kerr" <ichoran [at] gmail [dot] com> wrote:
>
> 2011/11/21 Cédric Beust ♔ <cedric [at] beust [dot] com>
>>
>>
>> But the problem with symbols is much deeper than this. For example, suppose you come across |@| in Scalaz code and you have never studied Haskell, much less applicatives. Your first reflex will be to google it. Searching for |@| alone yields no result (unsurprisingly) but "scalaz |@|" shows more promise. However, the first two links point to Scalaz' main project page, and none of them even contain "|@|" anywhere.
>
>
> This is not an argument against well-chosen symbolic methods (i.e. operators), but it is an argument in favor of fanatic efforts at documentation given that some of the usual approaches do not work.  Cryptic anything is bad, not just symbolic method names.  (Thus, poorly-chosen method names are bad, whether it is << instead of print, or dividedBy instead of /.)
>
> |@| is a bit of a questionable case. 

It also has nothing to do with haskell. It doesn't appear in haskell anywhere and exists solely for purposes that are specific to scala.

That's twice now that someone has decided to appeal to haskell unwarranted on the nature of |@|, which is an obvious indication that there has been no effort whatsoever to gather any understanding of the subject matter. In my mind that is an immediate forfeiture and it is no wonder this discussion goes in circles.

Cédric Beust ♔
Joined: 2011-06-17,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity

On Mon, Nov 21, 2011 at 12:06 PM, Tony Morris <tmorris [at] tmorris [dot] net> wrote:

It also has nothing to do with haskell. It doesn't appear in haskell anywhere and exists solely for purposes that are specific to scala.

That's twice now that someone has decided to appeal to haskell unwarranted on the nature of |@|, which is an obvious indication that there has been no effort whatsoever to gather any understanding of the subject matter.

I think we're running in circles mostly because you don't seem to even bother reading the messages you reply to. Here is what I wrote, again:
To make things worse, "applicative builders" don't exist in Haskell, so even if you decided to bite the bullet and educate yourself in Haskell (never a bad idea, but not everybody has the time), walking the ladder from functors to applicatives and finally to monads will be a long and arduous climb.
 -- Cédric

In my mind that is an immediate forfeiture and it is no wonder this discussion goes in circles.


Tony Morris
Joined: 2008-12-19,
User offline. Last seen 30 weeks 4 days ago.
Re: problems of scala complexity

Oh look it's mister honest.

On Nov 22, 2011 7:02 AM, "Cédric Beust ♔" <cedric [at] beust [dot] com> wrote:

On Mon, Nov 21, 2011 at 12:06 PM, Tony Morris <tmorris [at] tmorris [dot] net> wrote:

It also has nothing to do with haskell. It doesn't appear in haskell anywhere and exists solely for purposes that are specific to scala.

That's twice now that someone has decided to appeal to haskell unwarranted on the nature of |@|, which is an obvious indication that there has been no effort whatsoever to gather any understanding of the subject matter.

I think we're running in circles mostly because you don't seem to even bother reading the messages you reply to. Here is what I wrote, again:
To make things worse, "applicative builders" don't exist in Haskell, so even if you decided to bite the bullet and educate yourself in Haskell (never a bad idea, but not everybody has the time), walking the ladder from functors to applicatives and finally to monads will be a long and arduous climb.
 -- Cédric

In my mind that is an immediate forfeiture and it is no wonder this discussion goes in circles.


etorreborre 2
Joined: 2011-02-23,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity
Hi Bill,
I just want to point out that "^^" in specs2 was not completely taken out of thin air. I actually took the inspiration from the Parsers combinators library, because this is how you transform a Parser[T] into a Parser[U]. The analogy here is similar, where you transform a Matcher[T] into a Matcher[U]. So if you learn the specs2 way, you will also get the idea for Parsers. "compose" would not fit here because specs matchers are not Function1s.
About DataTables, I do agree that they're heavy on syntax but they fit my purpose which is to get a visually tabular notation for my examples. Which drives me to say that I wrote specs/specs2 first and foremost to learn Scala, and to give myself a library which I enjoy using. As it so happens, other people enjoy using it too, and I'm very dedicated to supporting them with whatever silly bug / sick feature I impose upon them. But then I think we should accept that one size does not fit all. There is room for different tastes in the ecosystem and we should just be grateful that Scala, as a language, gives us several ways of expressing ourselves. I love specs/specs2 because that's how I like it and I also love ScalaTest because that gives other users the possibility to use something different without having to push me in a direction where I might not want to go. I also love it because you gave me ideas for specs2 and because you're pushing hard to make sure that ScalaTest is not breaking client code and this is a lesson for every library maintainer.
It would be a sad world if we only had ScalaTest and not specs2, Scalatra and not Unfiltered, and so on just because we have to please the majority.
Eric.
Bill Venners
Joined: 2008-12-18,
User offline. Last seen 31 weeks 5 days ago.
Re: problems of scala complexity

Hi Eric,

On Nov 21, 2:36 pm, etorreborre wrote:
> Hi Bill,
>
> I just want to point out that "^^" in specs2 was not completely taken out
> of thin air. I actually took the inspiration from the Parsers combinators
> library,
> because this is how you transform a Parser[T] into a Parser[U]. The analogy
> here is similar, where you transform a Matcher[T] into a Matcher[U]. So if
> you learn the specs2 way, you will also get the idea for Parsers. "compose"
> would not fit here because specs matchers are not Function1s.
>
That's interesting. I hadn't made that connection with the parser
combinators "eyebrows" operator, but I see it now that you mention
it.

> About DataTables, I do agree that they're heavy on syntax but they fit *my*purpose which is to get a visually tabular notation for my examples. Which
> drives me to say that I wrote specs/specs2 first and foremost to learn
> Scala, and to give myself a library which I enjoy using. As it so happens,
> other people enjoy using it too, and I'm very dedicated to supporting them
> with whatever silly bug / sick feature I impose upon them. But then I think
> we should accept that one size does not fit all. There is room for
> different tastes in the ecosystem and we should just be grateful that
> Scala, as a language, gives us several ways of expressing ourselves. I love
> specs/specs2 because that's how I like it and I also love ScalaTest because
> that gives other users the possibility to use something different without
> having to push me in a direction where I might not want to go. I also love
> it because you gave me ideas for specs2 and because you're pushing hard to
> make sure that ScalaTest is not breaking client code and this is a lesson
> for every library maintainer.
>
> It would be a sad world if we only had ScalaTest and not specs2, Scalatra
> and not Unfiltered, and so on just because we have to please the majority.
>
I wholeheartedly agree. Sorry, I'm not trying to say we should all do
things the same way, just that a Scala API designer can, if they try,
usually find a way to avoid a made-up, non-obvious operator. I
highlighted specs because I also wrote a test framework and could
point out specific examples of alternatives to using non-obvious
operators. If I'd written a build system I might have picked on sbt. I
think those <+= etc symbols in sbt will make it harder for casual
users to figure out sbt build files, and I expect a great many users
of build tools are casual, i.e., non-expert-in-the-build-tool ones.
But it is hard for me to say for sure what might be an alternative way
to avoid those operators given I haven't ever tried to create a build
tool. I haven't walked in those shoes. Maybe there aren't any
satisfying alternatives to those operators. I myself did put one non-
obvious operator in ScalaTest, the dash in FreeSpec:

http://www.scalatest.org/scaladoc/1.6.1/#org.scalatest.FreeSpec

I thought long and hard to find a way around that, but there just
wasn't one that was as satisfying, so in it went even though it was
non-obvious.

Anyway, the I think the Scala community has definitely benefited from
having multiple test frameworks, web frameworks, etc., with different
design goals and designer tastes and visions to chose from. We inspire
each other and serve different niches. But still I think the community
of Scala library designers in general has been way too loose on the
operator front lately, and I think that lessens the approachability of
Scala to the masses to some extent. They aren't the end of the world,
but I think Scala would be more approachable if we used fewer
operators.

Bill

vpatryshev
Joined: 2009-02-16,
User offline. Last seen 1 year 24 weeks ago.
Re: Re: problems of scala complexity
Right. "Freedom from best practices". I've been using Java for many years, and still cannot always figure out whether this or that "practice" is just a stupid memory of old days of Java 1.1 or something that makes sense today, when the semantics of JVM has changed so much (I mean multicore concurrent coding style).

Thanks,
-Vlad


On Sun, Nov 20, 2011 at 5:06 AM, Oleg Galako <ojowoo [at] gmail [dot] com> wrote:
I've been using Scala for about 2 years (10 years of Java before that), and i've decided to post here just because of how absolutely precise (in my opinion) Martin's points are.- if you just do your job with Scala instead of looking for reasons why it is complex or something like that, it just starts to work in your hands and you like it more and more - the 'complexity' feeling is mostly the feeling of freedom from (or absence of) 'best practices'- the only thing we need to bust the 'complexity' myth is good libraries/frameworks

Bernd Johannes
Joined: 2011-01-28,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity

Am Dienstag, 22. November 2011, 02:04:42 schrieb Bill Venners:
> Hi Eric,
...
> Anyway, the I think the Scala community has definitely benefited from
> having multiple test frameworks, web frameworks, etc., with different
> design goals and designer tastes and visions to chose from. We inspire
> each other and serve different niches. But still I think the community
> of Scala library designers in general has been way too loose on the
> operator front lately, and I think that lessens the approachability of
> Scala to the masses to some extent. They aren't the end of the world,
> but I think Scala would be more approachable if we used fewer
> operators.
>
> Bill

As Eric said - one size doesn't fit all. I suppose heavy operator use will be
here to stay. Scala gives this option - people will use it.

What I can imagine to ease this situation for those who prefer descriptive
names (the "casual user"): if we had a possibility to add a descriptive alias
(e.g. as annotation) which could be used by IDEs to support hoover help for
those operators. This could help even in the absence of documentation.

Maybe it would be enough just to add the "long name" as the first word in the
docs to enable a quick "ah yes - that was it".

At least everybody delivering public libraries should be aware that operators
while intended to speed up or tidy up source code can achieve the opposite.

Just my 5cents
Greetings
Bernd

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: Re: problems of scala complexity

On 2011-11-21 9:56 PM, Bernd Johannes wrote:
> Am Dienstag, 22. November 2011, 02:04:42 schrieb Bill Venners:
>> Hi Eric,
> ...
>> Anyway, the I think the Scala community has definitely benefited from
>> having multiple test frameworks, web frameworks, etc., with different
>> design goals and designer tastes and visions to chose from. We inspire
>> each other and serve different niches. But still I think the community
>> of Scala library designers in general has been way too loose on the
>> operator front lately, and I think that lessens the approachability of
>> Scala to the masses to some extent. They aren't the end of the world,
>> but I think Scala would be more approachable if we used fewer
>> operators.
>>
>> Bill
> As Eric said - one size doesn't fit all. I suppose heavy operator use will be
> here to stay. Scala gives this option - people will use it.
>
> What I can imagine to ease this situation for those who prefer descriptive
> names (the "casual user"): if we had a possibility to add a descriptive alias
> (e.g. as annotation) which could be used by IDEs to support hoover help for
> those operators. This could help even in the absence of documentation.
>
> Maybe it would be enough just to add the "long name" as the first word in the
> docs to enable a quick "ah yes - that was it".
>
> At least everybody delivering public libraries should be aware that operators
> while intended to speed up or tidy up source code can achieve the opposite.
>
> Just my 5cents
> Greetings
> Bernd

Ka-Ching :-)

Applause!

There are many situations where I find myself the 'casual user' - such
as, when I have to find and fix a defect that has been assigned to me in
someone else's code, or when I am trying to learn about some new library
or other technology and I am looking at the code for the first time
trying to reverse engineer it in my mind.

While a tight team of expert Scala programmers is the ideal situation,
in a large enterprise legacy code is the norm - at least in my
experience. Legacy code usually results in people other than the authors
working on the code, in many cases the authors have long since moved on
to somewhere else and are usually inaccessible.

I really don't want to put a crimp in anyone's coding style, but it
would help enormously if the IDE could help reveal the intent of the
original authors in situations where it is not obvious.

Cheers, (the other) Eric

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: problems of scala complexity
Another idea: maybe the convention should be that all symbolic methods should be a simple alias for an alphabetic method.
def ^%[A,B](x: A, y: B, z: Int) = fgh(x,y,z)


On Tue, Nov 22, 2011 at 1:11 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
On 2011-11-21 9:56 PM, Bernd Johannes wrote:
Am Dienstag, 22. November 2011, 02:04:42 schrieb Bill Venners:
Hi Eric,
...
Anyway, the I think the Scala community has definitely benefited from
having multiple test frameworks, web frameworks, etc., with different
design goals and designer tastes and visions to chose from. We inspire
each other and serve different niches. But still I think the community
of Scala library designers in general has been way too loose on the
operator front lately, and I think that lessens the approachability of
Scala to the masses to some extent. They aren't the end of the world,
but I think Scala would be more approachable if we used fewer
operators.

Bill
As Eric said - one size doesn't fit all. I suppose heavy operator use will be
here to stay. Scala gives this option - people will use it.

What I can imagine to ease this situation for those who prefer descriptive
names (the "casual user"): if we had a possibility to add a descriptive alias
(e.g. as annotation) which could be used by IDEs to support hoover help for
those operators. This could help even in the absence of documentation.

Maybe it would be enough just to add the "long name" as the first word in the
docs to enable a quick "ah yes - that was it".

At least everybody delivering public libraries should be aware that operators
while intended to speed up or tidy up source code can achieve the opposite.

Just my 5cents
Greetings
Bernd

Ka-Ching :-)

Applause!

There are many situations where I find myself the 'casual user' - such as, when I have to find and fix a defect that has been assigned to me in someone else's code, or when I am trying to learn about some new library or other technology and I am looking at the code for the first time trying to reverse engineer it in my mind.

While a tight team of expert Scala programmers is the ideal situation, in a large enterprise legacy code is the norm - at least in my experience. Legacy code usually results in people other than the authors working on the code, in many cases the authors have long since moved on to somewhere else and are usually inaccessible.

I really don't want to put a crimp in anyone's coding style, but it would help enormously if the IDE could help reveal the intent of the original authors in situations where it is not obvious.

Cheers, (the other) Eric

Bill Venners
Joined: 2008-12-18,
User offline. Last seen 31 weeks 5 days ago.
Re: problems of scala complexity

Hi Naftoli,

On Nov 21, 10:16 pm, Naftoli Gugenheim wrote:
> Another idea: maybe the convention should be that all symbolic methods
> should be a simple alias for an alphabetic method.
>
> def ^%[A,B](x: A, y: B, z: Int) = fgh(x,y,z)
>
Perhaps a better alias might be:

def ^%[A,B](x: A, y: B, z: Int) = wtf(x,y,z)

I like Bernd's idea of some kind of scaladoc notation that can be used
for hover help over operator methods. That seems like it could help a
lot. Wait, don't they already pop up scaladoc?

Bill

> On Tue, Nov 22, 2011 at 1:11 AM, Eric Kolotyluk wrote:
>
>
>
>
>
>
>
> > On 2011-11-21 9:56 PM, Bernd Johannes wrote:
>
> >> Am Dienstag, 22. November 2011, 02:04:42 schrieb Bill Venners:
>
> >>> Hi Eric,
>
> >> ...
>
> >>> Anyway, the I think the Scala community has definitely benefited from
> >>> having multiple test frameworks, web frameworks, etc., with different
> >>> design goals and designer tastes and visions to chose from. We inspire
> >>> each other and serve different niches. But still I think the community
> >>> of Scala library designers in general has been way too loose on the
> >>> operator front lately, and I think that lessens the approachability of
> >>> Scala to the masses to some extent. They aren't the end of the world,
> >>> but I think Scala would be more approachable if we used fewer
> >>> operators.
>
> >>> Bill
>
> >> As Eric said - one size doesn't fit all. I suppose heavy operator use
> >> will be
> >> here to stay. Scala gives this option - people will use it.
>
> >> What I can imagine to ease this situation for those who prefer descriptive
> >> names (the "casual user"): if we had a possibility to add a descriptive
> >> alias
> >> (e.g. as annotation) which could be used by IDEs to support hoover help
> >> for
> >> those operators. This could help even in the absence of documentation.
>
> >> Maybe it would be enough just to add the "long name" as the first word in
> >> the
> >> docs to enable a quick "ah yes - that was it".
>
> >> At least everybody delivering public libraries should be aware that
> >> operators
> >> while intended to speed up or tidy up source code can achieve the
> >> opposite.
>
> >> Just my 5cents
> >> Greetings
> >> Bernd
>
> > Ka-Ching :-)
>
> > Applause!
>
> > There are many situations where I find myself the 'casual user' - such as,
> > when I have to find and fix a defect that has been assigned to me in
> > someone else's code, or when I am trying to learn about some new library or
> > other technology and I am looking at the code for the first time trying to
> > reverse engineer it in my mind.
>
> > While a tight team of expert Scala programmers is the ideal situation, in
> > a large enterprise legacy code is the norm - at least in my experience.
> > Legacy code usually results in people other than the authors working on the
> > code, in many cases the authors have long since moved on to somewhere else
> > and are usually inaccessible.
>
> > I really don't want to put a crimp in anyone's coding style, but it would
> > help enormously if the IDE could help reveal the intent of the original
> > authors in situations where it is not obvious.
>
> > Cheers, (the other) Eric

Matthew Pocock 3
Joined: 2010-07-30,
User offline. Last seen 42 years 45 weeks ago.
Re: problems of scala complexity


2011/11/21 Rex Kerr <ichoran [at] gmail [dot] com>

This is not an argument against well-chosen symbolic methods (i.e. operators), but it is an argument in favor of fanatic efforts at documentation given that some of the usual approaches do not work.  Cryptic anything is bad, not just symbolic method names.  (Thus, poorly-chosen method names are bad, whether it is << instead of print, or dividedBy instead of /.)

I agree. If you have /. as the def, it isn't google-visible. However, if its scaladoc includes text like 'divide' and 'divided by', there's a fighting chance people will be able to find it. Symbols can be far clearer than names in some situations, but without scaladoc they can't be googled for, and without a federated, type-aware scala search engine, in practice google is what people use to find out about things they aren't intimately knowledgeable about..
Matthew 

  --Rex




--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle Universitymailto: turingatemyhamster [at] gmail [dot] com gchat: turingatemyhamster [at] gmail [dot] commsn: matthew_pocock [at] yahoo [dot] co [dot] uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity

On 2011-11-20 7:58 PM, Bill Venners wrote:
> Hi Kevin,
>
> I just noticed this thread.
>
> On Nov 20, 5:55 am, Kevin Wright wrote:
>> Oh absolutely! It also doesn't help that many of our current "high
>> profile" libraries are particularly heavy on symbolic method names. Things
>> are improving in at least two notable libraries though:
>>
>> - Akka has culled its symbols down to essentially just ! and ?
>> - scalaz is near the end of a rewrite that will make it far easier to use
>> non-symbolic equivalents for many concepts
>>
> Hey, you forgot ScalaTest, which I would point out was designed with
> the philosophy of: *avoid any operators that users are not already
> experts in.*

Good philosophy.

> So ScalaTest originally just had ===, which means
> equality,< for less than,> for greater than,<= for less than or
> equals, and>= for greater than or equals. At some point I did add one
> non-obvious operator, the - in FreeSpec, because after much searching
> for a way to avoid it, it was the best solution. In 2.1, which is
> coming next year, I'll be adding a few more operators. One is +/- as
> an alias for plusOrMinus. This one has been requested by multiple
> users over time, and I've done several informal surveys asking people
> if they can guess its meaning, and people always have. So I decided to
> add that one. I'm also adding&&, ||, and ! for boolean-like
> expressions with the triple equals operator, and they will mean
> exactly what they look like they mean. Lots of new features are
> coming, but no other operators than these few that pass the "obvious
> test."
>
> I have been bummed that so many non-obvious operators have been
> showing up in Scala APIs. The trouble is that although obvious
> operators makes code easier to read (a + b is nicer than a add b), non-
> obvious operators makes code harder for casual users to understand,
> because they have to look up what all the meanings are. And a lot of
> users are casual, in that they don't use your library often enough to
> remember the symbols for whatever reason. And to Java programmers, at
> least, it makes Scala code look cryptic.
>
> Moreover I would claim that 99% of the time, if you work at it, you
> can find a better alternative to a non-obvious operator. Compare Specs
> tables to ScalaTest tables. Specs uses lots of operators:
>
> http://etorreborre.github.com/specs2/guide/org.specs2.guide.Matchers.htm...
>
> ScalaTest doesn't use any:
>
> http://www.scalatest.org/user_guide/table_driven_property_checks#testing...
>
> You just don't need non-obvious operators most of the time. There's a
> better way if you look for it.
>
> The feeling I get sometimes from all this is that we're a bunch of
> really smart, passionate Scala experts designing libraries for each
> other, rather than for the mainstream. Because we can certainly learn
> and understand each others cryptic operators, and maybe even enjoy the
> conciseness of the expressions we can make out of them. But the
> mainstream developer is not that interested. It's not to say they
> aren't smart. They may be super-smart, but just passionate about
> designing airplane wings or getting their startup off the ground or
> something else rather than becoming experts in our libraries. They're
> just not that into us.

Well said.

I would add, that for any software developer use whatever style you like
just so long as you know who your audience is. If you are part of a
small clique of experts in something, go with whatever works for you.
However, if you want to foster broad appeal of your APIs or libraries,
favor clarity and familiarity over concise expressiveness.

I would not even be opposed to going beyond the ASCII set of characters
and using some math or Greek symbols where they are exceptionally clear
- such as ≠ ≤ ≥ but there needs to be an easy/obvious way for people
without unicode or UTF-8 support to interoperate, and I am not sure we
are really there yet.

Cheers, Eric

>
> Bill
>
>> Specs2 uses more symbols that specs1, but they're tightly contained and
>> well documented, so this isn't a great concern. I'm not so convinced about
>> the mixed identifiers (e.g. be_==), but it does offer alternative notations
>> and I'm generally comfortable allowing slightly different rules to apply in
>> a test framework.
>>
>> Lift seems to be using ever more symbols and mixed identifiers (e.g. #> and
>> unsafe_!), but the range of web frameworks now available for Scala means
>> that developers have alternatives to chose from if they disagree with
>> Lift's decisions.
>>
>> Databinder Dispatch is one of the few libraries remaining that is still
>> symbol-heavy, not moving towards a design with at least the *option* of
>> fewer symbols, and doesn't really have a viable alternative (for example,
>> nothing else I know of can offer OAuth support out of the box). The saving
>> grace of dispatch is that it uses a convention which is internally very
>> consistent. Usage of Dispatch is also likely to be constrained to just a
>> small corner of any codebase.
>>
>> On 20 November 2011 13:06, Oleg Galako wrote:
>>
>>
>>
>>
>>
>>
>>
>>> I've been using Scala for about 2 years (10 years of Java before that),
>>> and i've decided to post here just because of how absolutely precise (in my
>>> opinion) Martin's points are.
>>> - if you just do your job with Scala instead of looking for reasons why it
>>> is complex or something like that, it just starts to work in your hands and
>>> you like it more and more
>>> - the 'complexity' feeling is mostly the feeling of freedom from (or
>>> absence of) 'best practices'
>>> - the only thing we need to bust the 'complexity' myth is good
>>> libraries/frameworks

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland