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

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.

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

Hello Ken,

1)
This is already TOO true for java. Look at the 'framework' mess. Are
you sure you can handle everything a advanced 'spring' user did in a
company? I'm quite certain you can't.
Secondly that is not at all a scala related problem. You don't fix
your problems by putting framework XYZ in the job requirements.
Do you consider yourself a Senior developer?
http://groups.google.com/group/javaposse/browse_thread/thread/deb82e0c7e...

2)I dont think there is anything IQ related here. What I can tell from
my experience is maybe EP P's are lazy. They go to school/Univiversity
whatever learn xyz and then they go to business. Of course they try to
use the gained knowledge as long as possible. But first thing you
should learn as school is how to reflect upon yourself and your work
style. Sure EPP's ( and i'm one of them) are 'just' tools of the
enterprise to generated value out of directions ( hopefully). But to
do so I can choose some tools on my own too.
I don't know what GRE is , and I wont google it either. But I am a
curious person since I got introduced to scala and scalaz I learned
many things. Things that ALREADY help me in my dayjob with java. My
Thinking and thus my coding style changed. I discuss those change with
my coworkers and I think there is a very healthy balance things dont
get too far off. But they are changing.

3) I don't know but i dislike the idea of 'Scala Lite'

regards andreas

On 14 Nov., 19:43, 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.
>
> 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

time for me to join the discussion.
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. if scala would be just like
java, but with java's biggest 3 flaws solved, it would be accepted more
quickly. jetbrains is trying to create such a language (kotlin). it's
pretty much java + closures + attached methods + working generics + type
inference. but not more. we'll see if that works better. my guess is it
might.

where scala and other nerd languages (by this, i mean lisp) really shine
is when you manage to put together a small team of freaks like me and
let them roam freely. being in a small team means you won't need to
restrain yourself. even if everyone brings in his own concepts, no one
is being overwhelmed by too many. once the team grows too large, it's
like a (social) flock: the slowest birds slow down the rest.

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.

Am 14.11.2011 19:43, schrieb Ken McDonald:
> 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.
>
> 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 Mon, Nov 14, 2011 at 1:43 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> 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.
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.

I don't think this is a fault of the language.  In my experience, these developers will do so regardless of what language you put in front of them.  I've seen some amazingly complex Java frameworks.  At least in Scala, many of these 'complexities' are easier to understand and less magic than annotation processors and dynamic code generation.  Luckily, most of us just use perl for personal scripting and not group projects anymore....  

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

Claiming that Scalaz is a reason that Scala is complex is pretty poor.  Scalaz is improving, but it has for the longest time had poor documentation and naming.  As time goes on, this has been dramatically improving.   I definitely do not see Scala as a language that's "only for the intelligent".  I do see Category theory as requiring a brain able to handle abstract concepts.  However, I've done my part to try to simplify these for average developers.  I think libraries like Scalaz, if they hope to target the mass of enterprise engineers, will improve documentation and training of the core concepts.  If they don't wish to target the mass of enterprise engineers, they won't.   Simple as that.  But I don't really see the complexity of terse Scalaz code as a sign that Scala the langauge is inherently complex.   Take someone who has never seen Spring/Hibernate before and give them no help, remove the Spring manual (just source code) and see if they can understand the spring framework.   

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.

It's called "code style guidelines" and they're enforced for many different languages.   The fact that C++ has heavy usage is evidence of their effectiveness.   There are even tools that can enforce style rules, perhaps we need someone in Scala to step up with one.  

Other suggestions are left for other readers.

Cheers,Ken

On 14/11/2011 19:43, 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.
>
> 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 true for absolutely all and every languages. Or if not the
language, it's its frameworks. But I believe that was said many times,
so I'm not sure that saying it one more time will change anything.
For example, I believe I'm a correct programmer. I love programming,
understanding new things, etc. I did some work with Coq to prove some
properties about memory contiguity on a compiler. I now a bunch of Java
frameworks and contributes to several. All that to bring some
credibility to the following: I *never* get struts. I *never* get
hibernate. I *never* get Java generics. For each of them, sometime I
thought I finally get them, to discover at the next corner that that
wasn't true.

So, having interchangeable engineers is just an utopy. What Java really
have for it is something like 15 years of tries and errors that refined
some convention to be accepted and well documented to the point of "you
just have to copy that, don't think". I'm sure that with the same amount
of time and exposure to interchangeable engineers, Scala will have the
same patterns.
It was a time of Java and OO was also unable to maintain. Who really
succeeded in maintaining EJB entreprise applications ? OK, and in a cost
effective way ?

That being said, we (Scala user) have certainly some work to do in
speaking about how easy is Scala, and not only how many theorical buzz
word we are able to sank on a single line. Things like the example on
https://github.com/harrah/xsbt/wiki/Scripts

Thanks,

On 2011-11-14 10: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.
>
> 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.
Well articulated! Excellent point!

As a leader in establishing agreement in coding guidelines in my
organization I was frustrated by how many compromises we had to make for
individuals coding styles - I simply could not convince some people to
stop using Hungarian Notation in Java and C#. I was further frustrated
that after achieving a consensus, some developers continued to ignore
the agreed upon guidelines. In one case when I did a code review on
someone else's changes, then failed it because it did not conform to the
guidelines, they took it as a personal insult on their ability, which
led to a mess of other issues. As the software architect I am not sure
how I would manage these issues with Scala.
>
> 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.
Interesting Idea!
>
> Other suggestions are left for other readers.
>
>
> Cheers,
> Ken
>

Francois, don't take it personally, I was simply reporting a fact.

Going back to binary compatibility, I think that an important step has been made: Scala minor releases
are now binary compatible.
That demonstrates the problem is (1) relevant, and (2) work is being done to mitigate it.

I agree with you when you say that a Java dev is not used to deal with binary incompatibilities, hence we
need to make his (and our!) life easier.

How can we do that? In my opinion, the first thing that is needed is a way to tell programmatically if a
library is binary incompatible wrt the used scala library (the example you reported for Play! is a perfect
use case).

Just imagine the Scala IDE issuing an error when you add in the classpath a library that is not binary compatible.
I bet that it would make binary compatibility a much simpler problem to deal with (for everyone).
But for making this real we need help from the compiler. Specifically, we need to know with what Scala version
a binary class is compiled.

An additional important aspect is improving the documentation and understanding of how to evolve Scala
code to ensure release-to-release binary compatibility. If library maintainers are given the tools to strive for
binary compatible releases, then the whole problem will simply go away.

Cheers,
Mirco

On Nov 11, 2011, at 10:27 PM, Francois wrote:

> On 11/11/2011 21:55, Mirco Dotta wrote:
>>> and Scala IDE came with 2.9.
>> For the record, the Scala IDE supports both 2.8 and 2.9.
>>
>> http://download.scala-ide.org/releases-28/stable/site
>> http://download.scala-ide.org/releases-29/stable/site
>
> I do know that, as I think any Scalaiste more than some days old do. What I wanted to report is that complettly newcomers, especially Java one, it was a surprise to have to care about binary compatibility between Scala version.
>
> Well, and it was just a report, I don't want to have to argue against fact. You can take care of them of not, it was just to contribute what might be an "highest priority for Scala to succeed in corporate world".
>
> Thanks,
>