LINQ – Lessons that could have been learned from languages like Progress

In a previous post, I mentioned lessons I learned from what I think Progress made mistakes at. However, when looking at the implementation of LINQ in .NET, I think much could have been learned from these types of applications and tools.

At the time I used to use it, Progress applications implicitly has a database context. It's often said that over 90% of applications are data-related. This is the argument for why data libraries shouldn't be an add-on to the language but should be baked in.

I'd go further and suggest that over 90% of the data-related applications operate in the context of a single database. So why don't applications or middle-tier components have the option to specify that database context globally?

I really liked the detailed integration of database objects and language objects in Progress. It was quite seamless. If I wanted to iterate through customers, I could just say:

for each customer:

If I had the equivalent of a where clause, I could just say:

for each customer where somecolumn = something:

To locate a particular customer row, I could just say:

find customer where somecolumn = something.

If there were multiple possible rows, I could say:

find first customer where somecolumn = something.

Where LINQ still feels like an add-on to the language, this is very natural syntax and behaviour. I totally struggle with why there was any need to use SQL-like syntax with LINQ. And given that LINQ is a language extension for querying, unrelated to databases, why not use syntax that's more related to object querying rather than a messed-up variant of SQL?

Another aspect that the Progress language had was default display formats associated with each data type. An entire program (not a great one :-)) could be:

find customer where somecolumn = something.


These two lines encapsulated the data access, the update logic, the transaction scoping (poor in this case), the entire screen layout and display/update format for the column, etc. I'm not suggesting I want that style of code any more, particularly given application layering and tiers but it gives an indication of the level of abstraction that you could work at. We're still a long way short of that. (People who use Access are probably chuckling at this point).

I suspect we still need a standardised way to store a variety of column and data type related metadata in the database. We can do a lot of that via extended properties but everyone does it in a different way.

6 thoughts on “LINQ – Lessons that could have been learned from languages like Progress”

  1. Progress was my first RDBMS, so SQL at first seemed upside-down to me!
    FOR EACH table:
      DISPLAY col1 col2 col3.
    … rather than SELECT col1, col2, col3 FROM table;
    Enjoyed hearing about it again (it's still around, now called OpenEdge) but I agree it lost its simplicity & power trying to update to an Object-Oriented, GUI style.  Still, it was (is?) VERY reliable.

  2. Won't that be possible with LINQ for Entities?
    Although it's not mentioned specifically, a Channel9 webcast on EDM/EF featuring Brian Beckman and Sam Drucker somehow led me to believe that would be possible.

  3. Hi Ian,
    Sort of but it's still very much an add-on rather than being fully baked into the language.

  4. Also, I should have mentioned that it only deals with the objects, not with the associated metadata.

  5. >it's still very much an add-on rather than being fully baked into the language.
    I remain somewhat perplexed by just what you mean by this. By definition LINQ is 'burned in'. This is the achievement that MS has accomplished. To imply that it's not fully baked in is like saying a woman is somewhat pregnant. It is or it isn't, you are or you are not:) Either a table/entity or projection can be represented as a variable or it cannot. That all these things 'can' be a variable of some type referenced in the language is the whole point of it no? Your use of 'add-on' seems to imply that LINQ is something external to the language much like an external 4GL like Progress. I don't think this can be further from the truth. In your interview with Pablo Castro he referred to Progress as an example of a language having 'direct line of sight from language to database'. Wasn't he struggling here to convey the idea to sql folks of the fundamentally different natures of the two? To bring the 4GL idea into contemporary languages one shouldn't expect they are going to be similar. And you seem to be implying that LINQ is not as 'natural' as Progress. How could it be? If you first have to define a query variable (table) you certainly can't expect to start your    variable with a Select/Find. You define and then perform an action right? In t-sql 'Select @MyNumber' only makes sense if your first declare @MyNumber. Is LINQ any different? And in the sense that 'declare @MyNumber int' is burned into t-sql, isn't 'var customers = from c in db.Customers' burned into C#?
    I do think sql folks should listen to your interview with Pablo. It is proving difficult for MS folks to convey just what they have done to those outside of net. What is worse, misunderstanding it or ignoring it? 🙂 Shouldn't sql folks fully understand why MS thinks it's such an improvement over sql? So far I think either they don't or simply don't care.

  6. Greg coming from a Progress background myself (and still working extensively with OpenEdge) I find the LINQ project really interesting.  
    What I find interesting about the LINQ extension to .NET is that the 3GL world is trying to simplify certain actions by applying 4GL principles (e.g. ForEach statements, etc) whilst at the same time those of us in the 4GL world are now moving towards 3GL style coding as well (using things like object orientation, etc).
    I also understand what Alphatros means by SQL looking like it's on its head 🙂  It's funny how different people perceive programming, it's almost a religious war.
    Thanks for the post, I look forward to hearing more.

Leave a Reply

Your email address will not be published. Required fields are marked *