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