Amazing LINQ for .Net

[Frans Bouma [C# MVP]]

Yep. AFAIK it's really only needed for inline construction of
anonymous types. The rest is mere convenience.

So in real life scenario's where in most cases teh GUI developers have
to call BL methods, it's not that useful... why even bother adding it..

See, the thing is that people like me think the var version is more
readable, not less so. You seem to think that code always gets more
readable as it gets longer. I think that the most readable code is
the shortest code that still conveys the intended meaning.

Readable code to me is code which is understandable from the text it's
written in, thus doesn't need help from tools to get understood. A type
which is constructed by the compiler under the hood doesn't end up in
the text, at least that's how I see it.

Well, that's just a ridiculous statement. C# started out as a Java
clone with some C features, and its design philosophy was always
similar to Python: if a feature is useful, adopt it! C# is not a
single-minded reseach language that must be kept "pure".

*sigh*. My point is that C# is an OO, single-inheritance, imperative
language. If you add constructs of other paradigms to it, you get a mix
of paradigms, which blur the intentional purpose of the language. I
mean: why even use types at all, if Ruby apparantly is so great?

You might as well say "if people want OOP they should use Smalltalk"
as an argument to keep OOP out of all existing procedural languages.
And you could have made the same complaint when generics were
introduced: "If people want generics they should use C++"!

No, because that doesn't have anything to do with mixing paradigms.

Functional programming is just as valid as the two other paradigms,
procedural and object-oriented programming. It's just another tool in
a toolbox. The fact that FP used to be limited to research languages
is a historical coincidence, not some holy law of design.

Again, I didn't say anything about the validity of a different
paradigm, I just think it's bad to mix paradigms in a language.

FB

--

 

[Cor Ligthert [MVP]]

Frans,

About SQL just because you take this sidestep.

In my opinion is the repeated 3 dimensional table approach that once is
taken a very limited approach.

Genealogie is a very good chalenge to use on a database and than not our
current culture, however cultures where one person can be a father, a
brother, a son, a uncle, a newphew, a male etc from the same woman.. Try it
on our current approaches. In my opinion can any language only be created
when this problem is fixed (without creating extra link tables).

If you are interested about my opinion about LINQ, why don't they do it in
common Fries to make it for even more people difficult. (Although everything
is in my opinion better than SQL).

I agree with you what I have read in your messages in this message thread,
C# has to be a very clear as much as possible on mathimetical symbols based
language. Otherwise just use VB 2002/3/5.

Just my thought,

Cor

 

[Wavemaker]

"Frans Bouma [C# MVP]" wrote:

Well, that's just a ridiculous statement. C# started out as a Java
clone with some C features, and its design philosophy was always
similar to Python: if a feature is useful, adopt it! C# is not a
single-minded reseach language that must be kept "pure".

*sigh*. My point is that C# is an OO, single-inheritance, imperative
language. If you add constructs of other paradigms to it, you get a
mix of paradigms, which blur the intentional purpose of the language.
I mean: why even use types at all, if Ruby apparantly is so great?

I won't comment on the merits of C# v3.0; I'm still becoming familiar
with 2.0. I think, however, that traditional OO programming can benefit
from approaches used in functional languages. A few years ago, Thomas
Kuhne wrote a book describing several design patterns that incorporate
functional programming concepts into OOP.

http://www.mm.informatik.tu-darmstadt.de/~kuehne/fps/

My opinion is that this is pretty neat stuff. I think a melding of
these two approaches represents an evolution in programming. So I see
C#'s new features that help facilitate a more functional approach as
being a step forward; I especially like closures. Of course, features
shouldn't be added to a language lightly, and I trust a lot of thought
goes into each feature addition.

At any rate, I just wanted to chime in and at least suggest that using
aspects of functional programming within a traditional OO context can be
a good thing.