Leaking abstractions declared harmless! (and Grails config)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Leaking abstractions declared harmless! (and Grails config)

hamishagain@dcs.shef.ac.uk

Hi,

There was a post a few weeks ago citing a criticism of Grails on the
basis that it might suffer from "leaking abstractions". I took this
to mean that the underlying systems that Grails is layered on
(Spring, Hibernate, etc.) could "poke through" and become visible.
For example, if you needed some kind of mapping that GORM didn't
support but Hibernate did then you'd need to write some config for
the latter instead of only using Grails' various domain relationship
mechanisms.

I've been mulling this over, and I started to wonder if this is
actually a strength rather than a weakness. I started using Grails
around a year ago, and although I'd played with various J2EE
technologies over the years I was pretty near to beginner level.  A
huge difference between my previous J2EE experience and what I found
in Grails was that I could get a running system very quickly that
did useful things without writing a spider's nest of XML spread
across a bunch of 10-deep directory trees. As time went on I met
problems that meant I needed to tinker with some of the innards, and
write a big of Spring config or web.xml, but it was quite different
to be doing that in the context of a running system. Scaffolding
generation is the same: a working example makes it easier to learn.

So: it seems to me that the fact that Grails allows users to drop
down into the "assembler" is a benefit, not a weakness.

Apologies for rambling on, but I think there is an implication for
how Grails develops, which is that it shouldn't try too hard to hide
everything in the J2EE stack that it depends on. For example, hiding
the Log4J config has some benefits, but if it was also possible to
fall back to the Log4J version then that would also be a good thing?

Best,
--
Hamish
http://www.dcs.shef.ac.uk/~hamish/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Leaking abstractions declared harmless! (and Grails config)

Graeme-Rocher
Hi Hamish

Rails people view Rails as a leaky abstraction and consider it a
strength, so you're not alone.

Cheers

On 10/11/07, Hamish Cunningham <[hidden email]> wrote:

>
> Hi,
>
> There was a post a few weeks ago citing a criticism of Grails on the
> basis that it might suffer from "leaking abstractions". I took this
> to mean that the underlying systems that Grails is layered on
> (Spring, Hibernate, etc.) could "poke through" and become visible.
> For example, if you needed some kind of mapping that GORM didn't
> support but Hibernate did then you'd need to write some config for
> the latter instead of only using Grails' various domain relationship
> mechanisms.
>
> I've been mulling this over, and I started to wonder if this is
> actually a strength rather than a weakness. I started using Grails
> around a year ago, and although I'd played with various J2EE
> technologies over the years I was pretty near to beginner level.  A
> huge difference between my previous J2EE experience and what I found
> in Grails was that I could get a running system very quickly that
> did useful things without writing a spider's nest of XML spread
> across a bunch of 10-deep directory trees. As time went on I met
> problems that meant I needed to tinker with some of the innards, and
> write a big of Spring config or web.xml, but it was quite different
> to be doing that in the context of a running system. Scaffolding
> generation is the same: a working example makes it easier to learn.
>
> So: it seems to me that the fact that Grails allows users to drop
> down into the "assembler" is a benefit, not a weakness.
>
> Apologies for rambling on, but I think there is an implication for
> how Grails develops, which is that it shouldn't try too hard to hide
> everything in the J2EE stack that it depends on. For example, hiding
> the Log4J config has some benefits, but if it was also possible to
> fall back to the Log4J version then that would also be a good thing?
>
> Best,
> --
> Hamish
> http://www.dcs.shef.ac.uk/~hamish/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Graeme Rocher
Grails Project Lead
http://grails.org

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Leaking abstractions declared harmless! (and Grails config)

Steven Devijver
Leaky abstraction is a rather abstract issue and it's not easy to
determine whether it's harmful or not (it's bound to be a rather
theoretic discussion).

A far more important indicator is excessive complexity due to layering
and abstraction gone wrong.

I think the reduction and near total elimination of excessive
complexity is one of Grails' major strengths.

Steven

On 10/11/07, Graeme Rocher <[hidden email]> wrote:

> Hi Hamish
>
> Rails people view Rails as a leaky abstraction and consider it a
> strength, so you're not alone.
>
> Cheers
>
> On 10/11/07, Hamish Cunningham <[hidden email]> wrote:
> >
> > Hi,
> >
> > There was a post a few weeks ago citing a criticism of Grails on the
> > basis that it might suffer from "leaking abstractions". I took this
> > to mean that the underlying systems that Grails is layered on
> > (Spring, Hibernate, etc.) could "poke through" and become visible.
> > For example, if you needed some kind of mapping that GORM didn't
> > support but Hibernate did then you'd need to write some config for
> > the latter instead of only using Grails' various domain relationship
> > mechanisms.
> >
> > I've been mulling this over, and I started to wonder if this is
> > actually a strength rather than a weakness. I started using Grails
> > around a year ago, and although I'd played with various J2EE
> > technologies over the years I was pretty near to beginner level.  A
> > huge difference between my previous J2EE experience and what I found
> > in Grails was that I could get a running system very quickly that
> > did useful things without writing a spider's nest of XML spread
> > across a bunch of 10-deep directory trees. As time went on I met
> > problems that meant I needed to tinker with some of the innards, and
> > write a big of Spring config or web.xml, but it was quite different
> > to be doing that in the context of a running system. Scaffolding
> > generation is the same: a working example makes it easier to learn.
> >
> > So: it seems to me that the fact that Grails allows users to drop
> > down into the "assembler" is a benefit, not a weakness.
> >
> > Apologies for rambling on, but I think there is an implication for
> > how Grails develops, which is that it shouldn't try too hard to hide
> > everything in the J2EE stack that it depends on. For example, hiding
> > the Log4J config has some benefits, but if it was also possible to
> > fall back to the Log4J version then that would also be a good thing?
> >
> > Best,
> > --
> > Hamish
> > http://www.dcs.shef.ac.uk/~hamish/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Graeme Rocher
> Grails Project Lead
> http://grails.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Leaking abstractions declared harmless! (and Grails config)

peter_m
If it weren't for the fact that we could fall back on the Hibernate
and Spring XML configuration files and their associated objects, we
wouldn't have used Grails. Simple as that. So in our case, the
decision to allow those leaks is certainly a strength, as I think it
will be for any "enterprise" development team.

-Peter

On 10/11/07, Steven Devijver <[hidden email]> wrote:

> Leaky abstraction is a rather abstract issue and it's not easy to
> determine whether it's harmful or not (it's bound to be a rather
> theoretic discussion).
>
> A far more important indicator is excessive complexity due to layering
> and abstraction gone wrong.
>
> I think the reduction and near total elimination of excessive
> complexity is one of Grails' major strengths.
>
> Steven
>
> On 10/11/07, Graeme Rocher <[hidden email]> wrote:
> > Hi Hamish
> >
> > Rails people view Rails as a leaky abstraction and consider it a
> > strength, so you're not alone.
> >
> > Cheers
> >
> > On 10/11/07, Hamish Cunningham <[hidden email]> wrote:
> > >
> > > Hi,
> > >
> > > There was a post a few weeks ago citing a criticism of Grails on the
> > > basis that it might suffer from "leaking abstractions". I took this
> > > to mean that the underlying systems that Grails is layered on
> > > (Spring, Hibernate, etc.) could "poke through" and become visible.
> > > For example, if you needed some kind of mapping that GORM didn't
> > > support but Hibernate did then you'd need to write some config for
> > > the latter instead of only using Grails' various domain relationship
> > > mechanisms.
> > >
> > > I've been mulling this over, and I started to wonder if this is
> > > actually a strength rather than a weakness. I started using Grails
> > > around a year ago, and although I'd played with various J2EE
> > > technologies over the years I was pretty near to beginner level.  A
> > > huge difference between my previous J2EE experience and what I found
> > > in Grails was that I could get a running system very quickly that
> > > did useful things without writing a spider's nest of XML spread
> > > across a bunch of 10-deep directory trees. As time went on I met
> > > problems that meant I needed to tinker with some of the innards, and
> > > write a big of Spring config or web.xml, but it was quite different
> > > to be doing that in the context of a running system. Scaffolding
> > > generation is the same: a working example makes it easier to learn.
> > >
> > > So: it seems to me that the fact that Grails allows users to drop
> > > down into the "assembler" is a benefit, not a weakness.
> > >
> > > Apologies for rambling on, but I think there is an implication for
> > > how Grails develops, which is that it shouldn't try too hard to hide
> > > everything in the J2EE stack that it depends on. For example, hiding
> > > the Log4J config has some benefits, but if it was also possible to
> > > fall back to the Log4J version then that would also be a good thing?
> > >
> > > Best,
> > > --
> > > Hamish
> > > http://www.dcs.shef.ac.uk/~hamish/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
> > --
> > Graeme Rocher
> > Grails Project Lead
> > http://grails.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email