|
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...
|
|
|
|
|
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
|
|
|
|