problems of scala complexity

I am moving this from scala-user to scala-debate upon request. First, a bit of context (copied):
    However, as I've thought more about it, I've realized that what enterprises need is _controllable_ complexity. If you have 2,000 software engineers using Scala (which is what we all hope for, right?), then some of them _will_ use the most complex features because they think it's cool, regardless of corporate guidelines.
Next, to put this into my own personal perspective: Until recently, I dismissed arguments that Scala was too complex on the grounds that "you can always use as simply a more productive Java".
More recently, I have seen arguments that convinced me that a significant problems with Scala was that _the possibility of using it an an unduly complex manner restricted its corporate applicability_. I see this as a highly valid point. (Large) corporations need to expect that engineers are, to some degree, interchangeable. I think even Google must have that approach these days. It should be expected that an engineer can be dumped into another engineers' job and be able, int not too long, to pick up on what is going on.
I don't believe this is possible with "full Scala". For example, look at Tony M. and (in addition) scalaz. How many engineers could pick up on code engineered in that universe? Very, very few.
I know from experience that given enough people, developers who are completely incompetent in a technology will nonetheless use the extreme abilities of that technology. For example, I once spent several nasty months fixing the "code" of a "developer" who knew virtually nothing about C++, but who nonetheless decided she could overload operators at her discretion. Do you have any idea how difficult it is to understand code where "+"  means "accumulate into a queue"?
Given, than , I refer back to the (implicit question) of my original post: does it make sense to allow the enterprise to control the degree of complexity of Scala that is used? (I think it does)
I understand that such a topic may be part of the scala language discussions. If so, apologies, I have not seen it.
Ken

Re: Re: problems of scala complexity

Added by kolotyluk on 2011-11-22, 07:17

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

Re: Re: problems of scala complexity

Added by Naftoli Gugenheim on 2011-11-22, 07:37
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

Re: problems of scala complexity

Added by Bill Venners on 2011-11-22, 08:37

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

Re: problems of scala complexity

Added by Jason Zaugg on 2011-11-21, 09:37
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

Re: problems of scala complexity

Added by Joshua.Suereth on 2011-11-21, 16:47
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

Re: problems of scala complexity

Added by Tony Morris 2 on 2011-11-21, 09:07

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

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-20, 15:17


On Nov 20, 2011 2:55 PM, "Kevin Wright" <kev [dot] lee [dot] wright [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 ?

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

> - scalaz is near the end of a rewrite that will make it far easier to use non-symbolic equivalents for many concepts
>
> 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 <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
>
>
>

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-20, 15:17


On Nov 20, 2011 2:55 PM, "Kevin Wright" <kev [dot] lee [dot] wright [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 ?

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

> - scalaz is near the end of a rewrite that will make it far easier to use non-symbolic equivalents for many concepts
>
> 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 <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
>
>
>

Re: Re: problems of scala complexity

Added by Ken McDonald on 2011-11-20, 21:27

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

Ken

Re: Re: problems of scala complexity

Added by Ken McDonald on 2011-11-20, 21:27

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

Ken

Re: Re: problems of scala complexity

Added by Russ P. on 2011-11-20, 22:47


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

Re: Re: problems of scala complexity

Added by Russ P. on 2011-11-20, 22:47


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

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-20, 21:57


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

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-20, 21:47


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

Re: Re: problems of scala complexity

Added by Arif Mustafa on 2011-11-20, 22:17
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

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-20, 22:27


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

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-20, 22:27


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

Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 05:57

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 do not believe this thread is designed to negatively criticize Scala
for being too complicated, I think many of us accept Scala for what it
is. The problems of Scala complexity should not always be problems to be
disputed, they should also be problems to embrace as challenges to
solve. I believe this thread is designed to find ways to safely include
those people, especially the undecided or cautious, into the community
and culture of Scala.

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

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

> 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. Also, I do not
see us wringing our hands any longer, I think this thread is actually
going somewhere productive and should be encouraged.

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

>
> [Cross-posted to scala-user, because it relates to quite a few threads
> there as well]
>

Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 05:57

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 do not believe this thread is designed to negatively criticize Scala
for being too complicated, I think many of us accept Scala for what it
is. The problems of Scala complexity should not always be problems to be
disputed, they should also be problems to embrace as challenges to
solve. I believe this thread is designed to find ways to safely include
those people, especially the undecided or cautious, into the community
and culture of Scala.

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

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

> 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. Also, I do not
see us wringing our hands any longer, I think this thread is actually
going somewhere productive and should be encouraged.

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

>
> [Cross-posted to scala-user, because it relates to quite a few threads
> there as well]
>

Re: problems of scala complexity

Added by odersky on 2011-11-20, 11:37


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


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!

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


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

Re: problems of scala complexity

Added by odersky on 2011-11-20, 11:27


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


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!

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


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

Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 22:57
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

Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 22:57
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

Re: Re: problems of scala complexity

Added by Arif Mustafa on 2011-11-21, 00:27
" 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

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-21, 10:47


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

Re: Re: problems of scala complexity

Added by Viktor Klang on 2011-11-21, 10:37


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

Re: problems of scala complexity

Added by Ken McDonald on 2011-11-20, 21:17
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).  
Don't feel bad about this Martin. I always use :\ and /:, though I'm nowhere near a power user. Why? Because I known that ":" is the "binding side", which lets me identify the "terminal case", which lets me figure  out how to assemble everything. (Yes, I always have to go through this mental process--not brilliant like the rest of you :-) ). In contrast, I can _never_ remember the correct arg order for foldLeft and foldRight. I really don't find those names meaninful at all.
Ken

Re: problems of scala complexity

Added by Ken McDonald on 2011-11-20, 21:17
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).  
Don't feel bad about this Martin. I always use :\ and /:, though I'm nowhere near a power user. Why? Because I known that ":" is the "binding side", which lets me identify the "terminal case", which lets me figure  out how to assemble everything. (Yes, I always have to go through this mental process--not brilliant like the rest of you :-) ). In contrast, I can _never_ remember the correct arg order for foldLeft and foldRight. I really don't find those names meaninful at all.
Ken

Re: problems of scala complexity

Added by Stefan Wagner on 2011-11-20, 16:47

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 20.11.2011 11:20, schrieb martin odersky:

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

I'm not very polyglott in programming languages, and my first
impression, when I saw them was OMG! I'll never get that! But soon I saw
a presentation on video - not sure by whom, which explained the /: as
part from a tree:

op /
/ \ /
op xs(1) / (xs (1))
/ \ /
init xs(0) / (xs (0))

(I hope it will survive the email layout.)

It was a very easy to remember and beautiful explanation, and to my own
surprise, I understood it very fast and learned it in half an hour.

In contrast, I don't know till today which of /: and :\ is 'foldLeft'
and which is foldRight. Okay - the shown example is 'foldLeft', which I
only remember indirectly, because in most cases I use /: and I realized,
most of the times, people use foldLeft, and that both match.

Another observation:
When I first stumbled over the arrow in C++: foo-> bar (x); it raised my
curiosity. After knowing, what it meant, and how to use it, it was a
pleasure to use something new which looked a little mysterious to
newbies. Yes - this is a little bit childish, but aren't we all a little
bit childish?
I guess it is a double-edged sword: it can attract curiosity, if you use
exotic constructs or method names, and it can distract the fearfull
(which shouldn't mean that I am courageous) or more conservative people.

Re: Re: problems of scala complexity

Added by vpatryshev on 2011-11-19, 21:47
Watching interns in our company, I do not observe any "complexity" complaints; they just do it. The coding style is not that good, too many statics and vars; and have to train them to do unittesting properly; and they use foldLeft just to calculate a max of an iterable; but that's all pretty simple and technical and easy to train.

What's interesting, the interns hardly ever use type parameters; and they leisurely mix Either (which I was enforcing), Option and nulls. But they do not have much Java experience either, so it's all the same to them.

Again, they don't seem to see any special "complexity". Seems like for someone who is not used to decades of Java, it's a language like any other. Easier than Haskell.

Thanks,
-Vlad


On Sat, Nov 19, 2011 at 6:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> 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.

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.

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.

Since Scala's enterprise use is still young, best practices have still a some way to develop and stabilize.
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.

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.

[Cross-posted to scala-user, because it relates to quite a few threads there as well]

 -- Martin


Re: Re: problems of scala complexity

Added by ichoran on 2011-11-20, 02:47
On Sat, Nov 19, 2011 at 3:46 PM, Vlad Patryshev <vpatryshev [at] gmail [dot] com> wrote:
 and they use foldLeft just to calculate a max of an iterable

Yay!  I would just as soon do away with redundant extra methods like max and sum and rely upon people to use fold and/or reduce.  Memorizing more methods which you can use instead of powerful generic ones is not an unqualified win.  But in any case, if they think, "Huh, I need to find the largest thing here" and they conclude "Oh, I'll just do a fold!" then I think you've got good people and/or training.

  --Rex

Re: Re: problems of scala complexity

Added by Simon Ochsenreither on 2011-11-20, 18:37
Folding is not always an acceptable choice performance-wise. Look at the disaster of folding in Range#sum for example.

Re: Re: problems of scala complexity

Added by dcsobral on 2011-11-19, 23:07

On Sat, Nov 19, 2011 at 18:46, Vlad Patryshev wrote:
> Watching interns in our company, I do not observe any "complexity"
> complaints; they just do it. The coding style is not that good, too many
> statics and vars; and have to train them to do unittesting properly; and
> they use foldLeft just to calculate a max of an iterable; but that's all
> pretty simple and technical and easy to train.
>
> What's interesting, the interns hardly ever use type parameters; and they
> leisurely mix Either (which I was enforcing), Option and nulls. But they do
> not have much Java experience either, so it's all the same to them.
>
> Again, they don't seem to see any special "complexity". Seems like for
> someone who is not used to decades of Java, it's a language like any other.
> Easier than Haskell.

Given what COBOL looks like, I'm pretty sure COBOL programmers thought
all other languages exceedingly weird and complex. I don't know how
many of them ever transitioned to another language, but that's
irrelevant -- new programmers learned new programming languages. Java
has quite a lot of COBOL potential: it might well outlive all of us,
their programmers might not ever switch to another language, but it
may well decrease in importance until few people would ever consider
learning it.

The complexity to *new programmers* is a much more important metric
than the complexity to existing programmers, and, yet, it is always
the latter that people talk about. Go figure.

Re: Re: problems of scala complexity

Added by dcsobral on 2011-11-19, 23:07

On Sat, Nov 19, 2011 at 18:46, Vlad Patryshev wrote:
> Watching interns in our company, I do not observe any "complexity"
> complaints; they just do it. The coding style is not that good, too many
> statics and vars; and have to train them to do unittesting properly; and
> they use foldLeft just to calculate a max of an iterable; but that's all
> pretty simple and technical and easy to train.
>
> What's interesting, the interns hardly ever use type parameters; and they
> leisurely mix Either (which I was enforcing), Option and nulls. But they do
> not have much Java experience either, so it's all the same to them.
>
> Again, they don't seem to see any special "complexity". Seems like for
> someone who is not used to decades of Java, it's a language like any other.
> Easier than Haskell.

Given what COBOL looks like, I'm pretty sure COBOL programmers thought
all other languages exceedingly weird and complex. I don't know how
many of them ever transitioned to another language, but that's
irrelevant -- new programmers learned new programming languages. Java
has quite a lot of COBOL potential: it might well outlive all of us,
their programmers might not ever switch to another language, but it
may well decrease in importance until few people would ever consider
learning it.

The complexity to *new programmers* is a much more important metric
than the complexity to existing programmers, and, yet, it is always
the latter that people talk about. Go figure.

Re: Re: problems of scala complexity

Added by Lex on 2011-11-19, 23:27
I think that paradoxically Scala is less complex than Java.

The complexity in Java arises from the lack of the right tools to get the job done. So you end up reimplementing the same functionality many time, or pick one of many non-compatible libraries that do so for you. On the ohter hand Scala provides many of such tools right out of the box. So the only complexity is to learn your tools once.

One perception of complexity comes from the functional side of Scala, which looks scary to anverage Java programmer. Another perception of complexity comes from the language flexibility, which looks like custom syntax for everything to an untrained eye. I think a I good way to combat this would be to put together a quick guide on the special syntax, and hammer that early in early on.

Here is a quick list of things that need to be covered before anyone is shown a real piece of Scala code:

blocks resulting in values (also no return statement)
functions
apply() / update()
operators
pattern matching


On Sat, Nov 19, 2011 at 3:56 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
On Sat, Nov 19, 2011 at 18:46, Vlad Patryshev <vpatryshev [at] gmail [dot] com> wrote:
> Watching interns in our company, I do not observe any "complexity"
> complaints; they just do it. The coding style is not that good, too many
> statics and vars; and have to train them to do unittesting properly; and
> they use foldLeft just to calculate a max of an iterable; but that's all
> pretty simple and technical and easy to train.
>
> What's interesting, the interns hardly ever use type parameters; and they
> leisurely mix Either (which I was enforcing), Option and nulls. But they do
> not have much Java experience either, so it's all the same to them.
>
> Again, they don't seem to see any special "complexity". Seems like for
> someone who is not used to decades of Java, it's a language like any other.
> Easier than Haskell.

Given what COBOL looks like, I'm pretty sure COBOL programmers thought
all other languages exceedingly weird and complex. I don't know how
many of them ever transitioned to another language, but that's
irrelevant -- new programmers learned new programming languages. Java
has quite a lot of COBOL potential: it might well outlive all of us,
their programmers might not ever switch to another language, but it
may well decrease in importance until few people would ever consider
learning it.

The complexity to *new programmers* is a much more important metric
than the complexity to existing programmers, and, yet, it is always
the latter that people talk about. Go figure.

--
Daniel C. Sobral

I travel to the future all the time.

Re: Re: problems of scala complexity

Added by Lex on 2011-11-19, 23:27
I think that paradoxically Scala is less complex than Java.

The complexity in Java arises from the lack of the right tools to get the job done. So you end up reimplementing the same functionality many time, or pick one of many non-compatible libraries that do so for you. On the ohter hand Scala provides many of such tools right out of the box. So the only complexity is to learn your tools once.

One perception of complexity comes from the functional side of Scala, which looks scary to anverage Java programmer. Another perception of complexity comes from the language flexibility, which looks like custom syntax for everything to an untrained eye. I think a I good way to combat this would be to put together a quick guide on the special syntax, and hammer that early in early on.

Here is a quick list of things that need to be covered before anyone is shown a real piece of Scala code:

blocks resulting in values (also no return statement)
functions
apply() / update()
operators
pattern matching


On Sat, Nov 19, 2011 at 3:56 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
On Sat, Nov 19, 2011 at 18:46, Vlad Patryshev <vpatryshev [at] gmail [dot] com> wrote:
> Watching interns in our company, I do not observe any "complexity"
> complaints; they just do it. The coding style is not that good, too many
> statics and vars; and have to train them to do unittesting properly; and
> they use foldLeft just to calculate a max of an iterable; but that's all
> pretty simple and technical and easy to train.
>
> What's interesting, the interns hardly ever use type parameters; and they
> leisurely mix Either (which I was enforcing), Option and nulls. But they do
> not have much Java experience either, so it's all the same to them.
>
> Again, they don't seem to see any special "complexity". Seems like for
> someone who is not used to decades of Java, it's a language like any other.
> Easier than Haskell.

Given what COBOL looks like, I'm pretty sure COBOL programmers thought
all other languages exceedingly weird and complex. I don't know how
many of them ever transitioned to another language, but that's
irrelevant -- new programmers learned new programming languages. Java
has quite a lot of COBOL potential: it might well outlive all of us,
their programmers might not ever switch to another language, but it
may well decrease in importance until few people would ever consider
learning it.

The complexity to *new programmers* is a much more important metric
than the complexity to existing programmers, and, yet, it is always
the latter that people talk about. Go figure.

--
Daniel C. Sobral

I travel to the future all the time.

Re: Re: problems of scala complexity

Added by Arif Mustafa on 2011-11-19, 23:47
great points @Aleksey ... what I have noticed is the sentax-complexity that does get in the way... and yes functional concepts to some degree ...

best regards

Arif


On Sat, Nov 19, 2011 at 5:19 PM, Aleksey Nikiforov <lexn82 [at] gmail [dot] com> wrote:
I think that paradoxically Scala is less complex than Java.

The complexity in Java arises from the lack of the right tools to get the job done. So you end up reimplementing the same functionality many time, or pick one of many non-compatible libraries that do so for you. On the ohter hand Scala provides many of such tools right out of the box. So the only complexity is to learn your tools once.

One perception of complexity comes from the functional side of Scala, which looks scary to anverage Java programmer. Another perception of complexity comes from the language flexibility, which looks like custom syntax for everything to an untrained eye. I think a I good way to combat this would be to put together a quick guide on the special syntax, and hammer that early in early on.

Here is a quick list of things that need to be covered before anyone is shown a real piece of Scala code:

blocks resulting in values (also no return statement)
functions
apply() / update()
operators
pattern matching


On Sat, Nov 19, 2011 at 3:56 PM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
On Sat, Nov 19, 2011 at 18:46, Vlad Patryshev <vpatryshev [at] gmail [dot] com> wrote:
> Watching interns in our company, I do not observe any "complexity"
> complaints; they just do it. The coding style is not that good, too many
> statics and vars; and have to train them to do unittesting properly; and
> they use foldLeft just to calculate a max of an iterable; but that's all
> pretty simple and technical and easy to train.
>
> What's interesting, the interns hardly ever use type parameters; and they
> leisurely mix Either (which I was enforcing), Option and nulls. But they do
> not have much Java experience either, so it's all the same to them.
>
> Again, they don't seem to see any special "complexity". Seems like for
> someone who is not used to decades of Java, it's a language like any other.
> Easier than Haskell.

Given what COBOL looks like, I'm pretty sure COBOL programmers thought
all other languages exceedingly weird and complex. I don't know how
many of them ever transitioned to another language, but that's
irrelevant -- new programmers learned new programming languages. Java
has quite a lot of COBOL potential: it might well outlive all of us,
their programmers might not ever switch to another language, but it
may well decrease in importance until few people would ever consider
learning it.

The complexity to *new programmers* is a much more important metric
than the complexity to existing programmers, and, yet, it is always
the latter that people talk about. Go figure.

--
Daniel C. Sobral

I travel to the future all the time.


Re: problems of scala complexity

Added by Justin du coeur on 2011-11-19, 07:07

I'm still trying to decide if I think this argument is reasonable, or rationalization.

I mean, C++ was fabulously complex for its day, full of features that you didn't want the average programmer going near, but the world didn't end - a little education and coding guidelines sufficed just fine.  (Ditto for Ada 95, but admittedly that didn't achieve such reach.)

I understand the argument reasonably well.  But history suggests to me that it is probably more catastrophizing than anything else - a problem mostly solveable by coding guidelines...

On Nov 18, 2011 6:56 PM, "Kenneth McDonald" <ykkenmcd [at] gmail [dot] com> wrote:
I am moving this from scala-user to scala-debate upon request. First, a bit of context (copied):
    However, as I've thought more about it, I've realized that what enterprises need is _controllable_ complexity. If you have 2,000 software engineers using Scala (which is what we all hope for, right?), then some of them _will_ use the most complex features because they think it's cool, regardless of corporate guidelines.
Next, to put this into my own personal perspective: Until recently, I dismissed arguments that Scala was too complex on the grounds that "you can always use as simply a more productive Java".
More recently, I have seen arguments that convinced me that a significant problems with Scala was that _the possibility of using it an an unduly complex manner restricted its corporate applicability_. I see this as a highly valid point. (Large) corporations need to expect that engineers are, to some degree, interchangeable. I think even Google must have that approach these days. It should be expected that an engineer can be dumped into another engineers' job and be able, int not too long, to pick up on what is going on.
I don't believe this is possible with "full Scala". For example, look at Tony M. and (in addition) scalaz. How many engineers could pick up on code engineered in that universe? Very, very few.
I know from experience that given enough people, developers who are completely incompetent in a technology will nonetheless use the extreme abilities of that technology. For example, I once spent several nasty months fixing the "code" of a "developer" who knew virtually nothing about C++, but who nonetheless decided she could overload operators at her discretion. Do you have any idea how difficult it is to understand code where "+"  means "accumulate into a queue"?
Given, than , I refer back to the (implicit question) of my original post: does it make sense to allow the enterprise to control the degree of complexity of Scala that is used? (I think it does)
I understand that such a topic may be part of the scala language discussions. If so, apologies, I have not seen it.
Ken

Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 04:27
You are very much correct Justin - the world did not end.

However, as far as I am concerned C++ is now a dead language. In spite of whatever else anyone else believes I will never again start any new projects with C++ for any reason whatsoever - although I can still see many reasons to write code in C sometimes. Also, as I now wield considerable influence in my own organization I would do everything in my power to prevent any new projects starting in C++ as I believe with my heart an soul it would detrimental to our organization to do so. I do not think I am being elitist (but I am being passionate) as there are so many better choices than C++ such as Java or even C#, and even Scala now.

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

In particular, I really do want to advocate using Scala in our projects and in my organization - but ten years from now I do now want to look back and regret it - they way I now regret advocating C++ once.

If I may use another analogy. I am not an American, but I hear people complain all the time about the American tax system - it is too complex. Some people would simplify it to the point of the tuple (9%, 9%, 9%) - although that is just performance art based on SIM City - but the reality is that it needs something more complex than that to work effectively, yet people still have a very valid point that it is now too complex.

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.

Cheers, Eric

On 2011-11-18 9:57 PM, Justin du coeur wrote:
CAO26FW3Vq4yXjao5w8NjFwEiYnE5F6VKnY5bFt4Q0cUUBLtMDw [at] mail [dot] gmail [dot] com" type="cite">

I'm still trying to decide if I think this argument is reasonable, or rationalization.

I mean, C++ was fabulously complex for its day, full of features that you didn't want the average programmer going near, but the world didn't end - a little education and coding guidelines sufficed just fine.  (Ditto for Ada 95, but admittedly that didn't achieve such reach.)

I understand the argument reasonably well.  But history suggests to me that it is probably more catastrophizing than anything else - a problem mostly solveable by coding guidelines...

On Nov 18, 2011 6:56 PM, "Kenneth McDonald" <ykkenmcd [at] gmail [dot] com" rel="nofollow">ykkenmcd [at] gmail [dot] com> wrote:
I am moving this from scala-user to scala-debate upon request. First, a bit of context (copied):
    However, as I've thought more about it, I've realized that what enterprises need is _controllable_ complexity. If you have 2,000 software engineers using Scala (which is what we all hope for, right?), then some of them _will_ use the most complex features because they think it's cool, regardless of corporate guidelines.
Next, to put this into my own personal perspective: Until recently, I dismissed arguments that Scala was too complex on the grounds that "you can always use as simply a more productive Java".
More recently, I have seen arguments that convinced me that a significant problems with Scala was that _the possibility of using it an an unduly complex manner restricted its corporate applicability_. I see this as a highly valid point. (Large) corporations need to expect that engineers are, to some degree, interchangeable. I think even Google must have that approach these days. It should be expected that an engineer can be dumped into another engineers' job and be able, int not too long, to pick up on what is going on.
I don't believe this is possible with "full Scala". For example, look at Tony M. and (in addition) scalaz. How many engineers could pick up on code engineered in that universe? Very, very few.
I know from experience that given enough people, developers who are completely incompetent in a technology will nonetheless use the extreme abilities of that technology. For example, I once spent several nasty months fixing the "code" of a "developer" who knew virtually nothing about C++, but who nonetheless decided she could overload operators at her discretion. Do you have any idea how difficult it is to understand code where "+"  means "accumulate into a queue"?
Given, than , I refer back to the (implicit question) of my original post: does it make sense to allow the enterprise to control the degree of complexity of Scala that is used? (I think it does)
I understand that such a topic may be part of the scala language discussions. If so, apologies, I have not seen it.
Ken

Re: problems of scala complexity

Added by Jesper Nordenberg on 2011-11-20, 09:57

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. 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'm not saying C++ is a nice language to work with, far from it, but it
gets the job done.

> 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 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). If there is a language feature to use/abuse, developers will
do so.

Btw, what mistakes in the C++ world are you referring to?

> 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). Scala is quite
similar, but with less bad ideas :)

/Jesper Nordenberg

Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 22:27


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

Re: problems of scala complexity

Added by Erik Engbrecht on 2011-11-19, 02:17
I'd phrase the question another way.
Given a large organization that needs to maintain the ability to move people between projects, and a language like Scala that allows for some very diverse forms of expression, how does one keep the intersection of the two from exploding?
I'm not sure it's possible.

Re: Re: problems of scala complexity

Added by Bernd Johannes on 2011-11-19, 13:17

Am Samstag, 19. November 2011, 02:09:24 schrieb Erik Engbrecht:
> I'd phrase the question another way.
>
> Given a large organization that needs to maintain the ability to move
> people between projects, and a language like Scala that allows for some
> very diverse forms of expression, how does one keep the intersection of the
> two from exploding?
>
> I'm not sure it's possible.

While I dismiss the option to disable scala features I see the beauty in being
able to "spot" "critical" sections somehow.

What I am missing currently is a survey giving some basic facts about what
furthers understanding and what blocks understanding if someone is about to
read some given section of code. "Critical" would be anything that makes it
unecessarily hard to understand or follow a concept / solution that is
implemented (the "what it does").

That's not to be mixed with the complexity of a concept/solution in itself. If
I don't understand the concept/solution (the "why") in itself I won't be able
to figure out the meaning of code implementing that concept/solution in any
language.

Existing code metrics (for different languages) try to capture aspects of this
"what it does" problem (and there has been some related research) - but I am
not aware of any good code metrics for scala.

If we had such code metrics we could tag the code and try to align metric
signatures with "comprehension effort". This would give enterprises a valuable
instrument to spot source parts which should be reworked.

I think that would help...

Greetings
Bernd

Re: Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 04:37

On 2011-11-19 4:15 AM, Bernd Johannes wrote:
> Am Samstag, 19. November 2011, 02:09:24 schrieb Erik Engbrecht:
>> I'd phrase the question another way.
>>
>> Given a large organization that needs to maintain the ability to move
>> people between projects, and a language like Scala that allows for some
>> very diverse forms of expression, how does one keep the intersection of the
>> two from exploding?
>>
>> I'm not sure it's possible.
> While I dismiss the option to disable scala features I see the beauty in being
> able to "spot" "critical" sections somehow.

I very much agree.

> What I am missing currently is a survey giving some basic facts about what
> furthers understanding and what blocks understanding if someone is about to
> read some given section of code. "Critical" would be anything that makes it
> unecessarily hard to understand or follow a concept / solution that is
> implemented (the "what it does").
>
> That's not to be mixed with the complexity of a concept/solution in itself. If
> I don't understand the concept/solution (the "why") in itself I won't be able
> to figure out the meaning of code implementing that concept/solution in any
> language.
>
> Existing code metrics (for different languages) try to capture aspects of this
> "what it does" problem (and there has been some related research) - but I am
> not aware of any good code metrics for scala.
>
> If we had such code metrics we could tag the code and try to align metric
> signatures with "comprehension effort". This would give enterprises a valuable
> instrument to spot source parts which should be reworked.
>
> I think that would help...
>
> Greetings
> Bernd

I believe you are very much thinking in the right direction Bernd.

For millennium (is that the right word?) there has been the notion of
artisan masters and apprentices. Apprentices would study, train and work
under the supervision of the masters until they themselves would become
masters. Often the apprentices would do much or most of the real work,
but the masters would routinely inspect their work and intervene or
guide when necessary.

It can be difficult doing serious code reviews all the time to make sure
that novices get the guidance they need or that mavericks are reined in
when necessary. If we had tools that could help automate this sort of
review we could make it easier for the masters to check on the work of
the apprentices.

Cheers, Eric

Re: problems of scala complexity

Added by Tony Morris on 2011-11-19, 01:57


On Nov 19, 2011 9:56 AM, "Kenneth McDonald" <ykkenmcd [at] gmail [dot] com> wrote:
>
> I am moving this from scala-user to scala-debate upon request. First, a bit of context (copied):
>
>     However, as I've thought more about it, I've realized that what enterprises need is _controllable_ complexity. If you have 2,000 software engineers using Scala (which is what we all hope for, right?), then some of them _will_ use the most complex features because they think it's cool, regardless of corporate guidelines.
>
> Next, to put this into my own personal perspective: Until recently, I dismissed arguments that Scala was too complex on the grounds that "you can always use as simply a more productive Java".
>
> More recently, I have seen arguments that convinced me that a significant problems with Scala was that _the possibility of using it an an unduly complex manner restricted its corporate applicability_. I see this as a highly valid point. (Large) corporations need to expect that engineers are, to some degree, interchangeable. I think even Google must have that approach these days. It should be expected that an engineer can be dumped into another engineers' job and be able, int not too long, to pick up on what is going on.
>
> I don't believe this is possible with "full Scala". For example, look at Tony M. and (in addition) scalaz. How many engineers could pick up on code engineered in that universe? Very, very few.

Hi! Look at me!

You keep saying this, yet you still do not recognise that the problem is not with me or scalaz, but you.

Plenty of us can get along just fine with it, and we do exactly that, right now, at this moment. It has about 10 or more willing contributors and many of them write stuff that I do not comprehend. Want to know what I about it? That's right, I set about coming to terms with comprehending that very thing. Why might I do this? Because that very thing is often *useful*. Your "corporate guidelines" are antithetical to utility, and every scalaz committer soon learns that the only criteria for inclusion is usefulness, not bureacratic garbage; quite the contrary.

You keep using "what Ken fails to comprehend" as some kind of synonym for complexity or obtusity. It is so blatantly transparent that you are inventing excuses for that which you have developed an irrational anxiety response and I will call you out on it each time you burden me,personally with your personal issues. Please pull your head out of the sand, for your own benefit. You might even come to the point where you are able to comprehend that actually scalaz is one of the most easy to comprehend libraries out there, just like others who have bothered to acquaint themselves with the subject matter. Do you think I have scalaz memorised or something?

You can stop looking at me now and start looking at yourself.

>
> I know from experience that given enough people, developers who are completely incompetent in a technology will nonetheless use the extreme abilities of that technology. For example, I once spent several nasty months fixing the "code" of a "developer" who knew virtually nothing about C++, but who nonetheless decided she could overload operators at her discretion. Do you have any idea how difficult it is to understand code where "+"  means "accumulate into a queue"?
>
> Given, than , I refer back to the (implicit question) of my original post: does it make sense to allow the enterprise to control the degree of complexity of Scala that is used? (I think it does)
>
> I understand that such a topic may be part of the scala language discussions. If so, apologies, I have not seen it.
>
> Ken

Re: problems of scala complexity

Added by Maxime Lévesque on 2011-11-19, 03:07

Let's leave aside the difference of perception on the complexity of
Scala, it's totally understandable
that perceived complexity varies as much as it does.

Finding the optimal ratio of complexity to power is always a goal in
language or library design,
personally, I'm a bit clueless on how Scala's complexity could be
reduced without reducing it's power,
I am sure there are much more capable minds than mine thinking about this.

I am certain however that improving the tools can go a long way to
reduce the overall complexity that
Scala can bring to a project. Auto completion for example in an IDE
can be a powerfull educational tool,
when a user stalls the mouse pointer on a val and the IDE shows the
type, that is a huge complexity
reducer, that is just the begining, if an IDE could show a visual hint
at places in the code where
implicit conversions occur, and provide a link to the conversion function,
that would have a huge educational potential, and the complexity would
in effect have been reduced, without changing anything in the language.
Improvements in other tools could also go a long way, Scaladoc could
be made more explanatory,
for example with implicit params, showing a link to implicit val or
def declarations that applies within
the given library. SBT is another area, it needs to be as simple as
possible because it's the first tool
that a Scala new commer will use.
There is also accidental complexity, unstable or insufficiently
documented tools, etc...
All this can be addressed right now without even debating, not that
debating isn't usefull,
but if someont wishes to reduce the complexity of Scala for new
comers, there are plenty
of things that can be done by just helping improve tools in the ecosystem.

Cheers

ML

2011/11/18 Tony Morris :
>
> On Nov 19, 2011 9:56 AM, "Kenneth McDonald" wrote:
>>
>> I am moving this from scala-user to scala-debate upon request. First, a
>> bit of context (copied):
>>
>>     However, as I've thought more about it, I've realized that what
>> enterprises need is _controllable_ complexity. If you have 2,000 software
>> engineers using Scala (which is what we all hope for, right?), then some of
>> them _will_ use the most complex features because they think it's cool,
>> regardless of corporate guidelines.
>>
>> Next, to put this into my own personal perspective: Until recently, I
>> dismissed arguments that Scala was too complex on the grounds that "you can
>> always use as simply a more productive Java".
>>
>> More recently, I have seen arguments that convinced me that a significant
>> problems with Scala was that _the possibility of using it an an unduly
>> complex manner restricted its corporate applicability_. I see this as a
>> highly valid point. (Large) corporations need to expect that engineers are,
>> to some degree, interchangeable. I think even Google must have that approach
>> these days. It should be expected that an engineer can be dumped into
>> another engineers' job and be able, int not too long, to pick up on what is
>> going on.
>>
>> I don't believe this is possible with "full Scala". For example, look at
>> Tony M. and (in addition) scalaz. How many engineers could pick up on code
>> engineered in that universe? Very, very few.
>
> Hi! Look at me!
>
> You keep saying this, yet you still do not recognise that the problem is not
> with me or scalaz, but you.
>
> Plenty of us can get along just fine with it, and we do exactly that, right
> now, at this moment. It has about 10 or more willing contributors and many
> of them write stuff that I do not comprehend. Want to know what I about it?
> That's right, I set about coming to terms with comprehending that very
> thing. Why might I do this? Because that very thing is often *useful*. Your
> "corporate guidelines" are antithetical to utility, and every scalaz
> committer soon learns that the only criteria for inclusion is usefulness,
> not bureacratic garbage; quite the contrary.
>
> You keep using "what Ken fails to comprehend" as some kind of synonym for
> complexity or obtusity. It is so blatantly transparent that you are
> inventing excuses for that which you have developed an irrational anxiety
> response and I will call you out on it each time you burden me,personally
> with your personal issues. Please pull your head out of the sand, for your
> own benefit. You might even come to the point where you are able to
> comprehend that actually scalaz is one of the most easy to comprehend
> libraries out there, just like others who have bothered to acquaint
> themselves with the subject matter. Do you think I have scalaz memorised or
> something?
>
> You can stop looking at me now and start looking at yourself.
>
>>
>> I know from experience that given enough people, developers who are
>> completely incompetent in a technology will nonetheless use the extreme
>> abilities of that technology. For example, I once spent several nasty months
>> fixing the "code" of a "developer" who knew virtually nothing about C++, but
>> who nonetheless decided she could overload operators at her discretion. Do
>> you have any idea how difficult it is to understand code where "+"  means
>> "accumulate into a queue"?
>>
>> Given, than , I refer back to the (implicit question) of my original post:
>> does it make sense to allow the enterprise to control the degree of
>> complexity of Scala that is used? (I think it does)
>>
>> I understand that such a topic may be part of the scala language
>> discussions. If so, apologies, I have not seen it.
>>
>> Ken

Re: problems of scala complexity

Added by Russ P. on 2011-11-19, 01:27


On Fri, Nov 18, 2011 at 3:56 PM, Kenneth McDonald <ykkenmcd [at] gmail [dot] com> wrote:

Given, than , I refer back to the (implicit question) of my original post: does it make sense to allow the enterprise to control the degree of complexity of Scala that is used? (I think it does)
I understand that such a topic may be part of the scala language discussions. If so, apologies, I have not seen it.
Ken


This idea was discussed extensively a few months ago. I suggest you find the discussion. I don't recall off hand if any consensus was reached. The basic idea makes sense to me, but I don't know if it is practically feasible.

Any company can institute its own coding standards, of course. Heck, any large enough company can probably develop a compiler plug-in to *enforce* its coding standards and restrictions. Maybe someone should try that and see how it works in practice.

--Russ P.

--
http://RussP.us

Re: problems of scala complexity

Added by kolotyluk on 2011-11-19, 01:37
On 2011-11-18 4:21 PM, Russ Paielli wrote:
CAHy81hP0rrj5Xu5UBidJiy1sA_Km32SsBk-HypuPzJgcqZsuJw [at] mail [dot] gmail [dot] com" type="cite">

On Fri, Nov 18, 2011 at 3:56 PM, Kenneth McDonald <ykkenmcd [at] gmail [dot] com" rel="nofollow">ykkenmcd [at] gmail [dot] com> wrote:

Given, than , I refer back to the (implicit question) of my original post: does it make sense to allow the enterprise to control the degree of complexity of Scala that is used? (I think it does)
I understand that such a topic may be part of the scala language discussions. If so, apologies, I have not seen it.
Ken


This idea was discussed extensively a few months ago. I suggest you find the discussion. I don't recall off hand if any consensus was reached. The basic idea makes sense to me, but I don't know if it is practically feasible.

Any company can institute its own coding standards, of course. Heck, any large enough company can probably develop a compiler plug-in to *enforce* its coding standards and restrictions. Maybe someone should try that and see how it works in practice.

--Russ P.

--
http://RussP.us

I seem to recall recently someone suggested some sort of switches to control which language features could be enabled.

For example, in C#/.NET there is the concept of 'unsafe' code so that the developer has to expressly declare they are doing something 'unsafe'. This becomes a warning to both the person choosing to do something unsafe, and to the reader that someone chose to do something unsafe - hopefully for good reason - hopefully because they were qualified to do so. I leave it up to each particular enterprise to decide what their internal conventions are, and who is qualified to do what, but at least there is some language support to make it clearer what is happening (and maybe who is doing it).

I am not sure what this would look like in Scala, but I will naively start off with something based on the now famous A1, A2, A3, L1, L2, L3 classifications. I'm sure there are smarter people who can figure out something better. You could probably do something extra like the @author javadoc so that systems like Maven could test who is allow author certain types of code and fail the build or generate a report when unqualified people (who can't swim) enter the deep end (so to speak). At a minimum the build could signal the software architects that maybe some code review is in order.

It's Friday - I'm tired, but I think Ken is onto something.

Cheers, Eric

Re: problems of scala complexity

Added by runaro on 2011-11-20, 19:07
"I seem to recall recently someone suggested some sort of switches to control which language features could be enabled."

That sounds pretty complex.

Re: problems of scala complexity

Added by kolotyluk on 2011-11-20, 23:07

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

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