|
I'd really enjoy hearing your thoughts on the down-side of 'var. thanks, Bill
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. » Alan Kay's clarification on what he meant by the term "Object" in "Object-Oriented Programming."
|
|
|
|
|
I would agree.
Started with COBOL/FORTRAN, moved to Pascal and assembler, then to C and Assembler, and C++ and assembler. Then moved to C# five or six years ago.
It's a coherent, well-thought-out language, that works very, very well indeed. My only criticism is that it's become easier to abuse it: var in particular, along with ArrayList and it's unpleasant ilk still remaining in the framework years after they should have been put to sleep as a mercy killing...along with teachers who think goto is something they should start off by teaching.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I'd really enjoy hearing your thoughts on the down-side of 'var. thanks, Bill
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. » Alan Kay's clarification on what he meant by the term "Object" in "Object-Oriented Programming."
|
|
|
|
|
var is necessary - it's hard to see how Linq could work without it - and yes, it's still strongly typed. But...it's lazy, and it promotes code that is harder to read - for the sake of saving a couple of seconds when you write the code.
For example, what is this code doing:
foreach (var item in myList)
{
...
} What type is item? I don't know - so I have to go elsewhere, find the definition of myList and work it out from there.
And then I find that myList is declared as
var myList = myUserControlInADifferentAssembly.GetAll(userInput); Which means I have to hunt that down as well.
If instead the original coder had spent a couple of seconds writing:
foreach (UserProfile item in myList)
{
...
} My concentration wouldn't be broken and I could keep on with the flow of the code.
I've seen people write this:
var i = 0; Which is spectacularly pointless!
There is also the fun that if a var is an IEnumerable returned by Linq methods, it isn't obvious that using it twice in successive lines of code will re-evaluate the whole enumerable again! At least if you have to write the type in full, you get a clue that probably what you should be doing is converting it to a List to evaluate the IEnumerable! You don't get that from var because "the system just handles it for you" - in the same way that untyped Dim works in VB, and that always comes back to bite people!
For example:
private string Showme(string s)
{
Console.WriteLine(s);
return s;
}
If you do this:
List<string> list = new List<string>() { "hello", "there", "Paul" };
var enumerable = list.Where(s => s != "c").Select(s => Showme(s));
Console.WriteLine("111111");
string s1 = string.Join(";", enumerable);
Console.WriteLine("222222");
string s2 = string.Join(";", enumerable);
Console.WriteLine("333333");
It isn't obvious that you get this:
111111
hello
there
Paul
222222
hello
there
Paul
333333
But as a List it is evaluated once:
List<string> list = new List<string>() { "hello", "there", "Paul" };
var enumerable = list.Where(s => s != "c").Select(s => Showme(s)).ToList();
Console.WriteLine("111111");
string s1 = string.Join(";", enumerable);
Console.WriteLine("222222");
string s2 = string.Join(";", enumerable);
Console.WriteLine("333333");
hello
there
Paul
111111
222222
333333 And spelling it out makes that clearer:
List<string> list = new List<string>() { "hello", "there", "Paul" };
List<string> enumerable = list.Where(s => s != "c").Select(s => Showme(s)).ToList();
Console.WriteLine("111111");
string s1 = string.Join(";", enumerable);
Console.WriteLine("222222");
string s2 = string.Join(";", enumerable);
Console.WriteLine("333333");
To my mind, it promotes laziness, which leads to lazy, unthinking code which is harder to maintain.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Say what you like about Microsoft, but they were able to get the smartest guys in the industry in the same room at the same time, over an extended period of time, and leave them to it. The result was C# and I agree, it's bloody brilliant!
|
|
|
|
|
In violent agreement! (Although I must confess I'm ignorant about F#.)
/ravi
|
|
|
|
|
To each their own. I frankly never liked C# - feels like VB sprinkled with semicolons and curly braces
|
|
|
|
|
I thought that way for a while too, until I had to use it. I wouldn't use it for apps that require heavy computation, but for business apps its nice and much much better than VB.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: much much better than VB Why, I converted to c# about 6 years ago and would not like to go back but that is mainly comfort and familiarity.
When I was doing VB I though the same thing about c#, imagine a language that is case sensitive bleh.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Well, to be fair, my comparison is really more about the bias I've built up against the typical VB crowd than the language itself. My first language was QBasic. I did a lot of classic VB. Never really had to use VB.NET all too much thankfully. It's a good tool for what it's intended for.
But the main reason would be I just don't like the mentality of the typical VBer, which is lazy when it comes to learning how to effectively program. Not all VB devs are like that of course, but you get the idea. I have the same issue with FoxPro devs.
I do think C#'s syntax is much cleaner and more elegant though. Which can lead to less typing errors. Which would be enough of a reason for me to choose C# over VB.NET, regardless of the typical VB crowd.
Jeremy Falcon
|
|
|
|
|
I think VBA is where you can lay the most blame, power users who work up through the VBA/Access route and keep going. No real discipline and no training. I started out that way and can understand the mind set, I do miss the formal training and grounding most really good devs must have.
I started with macros in the late 80s then went down the path of Superbase till it got completely marginalised, spent a couple of years doing Turbo Pascal and then moved to VB. I would not willingly go back to VB.net but only for comfort and familiarity not because I dislike the language.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: I think VBA is where you can lay the most blame, power users who work up through the VBA/Access route and keep going. No real discipline and no training. I started out that way and can understand the mind set, I do miss the formal training and grounding most really good devs must have.
Oh man don't get me started on people using VBA inside Access to make a "real program". Totally get your point. But like you said, a good dev never stops learning and undergoes a lot of training about how things really work.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I wouldn't use it for apps that require heavy computation
I ended up re-writing a very computationally heavy app in C# from C++ and was quite surprised that the C# version performed as well, if not better, than the C++ version. Now, granted, I was using STL heavily in C++ and in the C# version, I optimized my data structures so I wasn't manipulating vectors and queues all over the place. Which just goes to show, that performance is less a function of the language than it is of the skill of the programmer.
It would be interested to see how the code would fare in C++ now with the new data structures, but I'm a bit wary of STL's performance.
Marc
|
|
|
|
|
What you're saying is totally true, but I'd still wager an expert at C/C++/ASM could still write code to outperform most things in .NET. Of course, that's not practical for every last application as they'd have to be leery of frameworks used, if any, such as STL.
I mean I can write a slow program in C easy as pie, and probably make something run better in classic VB if I really wanted to. Doesn't mean classic VB is the way to go for real time code. It doesn't mean VB is quicker. It means I'd know VB better in that instance.
All that being said, I sure don't enjoy the slow compile times for C++. Especially with some of newer compiler tricks with C++ 11, such as generics. But it's still pretty zippy once compiled, and C/C++ will always be my go-to language for non-business apps.
Jeremy Falcon
|
|
|
|
|
I started in BASIC back in the 80's, and made my way through C, Perl, Java, and some dabbling in TCL and Python... But I haven't found anything better than C#.
Granted, Visual Studio has something to do with that... Haven't found a better IDE anywhere. The others I've tried all feel clumsy and weak. Well, I mean, Unity is several kinds of awesome, but that's a little different.
Now if only they would switch Excel's scripting interface from VBA to .NET, I could stop hating MS Office too.
|
|
|
|
|
Ian Shlasko wrote: Granted, Visual Studio has something to do with that... Haven't found a better IDE anywhere.
And I'm not an MS fanboy at all, but I recognize a good piece of software when I see it.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: And I'm not an MS fanboy at all, but I recognize a good piece of software when I see it. Exactly... I generally dislike uSoft, but Visual Studio is just a work of art...
And honestly, so is Excel, as long as people use it as a spreadsheet/calculator and not an application platform...
|
|
|
|
|
Definitely - Excel is a superb piece of work. It's little touches, like CTRL+; inserts today's date that tells you is was designed by people who actually throw numbers around on a regular basis.
Mind you, that comes with a price: I have seen some total abortions done in Excel formulas (not even VBA). One guy I used to work for ran his entire stock control, estimating and build list production from a massive Excel spreadsheet. Damn thing took 15 minutes to load in the morning, and data entry was painful. Worked though...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Ian Shlasko wrote: Granted, Visual Studio has something to do with that... Haven't found a better IDE anywhere.
I will have to agree with that... I'm currently using Eclipse and it pisses me off on a regular basis.
Ian Shlasko wrote: Unity is several kinds of awesome
As in Ubuntu's Unity? ...there has never been a slower interface ever developed for Linux! I actually stopped using Ubuntu because of Unity, now I use Mint (grant it, it's still based on Ubuntu but with a better interface).
|
|
|
|
|
No no no no....
Unity 3D... The game development IDE...
|
|
|
|
|
Was wondering about that... it didn't make sense but I've also never heard of Unity 3D.
|
|
|
|
|
I haven't actually managed to make anything playable with it, but that's because I aimed a little too high... Like... Alpha Centauri...
But I wrote a hex-map model and generator in C#/Unity, and it worked really well... It makes the graphical side really easy.
One of these days I'll go back to that... But once I started planning out the AI, I realized I had designed it so complicated that it'd make Black and White look like Tetris by comparison.
|
|
|
|
|
Ian Shlasko wrote: Haven't found a better IDE anywhere
The only IDE that comes close is the one made by JetBrains, which I use a lot for Ruby and Java stuff.
Marc
|
|
|
|
|
Marc Clifton wrote: frankly, C# is the most elegant and well crafted language I've ever worked with Yes, it is.
Even though I still miss a QUICK compiler like Delphi had (and sometimes a linker), and aw, the joy of compiling your own VCL. Being able to allocate and deallocate by hand also seemed to be better than having the memory fill up until some lowpriority thread halts your app and starts cleaning up - even though NET4 does a good job at it, I'd rather still be doing it myself.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I agree - but it does mean it's a lot harder to get leaky programs. Not impossible, but a lot harder. You remember what it was like before C# - morons not releasing memory until the whole PC judders to a halt...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|