Re: I freaking HATE var!!

Nicholas,

Bravo. Yours is the kind of response I highly admire and respect. You don't patronize nor insult me. You examine what I have to say, not who I am or how well I'm doing (although the "welcome to the world of software development" comment was a little presumptuous of a lack of experience with the industry, but I'll take it tongue-in-cheek). And your response went well beyond the level of appreciable merit than my light-hearted melodrama (which was sincere nonetheless).

I'll take your thoughts to heart.

Thanks,
Jon



"Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:OAjdHOqfHHA.2432@xxxxxxxxxxxxxxxxxxxxxxx
Jon,

See inline:

a) our team would be forced to withhold ourselves from taking advantage of other 3.0 features than what var uses,

No, you won't. You can eschew var, as well as extension methods, and the syntax that translates queries from the C# 3.0 language and actually chain the static method calls yourself, passing anonymous delegates and known types as the return. Granted, it is going to be a ROYAL PITA but it ^IS^ possible.

b) I personally, and the other engineers on our team, would be presented with an unpredicted and undesirable dillemma of whether to offer engineering services, whether to the public or to an employer, as a C# 2.0 purist or as a C# 3.0 cutting edge Microsoftie who drinks all the kool aid that gushes out of the fountains of Redmond and participates in the very bandwagon that will ultimately make a mess of the output of C# coders everywhere, and

Well, welcome to the wonderful world of software engineering. "It ain't just static" should be the motto. That's just the nature of the beast. There are ALWAYS going to be new technologies that are coming out and you, being a professional in the field, will have to decide on how you want to leverage those technologies in what you do to provide for how you make a living. You aren't the first person to have to face this, and you won't be the last.

c) put in context, the point was, add us to the list of people who don't subscribe to the appreciation of 'var'. "Don't like it, don't use it," phooey, what are you doing here? I'm here to discuss this sort of stuff--even if in a monologuish soapbox stance. :p

I was trying to respond to what was a predominantly rhetoric-filled post. Granted, you have some very valid, and very good points, some of which I agree with (VS being able to generate known types) and some which I don't agree with (var is evil). However, the rhetoric gets in the way

However, in order to get projections to work, there is no way around var.

Yes. There is. Auto-generate the inferred type information directly in the code rather than at compile time. Actually, you and others talk as if projections were a necessity in themselves. What I'm getting at is, if 'var' is the necessity of a new feature, my hatred of 'var' is greater than that feature. I loved the LINQ idea, but that was when I heard about C-Omega as C#-based language, not as C# v3, supposed successor to the language I work with everyday.

Doing work with SQL, you realize that projections become necessary VERY quickly. Ok, I don't want to be absolute. COULD you get away without having them, yes, absolutely, but again, ROYAL PITA. I'm not against doing something that takes a lot of work because it is the right thing to do, but LINQ here is trying to bridge that gap between the relational and procedural models. The relational model (as represented by the implementation of the SQL standard across many database products) depends heavily on projections. It's something that they probably feel they couldn't leave out.

Now, I agree, I do hope, and expect, quite frankly, that VS.NET will be able to take your anonymous types and make known types. If it has that facility, then you can still code in your 2.0 style, and pass back IEnumerable<known type> as the return values of the calls to the LINQ library functions (you might have to cave and use the assignment feature in C# 3.0 though).

However, this is what I meant by you shouldn't depend on tools to fill in the gap where the language fails. You can't expect that everyone will have VS.NET installed. Hell, I've written code in notepad before, others write code in Eclipse, someone is writing C# code in Emacs as well. Those tools can not be depended on to support the feature.

Not that bad? I spend half my coding time already pulling my hair out looking at other people's lazily written or generated code--XML node or Control lookups that should have been referenced by name or ID are instead referenced by index, referenced ASP.NET control names plopped in with namespace of "uc1" rather than origin, variable names as numbered type names rather than purpose, little "thorn in the side" things that make my job one minor bit less enjoyable. And now 'var'? Ugh.

You see the potential for abuse here because of the ways that other technologies have been abused in the past by people that don't have an understanding of those technologies.

I get that, completely. I respect it tremendously.

There are always going to be people who don't know what the best way to do things are. The ones that do it out of ignorance which they choose to perpetuate are never going to advance in this field, while the ones that are not ignorant are going to learn and perpetuate (hopefully) best practices.

If the case where that as a society we restricted all growth and innovation because of the potential for abuse of those innovations, then we would still be living in caves without fire.

So this leads to what I think you and your team should do in respects to C# 3.0. Don't give up on it, and certainly don't throw it away. You are throwing away a HUGE amount of benefit for one simple language feature which you don't like, don't have to use, and can get around and still gain the benefits of.

For example, say you had your class:

public class Customer
{
public string Name;
public int Age;
public string Address;
}

And you wanted a query that returns just the name and age. Well, hopefully the tooling will support it (from anonymous types), and if it doesn't, you can always code by hand, the following:

// Ok, the naming here is abhorrent, but that's not the point.
public class PartialCustomer_Name_Age
{
public string Name;
public int Age
}

And then you can perform your query on an IEnumerable<Customer> implementation (like an array) like this:

IEnumerable<PartialCustomer_Name_Age> query =
from c in customers
select new PartialCustomer_Name_Age(){ Name = c.Name, Age = c.Age };

No var at all!

LOL .. well we differ here :) I use the weekends to zoom out and ask myself questions like what the heck am I doing it all for.

Money? You like it? The women?

While I am making light of it, I do hate the idea of seeing someone in this profession asking these questions because of something they don't like, when there is so much more about this field which can be enjoyed.

Kind of like anything else. =) Enjoy the weekend.

--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx


.

Relevant Pages

  • Re: I freaking HATE var!!
    ... other 3.0 features than what var uses, ... the syntax that translates queries from the C# 3.0 language and actually ... There are ALWAYS going to be new technologies that are coming out and you, ... 'var' is the necessity of a new feature, my hatred of 'var' is greater ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: I freaking HATE var!!
    ... of other 3.0 features than what var uses, ... the syntax that translates queries from the C# 3.0 language and actually ... There are ALWAYS going to be new technologies that are coming out ... greater than that feature. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: best way to load arrays with large amounts of data?
    ... var a = new Array; ... Reading files or rather accessing resources is not a feature of the ... language, but a feature of an API that can be used by the language. ...
    (comp.lang.javascript)
  • Re: Yet Another Newbie Question
    ... client-side script support is not a viable option as that feature can ... Arrays in ECMAScript implementations are of dynamic length by nature. ... var e_cart_descr; ... Even if the declarations above were omitted, that does not make sense as ...
    (comp.lang.javascript)
  • Re: Javascript problems from a lightweight - xmlhttprequest and html fragments
    ... req = new XMLHttpRequest; ... var returnedText; ... but to do a feature test before you use the feature. ... iff you use them within the HTML `script' element. ...
    (comp.lang.javascript)