Ingen idé att försöka gömma sin inkompetens bakom fånga kommentarer.
Tja, i och med att Alan Kay & Co började bygga det blev Smalltalk redan under 60-talet så har jag inga som helst problem med en sådan gissning. Du tycker att det är strunt av det enkla skälet att du inte har någon som helst aning vad jag syftar på:
Naturligtvis. Men att försöka lyfta fram ett "managed" API som något jätteviktigt i och med den närmsta framtiden problem med multipla cores i processorna känns fruktansvärt korkat.
Kommentarer som denna upphör aldrig att förvåna. Du saknar kunskap att avgöra om kritiken jag framför är vettig och vad gör du? Försöker lasta över ansvaret på mig?
Läs kommentarerna till hans artikel så förstår du att många redan framfört kritik - som artikelförfattaren tyvärr väljer att ignorera.
"From my perspective it is a little unfair to compare the recent rise of managed code / platforms to the Copland disaster. Copland happened because Apple held on to the classic MacOS, which was already very antiquated in terms of OS technology when development of Copland started.
The features that MacOS lacked and Copland should bring, like preemptive multitasking, multithreading, memory protection and good VM support were not only things that develpers were expecting - they were a technical necvessity for any modern OS which isn't necessarily true for managed code today/tomorrow.
Those features (or the lack thereof) drastically affected the user experience. Since computers and applications got more and more complex, with the computer making inroads in new areas like multimedia you could no longer have a machine that completely locked up only because _one_ application misbehaved...
The situation with managed code today is a bit different. Though, granted, it bears some resemblance too. If you talk about managed code and APIs you have to really distinguish those two, though. You mentioned C#, CLR and WinFXas examples for a amanged environment, so I'll use them too. So, why did MS develop C# and the CLR? I believe that much motivation came from the success of - and the dispute with Sun over - Java. Java was developed as a cross-platform solution, so they obviously needed a VM to make apps run unchanged on different platforms. And they did the only sane thing to do if they were to create such a thing in the first place and abstracted away most OS details -including management of application memory. Since MS didn't want to use Java, but couldn't deny its advantages, they needed something comparable to compete with Sun.
Your most valid point in favor of managed languages is the ability of managed runtimes like the CLR or the JVM to prevent applications from clobbering their own memory, and by that plugging many potential security holes. Apple really needs to something in the future here, since this is still very possible with Objective-C/Cocoa applications. And this will be the area where managed runtimes shine the most. But still, this could be done even with keeping the Objective-C language (mostly) intact in an evolutionary way (just guessing). It's not the languages, it's the runtime system that really matters.
The second advantage you get is memory management with automatic garbage collection, which helps developers focus on the task at hand and not tedious work just to make the application run correctly.
The third major component to a managed runtime is the used API, which will be an object-oriented class library in most cases, such as the Java class library or WinFX.
When you talk about abstraction, this is the area to look at. I fully agree that a more abstracted approach to most problems will win in the long run. But you don't necessarily need a managed environment for a good abstract API. And Mac OS X has a very good abstracted high level API - Cocoa. I honestly believe Cocoa can stand beside WinFX or the Java API in terms of abstraction and features if continues to evolve.
Windows on the other hand desperately needed a new API to replace the aging procedural Win32. Though there was the MFX as an object oriented alternative, it wasn't much help since the MFC essentially was a very thin wrapper around Win32 which did not provide any OS abstraction.
To make a long story short - Mac OS X has a great API and a dynamic, simple language as its primary programming language. That leaves the runtime system, which needs to evolve much further to gain "all" the advantages that the managed environments provide.
But even here there is no immediate nor short term danger that a scenario like with Copland could resurface. If Apple keeps an eye on the issue, and continues to improve the runtime libraries and compiler (perhaps over time even by sacrificing backward compatibility), they can compete with managed environments. In my opinion, garbage collecting Objective-C would be a very nice feature and a first step in the right direction. The fact that you can still write C-code can stay an advantage for quite some time, the good thing is: You don't _have_ to write C code. Why not give developers a choice?
Yes, we need evolution in the direction of managed code, but we don't need a revolution which was required at the time Copland happened.
BTW: A word on performance:
The Java model of taking away every responsibility from the developer brings some disadvantages along too. Most of them are performance-related, and I believe performance is still (and will remain) a very important feature in a software product especially in markets where Apple is strong today. Office and "enterprise" (I hate that term) applications may not suffer much if performance degrades from introducing overhead due to a managed / virtual environment, but media / real time applications certainly do. Yes, computers get faster, but there should be a balance between abstraction / automatism and efficiency."
