But then you might argue, what is the point (or difference) between that and what we already have.
To which i must answere: nada. I am a delphi programmer who was forced to learn C# to survive for a while, but mono is actually not half bad once you get the hang of it. They have added the missing bits that microsoft left out. When microsoft writes “platform independent” they are really talking about different versions of Windows. Mono blew all that apart and also added “real” compilation. To me that ended up as the best solution to an otherwise awful situation.

Anyway, the point of this thread is that some people, who by coincidence have put many of their eggs into the managed world basket, suddenly start calling managed apps native (reminds me a bit of the free as in beer vs free as in freedom discussion).

Maybe that’s why I’m finding Objective-C and Cocoa so welcoming – I haven’t got that far with it yet but I get the same impression – that it’s there to help when you want and happy to get out of the way when needed. Maybe that’s a false impression. I shall find out I am sure.

You must have missed my recent posts on Google+. If you did then you might be interested to learn that I am so thoroughly comfortable and entrenched in my comfort zone that I am currently teaching myself Objective-C and Xcode, and further more actually enjoying it and appreciating it.

For some reason, .NET was never as interesting, exciting or enjoyable in the same way. Perhaps because coming at it from a Delphi perspective the benefit just wasn’t as great in comparison to what I was used to or to my skill level, or because the differences weren’t that great (as in significant) either, just largely unnecessary (in the sense that getting to grips with the differences would take a great deal of time and effort, with the net result that I could do what I already can do, just differently).

you’re clearly picking and choosing what to read into my text so suite the message you want to see.

the .NET-written tools i depend on every day are far from “fire, forget and terminate” (although we do have many of those too, of course, and the fact that they are fast also disproves the supposed repeated startup cost, as that is what “fire, forget and terminate” would get to suffer form, most). our CI system, for example, runs 24/7 and across 5 different servers, and it runs rock solid and fast. the middle tier to our bug tracking system runs 24/7 on a tiny Linux box (an EC2 Micro imstance) and it runs solid. our website is completely done in custom ASP.NET with Data Abstract, and it runs 24/7 and solid.

None of these are “fire, forget and terminate” tools. but of course that won’t keep you from finding another example why these examples, too, don’t matter at all, for whatever point you are trying to make.

everything you say about the garbage collector is the usual Chicken Little “the sky is falling” i’ve been hearing from die-hard Delphi-Lovers/.NET-haters for over ten years, and it’s as bogus now as it was then — if not maybe more so.

as i said elsewhere in this thread: bad code leads to bad apps, good code leads to good apps. i don’t for a second doubt that you’ve maybe seen some pretty crappy apps written in .NET. but that doesn’t mean .NET is bad. or slow. it just means the apps (or tools, or long-running systems) you saw were bad.

re overhead: there’s overhead in every application. you think the Delphi heap magically manages itself, for example? essentially, your argument boils down to the same old reductio-ad-absurdum: writing low-level assembler would be best, because that way you control every single bit that flows thru the system.

that last part is true, and i wont argue that increasing levels of abstraction remove increasing levels of control from the developer. but that’s not, in itself, a BAD thing. a managed system can actually be BETTER at managing memory for you than you are, just like a high-level language compiler can be better at constructing that optimized FOR loop for you then you would be, in assembler.

your problem (and in all fairness it’s a problem that most people get stuck in, and i don’t necessarily exclude myself from that) is that you are so comfortable in your current environment that you decided (probably subconsciously) that the CURRENT level of abstraction you have is just perfect and cannot be improved on. anything less would suck (you’d never wanna go back to writing machine code), but anything more would take away too much previous control from you.

people said the same when they were using Borland Pascal 7, and Delphi came out (“pah, VCL! that’ll just be so much worse and slower than if i can fine-tune my Window Message function.”), when Turbo Pascal with Objects came out (“pah, objects. all those virtual method calls will just slow things down!”, or when Pascal and non-assembly languages themselves came out (“how could a a fancy-schmancy ‘compiler’ ever create as efficient assembly code as my brain can?”).

what makes you think that your *current* sweet spot is somehow different, beyond reproach, and can *not* be vastly improved upon by advanced technologies that, yes, take even MORE control away from you, inorder to make things easier AND better?

ps: re: “Not even they claim that the JIT delivers an advantage” i thought we were beyond the JIT at this stage of the discussion.

Tools that are “fire, forget and terminate” won’t run into the cumulative problems that were the underlying cause of the issues in the cases that I repeatedly come across, which as I said before are primarily due to the garbage collector. Not worrying about memory management and letting the managed runtime manager do it’s management is fine when the entire fabric of the thing being managed is torn down after only a short period of time.

It’s the difference between the infrastructure and organisational effort required to smoothly run a School Sports Day vs The Olympics. What works very well for one won’t even begin to be adequate for the other.

Also, you are a high technology company with roots in the unmanaged era. I very much doubt that your developers are in that group that are easily tempted down the path of carelessness that plagues the great proportion of the “business app” developer community, where speed of delivery often takes higher precedence than quality of build and there is an active disinterest/inverse snobbery when it comes to learning the ins/outs and nuts and bolts of the tools (“we’re here to solve business problems, we’re not compiler engineers!”).

I didn’t think I skipped over your comments about how all code eventually boils down to JMP, ADD and MOV instructions. My observation that Zenon had made my point was intended to cover that. But if you would like me to respond directly, here you go:

When comparing simple arithmetic expressions and looping/control constructs, what you say of course is true. But what that – and you – conveniently ignore is what I and others have pointed out: In a managed runtime there is by definition *something* going on other than the application code. If it is a managed runtime then something is doing the managing, and that something is by necessity in addition to any code you write. i.e. an overhead. Yes, it’s an overhead that delivers some benefits to developer productivity, but it certainly isn’t free. TANSTAAFL applies, as always.

So yes, it is perfectly possible to devise benchmarks that “prove” that the IL code that eventually executes is just as efficient as the equivalent binaries spewed out by a compiler, but artificial benchmarks aren’t worth a hill of beans. Real world results are what matters and beyond the narrow field of highly technical software written by highly technical people, the overwhelming experience that I – and it seems many/most others – seem to encounter is that managed code is SLOW. Sometimes merely noticeably so, sometimes unacceptably so.

But perhaps we should just leave it to the people that created this stuff.

Not even they claim that the JIT delivers an advantage, only that it brings managed code performance that is “comparable to traditional native code—at least in the same ballpark“.

Whatever your common sense tells you to expect, the authors of this technical miracle appear to have far less ambitious expectations.

ok, its obvious that our experiences differ vastly, then. we have huge codebases of .NET, in internal tools, in our products, and none of them are slow. The Oxygene compiler itself is very fast. Just about our entire CI build system is written in Oxygene and runs on .NET and Mono (parts of it are open source with Train and Script), and its all blazingly fast.

the only place i have ever seen performance issues with .NET apps has been the WinForms UI.

So both my experience *and* common sense (see my explanation above for how managed code actually *runs*, which you conveniently just skipped over) back up that there’s really no reason to assume that — all other things being equal — code written in a managed language should be any slower that code written in Delphi or C++.

For MS case, it is obvious slow and a snail
For Embarcadero, until they use FireMonkey in their IDE GUI, don’t expect too much. At some day, they may abandon it (same as .NET from MS)

Cheers