This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Standard library or example implementations

9 replies
John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.

I just watched Martins keynote from Scala Exchange 2011 and it got me thinking.

There seems to be lots of plans to add various things to the standard
library. For example there was talk about adding a databse DSL. Is
this really a good idea?

I'm thinking that adding all this stuff to the standard library is risky.

* You risk promoting an implementation that is "premature" in that
later experiments by third parties proves to be better in some
respects. Which leads to all sorts of issues regarding support and
deprecations.
* By doing it in the standard library you spend resources on specific
sub-domains that could potentially be better spent on more generic
infrastructure.
* The life cycle of the library is tied to the language. So new
releases of either has to be synced with the other.
* By having a standard implementation there might be less of an
incentive by third parties to explore the area.
* The standard library gets bigger. I don't know how much of a problem
this is but the very existence of project jigsaw suggests that it
could be.

So instead of expanding the standard library, how about doing these
kinds of things as prototypes, distributed separately as subprojects.
Example implementations that can be used before there are good third
party solutions. This implementation will also serve as the test for
more generic features that can be adopted by said third parties.

BR,
John

sergei
Joined: 2011-03-29,
User offline. Last seen 1 year 20 weeks ago.
Re: Standard library or example implementations

Yes I think that adding standard DB library would be a good idea. There are several Scala DB libraries already, some pretty cute and useful, yet none comprehensive and well-supported, as enterprise customers would require.

So, I think such library would be a step forward, as long as its complexity stays manageable of course. Scala couterpart of JDBC would be nice. Analog of EJB would not be much appreciated.

On Jun 17, 2011, at 5:55 PM, John Nilsson wrote:

> I just watched Martins keynote from Scala Exchange 2011 and it got me thinking.
>
> There seems to be lots of plans to add various things to the standard
> library. For example there was talk about adding a databse DSL. Is
> this really a good idea?
>
> I'm thinking that adding all this stuff to the standard library is risky.
>
> * You risk promoting an implementation that is "premature" in that
> later experiments by third parties proves to be better in some
> respects. Which leads to all sorts of issues regarding support and
> deprecations.
> * By doing it in the standard library you spend resources on specific
> sub-domains that could potentially be better spent on more generic
> infrastructure.
> * The life cycle of the library is tied to the language. So new
> releases of either has to be synced with the other.
> * By having a standard implementation there might be less of an
> incentive by third parties to explore the area.
> * The standard library gets bigger. I don't know how much of a problem
> this is but the very existence of project jigsaw suggests that it
> could be.
>
> So instead of expanding the standard library, how about doing these
> kinds of things as prototypes, distributed separately as subprojects.
> Example implementations that can be used before there are good third
> party solutions. This implementation will also serve as the test for
> more generic features that can be adopted by said third parties.
>
> BR,
> John

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Standard library or example implementations

On 18/06/11 11:51, Sergei wrote:
> There are several Scala DB libraries already, some pretty cute and useful, yet none comprehensive and well-supported, as enterprise customers would require.
...in the public domain.

We have been using iteratee-based JDBC, monad (transformer) based
resource-handling and an algebraic representation of the usual SQL
constructs for quite a few months in production code. I know of one
other company that has been doing so too.

I hope to include a robust implementation of this in scalaz 7
(scalaz.sql._).

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Standard library or example implementations

I agree that something like JDBC should probably be there. But that is more infrastructure than a particular abstraction. My point was more that the breadth of options for database abstractions/ORMs in Scala indicates that there is no "correct" one to choose.

BR,
John

Sent from my phone

Den 18 jun 2011 03:52 skrev "Sergei" <hello [dot] sergei [at] gmail [dot] com>:
> Yes I think that adding standard DB library would be a good idea. There are several Scala DB libraries already, some pretty cute and useful, yet none comprehensive and well-supported, as enterprise customers would require.
>
> So, I think such library would be a step forward, as long as its complexity stays manageable of course. Scala couterpart of JDBC would be nice. Analog of EJB would not be much appreciated.
>
> On Jun 17, 2011, at 5:55 PM, John Nilsson <john [at] milsson [dot] nu> wrote:
>
>> I just watched Martins keynote from Scala Exchange 2011 and it got me thinking.
>>
>> There seems to be lots of plans to add various things to the standard
>> library. For example there was talk about adding a databse DSL. Is
>> this really a good idea?
>>
>> I'm thinking that adding all this stuff to the standard library is risky.
>>
>> * You risk promoting an implementation that is "premature" in that
>> later experiments by third parties proves to be better in some
>> respects. Which leads to all sorts of issues regarding support and
>> deprecations.
>> * By doing it in the standard library you spend resources on specific
>> sub-domains that could potentially be better spent on more generic
>> infrastructure.
>> * The life cycle of the library is tied to the language. So new
>> releases of either has to be synced with the other.
>> * By having a standard implementation there might be less of an
>> incentive by third parties to explore the area.
>> * The standard library gets bigger. I don't know how much of a problem
>> this is but the very existence of project jigsaw suggests that it
>> could be.
>>
>> So instead of expanding the standard library, how about doing these
>> kinds of things as prototypes, distributed separately as subprojects.
>> Example implementations that can be used before there are good third
>> party solutions. This implementation will also serve as the test for
>> more generic features that can be adopted by said third parties.
>>
>> BR,
>> John
nivanov
Joined: 2009-09-15,
User offline. Last seen 37 weeks 5 days ago.
Re: Standard library or example implementations

I would welcome Typesafe attention on making JDBC and many other core
libs more FP friendly (a-la IO that the made). That would be really
helpful in removing dependency on JDK libs (that are in some cases
plain ugly in Scala).

--
Nikita Ivanov
GridGain Systems
www.gridgain.com

On Jun 17, 5:55 pm, John Nilsson wrote:
> I just watched Martins keynote from Scala Exchange 2011 and it got me thinking.
>
> There seems to be lots of plans to add various things to the standard
> library. For example there was talk about adding a databse DSL. Is
> this really a good idea?
>
> I'm thinking that adding all this stuff to the standard library is risky.
>
> * You risk promoting an implementation that is "premature" in that
> later experiments by third parties proves to be better in some
> respects. Which leads to all sorts of issues regarding support and
> deprecations.
> * By doing it in the standard library you spend resources on specific
> sub-domains that could potentially be better spent on more generic
> infrastructure.
> * The life cycle of the library is tied to the language. So new
> releases of either has to be synced with the other.
> * By having a standard implementation there might be less of an
> incentive by third parties to explore the area.
> * The standard library gets bigger. I don't know how much of a problem
> this is but the very existence of project jigsaw suggests that it
> could be.
>
> So instead of expanding the standard library, how about doing these
> kinds of things as prototypes, distributed separately as subprojects.
> Example implementations that can be used before there are good third
> party solutions. This implementation will also serve as the test for
> more generic features that can be adopted by said third parties.
>
> BR,
> John

Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: Standard library or example implementations

On Sat, Jun 18, 2011 at 5:26 PM, Nikita Ivanov wrote:
> I would welcome Typesafe attention on making JDBC and many other core
> libs more FP friendly (a-la IO that the made). That would be really
> helpful in removing dependency on JDK libs (that are in some cases
> plain ugly in Scala).

If anyone is after a Scala friendly alternative to Spring
JDBC-Template, take a look at Querulous [1], an open source library
released by Twitter.

-jason

[1] https://github.com/nkallen/querulous#readme

sergei
Joined: 2011-03-29,
User offline. Last seen 1 year 20 weeks ago.
Re: Re: Standard library or example implementations
+1
Use Querulous and like it.
@John Nilsson: I agree, there is no "correct" one to choose. Also agree that mandating a particular one could stifle the innovation. A perennial innovation-stability tension in action ...
There is another reason I think Typesafe could be a good entity to trust the development of the DB library and DSL - it may turn out that in order to reach (or go beyond) the seamlessness of Microsoft LINQ some changes in the Scala compiler would be required, or at the very least deep understanding of the compiler.

On Sat, Jun 18, 2011 at 8:33 AM, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:
On Sat, Jun 18, 2011 at 5:26 PM, Nikita Ivanov <nivanov [at] gridgain [dot] com> wrote:
> I would welcome Typesafe attention on making JDBC and many other core
> libs more FP friendly (a-la IO that the made). That would be really
> helpful in removing dependency on JDK libs (that are in some cases
> plain ugly in Scala).

If anyone is after a Scala friendly alternative to Spring
JDBC-Template, take a look at Querulous [1], an open source library
released by Twitter.

-jason

[1] https://github.com/nkallen/querulous#readme

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Standard library or example implementations

On Sat, Jun 18, 2011 at 8:54 PM, Sergei wrote:
> There is another reason I think Typesafe could be a good entity to trust the
> development of the DB library and DSL - it may turn out that in order to
> reach (or go beyond) the seamlessness of Microsoft LINQ some changes in the
> Scala compiler would be required, or at the very least deep understanding of
> the compiler.

I agree that this is a good argument for working on such stuff. But I
think one of the great design aspects of Scala is that stuff like this
is usually done generically rather than for special cases. So while it
would be good for Typesafe to experiment in the area to find the needs
it's enough to add the mechanism to the standard library and then
release the experiment as a canonical example use case. As an example
the App trait could easily been special cased, but instead the magic
was delegated to DelayedInit as a more general mechanism.

BR,
John

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Standard library or example implementations
Also, scala.reflect.Code could be supported. That would help writing concise ORMs (e.g., a field reference without an actual instance, in a query expression).


On Sat, Jun 18, 2011 at 4:48 PM, John Nilsson <john [at] milsson [dot] nu> wrote:
On Sat, Jun 18, 2011 at 8:54 PM, Sergei <hello [dot] sergei [at] gmail [dot] com> wrote:
> There is another reason I think Typesafe could be a good entity to trust the
> development of the DB library and DSL - it may turn out that in order to
> reach (or go beyond) the seamlessness of Microsoft LINQ some changes in the
> Scala compiler would be required, or at the very least deep understanding of
> the compiler.

I agree that this is a good argument for working on such stuff. But I
think one of the great design aspects of Scala is that stuff like this
is usually done generically rather than for special cases. So while it
would be good for Typesafe to experiment in the area to find the needs
it's enough to add the mechanism to the standard library and then
release the experiment as a canonical example use case. As an example
the App trait could easily been special cased, but instead the magic
was delegated to DelayedInit as a more general mechanism.

BR,
John

Chris Marshall
Joined: 2009-06-17,
User offline. Last seen 44 weeks 3 days ago.
RE: Standard library or example implementations
That would be awesome - I'm looking forward to taking a look

> Date: Sat, 18 Jun 2011 12:20:10 +1000
> From: tonymorris [at] gmail [dot] com
> To: scala-debate [at] googlegroups [dot] com
> Subject: Re: [scala-debate] Standard library or example implementations
>
> On 18/06/11 11:51, Sergei wrote:
> > There are several Scala DB libraries already, some pretty cute and useful, yet none comprehensive and well-supported, as enterprise customers would require.
> ...in the public domain.
>
> We have been using iteratee-based JDBC, monad (transformer) based
> resource-handling and an algebraic representation of the usual SQL
> constructs for quite a few months in production code. I know of one
> other company that has been doing so too.
>
> I hope to include a robust implementation of this in scalaz 7
> (scalaz.sql._).
>
> --
> Tony Morris
> http://tmorris.net/
>
>

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