I don't think I ever said that... I've mostly been using it since
starting to write my book.

Much as I respect Joel's writing in many cases, I think he's wrong on
this one (and a few others - his objection to exceptions being the
most notable mistake IMO).

You aren't forced to learn a new toolset - it's just that you might
become more productive if you do. Now, I do think there's a risk that
MS is putting out too *many* new technologies at the moment (WPF,
Silverlight, WCF, LINQ, WF, the list goes on) - but my existing
applications are still working absolutely fine, and I can still
maintain them.

Likewise you aren't forced to rewrite applications, and in many cases
doing so would be a bad idea - but *sometimes* it's a good idea, and
*often* it's worth using the newer technologies for greenfield
projects.

Jon

Considering C# 3.0 didn't actually break any old code, except for in few
minor cases where you've happened to use a (now) reserved language
keyword for a variable or similar, 3.0 isn't really related to that article.

While I sympathize with some of the sentiments of that article, a
similar article could equally well be written about how Microsoft never
reinvents itself and there's never any new API's or framework
technologies coming out from them, assuming we lived in a world without
.NET.

The Windows API has lived for a long time, and some of the issues with
it are hard to live with over time. In particular, dll versioning,
manual memory management and return-vales-to-signal-errors, all of those
make the job of producing anything that interfaces with core windows
subsystems more of a chore than what .NET, or other similar frameworks,
does. It is a very well thought-out framework that has been stable for
quite some time, in the sense of backwards compatibility, but it is
starting to show some wear and tear, at least thats my opinion.

Additionally, if you built a program for .NET 1.1 a few years ago, that
program will still run today and will continue to do so as long as the
subsystems you use are part of Windows.

I think the main problem with progress is that you can never get people
to agree on what progress really is, and how it applies to them. It
wasn't long ago on this very newsgroup that someone lamented Microsoft
going away from ActiveX applets for browsers in favor of .NET and
Silverlight. I have dealt with two ActiveX projects and I don't think I
will ever encounter something more messy and hard to get working
properly, with some of the same comments that Joel make in that article.

Re calling SPs more easily... how about just an exmaple?
Add a "LINQ to SQL classes" file, named kinda like your database; the
dbml designer should appear. I've opted for Northwind, so in the
Server Explorer I've locate the database, expanded "Stored Procedures"
and dragged "Ten Most Expensive Products" into the designer (righ hand
pane; left is data entities). You can tweak the (object-model) name if
you like (it replaces space with underscore by default). Note that it
will inspect the SP to see how it behaves, and try to model the args
and return value accordingly (you can fixup any oddities in the xml if
needed).

Each dbml creates an "data context" (which btw is extensible, both by
partial classes and the new partial methods); procs then appear as
instance methods on that dc (tables as queryable entities); for
instance:

           using (NorthwindDataContext db = new
NorthwindDataContext()) {
               foreach (var product in db.TenMostExpensiveProducts())
               {
                   Console.WriteLine("{0}: {1}",
                       // this is the bizarre column name
                       // from the SP! Blame Northwind... could
                       // probably change in the dbml if needed
                       product.TenMostExpensiveProducts,
                       product.UnitPrice);
               }
           }

and it works:

Côte de Blaye: 263.5000
Thüringer Rostbratwurst: 123.7900
Mishi Kobe Niku: 97.0000
Sir Rodney's Marmalade: 81.0000
Carnarvon Tigers: 62.5000
Raclette Courdavault: 55.0000
Manjimup Dried Apples: 53.0000
Tarte au sucre: 49.3000
Ipoh Coffee: 46.0000
Rössle Sauerkraut: 45.6000

There is a *lot* more depth here, especially when talking about procs
that are CRUD for your entities (that should *also* be part of the
dbml). But the point is - we haven't had to had-crank any of the
command, args or result. It should work OK against most SQL Server
variants (SQL2000 is a bit limited, but 2005+ including express are
fine). And "LINQ-to-Entities" (Entity Framework) provides multi-vendor
support and significantly more complex mappings (I'm not sure if this
latter is a good thing or not).

But to my view: they *have* addressed the "why to I have to write all
this data access code"... it is the primary goal of LINQ-to-SQL.

Marc

Yes they are, and they work. As long as bits are added that make it
easier to write concise code, I'll welcome such changes, as long as it
doesn't break existing code (too much).

Without delegates and lambas, you would be forced to create a class
implementing an interface, and pass an instance of that object to the
method that in the current implementation takes a delegate which can be
specified with an anonymous method or a lambda.

The net result would be a new interface to replace the delegate, a new
class, making sure all relevant data are passed to the object when you
construct it, and code that is split out over several places. The
concise way of writing the same code with an anonymous method is at
least preferred by me.

Inheritance is a concept mainly related to polymorphism, which doesn't
bring much to a static hierarchy. I agree, the syntax might look good
but I'm not entirely sure there's a lot it would benefit me. For
instance, for the Log method to actually do something different when
called through ErrorLog, you'd have to rewrite it for ErrorLog anyway.

For instance, the Log method might call an internal InternalLog method
that did the actual logging. If this method is implemented in
BaseLoggingClass, you would not be able to override/replace this in
ErrorLog so that methods you didn't override in ErrorLog still ended up
calling the other overridden emthods from BaseLoggingClass.

The only way a base class can "know" about overridden methods is through
a vtable and this is linked to object instances.

or perhaps I'm missing something obvious?

I agree on this, I would welcome more base classes for data structures
beyond the ones provided in the BCL today.

So that is why my Javascript works one day and fails by the next
Monday.  "weekly typed".  Hmmm.  :)

rossum

Ok. I got a few minutes over, I'll type a proper respons.

- Michael Starberg

Well, now I am sure.

He posted his angry letter,
made a few comments that showed that
he don't even know .NET 3.5 nor C#3
and have then not responded at all.

I call that trolling.

But it is ok, becuase sorrounding his lame post,
we had a great discussion.

- Michael Starberg

Not on the standard datacontext members of LINQ-to-SQL; SPs become
methods, and tables become "Table<SomeType> Name" properties. LINQ-to-
Entities may provide more flexibility (I honestly don't know), since
that is the broadly the concept between the different layers in the
model. I don't know if it extends to SPs vs tables without loss of
generality.

There are perhaps some things you can do around this, but...

Marc

Hmm. Stored Procedures maps to methods on your DataContext, so it can't be
easily compared.
But for a more general answer, SOMETHING can be anything that implements
IEnumerable<T> like an Array or a List.

For more complex structures LINQ works if it has a provider for it, i.e that
has a custom implementation of IQuerable<T>. Take xml for instance, it can
be queried using LINQ by using System.Xml.Linq.

LINQ is so powerful, that you can even make join a database, a list and a
xml-document in one single query and also group them.

Well this is a matter of taste.
You can always map all your stored procedures to a DataContext, but then you
are not really making much use of linq.

Some people like the idea of keeping all sql in the database in form of
stored procedures.
One argument would be that you can make changes in your schema and not
affect applications.

In my experience this never happens. Typically it is always the application
that changes, that then demands changes in the database. Maybe for a
enterprisy system with many application sharing the same database, things
might be different.

I mostly work with one appliction, one database.
Consider the system I am working on now.
We got a 3 layer architecture on 2-tiers.

-- tier 1
ASP.NET web-site.  - presentation
LINQ DAL .dll  - business logic / rules
--- tier 2
SQL Server 2005 - data / schema

As by not using stored procedures we have really seperated data and code. =)

Well that would be easy, just don't use plinq. =)
But maybe the OP has a point. I think some low-level classes are missing in
.NET

It would be cool if .NET could sport a red-black-binary-tree, and why not a
balanced B-Tree.
Also, it would also be a good thing if there different sorting algorithms
already implemented instead of just '.Sort method uses quicksort'.

Well, there are always third party components.

- Michael Starberg