Re: Some notes on C# 3.0 (was RE: [DOTNET-CX] How to overload == for System.Double)

>So, certainly the C# 3.0 features are for a big part "syntactical sugar"

For the most part, I agree.  My comments were mostly about extension
methods; which aren't "sugar".  The other sugar in 3.0 I haven't really
commented on.  I think future fxcop rules relating to C# 3.0 will speak
volumes.

>Well, simplicity becomes apparent even in the (at first sight frightening)
>LINQ world when you compare it to all of the rabbits you have to pull out
of
>your magic .NET (or Java or C++ or ...) programmer's hat

Again, I was only commenting on extension methods.  There's nothing in 2.0
that allows you to do what extension methods allow you to do in 3.0.  That
was on purpose in C# 1.x and 2.0.  Research showed that nonmember
functions caused confusion, made code hard to maintain, and lead to
quality issues, so they didn't put that into C# (mostly, I believe,
because of the more object-oriented aspect of C#, nonmember functions are
global functions).  The effort and focus to make a more maintainable
language seems to have gone out the window.  If flexibility has become
more important than maintainability and/or object-orientation (in the
aspect-oriented or law of Demeter sense) then there really was no need to
branch from C++ to create C#.  Programmers already had choice not to use
all the same things in C++ that didn't make it into C#; but that wasn't
the point.  C# was changed essentially save programmers from themselves,
it allowed programmers to focus on object-oriented implementation and
avoid getting caught up in too many language details and interactions.
Reverting back to problematic features of C++ (no matter what you call the
feature) is really defeating the purpose and putting C# in a track that it
was intended to avoid.

And there's many issues with extension methods that are simply not
specified yet; like will "sealed" be diluted by allowing extension methods
to extend sealed classes ("extension methods" would be somewhat neutered
if they didn't), will extension methods support operators (introducing
nonmember operator overloding purposly avoided in the original design of
C#), etc.

>today's data querying APIs. As Anders has stated many times already, where
>do you still find any trace of the original simplicity (although implying
>limitations as well) of dBase, Reflex, FoxPro? Somewhere in the dark ages
of
>programming, data and programming were so close together that we've said
>some way or another it was too simple to be true, hence all of the (ever
>becoming more complicated) data access APIs out there. Consider the
>following:
>
>using (SqlConnection conn = new SqlConnection(dsn))
>{
>   SqlCommand cmd = new SqlCommand(conn, "SELECT Name FROM Customers WHERE
>Age > @Age");
>   cmd.Parameters.Add("@Age", SqlDbType.Int);
>   cmd.Parameters["@Age"].Value = age;
>   conn.Open();
>   SqlDataReader reader = cmd.ExecuteReader();
>   while (reader.Read())
>   { ... }
>}
>

I'm not saying the data query syntax in LINQ is neither good nor bad.
Clearly the existing ADO.NET functionality does not enforce type-safety,
and for legacy reasons never will.  Improving type-safety is always good
in my books.  But, the problems of the existing type-UNsaftey of ADO.NET
is really just a legacy issue inherited from ADO (and even ODBC).  There
were improvements in a more object/aspect-oriented API for data queries;
but, to say that LINQ is required to make data queries type-safe in .NET
is wrong.  The inherent problems of declaring a command object from an
nebulous SQL statement where never really addressed in ADO.NET.  ADO
allowed creating a stored procedure command (as a checked/generated SQL
statement) that wasn't as type-unsafe; but nothing was done in the same
way to separate the components of a SQL statement into properties or
methods.  And your example of not using the LINQ syntax and using
classes/methods/properties exemplifies that it was doable without creating
LINQ, without extending the language, without diluting (subjective) the
language.

Is progression from where we are with inline data query (or lack thereof)
to concepts like LINQ good?  Indeed.  Should it be the cornerstone of a
single release of a product, I don't believe so.  Keep in mind, when LINQ
is released there will be countless data-based projects being worked on
with a specific release schedule and resource loading.  By the time these
projects are able to embrace LINQ and upgrade to a new compiler/IDE and
LINQ becomes mainstream is years from now.  All the while there are
pressing issues that are seriously hindering programmers abilities to
develop with Visual Studio 2005 effectively and efficiently; none of which
get the press/spin that C# and LINQ get.  e.g. will I still have to
terminate Visual Studio because
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
FeedbackID=105195 ,
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
FeedbackID=90946 or
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
FeedbackID=234324 don't have the resources allocated to it that LINQ does?

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com