What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

On 11/15/2011 04:43 AM, Ken McDonald wrote:
> Hello from the original poster of this article. I've had my #1
> position changed by a couple of articles including one good, long one
> by Jim Herber (sp?). So here it is: the #1 problem with Scala being
> accepted in the Enterprise world:
>
> Scala is too complex.

No.

>
> Not too long ago, I would have said this is incorrect, because Scala
> can be used at 90% productivity while being no more complex than Java.
> My attitude was changed by the aforementioned articles, plus some
> recent experience with collections.breakOut.
>
> 1) The obvious: Scala can be used as great advantage without undue
> complexity. However, there will always be people in an organization
> who are capable of using the more complex features, and ultimately do
> so regardless of coding guidelines. They will leave behind them code
> that the standard programmer, or even another advanced programmer who
> took a different tack in the Scala ecosphere, are simply unable to
> maintain. This is simply death to a large organization; much as we
> would like to think of ourselves as uniquely talented individuals,
> they _must_ have interchangeable engineers in order to continue their
> existence.

This is not what happens at all. It only looks that way to you.

What really happens is that there will always be people who either
refuse or fail to understand the intrinisically theoretical nature of
our profession. You need only look outside of Scala for many examples of
this. This leads some to introduce undue complexity while complaining
about precise solutions because of some cognitive dilemma. By this I
mean, you will hear people complain of "I am unable to read the code",
yet not considering the possibility that the problem is the "I" part,
not the "code" part in that statement. They're simply unacquainted with
the fundamentals of the profession; this symptom is *absolutely prolific*.

This leaves people who wish to solve problems, actually solve them
instead of piss-fiddling about, burdened with such riclildudlous
bureaucracy like "coding guidelines." A resentment of this
fiddle-farting can begin to form, leading those who wish to actually
solve problems ignoring the nonsense and just getting on with it.

But it doesn't end there. Those who wish to solve problems also have to
endure the seemingly endless whining, while simultaneously solving
actual problems. It just gets out of hand, so something must be
sacrificed -- often politeness.

People who solve actual problems, without undue complexity or
redundancy, are often charged with "leaving behind unmaintainable code."
To these people, I tell you: I have developed a strategy for dealing
with this charge. What you do is you actually solve the problem; nice
and easy *but don't tell anyone*. Next, you introduce the unnecessary
complexity, however, you must be very tactful here. Make sure it is not
obvious that the complexity can be removed without penalty -- it must
appear to be intertwined and inherent to the nature of the problem at
hand. However, you don't want to *actually* burden yourself with this
entanglement -- you've just got to give the appearance. Essentially,
perhaps most importantly, you must always remember that you are solving
an additional problem on top of the computational one: that of a social
disorder which gives rise to masochistic tendencies. Make up a few terms
that have no meaning -- ensure that you can shift the goal posts at
will. You probably think I am joking here; I am not -- I have several
tools for dealing with this disorder. This means that your dealings with
the nonsense are very short-lived.

>
> 2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
> one feature does not "overlap" another feature, so each additional
> feature multiplies the abilities of Scala by the number of its
> possible states. Java is not so orthogonal, so let's say that each
> feature adds to the abilities of Java by the number of its position in
> the feature sequence. Let's assume that each language has five
> "features", each of which may be "used" or "unused". Scala has 2^5
> possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
> counterargument to this is that you can understand entire swaths of
> the Scala feature set by understanding a single concept. This is
> theoretically true, but realistically invalid. For example, I placed
> in the upper part of the top 1% of the GREs when I took them, and I
> don't understand a freakin' thing about scalaz, plus my understanding
> of implicit parameters is coming along very slowly. I'm sure that many
> of you are brighter than I, but consider the target; the Enterprise
> programmer. They are not even in my IQ range, let alone yours. (No
> offense to EP programmers out there. I've appreciated other people's
> well-written, non fancy code, as opposed to brilliant, impenetrable
> code, many times in my career. And to be honest, you almost certainly
> have a much more successful personal life than I do.)

*boggle*

>
> 3) Least obvious: more power =/= more productivity. So the Scala type
> system is Turing complete, great. How many think this is important?
> How many think this should be used in code? How many think this is,
> net, a gain? I'm hoping the answer is well under 5% in each case. This
> is a bit of a rehash of (2) above, but not completely. Scala has a lot
> of features. To be honest, it has _enough_ features for the time
> being, unless new features can simplify it.

If you are incapable of using a more proficient programming language,
you're not going to be more capable with a less proficient programming
language. It's just a myth. To be clear, Java programmers seldom get
anything useful done; they just appear to, and solicit peer support that
they have done -- good for them, but don't for a minute expect me to
deny it.

>
> How to handle this situation in the Enterprise? One previous post
> mentioned "Scala Lite", but did not elaborate. I think it's time to
> consider the possibility of optionally "feature-restricting" Scala so
> that the Enterprise can ensure its code is at a certain level of
> approachability. I won't try to give a full spec here, but will give
> one suggestion I think makes sense: It should be possible, in the
> Enterprise, to disable the ability to define implicit parameters.
>
> Other suggestions are left for other readers.
>
>
> Cheers,
> Ken
>

There is a valid "Scala is too complex" argument, but nobody is anywhere
near the ball. Not even close. This is sad.

> How to handle this situation in the Enterprise? One previous post mentioned
> "Scala Lite", but did not elaborate. I think it's time to consider the
> possibility of optionally "feature-restricting" Scala so that the
> Enterprise can ensure its code is at a certain level of approachability. I
> won't try to give a full spec here, but will give one suggestion I think
> makes sense: It should be possible, in the Enterprise, to disable the
> ability to define implicit parameters.

Sorry, but that would be fixing the symptoms, not the causation. What
would that even buy you? Code which uses the same features as Java, but
in a slightly different syntax? More features than Java, but not too
many, in order to not scare people off?

I'd say that there are plenty of people around here who would be happy
to assist learners who struggle with advanced features. It's certainly
not an indication of a low IQ (or some other nonsense metric) that
someone new has no clue about higher kinds or union types or
catamorphism or ... The point is that many people are keen to learn, and
that's a good thing. If you are not keen to learn, you have to rethink
your attitude towards programming.

On Mon, Nov 14, 2011 at 17:12, marc wrote:
> I should add that it is not the profanity that I have a problem with, if you
> knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by the
> metric UFPM (" uttered f*cks per minute")
> However, to have a core design pattern named after an absusive industry that
> exists solely to subjugate and profit from the exploitation of women is more
> than just profane, it is offensive.

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Amen.

Something I'm truly allergic to is the idea of "interchangeable
engineers" that seems to be prevalent in the corporate world. That
somehow all software engineers comes from the mold and have the same
level of expertise and experience. Nothing could be further from the
truth...

/Jesper Nordenberg

Tony Morris skrev 2011-11-14 21:29:
> On 11/15/2011 04:43 AM, Ken McDonald wrote:
>> Hello from the original poster of this article. I've had my #1
>> position changed by a couple of articles including one good, long one
>> by Jim Herber (sp?). So here it is: the #1 problem with Scala being
>> accepted in the Enterprise world:
>>
>> Scala is too complex.
>
> No.
>
>>
>> Not too long ago, I would have said this is incorrect, because Scala
>> can be used at 90% productivity while being no more complex than Java.
>> My attitude was changed by the aforementioned articles, plus some
>> recent experience with collections.breakOut.
>>
>> 1) The obvious: Scala can be used as great advantage without undue
>> complexity. However, there will always be people in an organization
>> who are capable of using the more complex features, and ultimately do
>> so regardless of coding guidelines. They will leave behind them code
>> that the standard programmer, or even another advanced programmer who
>> took a different tack in the Scala ecosphere, are simply unable to
>> maintain. This is simply death to a large organization; much as we
>> would like to think of ourselves as uniquely talented individuals,
>> they _must_ have interchangeable engineers in order to continue their
>> existence.
>
> This is not what happens at all. It only looks that way to you.
>
> What really happens is that there will always be people who either
> refuse or fail to understand the intrinisically theoretical nature of
> our profession. You need only look outside of Scala for many examples of
> this. This leads some to introduce undue complexity while complaining
> about precise solutions because of some cognitive dilemma. By this I
> mean, you will hear people complain of "I am unable to read the code",
> yet not considering the possibility that the problem is the "I" part,
> not the "code" part in that statement. They're simply unacquainted with
> the fundamentals of the profession; this symptom is *absolutely prolific*.
>
> This leaves people who wish to solve problems, actually solve them
> instead of piss-fiddling about, burdened with such riclildudlous
> bureaucracy like "coding guidelines." A resentment of this
> fiddle-farting can begin to form, leading those who wish to actually
> solve problems ignoring the nonsense and just getting on with it.
>
> But it doesn't end there. Those who wish to solve problems also have to
> endure the seemingly endless whining, while simultaneously solving
> actual problems. It just gets out of hand, so something must be
> sacrificed -- often politeness.
>
> People who solve actual problems, without undue complexity or
> redundancy, are often charged with "leaving behind unmaintainable code."
> To these people, I tell you: I have developed a strategy for dealing
> with this charge. What you do is you actually solve the problem; nice
> and easy *but don't tell anyone*. Next, you introduce the unnecessary
> complexity, however, you must be very tactful here. Make sure it is not
> obvious that the complexity can be removed without penalty -- it must
> appear to be intertwined and inherent to the nature of the problem at
> hand. However, you don't want to *actually* burden yourself with this
> entanglement -- you've just got to give the appearance. Essentially,
> perhaps most importantly, you must always remember that you are solving
> an additional problem on top of the computational one: that of a social
> disorder which gives rise to masochistic tendencies. Make up a few terms
> that have no meaning -- ensure that you can shift the goal posts at
> will. You probably think I am joking here; I am not -- I have several
> tools for dealing with this disorder. This means that your dealings with
> the nonsense are very short-lived.
>
>
>>
>> 2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
>> one feature does not "overlap" another feature, so each additional
>> feature multiplies the abilities of Scala by the number of its
>> possible states. Java is not so orthogonal, so let's say that each
>> feature adds to the abilities of Java by the number of its position in
>> the feature sequence. Let's assume that each language has five
>> "features", each of which may be "used" or "unused". Scala has 2^5
>> possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
>> counterargument to this is that you can understand entire swaths of
>> the Scala feature set by understanding a single concept. This is
>> theoretically true, but realistically invalid. For example, I placed
>> in the upper part of the top 1% of the GREs when I took them, and I
>> don't understand a freakin' thing about scalaz, plus my understanding
>> of implicit parameters is coming along very slowly. I'm sure that many
>> of you are brighter than I, but consider the target; the Enterprise
>> programmer. They are not even in my IQ range, let alone yours. (No
>> offense to EP programmers out there. I've appreciated other people's
>> well-written, non fancy code, as opposed to brilliant, impenetrable
>> code, many times in my career. And to be honest, you almost certainly
>> have a much more successful personal life than I do.)
>
> *boggle*
>
>>
>> 3) Least obvious: more power =/= more productivity. So the Scala type
>> system is Turing complete, great. How many think this is important?
>> How many think this should be used in code? How many think this is,
>> net, a gain? I'm hoping the answer is well under 5% in each case. This
>> is a bit of a rehash of (2) above, but not completely. Scala has a lot
>> of features. To be honest, it has _enough_ features for the time
>> being, unless new features can simplify it.
>
> If you are incapable of using a more proficient programming language,
> you're not going to be more capable with a less proficient programming
> language. It's just a myth. To be clear, Java programmers seldom get
> anything useful done; they just appear to, and solicit peer support that
> they have done -- good for them, but don't for a minute expect me to
> deny it.
>
>
>>
>> How to handle this situation in the Enterprise? One previous post
>> mentioned "Scala Lite", but did not elaborate. I think it's time to
>> consider the possibility of optionally "feature-restricting" Scala so
>> that the Enterprise can ensure its code is at a certain level of
>> approachability. I won't try to give a full spec here, but will give
>> one suggestion I think makes sense: It should be possible, in the
>> Enterprise, to disable the ability to define implicit parameters.
>>
>> Other suggestions are left for other readers.
>>
>>
>> Cheers,
>> Ken
>>
>
> There is a valid "Scala is too complex" argument, but nobody is anywhere
> near the ball. Not even close. This is sad.
>

On 11/15/2011 06:43 AM, Lars Hupel wrote:
>> How to handle this situation in the Enterprise? One previous post mentioned
>> "Scala Lite", but did not elaborate. I think it's time to consider the
>> possibility of optionally "feature-restricting" Scala so that the
>> Enterprise can ensure its code is at a certain level of approachability. I
>> won't try to give a full spec here, but will give one suggestion I think
>> makes sense: It should be possible, in the Enterprise, to disable the
>> ability to define implicit parameters.
> Sorry, but that would be fixing the symptoms, not the causation. What
> would that even buy you? Code which uses the same features as Java, but
> in a slightly different syntax? More features than Java, but not too
> many, in order to not scare people off?
>
> I'd say that there are plenty of people around here who would be happy
> to assist learners who struggle with advanced features. It's certainly
> not an indication of a low IQ (or some other nonsense metric) that
> someone new has no clue about higher kinds or union types or
> catamorphism or ... The point is that many people are keen to learn, and
> that's a good thing. If you are not keen to learn, you have to rethink
> your attitude towards programming.
>
Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?

On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:

On Mon, Nov 14, 2011 at 17:12, marc <mill...@gmail.com> wrote:
> I should add that it is not the profanity that I have a problem with, if you
> knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by the
> metric UFPM (" uttered f*cks per minute")
> However, to have a core design pattern named after an absusive industry that
> exists solely to subjugate and profit from the exploitation of women is more
> than just profane, it is offensive.

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Yes, the word pimp has modern usage; however, the etymology is still clear as isthe current alternative meanings.    This is the same reason I don't use the word "gyp" to mean cheated.There is a history and context attached to some words and their usage cannot be separated from thisassociation. There is a difference between word usage in social or friendly informal situations and in professional settings.  Saying to friends that your computer is "pimped out" is different than if Dellor Apple had the option to "pimp out" your machine.  
 

--
Daniel C. Sobral

I travel to the future all the time.

On Mon, Nov 14, 2011 at 4:14 PM, marc <millstone@gmail.com> wrote:

On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:

On Mon, Nov 14, 2011 at 17:12, marc <mill...@gmail.com> wrote:
> I should add that it is not the profanity that I have a problem with, if you
> knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by the
> metric UFPM (" uttered f*cks per minute")
> However, to have a core design pattern named after an absusive industry that
> exists solely to subjugate and profit from the exploitation of women is more
> than just profane, it is offensive.

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Yes, the word pimp has modern usage; however, the etymology is still clear as isthe current alternative meanings.    This is the same reason I don't use the word "gyp" to mean cheated. There is a history and context attached to some words and their usage cannot be separated from thisassociation. There is a difference between word usage in social or friendly informal situations and in  professional settings.  Saying to friends that your computer is "pimped out" is different than if Dellor Apple had the option to "pimp out" your machine.  

So I guess you also object to the use of foo and bar as example variables?

Anyway, I object to the PML phrase because it gives me no idea what it actually does.  (Likewise with "monkey patching" in some dynamic languages--how does the appearance or behavior of monkeys help me here?)

Something like "extension method pattern" or "method addition pattern" both describes what is going on and, as a side effect, is less likely to be viewed as either offensive or insufficiently professional.

  --Rex

On Monday, November 14, 2011 1:27:00 PM UTC-8, Rex Kerr wrote:

On Mon, Nov 14, 2011 at 4:14 PM, marc <mill...@gmail.com> wrote:

On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:

On Mon, Nov 14, 2011 at 17:12, marc <mil...@gmail.com> wrote:
> I should add that it is not the profanity that I have a problem with, if you
> knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by the
> metric UFPM (" uttered f*cks per minute")
> However, to have a core design pattern named after an absusive industry that
> exists solely to subjugate and profit from the exploitation of women is more
> than just profane, it is offensive.

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Yes, the word pimp has modern usage; however, the etymology is still clear as isthe current alternative meanings.    This is the same reason I don't use the word "gyp" to mean cheated. There is a history and context attached to some words and their usage cannot be separated from thisassociation. There is a difference between word usage in social or friendly informal situations and in  professional settings.  Saying to friends that your computer is "pimped out" is different than if Dellor Apple had the option to "pimp out" your machine.  

So I guess you also object to the use of foo and bar as example variables?

No, profanity does not bother me in the slightest.  foo and bar from FUBAR is whatever.  It iswords and phrases that have clear, violent and abusive historical connection to a class of people.   Yes, some people are offended by profanity, but that is based on arbitrary ethics/morals.  By the samelogic, I will swear, but not use racial slurs.
Again, I am *not* saying that no one should use the phrase "pimp out", but in professionaland serious circles, it should be avoided.  And that it is the name of a core concept in scala is a travesty.

On 11/15/2011 07:33 AM, marc wrote:

On Monday, November 14, 2011 1:27:00 PM UTC-8, Rex Kerr wrote:

On Mon, Nov 14, 2011 at 4:14 PM, marc <mill...@gmail.com> wrote:

On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:

On Mon, Nov 14, 2011 at 17:12, marc <mil...@gmail.com> wrote:
> I should add that it is not the profanity that I have a problem with, if you
> knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by the
> metric UFPM (" uttered f*cks per minute")
> However, to have a core design pattern named after an absusive industry that
> exists solely to subjugate and profit from the exploitation of women is more
> than just profane, it is offensive.

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Yes, the word pimp has modern usage; however, the etymology is still clear as is the current alternative meanings.    This is the same reason I don't use the word "gyp" to mean cheated. There is a history and context attached to some words and their usage cannot be separated from this association. There is a difference between word usage in social or friendly informal situations and in  professional settings.  Saying to friends that your computer is "pimped out" is different than if Dell or Apple had the option to "pimp out" your machine.  

So I guess you also object to the use of foo and bar as example variables?

No, profanity does not bother me in the slightest.  foo and bar from FUBAR is whatever.  It is words and phrases that have clear, violent and abusive historical connection to a class of people.    Yes, some people are offended by profanity, but that is based on arbitrary ethics/morals.  By the same logic, I will swear, but not use racial slurs.
Again, I am *not* saying that no one should use the phrase "pimp out", but in professional and serious circles, it should be avoided.  And that it is the name of a core concept in scala is a travesty.

Demanding that someone stop using words because you have attributed magical properties to those words is unprofessionalism of the highest order. It is no different to certain thugs demanding that I do not draw specific pictures of specific prophets. Your argumentum ad antiquitatem does not fly.

-- 
Tony Morris
http://tmorris.net/

On Mon, Nov 14, 2011 at 4:35 PM, Tony Morris <tonymorris@gmail.com> wrote:

Demanding that someone stop using words because you have attributed magical properties to those words is unprofessionalism of the highest order.

However, it is worth considering is that when you want people to _learn_ and _concentrate_, they perform better when they're not distracted.  People get distracted by things that they arguably ought not, but sometimes it's more prudent to exercise restraint than freedom of expression.

Creative expression is a great tool for remembering something that otherwise would be hard to remember.  But that isn't the case here; the fuss is overdone, but it still wouldn't hurt to change the default phrasing to allow an even larger fraction of people to not lose focus on the important thing, which is how that pattern will let them solve problems.

  --Rex

This idea that all engineers are created equal and that programming is essentially a cookie cutter exercise is a furphy that suits corporate shops very nicely. This kind of thinking led to off-shoring and the like and has been mostly discredited. Programming is hard, and programmers need to continually improve and learn as technology and the state of the art evolves.
The thing that amazes me most in this kind of debate is the internal dishonesty of the common definitions of "complex" and "unmaintainable". A lot use these as synonyms for "unfamiliar" – particularly for syntactic constructs. However, these syntactic constructs may actually encode a much simpler execution profile. A classic example being a stack based functional program. This is much simpler than an imperative algorithm with side-effects – but the second version is "easier to read". A text-book example of mistaking easier for simpler. Many times I see hundred line methods with many embedded side-effects accepted over succinct functional abstractions purely due to syntactic unfamiliarity.
Rich Hickey had a talk* recently about the value of simple over easy. While he perhaps has some  controversial things to say about verification techniques – the point is still a good one. Mistaking easy (which is subjective) with simple (which is objective) leads to poor decisions and a herd mentality.
What makes Scala a fantastic language for corporate environments is its abstraction tools. By enabling the brighter members of your teams to provide abstracted library for everyone else you actually enable everyone to get more done faster. This is not something to be afraid of but something to rejoice in.
* http://www.infoq.com/presentations/Simple-Made-Easy

On 15 November 2011 07:51, Jesper Nordenberg <megagurka@yahoo.com> wrote:

Amen.

Something I'm truly allergic to is the idea of "interchangeable engineers" that seems to be prevalent in the corporate world. That somehow all software engineers comes from the mold and have the same level of expertise and experience. Nothing could be further from the truth...

/Jesper Nordenberg

Tony Morris skrev 2011-11-14 21:29:

On 11/15/2011 04:43 AM, Ken McDonald wrote:

Hello from the original poster of this article. I've had my #1
position changed by a couple of articles including one good, long one
by Jim Herber (sp?). So here it is: the #1 problem with Scala being
accepted in the Enterprise world:

    Scala is too complex.

No.

Not too long ago, I would have said this is incorrect, because Scala
can be used at 90% productivity while being no more complex than Java.
My attitude was changed by the aforementioned articles, plus some
recent experience with collections.breakOut.

1) The obvious: Scala can be used as great advantage without undue
complexity. However, there will always be people in an organization
who are capable of using the more complex features, and ultimately do
so regardless of coding guidelines. They will leave behind them code
that the standard programmer, or even another advanced programmer who
took a different tack in the Scala ecosphere, are simply unable to
maintain. This is simply death to a large organization; much as we
would like to think of ourselves as uniquely talented individuals,
they _must_ have interchangeable engineers in order to continue their
existence.

This is not what happens at all. It only looks that way to you.

What really happens is that there will always be people who either
refuse or fail to understand the intrinisically theoretical nature of
our profession. You need only look outside of Scala for many examples of
this. This leads some to introduce undue complexity while complaining
about precise solutions because of some cognitive dilemma. By this I
mean, you will hear people complain of "I am  unable to read the code",
yet not considering the possibility that the problem is the "I" part,
not the "code" part in that statement. They're simply unacquainted with
the fundamentals of the profession; this symptom is *absolutely prolific*.

This leaves people who wish to solve problems, actually solve them
instead of piss-fiddling about, burdened with such riclildudlous
bureaucracy like "coding guidelines." A resentment of this
fiddle-farting can begin to form, leading those who wish to actually
solve problems ignoring the nonsense and just getting on with it.

But it doesn't end there. Those who wish to solve problems also have to
endure the seemingly endless whining, while simultaneously solving
actual problems. It just gets out of hand, so something must be
sacrificed -- often politeness.

People who solve actual problems, without undue complexity or
redundancy, are often charged with "leaving behind unmaintainable code."
To these people, I tell you: I have developed a strategy for dealing
with this charge. What you do is you actually solve the problem; nice
and easy *but don't tell anyone*. Next, you introduce the unnecessary
complexity, however, you must be very tactful here. Make sure it is not
obvious that the complexity can be removed without penalty -- it must
appear to be intertwined and inherent to the nature of the problem at
hand. However, you don't want to *actually* burden yourself with this
entanglement -- you've just got to give the appearance. Essentially,
perhaps most importantly, you must always remember that you are solving
an additional problem on top of the computational one: that of a social
disorder which gives rise to masochistic tendencies. Make up a few terms
that have no meaning -- ensure that you can shift the goal posts at
will. You probably think I am joking here; I am not -- I have several
tools for dealing with this disorder. This means that your dealings with
the nonsense are very short-lived.

2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
one feature does not "overlap" another feature, so each additional
feature multiplies the abilities of Scala by the number of its
possible states. Java is not so orthogonal, so let's say that each
feature adds to the abilities of Java by the number of its position in
the feature sequence. Let's assume that each language has five
"features", each of which may be "used" or "unused". Scala has 2^5
possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
counterargument to this is that you can understand entire swaths of
the Scala feature set by understanding a single concept. This is
theoretically true, but realistically invalid. For example, I placed
in the upper part of the top 1% of the GREs when I took them, and I
don't understand a freakin' thing about scalaz, plus my understanding
of implicit parameters is coming along very slowly. I'm sure that many
of you are brighter than I, but consider the target; the Enterprise
programmer. They are not even in my IQ range, let alone yours. (No
offense to EP programmers out there. I've appreciated other people's
well-written, non fancy code, as opposed to brilliant, impenetrable
code, many times in my career. And to be honest, you almost certainly
have a much more successful personal life than I do.)

*boggle*

3) Least obvious: more power =/= more productivity. So the Scala type
system is Turing complete, great. How many think this is important?
How many think this should be used in code? How many think this is,
net, a gain? I'm hoping the answer is well under 5% in each case. This
is a bit of a rehash of (2) above, but not completely. Scala has a lot
of features. To be honest, it has _enough_ features for the time
being, unless new features can simplify it.

If you are incapable of using a more proficient programming language,
you're not going to be more capable with a less proficient programming
language. It's just a myth. To be clear, Java programmers seldom get
anything useful done; they just appear to, and solicit peer support that
they have done -- good for them, but don't for a minute expect me to
deny it.

How to handle this situation in the Enterprise? One previous post
mentioned "Scala Lite", but did not elaborate. I think it's time to
consider the possibility of optionally "feature-restricting" Scala so
that the Enterprise can ensure its code is at a certain level of
approachability. I won't try to give a full spec here, but will give
one suggestion I think makes sense: It should be possible, in the
Enterprise, to disable the ability to define implicit parameters.

Other suggestions are left for other readers.


Cheers,
Ken

There is a valid "Scala is too complex" argument, but nobody is anywhere
near the ball. Not even close. This is sad.

On 2011, Nov 14, at 7:48 PM, Ken McDonald wrote:
> Tattoos I'm OK with now that they've become part of the cultural mainstream and are sometimes even artistic (But boy, are they going to look awful on a saggy 70-year old).

As a tattooed friend of mine said: "If all I have to worry about when it comes to how I look when I am 70 is a wrinkly tattoo, I figure I am ahead of the game."

Geir

>
> scala is not too complex, scala is too different from what the
> enterprise world is used to. once you use scala in a way where it really
> gives a productivity boost, you have to change your way of thinking,
> your strategies - everything is different.

I don't think Scala is *that* different. I had an intern come and work on a Scala project this past summer. She was a very bright woman but only had a few programming classes (One Java, and a couple Python classes). I gave here the 'Programming in Scala' book and spent a little time with her to explain functions/closures and implicits. She didn't have any trouble picking up Scala and was quite productive with it after just a few weeks.

On 11/15/2011 07:43 AM, Rex Kerr wrote:

CAP_xLa1DEmBKwWMLidjS01HQ4Vp_c8dzgfWsH0n4jDOr0Y7pxw [at] mail [dot] gmail [dot] com" type="cite">

On Mon, Nov 14, 2011 at 4:35 PM, Tony Morris <tonymorris [at] gmail [dot] com" rel="nofollow">tonymorris@gmail.com> wrote:

Demanding that someone stop using words because you have attributed magical properties to those words is unprofessionalism of the highest order.

However, it is worth considering is that when you want people to _learn_ and _concentrate_, they perform better when they're not distracted.  People get distracted by things that they arguably ought not, but sometimes it's more prudent to exercise restraint than freedom of expression.

Creative expression is a great tool for remembering something that otherwise would be hard to remember.  But that isn't the case here; the fuss is overdone, but it still wouldn't hurt to change the default phrasing to allow an even larger fraction of people to not lose focus on the important thing, which is how that pattern will let them solve problems.

  --Rex

Part of the learning requires the discipline to not distract yourself with whiny nonsense.

Have you ever noticed that those doing all that fuck-farting about and whining like little princesses also have the poorest understanding of the subject matter that was once at hand? This may be my bias, but it sure does seem that way to me. "I don't have a friggin' clue, so let me distract you with these magical attributes of words. That way, I will surely never have a clue and nobody will ever notice, not even me!"

-- 
Tony Morris
http://tmorris.net/

On Monday, November 14, 2011 1:35:33 PM UTC-8, Tony Morris wrote:

On 11/15/2011 07:33 AM, marc wrote:

On Monday, November 14, 2011 1:27:00 PM UTC-8, Rex Kerr wrote:

On Mon, Nov 14, 2011 at 4:14 PM, marc <mil...@gmail.com> wrote:

On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:

On Mon, Nov 14, 2011 at 17:12, marc <mil...@gmail.com> wrote:
> I should add that it is not the profanity that I have a problem with, if you
> knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by the
> metric UFPM (" uttered f*cks per minute")
> However, to have a core design pattern named after an absusive industry that
> exists solely to subjugate and profit from the exploitation of women is more
> than just profane, it is offensive.

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Yes, the word pimp has modern usage; however, the etymology is still clear as is the current alternative meanings.    This is the same reason I don't use the word "gyp" to mean cheated. There is a history and context attached to some words and their usage cannot be separated from this association. There is a difference between word usage in social or friendly informal situations and in  professional settings.  Saying to friends that your computer is "pimped out" is different than if Dell or Apple had the option to "pimp out" your machine.  

So I guess you also object to the use of foo and bar as example variables?

No, profanity does not bother me in the slightest.  foo and bar from FUBAR is whatever.  It is words and phrases that have clear, violent and abusive historical connection to a class of people.    Yes, some people are offended by profanity, but that is based on arbitrary ethics/morals.  By the same logic, I will swear, but not use racial slurs.
Again, I am *not* saying that no one should use the phrase "pimp out", but in professional and serious circles, it should be avoided.  And that it is the name of a core concept in scala is a travesty.

Demanding that someone stop using words because you have attributed magical properties to those words is unprofessionalism of the highest order. It is no different to certain thugs demanding that I do not draw specific pictures of specific prophets. Your argumentum ad antiquitatem does not fly.

 I respect this opinion.  But historical context is not a magical property.  Some words have negativeconnotations attached to them that are objectively hurtful and offensive.  "Pimp my library" uses a phrasewith that glamorizes the abuse and exploitation of women.  There is a clear distinction here between such phrases used throughout a professional community and profanity and phrases used between friends (or enemies...)

On 11/15/2011 07:43 AM, marc wrote:

On Monday, November 14, 2011 1:35:33 PM UTC-8, Tony Morris wrote:

On 11/15/2011 07:33 AM, marc wrote:

On Monday, November 14, 2011 1:27:00 PM UTC-8, Rex Kerr wrote:

On Mon, Nov 14, 2011 at 4:14 PM, marc <mil...@gmail.com> wrote:

On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:

On Mon, Nov 14, 2011 at 17:12, marc <mil...@gmail.com> wrote:
> I should add that it is not the profanity that I have a problem with, if you
> knew me you would know that I curse
> regularly (you can tell my happiness working with third-party code by the
> metric UFPM (" uttered f*cks per minute")
> However, to have a core design pattern named after an absusive industry that
> exists solely to subjugate and profit from the exploitation of women is more
> than just profane, it is offensive.

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Yes, the word pimp has modern usage; however, the etymology is still clear as is the current alternative meanings.    This is the same reason I don't use the word "gyp" to mean cheated. There is a history and context attached to some words and their usage cannot be separated from this association. There is a difference between word usage in social or friendly informal situations and in  professional settings.  Saying to friends that your computer is "pimped out" is different than if Dell or Apple had the option to "pimp out" your machine.  

So I guess you also object to the use of foo and bar as example variables?

No, profanity does not bother me in the slightest.  foo and bar from FUBAR is whatever.  It is words and phrases that have clear, violent and abusive historical connection to a class of people.    Yes, some people are offended by profanity, but that is based on arbitrary ethics/morals.  By the same logic, I will swear, but not use racial slurs.
Again, I am *not* saying that no one should use the phrase "pimp out", but in professional and serious circles, it should be avoided.  And that it is the name of a core concept in scala is a travesty.

Demanding that someone stop using words because you have attributed magical properties to those words is unprofessionalism of the highest order. It is no different to certain thugs demanding that I do not draw specific pictures of specific prophets. Your argumentum ad antiquitatem does not fly.

 I respect this opinion.  But historical context is not a magical property.  Some words have negative connotations attached to them that are objectively hurtful and offensive.  "Pimp my library" uses a phrase with that glamorizes the abuse and exploitation of women.  There is a clear distinction here between such phrases used throughout a professional community and profanity and phrases used between friends (or enemies...)

By connotation, you mean that which you decided to add to the word. A word does not glamorise anything -- to suggest it does is offensive to reality, and undermines any struggle against exploitation of women.

Do you understand that this very demand you are making is exactly anti-thetical to the cause that you claim to be passionate about? If I happened to be more passionate about the specific subject you raise, perhaps if I was a woman, and you were making these demands, I would probably tell you to go fuck yourself. Instead, I'll just tell you that you are departing from reality and not doing your cause any favours. I applaud your enthusiasm, but it is misdirected. Why don't you do the anti-misogyny cause a favour and stop demanding that certain words have magical properties? Your exact behaviour, this magical, authoritarian, superstitious bullshit *is the problem* with matters like subjugation of woman, or drawing pictures as it were.

"Historical context" is a fallacy as I said. You may keep saying it, or you may keep applying other magical attributes, but I am not superstitious and I reject your demands that I appease your superstitions. Appealing to "professionalism" while exhibiting the exact opposite just looks funny.

-- 
Tony Morris
http://tmorris.net/

I am so utterly glad that somebody posts something so clear in amongst
this mess of a thread.

I truly wish these threads would end. Scala is a programming
language, programming is hard, there isn't anything more to it.

There are many tools that give nice illusions of simplifying things,
Hibernate/Spring etc are mentioned a lot here, and I agree, they are
behemoths. But here's the rub, Hibernate CAN take a lot of the
drudgery out of dealing with ORM style dev - if its the best fit for
your problem so be it. I wouldn't go so far as to say that for Spring
though :-) (I jest)

Scala can give a wonderful set of tooling to developers. PMs and
"thought leaders" that shy away from trying other techniques and
languages are kidding themselves. Scala might simply not work for
your team however. Teams are full of people with differing levels of
skill, and you should think about the other developers as well. But
why not give them a chance to increase their toolkit, mental and
otherwise - you may be surprised.

With regards to the hiring meme that follows - if the developer can't
pick up Scala enough to use it on a project - (s)he is more than
likely to suffer in Java as well. You did want to hire capable devs
right?

I'm really not happy with the elitism statements bandied about here
and in blogs, I mean really - its not intellectual smugness that
drives people to use other languages - its a thirst to improve things
- to make it easier to create solutions. I'm not L33t, I just want to
get stuff done more quickly, Scala could let me do that - if I wasn't
encumbered with many other blockers (that EP thing again).

I'm sure I'll regret having posted this but I thought it worth thanking you.

On Mon, Nov 14, 2011 at 10:28 PM, Jed Wesley-Smith
wrote:
> This idea that all engineers are created equal and that programming is
> essentially a cookie cutter exercise is a furphy that suits corporate shops
> very nicely. This kind of thinking led to off-shoring and the like and has
> been mostly discredited. Programming is hard, and programmers need to
> continually improve and learn as technology and the state of the art
> evolves.
> The thing that amazes me most in this kind of debate is the internal
> dishonesty of the common definitions of "complex" and "unmaintainable". A
> lot use these as synonyms for "unfamiliar" – particularly for syntactic
> constructs. However, these syntactic constructs may actually encode a much
> simpler execution profile. A classic example being a stack based functional
> program. This is much simpler than an imperative algorithm with side-effects
> – but the second version is "easier to read". A text-book example of
> mistaking easier for simpler. Many times I see hundred line methods with
> many embedded side-effects accepted over succinct functional abstractions
> purely due to syntactic unfamiliarity.
> Rich Hickey had a talk* recently about the value of simple over easy. While
> he perhaps has some  controversial things to say about verification
> techniques – the point is still a good one. Mistaking easy (which is
> subjective) with simple (which is objective) leads to poor decisions and a
> herd mentality.
> What makes Scala a fantastic language for corporate environments is its
> abstraction tools. By enabling the brighter members of your teams to provide
> abstracted library for everyone else you actually enable everyone to get
> more done faster. This is not something to be afraid of but something to
> rejoice in.
> * http://www.infoq.com/presentations/Simple-Made-Easy
>
> On 15 November 2011 07:51, Jesper Nordenberg wrote:
>>
>> Amen.
>>
>> Something I'm truly allergic to is the idea of "interchangeable engineers"
>> that seems to be prevalent in the corporate world. That somehow all software
>> engineers comes from the mold and have the same level of expertise and
>> experience. Nothing could be further from the truth...
>>
>> /Jesper Nordenberg
>>
>> Tony Morris skrev 2011-11-14 21:29:
>>>
>>> On 11/15/2011 04:43 AM, Ken McDonald wrote:
>>>>
>>>> Hello from the original poster of this article. I've had my #1
>>>> position changed by a couple of articles including one good, long one
>>>> by Jim Herber (sp?). So here it is: the #1 problem with Scala being
>>>> accepted in the Enterprise world:
>>>>
>>>>     Scala is too complex.
>>>
>>> No.
>>>
>>>>
>>>> Not too long ago, I would have said this is incorrect, because Scala
>>>> can be used at 90% productivity while being no more complex than Java.
>>>> My attitude was changed by the aforementioned articles, plus some
>>>> recent experience with collections.breakOut.
>>>>
>>>> 1) The obvious: Scala can be used as great advantage without undue
>>>> complexity. However, there will always be people in an organization
>>>> who are capable of using the more complex features, and ultimately do
>>>> so regardless of coding guidelines. They will leave behind them code
>>>> that the standard programmer, or even another advanced programmer who
>>>> took a different tack in the Scala ecosphere, are simply unable to
>>>> maintain. This is simply death to a large organization; much as we
>>>> would like to think of ourselves as uniquely talented individuals,
>>>> they _must_ have interchangeable engineers in order to continue their
>>>> existence.
>>>
>>> This is not what happens at all. It only looks that way to you.
>>>
>>> What really happens is that there will always be people who either
>>> refuse or fail to understand the intrinisically theoretical nature of
>>> our profession. You need only look outside of Scala for many examples of
>>> this. This leads some to introduce undue complexity while complaining
>>> about precise solutions because of some cognitive dilemma. By this I
>>> mean, you will hear people complain of "I am  unable to read the code",
>>> yet not considering the possibility that the problem is the "I" part,
>>> not the "code" part in that statement. They're simply unacquainted with
>>> the fundamentals of the profession; this symptom is *absolutely
>>> prolific*.
>>>
>>> This leaves people who wish to solve problems, actually solve them
>>> instead of piss-fiddling about, burdened with such riclildudlous
>>> bureaucracy like "coding guidelines." A resentment of this
>>> fiddle-farting can begin to form, leading those who wish to actually
>>> solve problems ignoring the nonsense and just getting on with it.
>>>
>>> But it doesn't end there. Those who wish to solve problems also have to
>>> endure the seemingly endless whining, while simultaneously solving
>>> actual problems. It just gets out of hand, so something must be
>>> sacrificed -- often politeness.
>>>
>>> People who solve actual problems, without undue complexity or
>>> redundancy, are often charged with "leaving behind unmaintainable code."
>>> To these people, I tell you: I have developed a strategy for dealing
>>> with this charge. What you do is you actually solve the problem; nice
>>> and easy *but don't tell anyone*. Next, you introduce the unnecessary
>>> complexity, however, you must be very tactful here. Make sure it is not
>>> obvious that the complexity can be removed without penalty -- it must
>>> appear to be intertwined and inherent to the nature of the problem at
>>> hand. However, you don't want to *actually* burden yourself with this
>>> entanglement -- you've just got to give the appearance. Essentially,
>>> perhaps most importantly, you must always remember that you are solving
>>> an additional problem on top of the computational one: that of a social
>>> disorder which gives rise to masochistic tendencies. Make up a few terms
>>> that have no meaning -- ensure that you can shift the goal posts at
>>> will. You probably think I am joking here; I am not -- I have several
>>> tools for dealing with this disorder. This means that your dealings with
>>> the nonsense are very short-lived.
>>>
>>>
>>>>
>>>> 2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
>>>> one feature does not "overlap" another feature, so each additional
>>>> feature multiplies the abilities of Scala by the number of its
>>>> possible states. Java is not so orthogonal, so let's say that each
>>>> feature adds to the abilities of Java by the number of its position in
>>>> the feature sequence. Let's assume that each language has five
>>>> "features", each of which may be "used" or "unused". Scala has 2^5
>>>> possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
>>>> counterargument to this is that you can understand entire swaths of
>>>> the Scala feature set by understanding a single concept. This is
>>>> theoretically true, but realistically invalid. For example, I placed
>>>> in the upper part of the top 1% of the GREs when I took them, and I
>>>> don't understand a freakin' thing about scalaz, plus my understanding
>>>> of implicit parameters is coming along very slowly. I'm sure that many
>>>> of you are brighter than I, but consider the target; the Enterprise
>>>> programmer. They are not even in my IQ range, let alone yours. (No
>>>> offense to EP programmers out there. I've appreciated other people's
>>>> well-written, non fancy code, as opposed to brilliant, impenetrable
>>>> code, many times in my career. And to be honest, you almost certainly
>>>> have a much more successful personal life than I do.)
>>>
>>> *boggle*
>>>
>>>>
>>>> 3) Least obvious: more power =/= more productivity. So the Scala type
>>>> system is Turing complete, great. How many think this is important?
>>>> How many think this should be used in code? How many think this is,
>>>> net, a gain? I'm hoping the answer is well under 5% in each case. This
>>>> is a bit of a rehash of (2) above, but not completely. Scala has a lot
>>>> of features. To be honest, it has _enough_ features for the time
>>>> being, unless new features can simplify it.
>>>
>>> If you are incapable of using a more proficient programming language,
>>> you're not going to be more capable with a less proficient programming
>>> language. It's just a myth. To be clear, Java programmers seldom get
>>> anything useful done; they just appear to, and solicit peer support that
>>> they have done -- good for them, but don't for a minute expect me to
>>> deny it.
>>>
>>>
>>>>
>>>> How to handle this situation in the Enterprise? One previous post
>>>> mentioned "Scala Lite", but did not elaborate. I think it's time to
>>>> consider the possibility of optionally "feature-restricting" Scala so
>>>> that the Enterprise can ensure its code is at a certain level of
>>>> approachability. I won't try to give a full spec here, but will give
>>>> one suggestion I think makes sense: It should be possible, in the
>>>> Enterprise, to disable the ability to define implicit parameters.
>>>>
>>>> Other suggestions are left for other readers.
>>>>
>>>>
>>>> Cheers,
>>>> Ken
>>>>
>>>
>>> There is a valid "Scala is too complex" argument, but nobody is anywhere
>>> near the ball. Not even close. This is sad.
>>>
>>
>>
>
>

The idea of "interchangeable engineers" is treating software developers as fungible resources. With software development being an area where fungibility is wildly inapplicable, my view is that forcing the fungible resource model on software developers costs companies many times as much money, often an order of magnitude or more, and creates a significantly higher rate of outright and partial failure. It is rich to see management driven by aspirations of predictability, cheaper resources, and no-points-of-failure repeatedly spend mountains of money to fail when they could have succeeded with modest amounts of money.
Jon

On Mon, Nov 14, 2011 at 3:51 PM, Jesper Nordenberg <megagurka@yahoo.com> wrote:

Amen.

Something I'm truly allergic to is the idea of "interchangeable engineers" that seems to be prevalent in the corporate world. That somehow all software engineers comes from the mold and have the same level of expertise and experience. Nothing could be further from the truth...

/Jesper Nordenberg

Tony Morris skrev 2011-11-14 21:29:

On 11/15/2011 04:43 AM, Ken McDonald wrote:

Hello from the original poster of this article. I've had my #1
position changed by a couple of articles including one good, long one
by Jim Herber (sp?). So here it is: the #1 problem with Scala being
accepted in the Enterprise world:

    Scala is too complex.

No.

Not too long ago, I would have said this is incorrect, because Scala
can be used at 90% productivity while being no more complex than Java.
My attitude was changed by the aforementioned articles, plus some
recent experience with collections.breakOut.

1) The obvious: Scala can be used as great advantage without undue
complexity. However, there will always be people in an organization
who are capable of using the more complex features, and ultimately do
so regardless of coding guidelines. They will leave behind them code
that the standard programmer, or even another advanced programmer who
took a different tack in the Scala ecosphere, are simply unable to
maintain. This is simply death to a large organization; much as we
would like to think of ourselves as uniquely talented individuals,
they _must_ have interchangeable engineers in order to continue their
existence.

This is not what happens at all. It only looks that way to you.

What really happens is that there will always be people who either
refuse or fail to understand the intrinisically theoretical nature of
our profession. You need only look outside of Scala for many examples of
this. This leads some to introduce undue complexity while complaining
about precise solutions because of some cognitive dilemma. By this I
mean, you will hear people complain of "I am  unable to read the code",
yet not considering the possibility that the problem is the "I" part,
not the "code" part in that statement. They're simply unacquainted with
the fundamentals of the profession; this symptom is *absolutely prolific*.

This leaves people who wish to solve problems, actually solve them
instead of piss-fiddling about, burdened with such riclildudlous
bureaucracy like "coding guidelines." A resentment of this
fiddle-farting can begin to form, leading those who wish to actually
solve problems ignoring the nonsense and just getting on with it.

But it doesn't end there. Those who wish to solve problems also have to
endure the seemingly endless whining, while simultaneously solving
actual problems. It just gets out of hand, so something must be
sacrificed -- often politeness.

People who solve actual problems, without undue complexity or
redundancy, are often charged with "leaving behind unmaintainable code."
To these people, I tell you: I have developed a strategy for dealing
with this charge. What you do is you actually solve the problem; nice
and easy *but don't tell anyone*. Next, you introduce the unnecessary
complexity, however, you must be very tactful here. Make sure it is not
obvious that the complexity can be removed without penalty -- it must
appear to be intertwined and inherent to the nature of the problem at
hand. However, you don't want to *actually* burden yourself with this
entanglement -- you've just got to give the appearance. Essentially,
perhaps most importantly, you must always remember that you are solving
an additional problem on top of the computational one: that of a social
disorder which gives rise to masochistic tendencies. Make up a few terms
that have no meaning -- ensure that you can shift the goal posts at
will. You probably think I am joking here; I am not -- I have several
tools for dealing with this disorder. This means that your dealings with
the nonsense are very short-lived.

2) Somewhat less obvious: Scala is a highly orthogonal language, i.e.
one feature does not "overlap" another feature, so each additional
feature multiplies the abilities of Scala by the number of its
possible states. Java is not so orthogonal, so let's say that each
feature adds to the abilities of Java by the number of its position in
the feature sequence. Let's assume that each language has five
"features", each of which may be "used" or "unused". Scala has 2^5
possible "feature interactions". Java, by contract, has 1+2+3+4+5. The
counterargument to this is that you can understand entire swaths of
the Scala feature set by understanding a single concept. This is
theoretically true, but realistically invalid. For example, I placed
in the upper part of the top 1% of the GREs when I took them, and I
don't understand a freakin' thing about scalaz, plus my understanding
of implicit parameters is coming along very slowly. I'm sure that many
of you are brighter than I, but consider the target; the Enterprise
programmer. They are not even in my IQ range, let alone yours. (No
offense to EP programmers out there. I've appreciated other people's
well-written, non fancy code, as opposed to brilliant, impenetrable
code, many times in my career. And to be honest, you almost certainly
have a much more successful personal life than I do.)

*boggle*

3) Least obvious: more power =/= more productivity. So the Scala type
system is Turing complete, great. How many think this is important?
How many think this should be used in code? How many think this is,
net, a gain? I'm hoping the answer is well under 5% in each case. This
is a bit of a rehash of (2) above, but not completely. Scala has a lot
of features. To be honest, it has _enough_ features for the time
being, unless new features can simplify it.

If you are incapable of using a more proficient programming language,
you're not going to be more capable with a less proficient programming
language. It's just a myth. To be clear, Java programmers seldom get
anything useful done; they just appear to, and solicit peer support that
they have done -- good for them, but don't for a minute expect me to
deny it.

How to handle this situation in the Enterprise? One previous post
mentioned "Scala Lite", but did not elaborate. I think it's time to
consider the possibility of optionally "feature-restricting" Scala so
that the Enterprise can ensure its code is at a certain level of
approachability. I won't try to give a full spec here, but will give
one suggestion I think makes sense: It should be possible, in the
Enterprise, to disable the ability to define implicit parameters.

Other suggestions are left for other readers.


Cheers,
Ken

There is a valid "Scala is too complex" argument, but nobody is anywhere
near the ball. Not even close. This is sad.

On Monday, November 14, 2011 8:43:22 PM UTC+2, Ken McDonald wrote:

Hello from the original poster of this article. I've had my #1 position changed by a couple of articles including one good, long one by Jim Herber (sp?). So here it is: the #1 problem with Scala being accepted in the Enterprise world:
    Scala is too complex.

I agree 100%. Scala is complex. Not because the spec is complex, but because the subjective minds of many developers deem it as complex. These are the potential clients of the language. If they say the "product" is too complex for them, they are right.

The reply should not be trying to prove that Scala is in fact simple, or telling them they are princesses. Rather, it should be that it is worth handling the complexity because of the benefits. Most developers already deal with several complex frameworks, because they understand the value they bring. We should focus on the value side of Scala, not the cost of larning it.

The value is in more robust, maintainable, performant code and productivity. Examples are static typing (performance, robustness, navigation),  traits (modularity), type classes (via implicits, creating ad-hoc modularity, rather than baking it into the class), function values (not everything is an entity), lazy vals and call by name arguments (performance), case classes (productivity).

And if a developer does not see the value of these features, maybe he is not a client for the language. Similar to how some people don't like smart phones. That is ok. We should focus on those that will "buy" the language, if it is presented correctly to them

Ittay
 

Not too long ago, I would have said this is incorrect, because Scala can be used at 90% productivity while being no more complex than Java. My attitude was changed by the aforementioned articles, plus some recent experience with collections.breakOut.
1) The obvious: Scala can be used as great advantage without undue complexity. However, there will always be people in an organization who are capable of using the more complex features, and ultimately do so regardless of coding guidelines. They will leave behind them code that the standard programmer, or even another advanced programmer who took a different tack in the Scala ecosphere, are simply unable to maintain. This is simply death to a large organization; much as we would like to think of ourselves as uniquely talented individuals, they _must_ have interchangeable engineers in order to continue their existence.
2) Somewhat less obvious: Scala is a highly orthogonal language, i.e. one feature does not "overlap" another feature, so each additional feature multiplies the abilities of Scala by the number of its possible states. Java is not so orthogonal, so let's say that each feature adds to the abilities of Java by the number of its position in the feature sequence. Let's assume that each language has five "features", each of which may be "used" or "unused". Scala has 2^5 possible "feature interactions". Java, by contract, has 1+2+3+4+5. The counterargument to this is that you can understand entire swaths of the Scala feature set by understanding a single concept. This is theoretically true, but realistically invalid. For example, I placed in the upper part of the top 1% of the GREs when I took them, and I don't understand a freakin' thing about scalaz, plus my understanding of implicit parameters is coming along very slowly. I'm sure that many of you are brighter than I, but consider the target; the Enterprise programmer. They are not even in my IQ range, let alone yours. (No offense to EP programmers out there. I've appreciated other people's well-written, non fancy code, as opposed to brilliant, impenetrable code, many times in my career. And to be honest, you almost certainly have a much more successful personal life than I do.)
3) Least obvious: more power =/= more productivity. So the Scala type system is Turing complete, great. How many think this is important? How many think this should be used in code? How many think this is, net, a gain? I'm hoping the answer is well under 5% in each case. This is a bit of a rehash of (2) above, but not completely. Scala has a lot of features. To be honest, it has _enough_ features for the time being, unless new features can simplify it.
How to handle this situation in the Enterprise? One previous post mentioned "Scala Lite", but did not elaborate. I think it's time to consider the possibility of optionally "feature-restricting" Scala so that the Enterprise can ensure its code is at a certain level of approachability. I won't try to give a full spec here, but will give one suggestion I think makes sense: It should be possible, in the Enterprise, to disable the ability to define implicit parameters.
Other suggestions are left for other readers.

Cheers,Ken

On 15/11/11 16:22, Ittay Dror wrote:
> Not because the spec is complex, but
> because the subjective minds of many developers deem it as complex. These
> are the potential clients of the language. If they say the "product" is too
> complex for them, they are right.

You don't see a great big gaping hole in this argument and this very
fact fascinates me endlessly.

On Mon, Nov 14, 2011 at 12:05 PM, HamsterofDeath <h-star@gmx.de> wrote:

java is much better suited for big teams *because* it's a stupid
language that feels like you're coding with yours hands bound. the more
humans you add to a group, the more stupid each individual gets, even if
they all are geniuses.

You're not going to win over a lot of Java programmers with this depressingly condescending and sadly widespread  attitude.
--  Cédric

On Mon, Nov 14, 2011 at 12:36 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

http://en.wiktionary.org/wiki/pimp#Verb

Honestly, I don't care all that much by people who refuse to learn the
language they speak.

Ah, come on, now, let's not be obtuse. Do a search and the first two links are about sex and prostitutes.
This expression needs to disappear from the Scala lingo. "Enrich" is a great substitute.
-- Cédric

On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris <tonymorris@gmail.com> wrote:

Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?

It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.
-- Cédric

body p { margin-bottom: 0cm; margin-top: 0pt; }

Tony Morris wrote:

4EC21421 [dot] 4060004 [at] gmail [dot] com" type="cite">

On 15/11/11 16:22, Ittay Dror wrote:

Not because the spec is complex, but 
because the subjective minds of many developers deem it as complex. These 
are the potential clients of the language. If they say the "product" is too 
complex for them, they are right. 

You don't see a great big gaping hole in this argument and this very
fact fascinates me endlessly.

it isn't a matter of logic, but of emotions. people are irrational. and still, i want to convince these developers to try and use scala. i do this for my own benefit: so that the next place i work in will be a scala shop. talking about specs and toughening up just doesn't win IMHO.

4EC21421 [dot] 4060004 [at] gmail [dot] com" type="cite">

On 15/11/11 18:24, Ittay Dror wrote:
>
> Tony Morris wrote:
> > On 15/11/11 16:22, Ittay Dror wrote:
> >> Not because the spec is complex, but
> >> because the subjective minds of many developers deem it as complex. These
> >> are the potential clients of the language. If they say the "product" is too
> >> complex for them, they are right.
> > You don't see a great big gaping hole in this argument and this very
> > fact fascinates me endlessly.
> it isn't a matter of logic, but of emotions. people are irrational. and still, i
> want to convince these developers to try and use scala. i do this for my own
> benefit: so that the next place i work in will be a scala shop. talking about
> specs and toughening up just doesn't win IMHO.
> >
Does this "not a matter of logic" and "people are irrational" mantra
that is bandied about also mean I can dismiss your argument? Because it
sure is inviting it.

On 15 Nov 2011, at 08:48, "Tony Morris" wrote:

> On 15/11/11 18:24, Ittay Dror wrote:
>>
>> Tony Morris wrote:
>>> On 15/11/11 16:22, Ittay Dror wrote:
>>>> Not because the spec is complex, but
>>>> because the subjective minds of many developers deem it as complex. These
>>>> are the potential clients of the language. If they say the "product" is too
>>>> complex for them, they are right.
>>> You don't see a great big gaping hole in this argument and this very
>>> fact fascinates me endlessly.
>> it isn't a matter of logic, but of emotions. people are irrational. and still, i
>> want to convince these developers to try and use scala. i do this for my own
>> benefit: so that the next place i work in will be a scala shop. talking about
>> specs and toughening up just doesn't win IMHO.
>>>
> Does this "not a matter of logic" and "people are irrational" mantra
> that is bandied about also mean I can dismiss your argument? Because it
> sure is inviting it.
>

Exactly!  The *only* thing that counts is demonstrating that you can solve an existing problem better than current techniques.  There are many of these where Scala excels, right now the biggest is that it's really very good at DSLs.
Talk to anyone who's witnessed a process breaking down or a project failing and the #1 observation is invariably that there was a lack of communication.
If your language has the DSL support to work directly in the business domain, and if your test/spec framework reads closely enough to user stories that even a non-programmer can review them and spot problems, then everybody can "speak the same language" and communication is vastly improved.
The other widespread problem that Scala helps with is technical debt.  A smaller codebase with better abstractions and less repetition is simply more maintainable.  If I can read the essential complexity in a piece of logic without having to wade through boilerplate, then I'm going to be getting more tasks done for every day that I'm paid.
Massive concurrency is important too.  But if you work in a domain where it's relevant to you, then I guess you already know this :)

2011/11/15 Cédric Beust ♔ <cedric@beust.com>

On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris <tonymorris@gmail.com> wrote:

Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?

It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.
-- Cédric

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

While that may hold true sometimes, in the general case - if you refer to programming languages, it is completely false.

 

Lacking certain tools to SIMPLY express certain constructs (like multiple inheritance or lambdas) leads to mountains of incomprehensible code to

a)      achieve the same solution to the problem which stays the same

b)      implement an alternative, less efficient solution to the same problem

 

Most of the time, in programming, the simpler language complicates things.

 

Having said that, I don’t think a Scala Lite is the answer. I do however think that having configurable compiler warnings based on Martin’s language levels is a better approach.

 

If my two positions here seem to contradict each-other is because they do, to some extent. The world ain’t black and white.

 

From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Cédric Beust ?
Sent: November-15-11 3:28 AM
To: tmorris@tmorris.net
Cc: scala-user@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

 

 

On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris <tonymorris@gmail.com> wrote:

Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?

 

It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.

 

-- 

Cédric

 

Guys, please move this to scala-debate.

On Nov 15, 2011 8:21 AM, "Razvan Cojocaru" <pub@razie.com> wrote:

While that may hold true sometimes, in the general case - if you refer to programming languages, it is completely false.

 

Lacking certain tools to SIMPLY express certain constructs (like multiple inheritance or lambdas) leads to mountains of incomprehensible code to

a)      achieve the same solution to the problem which stays the same

b)      implement an alternative, less efficient solution to the same problem

 

Most of the time, in programming, the simpler language complicates things.

 

Having said that, I don’t think a Scala Lite is the answer. I do however think that having configurable compiler warnings based on Martin’s language levels is a better approach.

 

If my two positions here seem to contradict each-other is because they do, to some extent. The world ain’t black and white.

 

From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Cédric Beust ?
Sent: November-15-11 3:28 AM
To: tmorris@tmorris.net
Cc: scala-user@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

 

 

On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris <tonymorris@gmail.com> wrote:

Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?

 

It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.

 

-- 

Cédric

 

Guys, please move this to scala-debate.

On Nov 15, 2011 8:21 AM, "Razvan Cojocaru" <pub@razie.com> wrote:

While that may hold true sometimes, in the general case - if you refer to programming languages, it is completely false.

 

Lacking certain tools to SIMPLY express certain constructs (like multiple inheritance or lambdas) leads to mountains of incomprehensible code to

a)      achieve the same solution to the problem which stays the same

b)      implement an alternative, less efficient solution to the same problem

 

Most of the time, in programming, the simpler language complicates things.

 

Having said that, I don’t think a Scala Lite is the answer. I do however think that having configurable compiler warnings based on Martin’s language levels is a better approach.

 

If my two positions here seem to contradict each-other is because they do, to some extent. The world ain’t black and white.

 

From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Cédric Beust ?
Sent: November-15-11 3:28 AM
To: tmorris@tmorris.net
Cc: scala-user@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

 

 

On Mon, Nov 14, 2011 at 12:48 PM, Tony Morris <tonymorris@gmail.com> wrote:

Scala Lite. Are we doomed to the cesspits of neurotic aversion to thinking?

 

It's about using the right tool for the job. And sometimes, a simpler tool is the right choice.

 

-- 

Cédric

 

On 2011-11-14 10:22 PM, Ittay Dror wrote:

On Monday, November 14, 2011 8:43:22 PM UTC+2, Ken McDonald wrote:

Hello from the original poster of this article. I've had my #1 position changed by a couple of articles including one good, long one by Jim Herber (sp?). So here it is: the #1 problem with Scala being accepted in the Enterprise world:
    Scala is too complex.

I agree 100%. Scala is complex. Not because the spec is complex, but because the subjective minds of many developers deem it as complex. These are the potential clients of the language. If they say the "product" is too complex for them, they are right.

Excellent point!

The reply should not be trying to prove that Scala is in fact simple, or telling them they are princesses. Rather, it should be that it is worth handling the complexity because of the benefits. Most developers already deal with several complex frameworks, because they understand the value they bring. We should focus on the value side of Scala, not the cost of larning it.

Another great point!

The value is in more robust, maintainable, performant code and productivity. Examples are static typing (performance, robustness, navigation),  traits (modularity), type classes (via implicits, creating ad-hoc modularity, rather than baking it into the class), function values (not everything is an entity), lazy vals and call by name arguments (performance), case classes (productivity).

And if a developer does not see the value of these features, maybe he is not a client for the language. Similar to how some people don't like smart phones. That is ok. We should focus on those that will "buy" the language, if it is presented correctly to them

Exactly!

Ittay
 

Not too long ago, I would have said this is incorrect, because Scala can be used at 90% productivity while being no more complex than Java. My attitude was changed by the aforementioned articles, plus some recent experience with collections.breakOut.
1) The obvious: Scala can be used as great advantage without undue complexity. However, there will always be people in an organization who are capable of using the more complex features, and ultimately do so regardless of coding guidelines. They will leave behind them code that the standard programmer, or even another advanced programmer who took a different tack in the Scala ecosphere, are simply unable to maintain. This is simply death to a large organization; much as we would like to think of ourselves as uniquely talented individuals, they _must_ have interchangeable engineers in order to continue their existence.
2) Somewhat less obvious: Scala is a highly orthogonal language, i.e. one feature does not "overlap" another feature, so each additional feature multiplies the abilities of Scala by the number of its possible states. Java is not so orthogonal, so let's say that each feature adds to the abilities of Java by the number of its position in the feature sequence. Let's assume that each language has five "features", each of which may be "used" or "unused". Scala has 2^5 possible "feature interactions". Java, by contract, has 1+2+3+4+5. The counterargument to this is that you can understand entire swaths of the Scala feature set by understanding a single concept. This is theoretically true, but realistically invalid. For example, I placed in the upper part of the top 1% of the GREs when I took them, and I don't understand a freakin' thing about scalaz, plus my understanding of implicit parameters is coming along very slowly. I'm sure that many of you are brighter than I, but consider the target; the Enterprise programmer. They are not even in my IQ range, let alone yours. (No offense to EP programmers out there. I've appreciated other people's well-written, non fancy code, as opposed to brilliant, impenetrable code, many times in my career. And to be honest, you almost certainly have a much more successful personal life than I do.)
3) Least obvious: more power =/= more productivity. So the Scala type system is Turing complete, great. How many think this is important? How many think this should be used in code? How many think this is, net, a gain? I'm hoping the answer is well under 5% in each case. This is a bit of a rehash of (2) above, but not completely. Scala has a lot of features. To be honest, it has _enough_ features for the time being, unless new features can simplify it.
How to handle this situation in the Enterprise? One previous post mentioned "Scala Lite", but did not elaborate. I think it's time to consider the possibility of optionally "feature-restricting" Scala so that the Enterprise can ensure its code is at a certain level of approachability. I won't try to give a full spec here, but will give one suggestion I think makes sense: It should be possible, in the Enterprise, to disable the ability to define implicit parameters.
Other suggestions are left for other readers.

Cheers, Ken

On 2011-11-14 11:26 PM, Tony Morris wrote:
> On 15/11/11 16:22, Ittay Dror wrote:
>> Not because the spec is complex, but
>> because the subjective minds of many developers deem it as complex. These
>> are the potential clients of the language. If they say the "product" is too
>> complex for them, they are right.
> You don't see a great big gaping hole in this argument and this very
> fact fascinates me endlessly.
I disagree, I think there is no hole in this argument.

If you look at it in capitalistic or economic terms, the value of a
stock is usually related to the number of people willing to invest in
it. If the subjective minds of many investors deem the stock too risky,
then they are not likely to invest.

On the other hand, if you can show them that while the stock may be
risky, but still valuable in other ways, then they may be more willing
to invest. Don't try to change people's minds on what they have already
decided, instead show them other things they have not yet considered or
made up their minds on.

Scala is no different than any stock in this respect, and is not the
whole point of this debate is how to convince more developers and
architects, especially in the corporate world, to invest in Scala?

I think Ittay Dror showed us some remarkable economic insight there. Kudos!

With insight, change can begin.

On 2011-11-14 10:22 PM, Ittay Dror wrote:

On Monday, November 14, 2011 8:43:22 PM UTC+2, Ken McDonald wrote:

Hello from the original poster of this article. I've had my #1 position changed by a couple of articles including one good, long one by Jim Herber (sp?). So here it is: the #1 problem with Scala being accepted in the Enterprise world:
    Scala is too complex.

I agree 100%. Scala is complex. Not because the spec is complex, but because the subjective minds of many developers deem it as complex. These are the potential clients of the language. If they say the "product" is too complex for them, they are right.

Excellent point!

The reply should not be trying to prove that Scala is in fact simple, or telling them they are princesses. Rather, it should be that it is worth handling the complexity because of the benefits. Most developers already deal with several complex frameworks, because they understand the value they bring. We should focus on the value side of Scala, not the cost of larning it.

Another great point!

The value is in more robust, maintainable, performant code and productivity. Examples are static typing (performance, robustness, navigation),  traits (modularity), type classes (via implicits, creating ad-hoc modularity, rather than baking it into the class), function values (not everything is an entity), lazy vals and call by name arguments (performance), case classes (productivity).

And if a developer does not see the value of these features, maybe he is not a client for the language. Similar to how some people don't like smart phones. That is ok. We should focus on those that will "buy" the language, if it is presented correctly to them

Exactly!

Ittay
 

Not too long ago, I would have said this is incorrect, because Scala can be used at 90% productivity while being no more complex than Java. My attitude was changed by the aforementioned articles, plus some recent experience with collections.breakOut.
1) The obvious: Scala can be used as great advantage without undue complexity. However, there will always be people in an organization who are capable of using the more complex features, and ultimately do so regardless of coding guidelines. They will leave behind them code that the standard programmer, or even another advanced programmer who took a different tack in the Scala ecosphere, are simply unable to maintain. This is simply death to a large organization; much as we would like to think of ourselves as uniquely talented individuals, they _must_ have interchangeable engineers in order to continue their existence.
2) Somewhat less obvious: Scala is a highly orthogonal language, i.e. one feature does not "overlap" another feature, so each additional feature multiplies the abilities of Scala by the number of its possible states. Java is not so orthogonal, so let's say that each feature adds to the abilities of Java by the number of its position in the feature sequence. Let's assume that each language has five "features", each of which may be "used" or "unused". Scala has 2^5 possible "feature interactions". Java, by contract, has 1+2+3+4+5. The counterargument to this is that you can understand entire swaths of the Scala feature set by understanding a single concept. This is theoretically true, but realistically invalid. For example, I placed in the upper part of the top 1% of the GREs when I took them, and I don't understand a freakin' thing about scalaz, plus my understanding of implicit parameters is coming along very slowly. I'm sure that many of you are brighter than I, but consider the target; the Enterprise programmer. They are not even in my IQ range, let alone yours. (No offense to EP programmers out there. I've appreciated other people's well-written, non fancy code, as opposed to brilliant, impenetrable code, many times in my career. And to be honest, you almost certainly have a much more successful personal life than I do.)
3) Least obvious: more power =/= more productivity. So the Scala type system is Turing complete, great. How many think this is important? How many think this should be used in code? How many think this is, net, a gain? I'm hoping the answer is well under 5% in each case. This is a bit of a rehash of (2) above, but not completely. Scala has a lot of features. To be honest, it has _enough_ features for the time being, unless new features can simplify it.
How to handle this situation in the Enterprise? One previous post mentioned "Scala Lite", but did not elaborate. I think it's time to consider the possibility of optionally "feature-restricting" Scala so that the Enterprise can ensure its code is at a certain level of approachability. I won't try to give a full spec here, but will give one suggestion I think makes sense: It should be possible, in the Enterprise, to disable the ability to define implicit parameters.
Other suggestions are left for other readers.

Cheers, Ken

On 2011-11-15 6:50 AM, Eric Kolotyluk wrote:
> On 2011-11-14 11:26 PM, Tony Morris wrote:
>> On 15/11/11 16:22, Ittay Dror wrote:
>>> Not because the spec is complex, but
>>> because the subjective minds of many developers deem it as complex.
>>> These
>>> are the potential clients of the language. If they say the "product"
>>> is too
>>> complex for them, they are right.
>> You don't see a great big gaping hole in this argument and this very
>> fact fascinates me endlessly.
> I disagree, I think there is no hole in this argument.
>
> If you look at it in capitalistic or economic terms, the value of a
> stock is usually related to the number of people willing to invest in
> it. If the subjective minds of many investors deem the stock too
> risky, then they are not likely to invest.
>
> On the other hand, if you can show them that while the stock may be
> risky, but still valuable in other ways, then they may be more willing
> to invest. Don't try to change people's minds on what they have
> already decided, instead show them other things they have not yet
> considered or made up their minds on.
>
> Scala is no different than any stock in this respect, and is not the
> whole point of this debate is how to convince more developers and
> architects, especially in the corporate world, to invest in Scala?
>
> I think Ittay Dror showed us some remarkable economic insight there.
> Kudos!
>
> With insight, change can begin.

The greatest barrier to scala adoption by large enterprises is the certain knowledge that initial productivity gains will ultimately be offset as every single developer is dragged into yet another sequence of interminable debates on the complexity, or otherwise, of the language.
Chris

On Monday, November 14, 2011 8:43:22 PM UTC+2, Ken McDonald wrote:

Hello from the original poster of this article. I've had my #1 position changed by a couple of articles including one good, long one by Jim Herber (sp?). So here it is: the #1 problem with Scala being accepted in the Enterprise world:
    Scala is too complex.

Moving this to debate as per request.

On Tue, Nov 15, 2011 at 9:36 AM, Eric Kolotyluk <eric.kolotyluk@gmail.com> wrote:

On 2011-11-14 10:22 PM, Ittay Dror wrote:

On Monday, November 14, 2011 8:43:22 PM UTC+2, Ken McDonald wrote:

Hello from the original poster of this article. I've had my #1 position changed by a couple of articles including one good, long one by Jim Herber (sp?). So here it is: the #1 problem with Scala being accepted in the Enterprise world:
    Scala is too complex.

I agree 100%. Scala is complex. Not because the spec is complex, but because the subjective minds of many developers deem it as complex. These are the potential clients of the language. If they say the "product" is too complex for them, they are right.

Excellent point!

I was thinking exactly the same thing _and_ exactly the opposite thing.

For mass consumer products, like a cell phone, if the customer says it is too complex for them, then they are right; this opens up an opportunity for a simpler product (either the same one redesigned, or a new one).

But we're talking about professional software engineers here, aren't we?  People whose job it is to not only understand complex technology, but to instruct it on how to function?  If some of them complain that Scala is too complex, I think we need to look very carefully at what is going on.

Perhaps

(1) Scala isn't documented well enough, so _figuring out how to use it_ is complex, even though using it once you know it isn't complex.  Solution: better documentation (possibly better publicized or more easily accessible).

(2) Programing is complex, and Scala gives you constructs to more directly address this complexity.  Solution: rather than highlighting the complexity itself, highlight how much better it is to address a complex problem when you have tools to do so than when tools are missing.  Far too many examples show the minimal case to get anything at all working in Scala, which yields something without blatantly obvious value.  "Hello, world"-level examples are good for those who already know they want to say hello to the world, but not good for motivating apparent complexity.

(3) Scala really is complex.  Solution: come up with something simpler without sacrificing power.  Problem: people who point out complexity are almost universally unable to point out exactly how to do this.  (There are a few cases; for example, a MyType could convert the large conceptual overhead of implicit builders in collections into a trivial declaration for most common use cases.)  Conversely, some of the features most easy to abuse (i.e. yielding hard-to-understand program flow and logic) are widely desired (e.g. global mutable variables, up/downcasting to/from Object).

(4) Some people either don't know what they're doing, or know only what they're doing and don't want anything else which is more than a tiny bit different.  Anything different is "complex" for someone who already knows something and doesn't want to know more.  Solution: make it clear up front that Scala cannot be used at a high level of proficiency without learning a sizable number of new concepts.  They're worth it (see (2)), but they're there.  This doesn't make Scala complex compared to other things, just different-than-what-you-know.
 

The reply should not be trying to prove that Scala is in fact simple, or telling them they are princesses. Rather, it should be that it is worth handling the complexity because of the benefits. Most developers already deal with several complex frameworks, because they understand the value they bring. We should focus on the value side of Scala, not the cost of larning it.

Another great point!

I think this is similar to my point (2), except I'm not sure that _Scala_ deserves the blame for what is complicated (although its libraries may).  Rather, it gives powerful general features, and the consequences of those are complicated because programming is complicated.
 

The value is in more robust, maintainable, performant code and productivity. Examples are static typing (performance, robustness, navigation),  traits (modularity), type classes (via implicits, creating ad-hoc modularity, rather than baking it into the class), function values (not everything is an entity), lazy vals and call by name arguments (performance), case classes (productivity).

And if a developer does not see the value of these features, maybe he is not a client for the language. Similar to how some people don't like smart phones. That is ok. We should focus on those that will "buy" the language, if it is presented correctly to them

Exactly!

Here I agree completely.

  --Rex

As has already repeatedly been asked, please take this discussion over
to scala-debate.

http://www.scala-lang.org/node/199

On Tue, Nov 15, 2011 at 10:09 AM, Chris Marshall
wrote:
> The greatest barrier to scala adoption by large enterprises is the certain
> knowledge that initial productivity gains will ultimately be offset as every
> single developer is dragged into yet another sequence of interminable
> debates on the complexity, or otherwise, of the language.

Agree. All the hand-wringing about it is a self-sustaining,
self-fulfilling prophecy.

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

Agreed. We're going to start using "enrich" at my organization. The
use of "pimp" is embarrassing to the Scala community, which is relevant
to Scala's adoption.

On 11/15/2011 03:26 AM, Cédric Beust ♔ wrote:
> On Mon, Nov 14, 2011 at 12:36 PM, Daniel Sobral > wrote:
>
>
> http://en.wiktionary.org/wiki/pimp#Verb
>
> Honestly, I don't care all that much by people who refuse to learn the
> language they speak.
>
>
> Ah, come on, now, let's not be obtuse. Do a search
>
> and the first two links are about sex and prostitutes.
>
> This expression needs to disappear from the Scala lingo. "Enrich" is a
> great substitute.
>

On Mon, Nov 14, 2011 at 19:14, marc wrote:
>
>
> On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:
>>
>> On Mon, Nov 14, 2011 at 17:12, marc wrote:
>> > I should add that it is not the profanity that I have a problem with, if
>> > you
>> > knew me you would know that I curse
>> > regularly (you can tell my happiness working with third-party code by
>> > the
>> > metric UFPM (" uttered f*cks per minute")
>> > However, to have a core design pattern named after an absusive industry
>> > that
>> > exists solely to subjugate and profit from the exploitation of women is
>> > more
>> > than just profane, it is offensive.
>>
>> http://en.wiktionary.org/wiki/pimp#Verb
>>
>> Honestly, I don't care all that much by people who refuse to learn the
>> language they speak.
>
> Yes, the word pimp has modern usage; however, the etymology is still clear
> as is
> the current alternative meanings.    This is the same reason I don't use the
> word "gyp" to mean cheated.
> There is a history and context attached to some words and their usage cannot
> be separated from this
> association. There is a difference between word usage in social or friendly
> informal situations and in
> professional settings.  Saying to friends that your computer is "pimped out"
> is different than if Dell
> or Apple had the option to "pimp out" your machine.

Which is laudable and reasonable, as opposed of flat out claiming the
pattern was named after something it was not.

On 11/14/11 15:29, Tony Morris wrote:
> There is a valid "Scala is too complex" argument, but nobody is anywhere
> near the ball. Not even close. This is sad.

Mind enlightening us with making the "correct" 'scala is too complex' argument?

-Martin

2011/11/15 Cédric Beust ♔ :
> On Mon, Nov 14, 2011 at 12:36 PM, Daniel Sobral wrote:
>>
>> http://en.wiktionary.org/wiki/pimp#Verb
>>
>> Honestly, I don't care all that much by people who refuse to learn the
>> language they speak.
>
> Ah, come on, now, let's not be obtuse. Do a search and the first two links
> are about sex and prostitutes.
> This expression needs to disappear from the Scala lingo. "Enrich" is a great
> substitute.

Your Google is obviously different than mine:
http://www.google.com.br/search?gcx=c&sourceid=chrome&client=ubuntu&chan...

The first for links are: pimp my gun, pimp my profile, pimp my ride
and pimp my search. Then two pimp my rides, pimp my snack (?!), pimp
my safari, a brief return to pimp my ride, and closing the page is our
pimp my library.

But google searches are beside the point. Marc claimed the pattern was
named after people who explore prostitution, which is flat out wrong.
The pattern was named after customization of stuff, mainly cars.

On Mon, Nov 14, 2011 at 19:43, marc wrote:
>
>
> On Monday, November 14, 2011 1:35:33 PM UTC-8, Tony Morris wrote:
>>
>> On 11/15/2011 07:33 AM, marc wrote:
>>
>> On Monday, November 14, 2011 1:27:00 PM UTC-8, Rex Kerr wrote:
>>>
>>> On Mon, Nov 14, 2011 at 4:14 PM, marc wrote:
>>>>
>>>>
>>>> On Monday, November 14, 2011 12:36:58 PM UTC-8, Daniel Sobral wrote:
>>>>>
>>>>> On Mon, Nov 14, 2011 at 17:12, marc wrote:
>>>>> > I should add that it is not the profanity that I have a problem with,
>>>>> > if you
>>>>> > knew me you would know that I curse
>>>>> > regularly (you can tell my happiness working with third-party code by
>>>>> > the
>>>>> > metric UFPM (" uttered f*cks per minute")
>>>>> > However, to have a core design pattern named after an absusive
>>>>> > industry that
>>>>> > exists solely to subjugate and profit from the exploitation of women
>>>>> > is more
>>>>> > than just profane, it is offensive.
>>>>>
>>>>> http://en.wiktionary.org/wiki/pimp#Verb
>>>>>
>>>>> Honestly, I don't care all that much by people who refuse to learn the
>>>>> language they speak.
>>>>
>>>> Yes, the word pimp has modern usage; however, the etymology is still
>>>> clear as is
>>>> the current alternative meanings.    This is the same reason I don't use
>>>> the word "gyp" to mean cheated.
>>>> There is a history and context attached to some words and their usage
>>>> cannot be separated from this
>>>> association. There is a difference between word usage in social or
>>>> friendly informal situations and in
>>>> professional settings.  Saying to friends that your computer is "pimped
>>>> out" is different than if Dell
>>>> or Apple had the option to "pimp out" your machine.
>>>
>>> So I guess you also object to the use of foo and bar as example
>>> variables?
>>>
>>
>> No, profanity does not bother me in the slightest.  foo and bar from FUBAR
>> is whatever.  It is
>> words and phrases that have clear, violent and abusive historical
>> connection to a class of people.
>> Yes, some people are offended by profanity, but that is based on arbitrary
>> ethics/morals.  By the same
>> logic, I will swear, but not use racial slurs.
>> Again, I am *not* saying that no one should use the phrase "pimp out", but
>> in professional
>> and serious circles, it should be avoided.  And that it is the name of a
>> core concept in scala is a travesty.
>>
>> Demanding that someone stop using words because you have attributed
>> magical properties to those words is unprofessionalism of the highest order.
>> It is no different to certain thugs demanding that I do not draw specific
>> pictures of specific prophets. Your argumentum ad antiquitatem does not fly.
>>
>
>  I respect this opinion.  But historical context is not a magical property.
>  Some words have negative
> connotations attached to them that are objectively hurtful and offensive.
>  "Pimp my library" uses a phrase
> with that glamorizes the abuse and exploitation of women.  There is a clear
> distinction here between such phrases used throughout a professional
> community and profanity and phrases used between friends (or enemies...)

It uses a phrase that glamorizes the customization of cars.

I'll reply to this the once, and then stay quiet.
The capacity of people to be offended by 'pimp my library' is utterly independent of the etymology of that specific usage of 'pimp' in relation to a scala design pattern. This is not a question of logical correctness or provenance. It is exclusively an issue with people's emotional response to words. If the intention is to do the easy things we can to make it easier for scala to be adopted in the enterprise then people's negative emotional response to this word, no matter how ill-founded or irrational you may think these are, trump any and all logical arguments as to why they should feel differently. It is easy to use another word. It will be almost impossible to change people's emotional responses in the time-frame needed for them to build a positive feeling about scala so that they adopt it over something else.
People will have different responses to 'pimp my library'. It depends on your social background (if you are used to pimping up your car or pimping your girlfriend), if you are part way along the AS spectrum (in which case you may not understand why other people should be offended, given the etymology), or if you are psychopathic (in which case you just don't have much of an emotional response to words in any case). None of this matters. It is easy for us to use another word that doesn't offend and almost monolithically impossible to change 'hearts and minds' in the time-frame between someone thinking of using scala and deciding instead to use clojure or Java.
And I agree, we should probably take this to -debate.
Matthew

2011/11/15 Daniel Sobral <dcsobral@gmail.com>

2011/11/15 Cédric Beust ♔ <cedric@beust.com>:
> On Mon, Nov 14, 2011 at 12:36 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
>>
>> http://en.wiktionary.org/wiki/pimp#Verb
>>
>> Honestly, I don't care all that much by people who refuse to learn the
>> language they speak.
>
> Ah, come on, now, let's not be obtuse. Do a search and the first two links
> are about sex and prostitutes.
> This expression needs to disappear from the Scala lingo. "Enrich" is a great
> substitute.

Your Google is obviously different than mine:
http://www.google.com.br/search?gcx=c&sourceid=chrome&client=ubuntu&channel=cs&ie=UTF-8&q=pimp+my

The first for links are: pimp my gun, pimp my profile, pimp my ride
and pimp my search. Then two pimp my rides, pimp my snack (?!), pimp
my safari, a brief return to pimp my ride, and closing the page is our
pimp my library.

But google searches are beside the point. Marc claimed the pattern was
named after people who explore prostitution, which is flat out wrong.
The pattern was named after customization of stuff, mainly cars.


--
Daniel C. Sobral

I travel to the future all the time.

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

2011/11/15 Razvan Cojocaru <pub@razie.com>

Most of the time, in programming, the simpler language complicates things.

Isn't the transition from C++ to Java an obvious counter example to this claim?
-- Cédric

NOPE. Quite the contrary. I think I can prove that the LOC and headcount has gone up for the same Feature Count, whatever your favorite way to measure functional points is.

 

What it did is it allowed more people access to the job of “programmer” without much CS training, which given the previous lack of said “programmers”, seemed a good idea at the time… But, seeing the contraptions they’re capable of, I am convinced of the contrary now. C++ was in itself a great filter…

 

I think also that bug counts have shot up significantly and that supports all the above.

 

When using C++, we never interviewed more than 4-5 to select one for the “core team” while now it’s 20-30 to 1.

 

Again, do not confuse the two: the best thing about Java was, is and will always be the JVM, not the language itself (which I personally hated since day 1 and still don’t know enough to pass an online exam, as a form of protest J). Note the smiley.

 

If scala should become the new filter, my smile will only grow wider J.

 

From: cbeust@gmail.com [mailto:cbeust@gmail.com] On Behalf Of Cédric Beust ?
Sent: November-15-11 11:39 AM
To: Razvan Cojocaru
Cc: tmorris@tmorris.net; scala-user@googlegroups.com
Subject: Re: [scala-user] Re: What is highest priority for Scala to succeed in corporate world (Should be in scala-debate?) ?

 

 

2011/11/15 Razvan Cojocaru <pub@razie.com>

Most of the time, in programming, the simpler language complicates things.

 

Isn't the transition from C++ to Java an obvious counter example to this claim?

 

-- 

Cédric

Rex Kerr skrev 2011-11-15 16:21:
> (2) Programing is complex, and Scala gives you constructs to more
> directly address this complexity.

This is definitely true. People look at Scalaz code and say it's
complex, but that's simply because the abstraction level is so much
higher than anything they've seen in Java and C++. It takes time and
effort to grasp all the concepts used at these higher abstraction levels.

> (3) Scala really is complex. Solution: come up with something simpler
> without sacrificing power.

I don't see how Scala could be made much simpler without sacrificing
some power. You could simplify it to a more pure FP language like
Haskell or ML, but then you would lose the OO part and the Java
compatibility. You could simplify the type system so it becomes similar
to a language like C# or Kotlin, but then you would lose the powerful
abstractions that libraries like Scalaz can provide.

It's this combination of features that makes Scala unique and allows new
forms of constructs. And that's why I like it :)

> (4) Some people either don't know what they're doing, or know only what
> they're doing and don't want anything else which is more than a tiny bit
> different. Anything different is "complex" for someone who already
> knows something and doesn't want to know more.

This is just human nature. The only antidote is education.

/Jesper Nordenberg

Well, Google's results are based on an individual's search history. :-)

Hi,

Right. I'm not willing to spend more time on that and replaced all mentions of “pimp my ...” with “enrich ...” in the upcoming Scala tutorial for C# developers.

Can't we fix this once and for all? If you see “Pimp”, change it and send a pull request to the owner.

This worked quite nicely before (replacing “operator” with “method”).

Bye,


Simon

On 15 Nov 2011, at 14:50, Eric Kolotyluk wrote:

> Scala is no different than any stock in this respect, and is not the whole point of this debate is how to convince more developers and architects, especially in the corporate world, to invest in Scala?

From what I've seen in the financial sector in London, devs don't need a huge amount of convincing. A lot of orgs are already using scala, some in a big way.

I have met a few devs that dismiss scala as complex, but most of those haven't actually tried it my experience. They are also very comfortable being Java experts and fear the unknown. That fine by me, they can have those spring infested reflection-tastic legacy systems.

But, these orgs are gargantuan beasts that are slow and cumbersome, powered by an army of, typically, quiet devs that don't make a lot of noise about what they do.

Also, new projects don't happen often, particularly in this climate, so most of the scala work is around existing systems.

I am also being contacted by recruiters/agents on a weekly basis about scala jobs, so the demand is growing.

Fundamentally, don't underestimate how popular scala already is. But, more is better right?

Channing