development

How to move forward

September 23, 2005 7:50:39.451

Zefhemel has the right idea about language features and productivity. Noting how many extra (and complicated) language features C# had to add in order to do LINQ, he asks:

So, here’s my question. How far are we willing to drag on the huge beast that is a static language? If you look at a language like Ruby or Python, they already got most of the features that C# had to add to make this happen, but in Ruby and Python they’re not half as complicated. In Ruby you could already add methods to existing classes, anonymous methods (in Ruby known as blocks) are something a Ruby programmer breathes, anonymous types? var keyword? generics? Don’t need those.
If we want to carry on in the direction that LINQ is heading, and I think we should, shouldn’t we sacrifice this one thing: static languages? This makes things a lot simpler in many ways, and the sacrifice may just be worth it.

This was the point I was trying to make here. It's not that LINQ is a bad idea in and of itself; it's that all the cruft MS needed to add for it is. At some point, you would think that people like Hejlberg and Gosling would look at dynamic languages, ponder the complexity they've added to their own creations just to approach the same capabilities... and get a clue.

Comments

[Vincent Foley] September 23, 2005 9:45:34.769

Like you often say James, if it's not complex, it's probably not good1. I posted a (simplistic) Smalltalk version of a LINQ functionality on a forum I visit where they were talking about LINQ. Here's the code: 

Collection>>select: selectBlock where: whereBlock orderBy: aSymbol
  ^((self select: whereBlock) collect: selectBlock) sortBy: [ :a :b | (a perform: aSymbol) <= (b perform: aSymbol) ].

It's been a couple of months since I had the chance to write Smalltalk code, and I can't test it right now, but I think this works. So you could say: 

employees
  select: [ :manager | manager spouse ]
  where: [ :employee | employe isManager ]
  orderBy: #dateOfBirth.

That's not terribly complicated is it? We did not need to add a gazillion features to the language to take care of static typing issues, dynamic typing, blocks and keyword messages give us the same result as LINQ.

1. Where "not good" means: won't scale, is bug-prone, is complex, is slow, etc.

completely missing the point

[Isaac Gouy] September 23, 2005 11:49:21.983

Vincent a (simplistic) Smalltalk version of a LINQ functionality on a forum
The LINQ functionality works for in-memory objects and SQL query and XQuery - your example only works for in-memory objects.

Who missed?

[ James Robertson] September 23, 2005 12:09:34.862

Comment by James Robertson

Isaac - you missed the basic point - the way they added this functionality was to lard on complexity. Which, IMHO, is not a great way to go.

please show VW SQL and VW XQuery

[Isaac Gouy] September 23, 2005 13:01:25.315

lard on complexity
James please show Vincents query for SQL and XQuery (SQL should be easy with GLORP).

[Vincent Foley] September 23, 2005 13:26:03.077

The basic idea is that if you have closures that you can send to methods, the new stuff in LINQ is definitly possible to implement. Sure my version works only with in-memory objects, and sure the LINQ implementations has other things like group by, etc. We could definitly implement these methods on top of SQL and XQuery as well. It wouldn't require a change in the language, just adding methods to the appropriate methods.

[Vincent Foley] September 23, 2005 14:02:02.454

That should be "just adding methods to the appropriate classes"

As Vincent said

[ James Robertson] September 23, 2005 14:32:08.047

Comment by James Robertson

In Smalltalk, anyone can create that sort of framework without requiring a language change. With the CLR stuff, it required changes in the language by MS just to make it possible.

As is too often the case Isaac, you are looking squarely at the trees, and missing the surrounding forest.

change-in-the-language rhetoric

[Isaac Gouy] September 23, 2005 15:01:16.490

without requiring a language change
And the reason it wouldn't require a change in the language is that there's almost no Smalltalk language - Smalltalk is all library.

possible to implement
Nobody is talking about C# 3.0 and VB9 because it's possible to implement LINQ - they are talked about because they did implement LINQ.
Nobody is raving about Ruby because it's possible to implement Ruby-on-Rails - the buzz exists because they did implement RoR.

 Share Tweet This

comments(8) | permanent link | printer friendly | del.icio.us | diggIt | next | prev

-->