Overcomplication to use the latest features?

Question

I seem to see a number of people who seem to overcomplicate things both on here and even when I'm coding. I'm wondering if people have a facination with the latest features and attempt to incorporate these into their coding to help them learn more or use the 'funky' latest features at the expense of performance or complexity.

I think a classic example is the following question: http://stackoverflow.com/questions/682615/how-can-i-get-every-nth-item-from-a-listt

Linq and lambda expressions seem to be a favourite, and sometimes I find myself trying to write code using these approaches, when it may be best to stick to the simple itterations and conditional statements. I've also recently read that Linq actually performs quite slowly in comparison to the more traditional methods, so become more aware that it's all the rave at the moment.

I'm curious as to what other people think?

Answer 1

I agree with you.

On the Linq point, I know of one real world example where Linq to SQL has been removed in favour of standard stored procedures, due to performance reasons.

On the flip side of this, there may be functionality which would make your job more efficient and productive, which you would never know about if you didn't try new approaches.

So experimentation with new methods does definately have its place.

Answer 2

Personally I find that LINQ to objects removes a lot of complexity due to its declarative nature. I write what I need and the compiler figures out how to do it. I like that a lot.

Lambdas may take some getting use to, but I prefer them over delegates because they are less verbose.

Answer 3

The newest features do solve some old problems in interesting ways. But we should remember KISS. If you can solve a problem in a simple way, make it simple. Leave the new features to solve the hard problems.

Answer 4

I agree.

Programmers like to have stuffed toolboxes, and like using their shiniest tools even when the plain old hammer is a better choice.

Answer 5

The simple rule still applies. Your code should document it self. If it doesn't then one of two things happen. Either it is a complex problem trying to be solved or the code is overly complicated.

I find that most of the comments I write in code are not some much how I am doing something but more of why I am doing something. The code it self is pretty clear as to what is doing but it may not always be clear as to the why.

Answer 6

Strive to make your code as clear as possible. To me this often means using Linq, but it can mean using a loop. I agree that is the clearest way to find the Nth number.

If you are using C# in the first place, you probably don't need to worry about small optimizations, so the speed of Linq will usually not be a problem.

Answer 7

You're asking two separate questions. Do we overcomplicate things by using new features, and does it make our code slow.

For the former, no, not usually. Using a plain old for-loop is overcomplicating things. LINQ (as a common example) is simpler, more readable and expresses my intent better.

Second, about performance: Measure it. If it becomes a problem, fix it. If it doesn't, stick with the simple, clean, readable code.

Don't avoid making your code cleaner out of fear of a performance hit. Measure it and see if it's a problem.

Answer 8

Knowing when (and when not) to use new features is part of the community acceptance process. The fact that it's shiny and new is going to make people want to work them into their development scenarios. Adopting any of these features (especially the ones you listed) requires at least some change in the way you think in code, so it's a matter of developing the more mature thought process.

That being said, it's just as likely that you'll find a performance difference between LINQ2SQL and stored procedures, as LINQ2SQL is dynamically generated SQL. I wouldn't suspect that there is much performance difference between LINQ and traditional enumeration and checking (though I haven't tried).

Answer 9

I think that I could write just about anything in C without need for fancy-pants garbage collection, lambdas and all the other neat stuff that the "cool kids" have with their shiny new-fangled C# language and its enormous library of functions.

But, there is a lot of value in the language, a lot of value in experimenting with (new) language features and merit in stepping outside the traditional methods that you are already familiar with and would likely default to using. Sometimes, there's a better way and you likely won't know that unless you try.

I looked at the different solutions proposed to the problem. I might not have gravitated to the LINQ one initially, mostly because it is still new in my mind and it would take me longer to figure out the syntax than the tried-and-true approach that I've known since the early 1980's. Doesn't mean it is worse or better, just different.

Fast forward six months from now and I might have approached the problem differently and seen the LINQ solution immediately and used it instead.

Answer 10

I don't agree with the premise of the question. Neither LINQ nor lambda expressions are complex. I'm not denying that you have to learn them in order to use them, but they aren't complex.

And by the way, simply reading about possible performance issues and giving LINQ a demerit is one of the more extreme cases of premature optimization.

Answer 11

Linq is high-level in nature. It is more abstract, and better able to express problems and solutions, than straight procedural code.

In the particular example you mention, the best solution would look like

var myNewList = myList.EveryNth(k).ToList();

or

foreach(var el in myList.EveryNth(k)) {
    //do stuff
}

accompanied by a proper implementation of EveryNth.

The solution you propose, "iterations and conditionals", is actually less straightforward than the expression myList.EveryNth(k), especially as the problem gets more complicated than simply "every nth element."

Answer 12

Just to mention: Linq and lambda may be new to C#. The concepts behind are much older than C#. Personally I'm very happy that they have found their way into C#. I don't use them because they are new or "funky" but because I like them since my first steps in SML and I heavily missed them in the "mainstream" languages.

As for simplicity: If one's not used to functional style, it may seem more complicated to understand Linq/Lambda expressions. But I find

var result = from var c in objects where c.SomePredicate select c.Name;

much simpler than

List<string> result = new List<string>;
foreach (MyObject c in objects)
  if (c.SomePredicate)
    result.Add(c);

If performance is a problem of course Linq may not be the best solution. But the selection of technology is always a tradeof between simplicity/readability and performance (you could always argue for assembler after all). And I think that for many problems, performance is not that critical. Besides that, Linq doesn't perform that bad after all ...

Answer 13

I agree. People tend to complicate. YAGNI people! "Let's make it super duper flexible and reusable, with lots of design patterns, with the S framework for DI, and the M framework for the Presentation layer, bla di bla". In the end most of the applications just don't need the extensibility provided. SOME do but most of them are just a waste of over engineering.

Answer 14

I think it's just the way people work. When a shiny new hammer comes out we try hitting everything with it, whether it needs to be hit with a hammer or not. After a while of overuse we learn when's the best place to use the new thing and then we use it less. But we still need to go through that period of applying it to everything to figure out what those best times are.

An older example of this is java applets. When they first came out every website had one, regardless of use. Now they're used sparingly because alot of the time they're overkill.

Anyway, that's my 2c.

Answer 15

Like many programmers, I read about new tools and technologies, but only get time to use a percentage of them. It can only be a good thing to learn new techniques; if you don't, you stagnate.

Once you have this knowledge, you need to ask a second question: when is it appropriate to use this technique?

Answer 16

I'm all for developers experimenting with the latest and greatest tools. The problem I find is that many career developers would rather use their bosses time to experiment with these features on real world apps than simply building prototypes on their own time to find their way through the language / features.

As a result, a lot of really bad (read: inexperienced) code ends up in production that probably never should have made it past peer review.