Artima Developer Spotlight Forum - Language-Integrated Querying for Scala

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Artima Developer Spotlight Forum
Language-Integrated Querying for Scala

20 replies on 2 pages. Most recent reply: Nov 8, 2009 11:08 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 20 replies on 2 pages [ « | 1 2 ]

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Language-Integrated Querying for Scala

Posted: Nov 3, 2009 12:09 PM

> > > In my original post to this thread, I really didn't
> > > mean this as a rhetorical question. I believe it's
> > > quite possible that there is a reason. I mean the
> > > people behind things like LINQ must have a reason,
> > > right? I just don't know what it is.
> >
> > the reason that the selected columns are last and not
> > first is that you can do code completion. This is the
> only
> > deliberate difference.
>
> That makes sense and all. But I'm not convinced that it's
> hugely important.
No, but it's worth the benefit.

> > Apart, from that LINQ is not a language, but a set of
> > keywords that are processed by the C#/VB preprocessor.
> > This is the other reason that LINQ is not exactly SQL.
>
> What's your definition of a language? I don't consider
> the mechanics of how it's interpreted to have any bearing
> on whether something is a language or not.
No, of course not.
I'm just saying that some parts of this 'language' is being driven by the host language - e.g. String and number literals.
In a strict sense, LINQ is a superset of C#/VB, because you can call regular C#/VB methods.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Language-Integrated Querying for Scala

Posted: Nov 3, 2009 2:08 PM

> > > > In my original post to this thread, I really didn't
> > > > mean this as a rhetorical question. I believe it's
>
> > > > quite possible that there is a reason. I mean the
> > > > people behind things like LINQ must have a reason,
> > > > right? I just don't know what it is.
> > >
> > > the reason that the selected columns are last and not
> > > first is that you can do code completion. This is the
> > only
> > > deliberate difference.
> >
> > That makes sense and all. But I'm not convinced that
> it's
> > hugely important.
> No, but it's worth the benefit.

I tend to disagree but I can understand why you feel that way.

> > > Apart, from that LINQ is not a language, but a set of
> > > keywords that are processed by the C#/VB
> preprocessor.
> > > This is the other reason that LINQ is not exactly
> SQL.
> >
> > What's your definition of a language? I don't consider
> > the mechanics of how it's interpreted to have any
> bearing
> > on whether something is a language or not.
> No, of course not.
> I'm just saying that some parts of this 'language' is
> being driven by the host language - e.g. String and number
> literals.
> In a strict sense, LINQ is a superset of C#/VB, because
> you can call regular C#/VB methods.

OK. I think my lack of excitement about LINQ comes from not seeing queries integrated in the code as a benefit. I spent a stint maintaining some PowerBuilder code (PowerScript) and I decided that it was a sloppy way to do things. It's convenient initially but becomes a real pain the in ass over time. I think there needs to be a layer of abstraction between persistence and logic. What exactly that should look like I think is still an open question.

I guess I just feel like I've seen that movie before and it doesn't have a happy ending.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Language-Integrated Querying for Scala

Posted: Nov 7, 2009 12:23 PM

> OK. I think my lack of excitement about LINQ comes from
> not seeing queries integrated in the code as a benefit. I
> spent a stint maintaining some PowerBuilder code
> (PowerScript) and I decided that it was a sloppy way to do
> things. It's convenient initially but becomes a real pain
> the in ass over time. I think there needs to be a layer
> of abstraction between persistence and logic. What
> exactly that should look like I think is still an open
> question.
I currently work with JPA where I have Java objects that match the database tables (it doesn't really matter if these classes are generated or annotated, although I currently like the annotated way) and that can be cached (which is very important).

For me, LINQ would be "just" a more convenient way to write JPQL queries - it would save me a couple of iterations each time and would allow refactoring of queries (Eclipse could theoretically still refactor JPQL).
In other words, I don't see any drawbacks.
Maybe you can tell me if I just don't see them or whether you are PowerScript damaged...

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Language-Integrated Querying for Scala

Posted: Nov 7, 2009 6:21 PM

> In other words, I don't see any drawbacks.
> Maybe you can tell me if I just don't see them or whether
> you are PowerScript damaged...

I don't think the drawbacks are fundamental. I think you could structure your code such that the abstraction remains and the LINQ (or similar) is decoupled from the logic.

I was doing maintenance on code that was 5 to 10 years old. Powerscript was (is?) integrated with SQL. Kind of a superset language. You would write your queries and updates right in the middle of basic-esque code. The problem came when the database structure would need to be changed. There was gobs of SQL spread throughout the code. Behind buttons, at startup, on window opens, ... you name it and there was some SQL buried in there.

By the time I was involved, a newer approach had been adopted. You would define a sort of abstract data object which your code would use and resuse. The SQL was encapsulated inside this abstraction such that it could be changed without breaking it's clients.

In a nutshell, the integrated approach was quick and easy. Why bother with abstractions when you can just crack out the query or update that you need. But after a few years, you have hundreds if not thousands of these queries and updates to maintain. This lesson was learned by the PB community. Sybase didn't create the abstract layer approach just for kicks.

So it's not the feature that worries me. Someone like you will probably know to avoid this trap and still use the feature effectively. What worries me is that a lot of people seem way too excited about LINQ, they seem to think that it's a completely novel solution. I fear these people think that LINQ will 'free' them from the burden of creating an abstraction layer. Tools like Hibernate, for all their flaws, force some rigor. The cost of creating new mappings is high enough that people to take time to reuse existing mappings whether they want to or not. Eventually, people will realize why it's important to build abstractions but probably not until it's too late, mainly because we have such poor inter-generational communication in this industry.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Language-Integrated Querying for Scala

Posted: Nov 8, 2009 3:11 AM

> So it's not the feature that worries me. Someone like you
> will probably know to avoid this trap and still use the
> feature effectively. What worries me is that a lot of
> people seem way too excited about LINQ, they seem to think
> that it's a completely novel solution. I fear these
> people think that LINQ will 'free' them from the burden of
> creating an abstraction layer.
I understand your fear, but I'm skeptical that language features can enforce architecture, especially decoupling.

Apart from that, LINQ does come with a database layer in the sense that you get a Person object if you query the PERSON table. This is important, because
1) Person is cacheable
2) it can be refactored (which seemed to be one of your pain points)
3) it can be enhanced with a partial class of your own (this is not inheritance, the files are just appended by the compiler)

The Person class is generated from the DB schema (this is why partial classes make sense).
They were planning to generate the DB schema from an annotated class when I checked last year. They were also planning round-trip engineering (updates to existing schemas) like hibernate.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Language-Integrated Querying for Scala

Posted: Nov 8, 2009 11:08 AM

> I understand your fear, but I'm skeptical that language
> features can enforce architecture, especially decoupling.

I absolutely agree. On the other hand I do believe that language features can encourage bad approaches. An analogy is if I were to leave a loaded firearm in reach of a small child. Many people, even most people, would agree that I would culpable for anything that might happen if the child did take the weapon in hand.

It sounds terrible but what I've seen is that a lot of development shops are absolutely run without adult supervision. They are basically given these features by vendors and have no historical context to whether the approach had been tried and how it worked out.

To say that we should restrict features because someone might misuse them is a very difficult stance to defend and I don't want try. I'm not even sure how much I agree with that.

Really I just wish some of the excitement about LINQ were tempered a bit with some caut

> Apart from that, LINQ does come with a database layer in
> the sense that you get a Person object if you query the
> PERSON table.

That's OK for one half of the problem but I don't think it addresses the other part: the query and update definitions (perhaps just query.)

> They were planning to generate the DB schema from an
> annotated class when I checked last year. They were also
> planning round-trip engineering (updates to existing
> schemas) like hibernate.

That sounds to me like even tighter coupling between the code and the DB. That's the opposite of what I am looking for in a persistence layer.

Flat View: This topic has 20 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic


	Web Artima.com