Linq, Functional Vs Declarative programming | The Coffeehouse

vesuvius
Das Glasperlenspiel

I'm still a relative newcomer to .NET and have just had a chance to look at Linq and it appears amazing insofar as not having to use T-SQL and a different IDE. I already see the benefits but am still befuddled as to why some people are against the addition of this to .NET, specifically C#?

Dr Herbie
Horses for courses

vesuvius wrote:
I'm still a relative newcomer to .NET and have just had a chance to look at Linq and it appears amazing insofar as not having to use T-SQL and a different IDE. I already see the benefits but am still befuddled as to why some people are against the addition of this to .NET, specifically C#?

Well, one nice thing about C# is the language's simplicity. Adding Linq (and associated technologies) will add complication.
While these new additions will make life easier in some situations, they don't really add anything that you couldn't already do; they just reduce the number of lines of code that you need.
It seems to go against the KISS philosophy that most programmers like to keep to.

So I guess that's the balance that needs to be struck: complexity of language versus productivity in a business environment.

Herbie

Massif
aim stupidly high, expect to fail often.

Dr Herbie wrote:

So I guess that's the balance that needs to be struck: complexity of language versus productivity in a business environment.

Herbie

Or to restate that: Complexity of language versus simplicity of the program.

I like Linq, and as with all features, if you don't like it... don't use it. As long as it doesn't slow down a program written without it (and there's no reason it should) then feel free to cram whatever features you need into the language.

Features are good... Mmm... Features. (As long as they're consistent, and you don't pay the price for them if you don't use them.)

vesuvius
Das Glasperlenspiel

Dr Herbie wrote:

vesuvius wrote:I'm still a relative newcomer to .NET and have just had a chance to look at Linq and it appears amazing insofar as not having to use T-SQL and a different IDE. I already see the benefits but am still befuddled as to why some people are against the addition of this to .NET, specifically C#?

Well, one nice thing about C# is the language's simplicity. Adding Linq (and associated technologies) will add complication.
While these new additions will make life easier in some situations, they don't really add anything that you couldn't already do; they just reduce the number of lines of code that you need.
It seems to go against the KISS philosophy that most programmers like to keep to.

So I guess that's the balance that needs to be struck: complexity of language versus productivity in a business environment.

Herbie

When I use (or shall I say learn) ASP.NET 2.0, that's not simple! Even though C# is driving things in the code behind. There are several different technologies that you need learn before using ASP.NET. Language purity is meaningless to me because because I've got to use ASP.NET, AJAX, XHTML, SQL, Javascript, XML and soon WPF/E etc. I am at the stage where I see everything as a tool I need to get things done. I'm a newcomer though so cannot know-it-all, but to me I don't need to learn all the T-SQL which is a pain to enter in SQL Managment Studio Express, I can use queries in the C# IDE which saves me so much time. Does anybody still just use C# exclusively (concerned about purity) or can't they just omit the Linq stuff?

littleguru
<3 Seattle

I have my very own opinion why people complain about LINQ. LINQ is functional. It's different, it's new: must be bad! Wink

Functional programming is complexer than imperative (that's what we do right now). You need to understand the algorithm when implementing it in a functional language. Otherwise you won't success. You need to understand function calls and recursive calls (you won't believe how many don't know how that works). You need to look at the problem from a different viewpoint, which most never did and which might therefore be harder for some. It needs a deeper knowledge!

People also don't like new things. I mean as long as it is new libraries nobody cares that much. The most often excuse to not use them is that no customer has them installed. That gives time, time to wait until others (real experts, and people who understand how to do new stuff) put samples to the internet. Samples that are often copied and modified to create own code.

vesuvius wrote:
When I use (or shall I say learn) ASP.NET 2.0, that's not simple!

You are a little bit messing up things here. C# is not .NET! C# is a language. .NET is a library. .NET is the same from VB.NET or any other .NET language. C#, as language, is very simple! C# won't get much complexer with LINQ, btw. - it is an addition, you don't need to use it. Although using it might make the code nicer and run faster on multi core architectures...

Also LINQ is not just a replacement for SQL. SQL is functional, LINQ is functional. That makes it easy to convert a LINQ expression (tree) to a SQL statement! Functional programming is more than just outputing some SQL statements!

vesuvius
Das Glasperlenspiel

littleguru wrote:
You need to understand function calls and recursive calls (you won't believe how many don't know how that works). You need to look at the problem from a different viewpoint, which most never did and which might therefore be harder for some. It needs a deeper knowledge!

It's this deeper knowledge I'm trying to attain. I learned programming in C++ and got "Compos Mentes" with function pointers. The decision I'm struggling with is whether to forget .NET 3.0 presently and Linq, and focus on .NET 2.0 and do things the "traditional way" including database maniplulation, then move on to Linq, or to Get "Orcas" as soon as it's available and head for Linq head first. Looking at .NET 1.0 in ASP.NET for instance, there were no login controls ready made that were included in .NET 2.0. This greatly simplified things when I started ASP.NET 2.0 because I just dragged and dropped the control, set a few permissions/roles and bingo, it's done! The difficulty I get is knowing what to choose to learn.

littleguru
<3 Seattle

vesuvius wrote:
It's this deeper knowledge I'm trying to attain. I learned programming in C++ and got "Compos Mentes" with function pointers. The decision I'm struggling with is whether to forget .NET 3.0 presently and Linq, and focus on .NET 2.0 and do things the "traditional way" including database maniplulation, then move on to Linq, or to Get "Orcas" as soon as it's available and head for Linq head first. Looking at .NET 1.0 in ASP.NET for instance, there were no login controls ready made that were included in .NET 2.0. This greatly simplified things when I started ASP.NET 2.0 because I just dragged and dropped the control, set a few permissions/roles and bingo, it's done! The difficulty I get is knowing what to choose to learn.

.NET 3.0 is just additional libraries to .NET 2.0 - the .NET 2.0 classes didn't change. They just added new things. If you look the transition from .NET 1.1 to 2.0 you see that .NET classes changed, which didn't in .NET 3.0.

Question is, if you go with .NET 4.0 and LINQ. It depents. If you need to do work that needs to ship before 2008 you should go with .NET 3.0 (which is .NET 2.0 + WPF + WCF + WF). You can always install Orcas in a virtual pc and do stuff there - just for fun. That's what I do.

If you master .NET 3.0, you won't get a lot of problems in .NET 4.0 - same if you master .NET 2.0 Wink

staceyw
Before C# there was darkness...

Dr Herbie wrote:

vesuvius wrote: I'm still a relative newcomer to .NET and have just had a chance to look at Linq and it appears amazing insofar as not having to use T-SQL and a different IDE. I already see the benefits but am still befuddled as to why some people are against the addition of this to .NET, specifically C#?

Well, one nice thing about C# is the language's simplicity. Adding Linq (and associated technologies) will add complication.
While these new additions will make life easier in some situations, they don't really add anything that you couldn't already do; they just reduce the number of lines of code that you need.
It seems to go against the KISS philosophy that most programmers like to keep to.

So I guess that's the balance that needs to be struck: complexity of language versus productivity in a business environment.

Herbie

Lots of lines. You could just use the library or another library, but to get the language integration, var, and compile time checks, you would need it in the compiler and vs support. IMO, the feature would be a lot less useful without the integration. Plus it is optional. So I don't see how it effects a non-user of the feature.

Dr Herbie
Horses for courses

staceyw wrote:

Dr Herbie wrote:

vesuvius wrote: I'm still a relative newcomer to .NET and have just had a chance to look at Linq and it appears amazing insofar as not having to use T-SQL and a different IDE. I already see the benefits but am still befuddled as to why some people are against the addition of this to .NET, specifically C#?

Well, one nice thing about C# is the language's simplicity. Adding Linq (and associated technologies) will add complication.
While these new additions will make life easier in some situations, they don't really add anything that you couldn't already do; they just reduce the number of lines of code that you need.
It seems to go against the KISS philosophy that most programmers like to keep to.

So I guess that's the balance that needs to be struck: complexity of language versus productivity in a business environment.

Herbie

Lots of lines. You could just use the library or another library, but to get the language integration, var, and compile time checks, you would need it in the compiler and vs support. IMO, the feature would be a lot less useful without the integration. Plus it is optional. So I don't see how it effects a non-user of the feature.

I actually think Linq itself will be useful for the types of application I currently write, but the use of Lambda expression to generate hard-to-track-down code could impact those of us that work on multiple projects with several other developers, where opting out is not necessarily possible.
I remember the pain of C++ macros when in the hands of idiots. Lambda expression carry the same risk.

I'm reserving judgement until I get my hands on this technology. With a bit of luck the IDE will make it easy to find the code for a Lambda expression and remove some of the pain.

Herbie

littleguru
<3 Seattle

Dr Herbie wrote:
I actually think Linq itself will be useful for the types of application I currently write, but the use of Lambda expression to generate hard-to-track-down code could impact those of us that work on multiple projects with several other developers, where opting out is not necessarily possible.
I remember the pain of C++ macros when in the hands of idiots. Lambda expression carry the same risk.

Lambda expressions are just functions... If they are debuggable, they behave like normal function calls. Makros instead were injected in code and makros of makros of makros made the problems with makros arrise. You never knew what the code that was feed into the compiler looked like.

Dr Herbie wrote:
I'm reserving judgement until I get my hands on this technology. With a bit of luck the IDE will make it easy to find the code for a Lambda expression and remove some of the pain.

You need to write the code on your own - the one that is executed in the end. - It's not magic that happens there! LINQ for example uses iterators to get the elements from lists (for example List<T>).

I don't understand why and how you compare normal functions with makros?

JChung2006

To all those folks worried about adding LINQ and functional programming constructs to C#, they aren't that complicated. Suck it up and learn it. Or be labeled a Mort that likes curly braces.