Open Post to the C# Development Team

[sp3d2orbit]

Dear C# Development Team,

Is the latest version of C# for the development community's benefit,
or an opportunity to play around with features you would like to code?

Forgive me for asking, but it seems like you (the development team)
have lost sight of what the developer needs: productivity.

LINQ - What ever happened to separating data from code? Why are we
integrating it further? If you want to help me out, make it so I can
call stored procedures from C# natively:

DataSet oDs = MySqlServer.MyDB.dbo.MyStoredProc(strParam1, iParam2)

With all the work put into LINQ, I still can't do that. Sql Dmo is
close, but doesn't handle any of the work for me, doesn't enforce
types, doesn't create any stubs, and is slow.

As language designers, you should probably pick a paradigm and stick
with it, or create a new language. SQL is an imperative language (like
Prolog), C# is an object oriented language. There is no sane reason to
combine them -- especially when an object oriented approach would have
worked just as well, probably better.

Adding functional and imperative paradigms to C# is fine for some, but
wasn't C# supposed to be object oriented? If we're adding features
from non-object oriented languages (lambda functions, anonymous
functions), why not add file level functions like C++ and call it
even?

STL.NET - What happened? Wasn't this supposed to come to C# at some
point? Even with Generics I still don't have C++'s map, multimap, or
set equivalents. Hash tables are great for large amounts of data, but
you can't beat a red black binary tree for storing less than few
thousand items in memory.

Static Inheritance - Want to create a new feature that helps people
write better code? Static inheritance. I can write Singleton objects
all day long, and they're built into the language.

I see a tendency to solve problems that don't need solving. For
instance, the new property syntax (PropName{get;set;}) is elegant,
but a code snippet does that same thing and provides more flexibility
in the end.

I use C# and Visual Studio every day, have for years, and that's my 2
cents.

Thanks,
Matt Furnari

 

[Jon Skeet [C# MVP]]

Is the latest version of C# for the development community's benefit,
or an opportunity to play around with features you would like to code?

Forgive me for asking, but it seems like you (the development team)
have lost sight of what the developer needs: productivity.

I couldn't disagree more strongly. I've been using C# 3 for a while
now, and I find it *much* more productive than C# 2. How long have you
actually been using C# 3 for? Are these just first impressions, or
considered opinions after trying it for a long time?

<snip>

Jon

 

[Marc Gravell]

If we're adding features

from non-object oriented languages (lambda functions, anonymous
functions)

Lambdas are typically *consumers* of your existing OO model; if you've
ever used delegates as arguments (for example, List<T>.Find), then you
would be amazed at the simplicity that a lambda gives you... want to
find by name? myList.Find(x=>x.Name == name)

LINQ - What ever happened to separating data from code?

LINQ isn't just about databases... the point is: you can write similar
C# to query/manipulate any data source. Yes, sure, you could aggregate
a collection by creating a dictionary, enumerating the list, checking
the dictionary, changing the accumulator, etc - lots of places for
pain. Or you could just use a 3 line LINQ query. And as Jon is keen on
pointing out; even this isn't specific to in-memory colelctions; just

If you want to help me out, make it so I can call stored procedures from C# natively:

You can consume SPs in a LINQ-to-SQL, simply by dropping from the
server explorer onto the DBML designer, then you *can* invoke
myDataContext.MyStoredProc(strParam1, iParam2) - so you get *exactly*
what you want, while retaining the strength of having an agreed (and
explorable) API to your data, and being able to relocate "MySqlServer"
and "MyDb" through configuration. Want to add a new SP at a later
date? Great: just open the designer and drag it on! Or, simply edit
the xml (dbml) file directly if you like (perhaps from automated
scripts). What more could you ask for?

I see a tendency to solve problems that don't need solving.

And yet you mention static inheritance... for all its uses, I can't
say that the lack of this has ever hurt me?

the new property syntax

I think the point here is to take away the last remaining excuse for
people to use public fields when *all* they are doing is passthrus
(i.e. the "more flexibility" isn't an issue).

Marc

 

[sp3d2orbit]

I couldn't disagree more strongly. I've been using C# 3 for a while
now, and I find it *much* more productive than C# 2. How long have you
actually been using C# 3 for? Are these just first impressions, or
considered opinions after trying it for a long time?

<snip>

Jon

If you've been using C# 3.0 for a couple of years, I would love to
get your opinion on this:

http://www.joelonsoftware.com/articles/APIWar.html

In particular, I wonder how you feel about rewriting your
applications, relearning a toolset every time MS puts out a new
technology.

 

[sp3d2orbit]

Lambdas are typically *consumers* of your existing OO model; if you've
ever used delegates as arguments (for example, List<T>.Find), then you
would be amazed at the simplicity that a lambda gives you... want to
find by name? myList.Find(x=>x.Name == name)

I'll bite. Delegates are not part of the OO model. They're an import
from functional languages. Pure OO requires nothing but message
passing in the form of data. No code coupling. No pointers to
methods.

However, you raise an interesting point. When MS broke with the OO
model there they laid the groundwork for functional features in C#.
I'm not saying that C# should be 100% object oriented, but there are a
lot of holes in C# 2.0 features that need patching before adding new
paradigms.

The problem C# 3.0 raises for me is it walks a line between C++
(strongly typed + lots of paradigms) and Javascript (weekly typed
language + lots of paradigms). C# 2.0 carves out its own niche in
being (mostly) strongly typed and object oriented language. It fills a
different role -- not as fast as C++ but easier to code. Not as
flexible as Javascript but easier to code.

I feel C# 3.0 should focus on smoothing out the weak spots, instead of
adding new ones. It should perform it's role as well as possible, but
to continue to have a niche.

I don' think it is reasonable to expect to write a program in 1
language. Each domain requires its own tools. T-SQL is suited to run
in the database, which is optimized to run it.

LINQ isn't just about databases... the point is: you can write similar
C# to query/manipulate any data source. Yes, sure, you could aggregate
a collection by creating a dictionary, enumerating the list, checking
the dictionary, changing the accumulator, etc - lots of places for
pain. Or you could just use a 3 line LINQ query. And as Jon is keen on
pointing out; even this isn't specific to in-memory colelctions; just


You can consume SPs in a LINQ-to-SQL, simply by dropping from the
server explorer onto the DBML designer, then you *can* invoke
myDataContext.MyStoredProc(strParam1, iParam2) - so you get *exactly*
what you want, while retaining the strength of having an agreed (and
explorable) API to your data, and being able to relocate "MySqlServer"
and "MyDb" through configuration. Want to add a new SP at a later
date? Great: just open the designer and drag it on! Or, simply edit
the xml (dbml) file directly if you like (perhaps from automated
scripts). What more could you ask for?

Please, sir, post some links about this feature. I'll eat crow all day
long if I can call my stored procedures natively =) Mmmm, crow...

And yet you mention static inheritance... for all its uses, I can't
say that the lack of this has ever hurt me?

It may not hurt but it would be wonderful to do this:

static class BaseLoggingClass
{
static BaseLoggingClass{do singleton startup stuff};
static void Log(string strMessage)...
}
static class ErrorLog : BaseLoggingClass
....
ErrorLog.Log("my error")

I think the point here is to take away the last remaining excuse for
people to use public fields when *all* they are doing is passthrus
(i.e. the "more flexibility" isn't an issue).

Just to be clear, my request is for more tools over more paradigms. I
need containers and algorithms from the standard template library more
than a shorter parameter syntax.

 

[Marc Gravell]

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

 

[Marc Gravell]

(typos: sorry for the poor typing today!)

 

[sp3d2orbit]

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

Well done, sir. I wonder why it can't do any arbitrary ODBC source?
Seeing as I use MySQL for half my projects and SQL 2000 for another
quarter, that would be very convenient.

There is actually a book from Microsoft Press about generating code
with xslt's, including a full O/R layer. I'm left to wonder why they
didn't use this approach since it is data source neutral. Perhaps
simply a case of vendor lock-in.

 

[Jon Skeet [C# MVP]]

If you've been using C# 3.0 for a couple of years

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

I would love to get your opinion on this:

http://www.joelonsoftware.com/articles/APIWar.html

In particular, I wonder how you feel about rewriting your
applications, relearning a toolset every time MS puts out a new
technology.

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

 

[Marc Gravell]

Well done, sir. I wonder why it can't do any arbitrary ODBC source?
Reality is that many of the more interesting features (paging for
instance) work very differently with different products. LINQ-to-SQL
only addresses SQL Server.
DbLinq (http://code2code.net/DB_Linq/) is an alternative flavor of
LINQ that covers a range of vendors including MySQL. Andrus (see the
archives) may be able to comment on how good (or not) it currently is
(I haven't used it). Likewise, LINQ support is being added to
NHibernate.
On the MS side, LINQ-to-Entities (currently Beta3) is provider-
extensible, so it is entirely possible that a MySQL provider will be
available at some point, either by MS or by the community.
You are positively spoilt for choice, but note that the point is that
they are all using the same pattern and compiler technologies: LINQ.

Marc

 

[Michael S]

Dear C# Development Team,

I was going to reply, but then I realized you are just trolling

- Michael Starberg

 

[Lasse Vågsæther Karlsen]

I'll bite. Delegates are not part of the OO model. They're an import
from functional languages. Pure OO requires nothing but message
passing in the form of data. No code coupling. No pointers to
methods.

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.

It may not hurt but it would be wonderful to do this:

static class BaseLoggingClass
{
static BaseLoggingClass{do singleton startup stuff};
static void Log(string strMessage)...
}
static class ErrorLog : BaseLoggingClass
...
ErrorLog.Log("my error")

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?

Just to be clear, my request is for more tools over more paradigms. I
need containers and algorithms from the standard template library more
than a shorter parameter syntax.

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

 

[Lasse Vågsæther Karlsen]

If you've been using C# 3.0 for a couple of years, I would love to
get your opinion on this:

http://www.joelonsoftware.com/articles/APIWar.html

In particular, I wonder how you feel about rewriting your
applications, relearning a toolset every time MS puts out a new
technology.

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.

 

[Marc Gravell]

I was going to reply, but then I realized you are just trolling

I'm not sure I'd agree with that...

 

[Michael S]

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?

Well, in Delphi you can have a 'pointer to class'.
That would be like being able to do

ClassType t = SomeClass;
t.InvokeStaticMethod();

... so polymorhism works for static methods in Delphi and static methods are
indeed virtually inherited.

But you are right for C#.

- Michael Starberg

 

[Michael S]

I'm not sure I'd agree with that...

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

- Michael Starberg

 

[Michael S]

Dear C# Development Team,

Is the latest version of C# for the development community's benefit,
or an opportunity to play around with features you would like to code?

This part sounds like you are just trolling.
Surely the C# mission statement was not:
- "Let's screw development benefit and play around with features"

On the contrary, when I started digging into .NET 3.5 and C#3 I was amazed
on how inference, lambda and extentions led to the very brilliant LINQ.

Forgive me for asking, but it seems like you (the development team)
have lost sight of what the developer needs: productivity.

I disagree. With C#3 and especially LINQ I estimate I am twice as fast and
do tripple less bugs compared to using NET 1.1

LINQ - What ever happened to separating data from code?

The principle is alive and kicking. Especially when using LINQ.

Why are we integrating it further? If you want to help me out, make it so
I can
call stored procedures from C# natively:

DataSet oDs = MySqlServer.MyDB.dbo.MyStoredProc(strParam1, iParam2)

You can.

With all the work put into LINQ, I still can't do that. Sql Dmo is
close, but doesn't handle any of the work for me, doesn't enforce
types, doesn't create any stubs, and is slow.

It does. By drag-'n-drop. Very productive. =)

As language designers, you should probably pick a paradigm and stick
with it, or create a new language.
Why?

SQL is an imperative language (like> Prolog),
C# is an object oriented language. There is no sane reason to
combine them

I can think of several sane reasons, but only one insane reason.

-- especially when an object oriented approach would have
worked just as well, probably better.

Probably better?
You think a simple delegate is worse than implementing the Observer pattern?
Less productive?

Adding functional and imperative paradigms to C# is fine for some, but
wasn't C# supposed to be object oriented? If we're adding features
from non-object oriented languages (lambda functions, anonymous
functions), why not add file level functions like C++ and call it
even?

STL.NET - What happened? Wasn't this supposed to come to C# at some
point? Even with Generics I still don't have C++'s map, multimap, or
set equivalents. Hash tables are great for large amounts of data, but
you can't beat a red black binary tree for storing less than few
thousand items in memory.

Well, I got the impression that C# and .NET are moving from declarative
programming to intentional programming. In other words, by using LINQ and
later PLINQ, the runtime will decide if a proper datatype would be a simple
array or a red-black-binary-tree.

Static Inheritance - Want to create a new feature that helps people
write better code? Static inheritance. I can write Singleton objects
all day long, and they're built into the language.

I miss those too.

I see a tendency to solve problems that don't need solving. For
instance, the new property syntax (PropName{get;set;}) is elegant,
but a code snippet does that same thing and provides more flexibility
in the end.

But it is very good for productivity and no code bloat.

I use C# and Visual Studio every day, have for years, and that's my 2
cents.

Thanks,
Matt Furnari

- Michael Starberg

 

[Lasse Vågsæther Karlsen]

Well, in Delphi you can have a 'pointer to class'.
That would be like being able to do

ClassType t = SomeClass;
t.InvokeStaticMethod();

.. so polymorhism works for static methods in Delphi and static methods are
indeed virtually inherited.

But you are right for C#.

- Michael Starberg

In Delphi classes have a vtable as well, yes, and this is linked to what
you get back in the code above.

But, again, this breaks down in some cases, specifically where
InvokeStaticMethod needs to call other static methods. In this case it
will still call into methods that were available when the class
InvokeStaticMethods is in was compiled.

In other words, if SomeClass inherits from BaseClass, and BaseClass
defines InvokeStaticMethod as well as OtherStaticMethod. If you in
SomeClass override OtherStaticMethod, I believe calling
InvokeStaticMethod will still use the BaseClass implementation.

I think the overriding part only works through the "of class" type
variable, and not inside the base static class.

 

[Lasse Vågsæther Karlsen]

The principle is alive and kicking. Especially when using LINQ.

Can you write DLINQ that works with both stored procedures and normal
tables without changing the DLINQ query?

In other words, if in my app I write something like:

var data = from s in SOMETHING where ...

can SOMETHING for one database server be a stored procedure, and for
another be a table, or will it be locked to one type or the other?

I ask because in some environments, data separation is done with tables
and sql in a data layer for one type of database, and stored procedures
for another.

The whole point of separating data and code is that you can change the
implementation of one without affecting more than one layer up. In this
case it looks, but I could be wrong, like you've pulled details about
the database implementation directly up into the application.

Well, I got the impression that C# and .NET are moving from declarative
programming to intentional programming. In other words, by using LINQ and
later PLINQ, the runtime will decide if a proper datatype would be a simple
array or a red-black-binary-tree.

Personally I like this, if we also have the power to force one or the other.

 

[Marc Gravell]

can SOMETHING for one database server be a stored procedure, and for

another be a table, or will it be locked to one type or the other?

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