Re: Scala modularisation withdrawl

On Tue, Oct 20, 2009 at 1:56 AM, Jorge Ortiz wrote:
> The problem is shallow.
>
> Until I'm convinced otherwise, anyone declaring a dependency on anything
> other than a single Scala release is deluding themselves.

I agree ... definitely not a showstopper for a modularization effort.

Cheers,

Miles

On Tue, Oct 20, 2009 at 2:02 AM, Miles Sabin wrote:
> I agree ... definitely not a showstopper for a modularization effort.

I also hope Alex will continue. There's no need to throw out the baby
with the bath water.

Managing API evolution is one important aspect of modularisation, it's
true. But so are isolation, encapsulation and minimisation of
dependencies. One of the stated goals of this effort was to allow
applications that use only a subset of the Scala standard libraries to
depend on and ship with only the minimal closure of modules. More
robust evolution of APIs would allow individual modules to be
upgraded, and it's a shame if that is not possible yet, but we can
still put the framework in place for it to be possible in the future.

Neil

>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype:  milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin
>

Well, maybe we should throw out traits, then binary compatibility
would not be an issue anymore and modularizatiion could go forward :-)
(just joking).

Everybody, these are hard engineering problems. Contributions are
welcome. Throwing your hands up and putting the blame on others is not
helpful.

On 20 Oct 2009, at 08:18, martin odersky wrote:

> Everybody, these are hard engineering problems.

It is not a hard engineering problem to call the next version of Scala
3.0 instead of 2.8.

Whilst the lack of backward compatibility sucks, that wasn't the point
being made. The point being made was that if we're going to
(repeatedly) break backward compatibility, we should do so by
incrementing the major version each time.

Alex

On Tue, Oct 20, 2009 at 9:15 AM, Alex Blewitt wrote:
> On 20 Oct 2009, at 08:18, martin odersky wrote:
>
>> Everybody, these are hard engineering problems.
>
> It is not a hard engineering problem to call the next version of Scala 3.0
> instead of 2.8.

If the next version of Scala was labelled 3.0 rather than 2.8 would
you withdraw your withdrawl?

Cheers,

Miles

I think calling it 3.0, if 3.0 means "stable, well-tested, and better
in those respects than 2.7", would necessarily delay the release, and
delaying the release would make its stability and test status worse
than releasing it as 2.8 would.

I suggest you stick around and watch 2.8 - I expect there will be new
incompatible changes in successive 2.8 revisions, despite conscious
efforts to avoid that. Only when that's actually stopped or a class
file encoding for traits that avoids incompatibility developed would a
3.0 'with meaning' be useful.

Anyway, skipping from 2.7 to 3.0 would lose Scala the chance to make
its version numbers tend to e.

2009/10/20 Alex Blewitt :
> On 20 Oct 2009, at 08:18, martin odersky wrote:
>
>> Everybody, these are hard engineering problems.
>
> It is not a hard engineering problem to call the next version of Scala 3.0
> instead of 2.8.
>
> Whilst the lack of backward compatibility sucks, that wasn't the point being
> made. The point being made was that if we're going to (repeatedly) break
> backward compatibility, we should do so by incrementing the major version
> each time.
>
> Alex
>

On 20 Oct 2009, at 09:39, Ricky Clarkson wrote:

> I think calling it 3.0, if 3.0 means "stable, well-tested, and better
> in those respects than 2.7",

It's pretty rare for a x.0 release to be more stable and well-tested
to the prior version. In most cases, the incompatibility is introduced
with many new features which themselves are generally less well tested
than existing code.

This question can be phrased another way; if 3.0 is being eschewed for
irrational reasons associated with a .0 release, then at exactly what
point or criteria do you use to go from 2.x to 3.0? Isn't this exactly
the same mistake that Java made with 1.x? Or does the first number
mean 'the number of times Scala was rewritten from scratch'?

Either way, these are all pretty useless metrics for measuring version
numbers. What will make Scala succeed (or not) is whether developers
can write code, have it based on a version (or version range) and be
able to tell the difference between something that can be upgraded in
place versus something that can't. Otherwise, as was noted elsewhere
in this thread, you have to assume that the Scala convention is
2.major.minor.micro, and that every 2.x release is incompatible with
every other one.

> I suggest you stick around and watch 2.8 - I expect there will be new
> incompatible changes in successive 2.8 revisions, despite conscious
> efforts to avoid that.

The point was never about there never being binary incompatibilities
in the future. The point was that the breakage should be appropriately
reflected in the version numbering system. If we end up breaking each
time, then a transition from 3.0 to 4.0 to 5.0 would record that
effect perfectly. If the holy grail of backward compatibility is ever
kept, then 5.0 to 5.1 to 5.2 is still possible.

> Anyway, skipping from 2.7 to 3.0 would lose Scala the chance to make
> its version numbers tend to e.

At least that's a well-defined versioning system, even if arguably
we've already gone past that with 2.7.4. Metafont used that versioning
system, whilst TeX used the digits of Pi. On the other hand, they
never had backward compatibility issues to work with.

Alex

I couldn't resist a remark on Ricky's witty observation:  

Anyway, skipping from 2.7 to 3.0 would lose Scala the chance to make
its version numbers tend to e.

This privilege is of METAFONT. Sorry, Knuth got it first :)   http://www-cs-faculty.stanford.edu/~knuth/abcde.html   BR Christos

2009/10/20 Ricky Clarkson <ricky.clarkson@gmail.com>

I think calling it 3.0, if 3.0 means "stable, well-tested, and better
in those respects than 2.7",

That's wrong! A major increase means breaking changes and hence a lot of new stuff. Therefore it is obvious that in most cases stability cannot be better than before, at least regarding the new stuff.
Call it 3.0 and everybody will know that there are lots of new features. Call it 2.8 and everybody will expect NON-breaking changes and enhanced stability. As far as I can judge, 3.0 would be the better fit.
--
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

On 20/10/2009 10:39, Ricky Clarkson wrote:
> I think calling it 3.0, if 3.0 means "stable, well-tested, and better
> in those respects than 2.7"

I wanted to stay out of this thread, but well... Just look at some
(perhaps most) of the biggest opensource projects : OpenOffice 3.0 was
broken in loads of way, KDE 4.0 was at most a sketch, firefow 3.0 was
buggy even after months of beta/rc cycles, and I don't speak about MySQL
5.0, and so on.

So, really, people don't expect to have a .0 release really stable. They
expect to have new major, disruptive features, and not just
enhancements. They may hear "full rewrite" with .0. And they may hear,
and be happy to hear, things like "we did so many good work and brought
so many new, super features to our next version that we choose to make
it x+1.0 to reflect this state"

(all that is totally independent from scala next version number)

--
Francois 'fanf' Armand

Given Scala's inherent problems with binary compatibility, you can't
even hope to dream of expecting that going from what's in trunk now or
soon to a Scala 3.0 will yield something that can iteratively be
improved such that 3.0.1 or 3.1 is binary compatible with 3.0. The
situation's better with source compatibility, but even breakages there
wouldn't surprise me.

2009/10/20 Francois :
>
> On 20/10/2009 10:39, Ricky Clarkson wrote:
>>
>> I think calling it 3.0, if 3.0 means "stable, well-tested, and better
>> in those respects than 2.7"
>
> I wanted to stay out of this thread, but well... Just look at some (perhaps
> most) of the biggest opensource projects : OpenOffice 3.0 was broken in
> loads of way, KDE 4.0 was at most a sketch, firefow 3.0 was buggy even after
> months of beta/rc cycles, and I don't speak about MySQL 5.0, and so on.
>
> So, really, people don't expect to have a .0 release really stable. They
> expect to have new major, disruptive features, and not just enhancements.
> They may hear "full rewrite" with .0. And they may hear, and be happy to
> hear, things like "we did so many good work and brought so many new, super
> features to our next version that we choose to make it x+1.0 to reflect this
> state"
>
> (all that is totally independent from scala next version number)
>
> --
> Francois 'fanf' Armand
>

On 20/10/2009 12:03, Ricky Clarkson wrote:
> Given Scala's inherent problems with binary compatibility, you can't
> even hope to dream of expecting that going from what's in trunk now or
> soon to a Scala 3.0 will yield something that can iteratively be
> improved such that 3.0.1 or 3.1 is binary compatible with 3.0. The
> situation's better with source compatibility, but even breakages there
> wouldn't surprise me.

I thought I didn't talked at all about source nor binary compatibility.
And I'm pretty sure that I stated that I reported facts about what
happened for other major open source project regarding their ".0" release.

What should have been spotted is that a big difference with my examples
and Scala is that Scala is a base to build other software, not a final
product in itself. So it should be compared to other languages and/or
frameworks.

I can find framework with .0 bringing major evolution and some
instability easily : QT 4, despite the great quality of the lib was not
bug free at all, Axis 2.0 was (is) a real mess, GCC 3.0 and 4.0 (is
this a software or a framework ?) was, well, really ".0",

But I don't know for other languages (what about .0 in C# ? in Haskell ?
in Python ? etc). I know that C# increase major version number in a
rather consistent fashion. I know that OCaml and Ruby use minor
numbering even with disruptive change, and I know that I dislike it.

All in all, I think that numbering in itself is not so much important,
as long as there is a clear, consistent way of doing it. And perhaps
it's what is missing with Scala. Linux, or Ubuntu have their numbering
scheme, part of there identity and release process, and it seems to work
rather well for them.

--
Francois

martin odersky wrote:
> Everybody, these are hard engineering problems. Contributions are
> welcome. Throwing your hands up and putting the blame on others is not

> helpful.

Given that JavaFX has mixins, I assume it has the same problem. If that
is so, perhaps there is some Sun-driven motivation for a "native"
trait-like object in the JVM in future...

Not that it helps much now of course.

Kieron

This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain disclosures.

Well, compatibility was certainly mentioned prior to the email you
replied to. So forgive me for mentioning it again! :)

2009/10/20 Francois :
> On 20/10/2009 12:03, Ricky Clarkson wrote:
>>
>> Given Scala's inherent problems with binary compatibility, you can't
>> even hope to dream of expecting that going from what's in trunk now or
>> soon to a Scala 3.0 will yield something that can iteratively be
>> improved such that 3.0.1 or 3.1 is binary compatible with 3.0.  The
>> situation's better with source compatibility, but even breakages there
>> wouldn't surprise me.
>
> I thought I didn't talked at all about source nor binary compatibility. And
> I'm pretty sure that I stated that I reported facts about what happened for
> other major open source project regarding their ".0" release.
>
> What should have been spotted is that a big difference with my examples and
> Scala is that Scala is a base to build other software, not a final product
> in itself. So it should be compared to other languages and/or frameworks.
>
> I can find framework with .0 bringing major evolution and some instability
> easily : QT 4, despite the great quality of the lib was not bug free at all,
>  Axis 2.0 was (is) a real mess, GCC 3.0 and 4.0 (is this a software or a
> framework ?) was, well, really ".0",
>
> But I don't know for other languages (what about .0 in C# ? in Haskell ? in
> Python ? etc). I know that C# increase major version number in a rather
> consistent fashion.  I know that OCaml and Ruby use minor numbering even
> with disruptive change, and I know that I dislike it.
>
> All in all, I think that numbering in itself is not so much important, as
> long as there is a clear, consistent way of doing it. And perhaps it's what
> is missing with Scala. Linux, or Ubuntu have their numbering scheme, part of
> there identity and release process, and it seems to work rather well for
> them.
>
> --
> Francois
>
>
>
>
>
>

On Tue, Oct 20, 2009 at 3:29 AM, Neil Bartlett wrote:
> upgraded, and it's a shame if that is not possible yet, but we can
> still put the framework in place for it to be possible in the future.
>

+1

It would still be usable now, using exact versions in OSGi scala apps
for example. Its not as pleasant to work with, especially if you're
tracking nightlies :-), but it still adds value.

I'd rather start adding modular scala dependencies sooner rather than later.