Functional or Not?

[martin odersky-2]

I have found some friction on this list recently between ``pure
functional programmers'' and people who see in Scala just a better
Java (or Python, or whatever). I think this is unproductive. Everybody
has his or her favorite style of programming. Rather than putting the
other style down, it is *much better* to write great
examples/turorials/libraries which show how one's favorite style can
be used beautifully in Scala. If you do that, my bet is that you will
convince many others to follow you.

Another think I've noticed is that people on this list have very
different backgrounds. There are highly experienced industry veterans
as well as people with a strong academic background (of course, some
people belong in both sets). But this means we have to take more pains
than usual to explain things well to the other category of
programmers.

Cheers

 -- Martin

[Randall Schulz]

On Monday 24 September 2007 03:18, martin odersky wrote:
> ...
>
> Another think I've noticed is that people on this list have very
> different backgrounds. There are highly experienced industry veterans
> as well as people with a strong academic background (of course, some
> people belong in both sets). But this means we have to take more
> pains than usual to explain things well to the other category of
> programmers.

I'm one of those industry veteran guys, but it's the academic background
of Scala and its creators that gives it appeal for me and gives me
confidence that its principles are sound.

(I was just telling someone the other day that if I were starting out to
write my theorem prover right now, I'd surely use Scala for the whole
thing.)

But I have always rejected arguments from "purity" when it comes to
programming language (and pretty much everything except chemistry.)


> Cheers
>
>  -- Martin


Randall Schulz

[Erik Engbrecht]

I'm one of those industry veteran guys, but it's the academic background
of Scala and its creators that gives it appeal for me and gives me
confidence that its principles are sound.

 

A very big +1 on that.

 

On 9/24/07, Randall R Schulz <rschulz@...> wrote:

On Monday 24 September 2007 03:18, martin odersky wrote:
> ...
>
> Another think I've noticed is that people on this list have very
> different backgrounds. There are highly experienced industry veterans
> as well as people with a strong academic background (of course, some
> people belong in both sets). But this means we have to take more
> pains than usual to explain things well to the other category of
> programmers.

I'm one of those industry veteran guys, but it's the academic background
of Scala and its creators that gives it appeal for me and gives me
confidence that its principles are sound.

(I was just telling someone the other day that if I were starting out to
write my theorem prover right now, I'd surely use Scala for the whole
thing.)

But I have always rejected arguments from "purity" when it comes to
programming language (and pretty much everything except chemistry.)


> Cheers
>
>  -- Martin


Randall Schulz

--
http://erikengbrecht.blogspot.com/

[Lee MIghdoll-2]

On Mon, 2007-09-24 at 12:18 +0200, martin odersky wrote:
> I have found some friction on this list recently between ``pure
> functional programmers'' and people who see in Scala just a better
> Java (or Python, or whatever).

I agree -- relax a bit folks!  Remember that just about everyone on the
list is committing their time toward a common goal:  trying to make
Scala successful.    

I also encourage Amir and others to stay engaged and keep asking tough
or potentially naive questions.  Although there's been some friction,
there have also been many constructive conversations.  Keep it
constructive, and we can all learn things.

Lee

[John Nilsson]

On Mon, 2007-09-24 at 12:18 +0200, martin odersky wrote:
> Rather than putting the
> other style down, it is *much better* to write great
> examples/turorials/libraries which show how one's favorite style can
> be used beautifully in Scala.

Why not have community library? A code repository where almost anyone
will get commit-access. This would be used as a dumping ground for code
used more or less as a wiki.

This could then be used to generate some webpages where "beautiful"
examples and libraries could be showcased and discussed.

This could be an area where possible candidates for Scalas standard
library could be evaluated.

This could be used as community maintained utility library where such
things as the nonNull thing Jon posted could used in peoples projects.

(Wouldn't this be a security risk? As long as people take responsibility
for validating the code they use and the community keeps an eye on the
commit list I don't think it would be to hard to keep going)

Regards,
John Nilsson

[Lex Spoon-3]

John Nilsson <john@...> writes:
> On Mon, 2007-09-24 at 12:18 +0200, martin odersky wrote:
> > Rather than putting the
> > other style down, it is *much better* to write great
> > examples/turorials/libraries which show how one's favorite style can
> > be used beautifully in Scala.
>
> Why not have community library? A code repository where almost anyone
> will get commit-access. This would be used as a dumping ground for code
> used more or less as a wiki.

I like your ideas about the community contributing code.  Certainly
patches are welcome via the issue tracker, and they do go in if they
seem right.

For most community-contributed code, however, I believe that packages
are a betert arrangements.  Packages leave the code's author in direct
control o that code's future.  Further, they remove EPFL from the loop
for most decisions about propagating the package.  The authors can
instead directly post their stuff and try to get people to use them.

For package-based contributions, my best ideas are (1) posting your
project on a site like Google Code or SourceForge, and (2) sharing it
via sbaz.  More info is here:

  http://scala.sygneca.com/projects/start


That's just my current thinking of course, and I expect the best
mechanisms and culture will need to be felt out over time.


What do you and others think?  What can be done to support
non-EPFL folks in sharing Scala code with each other?


-Lex

[Jamie Webb-2]

On 2007-10-24 14:20:40 Lex Spoon wrote:

> John Nilsson <john@...> writes:
> > On Mon, 2007-09-24 at 12:18 +0200, martin odersky wrote:
> > > Rather than putting the
> > > other style down, it is *much better* to write great
> > > examples/turorials/libraries which show how one's favorite style
> > > can be used beautifully in Scala.
> >
> > Why not have community library? A code repository where almost
> > anyone will get commit-access. This would be used as a dumping
> > ground for code used more or less as a wiki.
>
> I like your ideas about the community contributing code.  Certainly
> patches are welcome via the issue tracker, and they do go in if they
> seem right.
>
> For most community-contributed code, however, I believe that packages
> are a betert arrangements.  Packages leave the code's author in direct
> control o that code's future.  Further, they remove EPFL from the loop
> for most decisions about propagating the package.  The authors can
> instead directly post their stuff and try to get people to use them.
>
> For package-based contributions, my best ideas are (1) posting your
> project on a site like Google Code or SourceForge, and (2) sharing it
> via sbaz.  More info is here:
>
>   http://scala.sygneca.com/projects/start
>
>
> That's just my current thinking of course, and I expect the best
> mechanisms and culture will need to be felt out over time.
>
>
> What do you and others think?  What can be done to support
> non-EPFL folks in sharing Scala code with each other?

I've been wondering about this. So here's a proposal:

There's a lot of stuff I think that various people have produced or
are considering producing at this point that ought to be 'on track' to
go into the standard library. Much of it does not warrant a project
to itself (or may be a small part of an existing project), but is
nevertheless useful. At present there is no formal mechanism for
publishing this work, beyond this mailing list and the bug tracker,
neither of which are really geared for community code review.

I propose that we will host a Git[1] repository, to which we will grant
write access to anyone (that we recognise) who asks for it. This
repository will contain a scalax._ package tree containing the
community-contributed code. We will set up a separate mailing list to
discuss this code. A second repository will be writable only by a
selection of 'influential' Scala users (list subject to nominations)
and will contain the code that passes peer review. That repository will
be published periodically via sbaz.

The purpose of this repository will be to contain the same sort of code
that is present in J2SE, the Haskell standard library, etc. and not
anything too domain-specific (for which sbaz, Sourceforge, etc. would
be a more appropriate channel). All code will be released under the
same license as Scala, and code may be moved from the community
repository into the main distribution as the Scala developers see fit.

Would this be useful? Practical? ...?

/J

[1] For our own work, we use Darcs and are very happy with it. However
Darcs has some problems that make it unsuitable for use with a publicly
writable repository. Git seems a reasonable alternative. In any case, a
distributed SCM (Darcs, Git, Mercurial, bzr, etc.) seems ideal for this
purpose.

[David Pollak-4]

On 10/24/07, Jamie Webb <j@...> wrote:

On 2007-10-24 14:20:40 Lex Spoon wrote:

> John Nilsson <john@...> writes:
> > On Mon, 2007-09-24 at 12:18 +0200, martin odersky wrote:
> > > Rather than putting the
> > > other style down, it is *much better* to write great
> > > examples/turorials/libraries which show how one's favorite style
> > > can be used beautifully in Scala.
> >
> > Why not have community library? A code repository where almost
> > anyone will get commit-access. This would be used as a dumping
> > ground for code used more or less as a wiki.
>

> I like your ideas about the community contributing code.  Certainly

> patches are welcome via the issue tracker, and they do go in if they
> seem right.
>
> For most community-contributed code, however, I believe that packages
> are a betert arrangements.  Packages leave the code's author in direct
> control o that code's future.  Further, they remove EPFL from the loop
> for most decisions about propagating the package.  The authors can
> instead directly post their stuff and try to get people to use them.
>
> For package-based contributions, my best ideas are (1) posting your
> project on a site like Google Code or SourceForge, and (2) sharing it
> via sbaz.  More info is here:
>
>   http://scala.sygneca.com/projects/start
>
>
> That's just my current thinking of course, and I expect the best
> mechanisms and culture will need to be felt out over time.
>
>
> What do you and others think?  What can be done to support
> non-EPFL folks in sharing Scala code with each other?

I've been wondering about this. So here's a proposal:

There's a lot of stuff I think that various people have produced or
are considering producing at this point that ought to be 'on track' to
go into the standard library. Much of it does not warrant a project
to itself (or may be a small part of an existing project), but is
nevertheless useful. At present there is no formal mechanism for
publishing this work, beyond this mailing list and the bug tracker,
neither of which are really geared for community code review.

I propose that we will host a Git[1] repository, to which we will grant
write access to anyone (that we recognise) who asks for it. This
repository will contain a scalax._ package tree containing the
community-contributed code. We will set up a separate mailing list to
discuss this code. A second repository will be writable only by a
selection of 'influential' Scala users (list subject to nominations)
and will contain the code that passes peer review. That repository will
be published periodically via sbaz.

The purpose of this repository will be to contain the same sort of code
that is present in J2SE, the Haskell standard library, etc. and not
anything too domain-specific (for which sbaz, Sourceforge, etc. would
be a more appropriate channel). All code will be released under the
same license as Scala, and code may be moved from the community
repository into the main distribution as the Scala developers see fit.

 

Would this be useful? Practical? ...?

Jamie,

This sounds like an excellent idea.  If you need hosting/bandwidth or any other contributions, please let me know.

Thanks,

David
 

/J

[1] For our own work, we use Darcs and are very happy with it. However
Darcs has some problems that make it unsuitable for use with a publicly
writable repository. Git seems a reasonable alternative. In any case, a
distributed SCM (Darcs, Git, Mercurial, bzr, etc.) seems ideal for this
purpose.

--
lift, the secure, simple, powerful web framework
http://liftweb.net

[Eric Willigers]

Jamie Webb wrote:

> I've been wondering about this. So here's a proposal:
>
> There's a lot of stuff I think that various people have produced or
> are considering producing at this point that ought to be 'on track' to
> go into the standard library. Much of it does not warrant a project
> to itself (or may be a small part of an existing project), but is
> nevertheless useful. At present there is no formal mechanism for
> publishing this work, beyond this mailing list and the bug tracker,
> neither of which are really geared for community code review.
>
> I propose that we will host a Git[1] repository, to which we will grant
> write access to anyone (that we recognise) who asks for it. This
> repository will contain a scalax._ package tree containing the
> community-contributed code. We will set up a separate mailing list to
> discuss this code. A second repository will be writable only by a
> selection of 'influential' Scala users (list subject to nominations)
> and will contain the code that passes peer review. That repository will
> be published periodically via sbaz.
>
> The purpose of this repository will be to contain the same sort of code
> that is present in J2SE, the Haskell standard library, etc. and not
> anything too domain-specific (for which sbaz, Sourceforge, etc. would
> be a more appropriate channel). All code will be released under the
> same license as Scala, and code may be moved from the community
> repository into the main distribution as the Scala developers see fit.
>
> Would this be useful? Practical? ...?
>
> /J
>
> [1] For our own work, we use Darcs and are very happy with it. However
> Darcs has some problems that make it unsuitable for use with a publicly
> writable repository. Git seems a reasonable alternative. In any case, a
> distributed SCM (Darcs, Git, Mercurial, bzr, etc.) seems ideal for this
> purpose.
>

Hi Jamie,

Excellent idea.


In particular, it would be good to put a Test or Behavior Driven
Development library through this process and have it promoted into the
standard library.

Another nomination would be a comprehensively lazy sequence, where no
elements are evaluated until needed, and methods like map, filter and
flatMap perform no work up-front
e.g. some of Tony's code, or port
   http://article.gmane.org/gmane.comp.lang.scala.user/1129
to use generics.


BTW, a quick web search and source browse a while ago led me to prefer
Mercurial over Git, and I understand OpenJDK will be available through
Mercurial. For continuous integration testing I came across
http://hudson.gotdns.com/wiki/display/HUDSON/Mercurial+Plugin
but have yet to try it.

Whatever system is used, it would be good to have the test suite output
online.


Also, lots of thanks for the work you and Jon are already doing hosting
the wiki.

Regards,
Eric.

[Alex Boisvert-3]

Great idea!   I also propose a regex package (from lift?) and a standardized {Result, Success, Failure} trifecta.

alex

On 10/24/07, Eric Willigers <ewilligers@...> wrote:

> I propose that we will host a Git[1] repository, to which we will grant
> write access to anyone (that we recognise) who asks for it. This
> repository will contain a scalax._ package tree containing the
> community-contributed code. We will set up a separate mailing list to
> discuss this code. A second repository will be writable only by a
> selection of 'influential' Scala users (list subject to nominations)
> and will contain the code that passes peer review. That repository will
> be published periodically via sbaz.

[David Pollak]

On Oct 24, 2007, at 8:37 PM, Alex Boisvert wrote:

Great idea!   I also propose a regex package (from lift?) and a standardized {Result, Success, Failure} trifecta.

I'm happy to share the pieces of lift that make sense to go into a larger repository.  I have to review the IP assignment documents to make sure that changing the code from an Apache 2.0 license to a BSD-style license is permissible, but I don't expect that that's a huge hurdle.

Things in lift that might be better in the world at large:

- The Can[T] class (like Option with with Failure in addition to Empty)

- The Textile parser

- The RegEx stuff (a thin layer on top of Java's RegEx package)

- The Logging stuff (a thin layer on Log4J)

- The Helpers object (all sorts of conversion, date related stuff, etc.)

Thanks,

David

alex

On 10/24/07, Eric Willigers <ewilligers@...> wrote:

> I propose that we will host a Git[1] repository, to which we will grant
> write access to anyone (that we recognise) who asks for it. This
> repository will contain a scalax._ package tree containing the
> community-contributed code. We will set up a separate mailing list to
> discuss this code. A second repository will be writable only by a
> selection of 'influential' Scala users (list subject to nominations)
> and will contain the code that passes peer review. That repository will
> be published periodically via sbaz.

--

David Pollak

http://blog.lostlake.org

[Eric Torreborre]

> In particular, it would be good to put a Test or Behavior Driven
> Development library through this process and have it promoted into the
> standard library

I couldn't be more happy to see people building on my own: http://code.google.com/p/specs and delivering it in the standard lib!

For the record, I have started working for the next version of specs on some new features:

- Table examples:

"A calculator" can {
   "do additions" in {
      ("a", "b", "c") |
      (1, 2, 3) |
      (3, 2, 3) |
      (2, 2, 4) |> {
      (a: Int, b: Int, result: Int) => calc.add(a, b) must_== result
      }
   }
}

This prints:

A calculator can
  x do additions
     |a|b|c|
   x|3|2|3| '3' is not equal to '5'
...


- Literal specifications (very experimental!):

"The timer spec" is <p>

A simple timer is an object which can measure time.

Let's create a timer{timer = new SimpleTimer}.
When a timer is stopped{timer.stop.shh}, the timer should {"return an elapsed time matching" + "\\d second".as(pattern) in {timer.hms must beMatching(pattern.toString)}}

</p>

I don't know if it's more readable/manageable than classical specs/junit specifications but it's fun trying
anyway!

E.

[Lex Spoon-3]

Jamie Webb <j@...> writes:

> I propose that we will host a Git[1] repository, to which we will grant
> write access to anyone (that we recognise) who asks for it. This
> repository will contain a scalax._ package tree containing the
> community-contributed code. We will set up a separate mailing list to
> discuss this code. A second repository will be writable only by a
> selection of 'influential' Scala users (list subject to nominations)
> and will contain the code that passes peer review. That repository will
> be published periodically via sbaz.
>
> The purpose of this repository will be to contain the same sort of code
> that is present in J2SE, the Haskell standard library, etc. and not
> anything too domain-specific (for which sbaz, Sourceforge, etc. would
> be a more appropriate channel). All code will be released under the
> same license as Scala, and code may be moved from the community
> repository into the main distribution as the Scala developers see fit.

It's an interesting idea for sure, and I would like to try and picture
it better. So I have two questions, if you would like to talk about it
further.  The first one is, do you have any more specific examples of
the kinds of thing that might be treated this way?  I'm not sure what
J2SE would include exactly.


I submit that even the "standard library" can be a pile of small
packages during development.  So javax.swing could be in a separate
package from java.util.regex.  Then, sbaz users would see the
individual jar's.  The javax organizers you hint at would still exist,
but their decision would be subtly different.  Instead of heading the
repository, they would periodically conglomerate some existing
packages into a larger javax jar.


The reason I keep bringing up this arrangement is that it seems really
nice for delegating responsibility and control.  One group can work on
regexes, and another group on the swing wrapper.  Then, there is a
separate group in about which version of which of these libraries get
integrated into the "standard" library.  From experience with Squeak,
I can tell you it is sometimes annoying to have your code go into the
standard library and from then on not be under your control any
longer.  It seems elegant if the division into packages or
repositories aligns with the division into responsibility and
authority.

Anyway, there is also the issue of the core of the standard library,
things that definitely should not be in separate packages, regular
patches to the bug tracker seem pretty good to me.  You mentioned
being unsure the bug tracker is enough, though, so that is my second
question.  Would you say the bug-tracker approach feels limiting even
for such core code, or is it more for the less central parts of the
standard library?


By the way, note that I am not at EPFL any more.  I am just a Scala
enthusiast who is interested in how open-source communities organize.


-Lex

[David Pollak]

Lex Spoon wrote:
>
>
> By the way, note that I am not at EPFL any more.  I am just a Scala
> enthusiast who is interested in how open-source communities organize.

Lex,

Can you tell us where you are now?  Can you tell us if this place is
putting any muscle behind Scala?

Thanks,

David

>
>
> -Lex
>
>
>

[Bill Venners]

Hi Jamie,

I'd like to respond to your entire proposal, so I'll do so up on top  
here. I think it is good to start figuring out a process for how  
things go into the standard library. I've been wanting to research  
how this is done in the Python community. When I get that done I'll  
post here for comparison.

I would like to see Scala achieve widespread adoption, and for that  
to happen, people need to have confidence their code won't break from  
release to release. That means language changes need to be backwards  
compatible, as do standard library APIs and functionality. Thus  
putting something into the standard library adds a burden for future  
releases in that someone will need to make sure client code doesn't  
break. Also, once you add something, you can't take it out, because  
that is of course a breaking change. (I think there may be a need to  
do some pruning in the standard library, and if so, it should be done  
very soon. Hopefully it isn't already impossible to achieve.) So in  
my mind it is important that before something is added to the  
standard library, it should in most cases have been proven to be a  
good and useful solution by real use. The standard library is not a  
place for experiments.

As a community, though, we should try and foster and encourage  
experimentation and innovation. The place for that is somewhere else  
besides the standard library. You suggest scalax.* I would advise  
against using scalax as the innovation/experimentation namespace,  
because in the Java community javax holds as much weight as java.  
javax.swing is a standard, not an experiment. So I'd suggest either  
having another name, or just not having a common name. People could  
be expected to register a domain name then use the reverse domain  
name convention for their API. People can easily use it via sbaz, and  
it can get a track record. For a while the provider of the API can  
warn users they reserve the right to make incompatible changes (I'd  
suggest as a convention we say we'll do so until release "1.0", but  
really this should be between a provider and his or her users).

Two design goals that are in tension for the standard library are  
maximizing "batteries included" and minimizing "surface area".  
"Batteries included" is the catchy way the Python community says that  
they have a lot of useful libraries. If you want to do something in  
Python, the lore goes, there's most often a Python library available  
that makes it easy and quick to do. So that's a good thing. "Surface  
area" is how Ken Arnold[1] has described the volume of functionality  
in an API design. He gives the example of Swing, which has tons of  
functionality, so much so that it is often hard to figure out what  
you have to ignore to just get something that should be simple done.  
It is easier to find your stapler in a drawer if there are only a few  
other essential items in there compared to it being stuffed full of  
objects, most of which you probably won't have a use for ever again.

Because Scala sits on top of the Java Platform, which has a vast  
ocean of useful libraries, Scala in a sense already comes with a geo-
thermal electric generator station included. I want to use Scala with  
these Java libraries at Artima. I want to "scalify" them in many  
places. For example, I want to use Scalified Hibernate entities that  
instead of get and set methods have Scala's more natural accessor  
syntax: 'user.name' instead of 'user.getName(),' and 'user.name =  
"Bob",' instead of 'user.setName("Bob").' But that's easy for me to  
do in my own project. I don't need a Scalified wrapper for Hibernate  
in the standard library.

I value simplicity in Scala's standard library, especially in the  
near future, because it makes Scala easier to learn if the library  
isn't so massive and scary looking. So I hope the community would be  
conservative about what goes in there, and really really picky. But  
on the other hand, I think we should encourage innovation and  
experimentation somewhere else. As things prove themselves, they can  
be brought into the standard library through some process. (One  
difficulty faced by all the Java communities I know of, is how do you  
change the package name of something to the standard namespace, in  
our case scala.*, if the thing is already being used in lots of code.  
An API can't be "proven" unless a lot of people use it, which means  
that by moving it into scala.* you'd break all that client code. I  
know of no good solution for this problem, but I was involved in  
trying to figure out how to deal with this problem in the Jini space,  
so I can also describe what we decided there if anyone is interested.)

Lastly, I think that not every domain needs to be covered in the  
standard library. I've been working on a test framework for us to use  
at Artima, and I'm planning to release it open source. But I never  
imagined it would be a candidate for the standard library. In the  
Java community they never put any kind of test framework in the  
standard library, and there has been some innovation (JUnit and  
TestNG, for example) that happened to fill that space. Adding some  
test framework to the Java API just doesn't seem necessary, and it  
might have a squelching effect on innovation thereafter in that  
space. I don't see why we'd need a testing framework in the Scala  
API. Some other examples of very useful APIs that aren't part of a  
standard Java library are Lucene, Hibernate, Spring, etc. My  
intuition is to keep the Scala standard library trim and fit and  
encourage innovation outside of it.

That said, there still should be a process to get things into the  
standard library. Two aspects I'd recommend are that Scaladoc  
documentation needs to be thorough, complete, and professional, and  
there needs to be a comprehensive regression test suite that will  
help ensure client code doesn't break from Scala release to release.

Sorry for the long post. I don't have time to compress it.

Thanks.

Bill

[1] Ken Arnold, the architect of JavaSpaces among many other things,  
who I once interviewed defines "surface area" at the...

...top of:
http://www.artima.com/intv/taste4.html

...and bottom of:
http://www.artima.com/intv/perfect2.html

On Oct 24, 2007, at 5:51 PM, Jamie Webb wrote:

> On 2007-10-24 14:20:40 Lex Spoon wrote:
>> John Nilsson <john@...> writes:
>>> On Mon, 2007-09-24 at 12:18 +0200, martin odersky wrote:
>>>> Rather than putting the
>>>> other style down, it is *much better* to write great
>>>> examples/turorials/libraries which show how one's favorite style
>>>> can be used beautifully in Scala.
>>>
>>> Why not have community library? A code repository where almost
>>> anyone will get commit-access. This would be used as a dumping
>>> ground for code used more or less as a wiki.
>>
>> I like your ideas about the community contributing code.  Certainly
>> patches are welcome via the issue tracker, and they do go in if they
>> seem right.
>>
>> For most community-contributed code, however, I believe that packages
>> are a betert arrangements.  Packages leave the code's author in  
>> direct
>> control o that code's future.  Further, they remove EPFL from the  
>> loop
>> for most decisions about propagating the package.  The authors can
>> instead directly post their stuff and try to get people to use them.
>>
>> For package-based contributions, my best ideas are (1) posting your
>> project on a site like Google Code or SourceForge, and (2) sharing it
>> via sbaz.  More info is here:
>>
>>   http://scala.sygneca.com/projects/start
>>
>>
>> That's just my current thinking of course, and I expect the best
>> mechanisms and culture will need to be felt out over time.
>>
>>
>> What do you and others think?  What can be done to support
>> non-EPFL folks in sharing Scala code with each other?
>
> I've been wondering about this. So here's a proposal:
>
> There's a lot of stuff I think that various people have produced or
> are considering producing at this point that ought to be 'on track' to
> go into the standard library. Much of it does not warrant a project
> to itself (or may be a small part of an existing project), but is
> nevertheless useful. At present there is no formal mechanism for
> publishing this work, beyond this mailing list and the bug tracker,
> neither of which are really geared for community code review.
>
> I propose that we will host a Git[1] repository, to which we will  
> grant
> write access to anyone (that we recognise) who asks for it. This
> repository will contain a scalax._ package tree containing the
> community-contributed code. We will set up a separate mailing list to
> discuss this code. A second repository will be writable only by a
> selection of 'influential' Scala users (list subject to nominations)
> and will contain the code that passes peer review. That repository  
> will
> be published periodically via sbaz.
>
> The purpose of this repository will be to contain the same sort of  
> code
> that is present in J2SE, the Haskell standard library, etc. and not
> anything too domain-specific (for which sbaz, Sourceforge, etc. would
> be a more appropriate channel). All code will be released under the
> same license as Scala, and code may be moved from the community
> repository into the main distribution as the Scala developers see fit.
>
> Would this be useful? Practical? ...?
>
> /J
>
> [1] For our own work, we use Darcs and are very happy with it. However
> Darcs has some problems that make it unsuitable for use with a  
> publicly
> writable repository. Git seems a reasonable alternative. In any  
> case, a
> distributed SCM (Darcs, Git, Mercurial, bzr, etc.) seems ideal for  
> this
> purpose.
>

Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com

[Alex Blewitt]

On 26/10/2007, Bill Venners <bv-jackrabbit@...> wrote:

> Because Scala sits on top of the Java Platform, which has a vast
> ocean of useful libraries, Scala in a sense already comes with a geo-
> thermal electric generator station included. I want to use Scala with
> these Java libraries at Artima. I want to "scalify" them in many
> places. For example, I want to use Scalified Hibernate entities that
> instead of get and set methods have Scala's more natural accessor
> syntax: 'user.name' instead of 'user.getName(),' and 'user.name =
> "Bob",' instead of 'user.setName("Bob").' But that's easy for me to
> do in my own project. I don't need a Scalified wrapper for Hibernate
> in the standard library.

The same argument is true of Groovy, but there's a few more libraries
in the vanilla 'groovy' space than just relying on Java:

http://groovy.codehaus.org/api/index.html

In any case, isn't the argument about scala (and 'the scala way') at
some kind of odds with the way that Java does things? Python is always
pretty elegant in this regard. I don't necessarily think it makes
sense to have a one-on-one mapping for each Java API or anything, but
having a set of libraries implemented in Scala (whether wrapper or
pure) would encourage the use of Scala.

Alex.

[Bill Venners]

Hi Alex,

On Oct 26, 2007, at 3:19 AM, Alex Blewitt wrote:

> On 26/10/2007, Bill Venners <bv-jackrabbit@...> wrote:
>> Because Scala sits on top of the Java Platform, which has a vast
>> ocean of useful libraries, Scala in a sense already comes with a geo-
>> thermal electric generator station included. I want to use Scala with
>> these Java libraries at Artima. I want to "scalify" them in many
>> places. For example, I want to use Scalified Hibernate entities that
>> instead of get and set methods have Scala's more natural accessor
>> syntax: 'user.name' instead of 'user.getName(),' and 'user.name =
>> "Bob",' instead of 'user.setName("Bob").' But that's easy for me to
>> do in my own project. I don't need a Scalified wrapper for Hibernate
>> in the standard library.
>
> The same argument is true of Groovy, but there's a few more libraries
> in the vanilla 'groovy' space than just relying on Java:
>
> http://groovy.codehaus.org/api/index.html
>
> In any case, isn't the argument about scala (and 'the scala way') at
> some kind of odds with the way that Java does things? Python is always
> pretty elegant in this regard. I don't necessarily think it makes
> sense to have a one-on-one mapping for each Java API or anything, but
> having a set of libraries implemented in Scala (whether wrapper or
> pure) would encourage the use of Scala.
>

I agree with your sentiment. I just want to be very conservative. The  
reason is that I'd hope we'd minimize the mistakes that go into the  
standard library. Once a mistake is in there, to the extent Scala is  
successful, it will be impossible to remove. The Java API is littered  
with bad design and regretful decisions. It adds a lot of noise to  
working in Java. Scala is such a nice language that it would be a  
pity if its standard library was full of noise.

The point I'm trying to make about batteries included is there is no  
real *pressure* to add a logging library, for example, because people  
have several great Java ones to chose from. When we're sure we're  
sure we're sure we have a good candidate for a standard logging  
library, or test framework, or what not, then we can put it into the  
standard library. In the meantime, we can do all kinds of innovation  
and trying things out outside the standard library. And anyone can  
use those libraries. They just won't be "standard" yet.

Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com