|
I agree- and even more so when I returnto something I wrote > 1 year ago in C# I can still work out what the code does and why, and am back up and running pretty quickly.
I do sometimes wish great swathes of it were marked as depreciated though - people who don't use typed (generic) lists and pass DataSets around between methods need nudging towards a better path...including me.
|
|
|
|
|
Sorry, DataSets and DataTables need to go - they are the spawn of Beelzebub himself.
|
|
|
|
|
Pete O'Hanlon wrote: DataSets and DataTables need to go - they are the spawn of Beelzebub himself.
I find them (DataTables more so) quite convenient, though I can definitely imagine both simpler and more flexible approaches. As long as we're not treading into dreaded O-R-M territory.
Marc
|
|
|
|
|
Friends don't let friends ORM.
|
|
|
|
|
Pete O'Hanlon wrote: DataSets and DataTables
Oh I like it when you talk dirty Pete.
Jeremy Falcon
|
|
|
|
|
I've got them blighting up one of my winform apps. The worst bit is there's not even a real DB involved.
They were the easiest way to get something with databinding to a grid working (at this point I don't recall exactly what); and in prototype the version of the backend that read/processed the xml data files with tables was moderately faster and had significantly less total code than the one that read it all into classes and handled it that way. After the testers finished finding every edge case I'd overlooked when playing with it the latter was definitely no longer the case and the code was a massive cluster elephant as well.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Ugh. Is it really that good?
I've fiddlyfarted with it here and there, but I've never done any serious work in it.
I've been a C++ guy since the 80s (with lots of everything in the interim.)
Maybe it's time to suck it up and take a serious bite out of it.
|
|
|
|
|
The heavily nerfed templates in C# will probably annoy you.
They annoy me, and I don't even work with C++ that much.
|
|
|
|
|
I'm on this same boat... I've been C/C++ for so long it's hard to see too much justification of why to change something that's worked so well for so long. I have however, heard good things about C#... and it'll be even more interesting once MS makes their .NET framework open source and it spreads to other platforms more easily.
As a side note, I've also recently started working in Python and can definitely see why people like it. Can easily be made as fast as C++ and easy to work with like Matlab scripts.
|
|
|
|
|
Python's a slick little language.
I use perl day to day. It's tough to justify C++ for these quick hit scripts I've fallen in to writing.
God how I miss real programming.
|
|
|
|
|
mikepwilson wrote: I use perl day to day. It's tough to justify C++ for these quick hit scripts I've fallen in to writing.
In my last job I used perl for quick scripts too. It worked out well...
|
|
|
|
|
I love it. It's the right tool for a great many jobs.
The fact that I can just develop and deploy as fast as I can is a godsend.
|
|
|
|
|
Albert Holguin wrote: Python and can definitely see why people like it. Can easily be made as fast as
C++ and easy to work with like Matlab scripts.
I use Python a lot these days and generally like it, but it is really impossible to make it even remotely as fast as C++. Even Java code is blazingly fast compared to Python.
|
|
|
|
|
Nemanja Trifunovic wrote: but it is really impossible to make it even remotely as fast as C++
What!? ...are you kidding? ...it's easy to make it that fast ...we use it on real-time systems.
|
|
|
|
|
Python? It is the slowest language I've ever worked with. And the benchmarks agree[^]: Python is up to 100 times slower than C++ and consumes up to four times more memory.
|
|
|
|
|
Perhaps you've never used it... the interpreter is C++... so you can easily code C++ libraries and pull them into Python. Saying it's way slower than what you can use natively is not really knowing the perks of the language.
|
|
|
|
|
Albert Holguin wrote: Perhaps you've never used it...
I use it daily.
Albert Holguin wrote: so you can easily code C++ libraries and pull them into Python
That's correct, but then we are comparing C++ to C++, not Python to C++. I am saying (and the benchmarks confirm) that native Python is way slower than C++, even in single-threaded applications. If we include threading, Python is even worse due to the Global Interpreter Lock.
|
|
|
|
|
Nemanja Trifunovic wrote: native Python is way slower than C++
Yeah but I'd argue that it's not typically used that way. To each his own cup of (there's no cup of tea but you know).
|
|
|
|
|
Not to insult you (hope not anyway)... but this reminds me of some of the reference material for git that states outrageously wrong information about svn to prove it's better. Whoever wrote that clearly doesn't understand svn.
We use python as the glue... guts are highly optimized C++. A lot of python code is set up that way. Of course, if you take pure python and do repetitive tasks without optimization of some sort, it will be as slow as any other interpreted language.
|
|
|
|
|
Limit yourself to the subset that Cython[^] can compile to C? A friend of mine swears by it for the intermediate level code where the python prototype isn't fast enough but which isn't worth the heavy lifting needed to write in raw cache aware C to scavenge every last cpu cycle.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
mikepwilson wrote: Ugh. Is it really that good?
Yeah, I think so.
I think if I were to identify the features that I find most useful, they would be lambda expressions, anonymous methods, the Func<> and Action<> classes, and reflection. I stay away from "var" and LINQ can be useful but I usually prefer using the extension methods directly instead. There's a lot I have dived into to fully appreciate -- covariance and contravariance, for example, but the type inference is damn impressive.
Marc
|
|
|
|
|
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...
|
|
|
|