I have. They are the obvious, plodding, boring software engineering solutions to image filtering and animation--not even invented at Apple. And in order to use them, applications usually need to be modified. Now have a look at what Linux compositing window managers manage to do, without any kind of modifications to applications.
I have an iMac on my desk, right next to my Ubuntu machine. For a brief while, Apple had the lead on desktop effects and usability, but these days, the OS X interface seems dull, limiting, and cumbersome to me.
I'd really like to see some innovation there, much like OSX created an amazing GUI layer on top what is essentially Mach/BSD
The OS X GUI layer is essentially NeXTStep on a revised Display Postscript. It's slower and more resource intensive than X11, its graphics is targeted primarily at desktop usage. Where is the innovation?
X11 has been innovative from its inception, and it continues to be amazingly innovative today. For example, the kinds of visual effects Compiz delivers effortlessly and cleanly are much harder to achieve in OS X.
this will be a wake-up call to Gnome/KDE
What exactly do you think will be the "wake-up call"? Both Gnome and KDE have non-X11 backends, but people don't use them because there really is no benefit associated with getting rid of X11.
A non-X11 backend may make sense for Chrome OS because Chrome OS probably needs less functionality than X11 provides and it makes writing drivers easier. But in terms of innovation and functionality, X11 is second to none.
So what you are saying is this...I don't like MSFT.NET but I DO like the Linux version of....well MSFT.NET. I'm sorry, but that really makes no sense.
No. What I'm saying is that I like ECMA C# and I like the Gnome and Linux APIs. And that's what Mono delivers and that's what ships by default with Linux distributions.
Here [wikipedia.org] is the Wiki on Mono, which as you can read is pretty much centered around being.NET compatible.
You shouldn't believe everything in Wikipedia.
So while your interest may truly be in the EMCA parts alone, you might want to tell that to Mr. Icaza who is building the thing and pretty much has a serious thing for.NET.
Icaza is running a company. They want to sell.NET compatibility to companies that have invested a lot of money in.NET apps but find Windows too expensive to deploy. That's why they keep talking about.NET compatibility. That's not the way FOSS users use Mono.
Lets be honest here-if MSFT truly didn't want it to be a "gotcha" that could have added such in writing. It isn't like they don't have some major IP lawyers on staff or that this wasn't brought to their attention.
I see far fewer legal concerns with Mono than I see with most other platforms right now: Microsoft has made a legally binding commitment to keep ECMA C# free and open, and if any third party holds any patents on ECMA C#, they are going to go after Microsoft, not Mono. And I don't have a problem if they go after anybody for the non-ECMA parts. That's Icaza's business risk; it doesn't affect me or most Linux users.
Java, in contrast, is heavily patented by Sun and Sun has been going after other implementations legally. With the new C, C++, Python, Perl, Ruby, etc., it's anybody's guess what submarine patents people may hold on them.
Now, rationally and factually, without your own personal bias and agenda, please explain to us why they aren't a choice for Linux apps and why they suck.
For VisualStudio: it's hard to learn, needlessly complex, commits numerous user interface sins (modal dialogs, bad layouts, etc.), and developers are not very productive in it. For Winforms: apart from numerous niggly technical issues, they are not native to Linux and don't work quite right on Linux. It's the same problem Java has on Linux (and then some). Furthermore, Gtk# is natural and familiar for Linux programmers while Winforms is not.
But, in any case, neither of them are a choice on Linux anyway because they aren't distributed with Linux distributions.
If you have an out right oversion to proprietary apps then you're just a dipshit.
I don't have an "outright aversion". I just think VisualStudio and Winforms are bad. There is some proprietary software I use, despite the hassles.
and think you've probably not used VisualStudio if you're going to make such statements.
There's another thing you're wrong on.
I can see how you may prefer Monodevelop over VS
Fortunately, the world doesn't come down to just those two choices. But, yes, given the choice, I prefer Monodevelop.
Do know we are talking about a language controlled by MSFT who just now went out of their way to very carefully spell out that the EMCA parts and ONLY the ECMA parts are covered by their "do not sue" yes?
That's all I care about.
Do you think that they went so far out of their way to cover ONLY the EMCA parts is to protect freedom and puppies?
I assume they may sue over the non-ECMA parts. Good for them. It doesn't affect me or most other Mono users.
And if you want to write.NET so badly,
I don't want to write.NET code at all.
Is.NET and Mono really so damned good that it is worth taking that risk? Really?
I think.NET sucks. I like Mono.
If MSFT truly believes they will not use their patents on.NET to crush Linux at a later date, then set the whole stack free.
I think.NET sucks, so I'm happy with the current situation, where ECMA C# is free and the non-ECMA parts are not. That's pretty much the same situation as with C and C++ today.
If the non-ECMA parts were free, then C# would turn into the same kind of turd as Java, with people trying to write "cross-platform code" using.NET APIs and the result applications would look and work horribly on Linux.
And it is a good idea to use this compiler and runtime to develop software for Linux?
Sure. C and C++ worked the same way.
Isn't this like using the Java JVM but not use any of the java.* libraries?
No, it's like using C with Gtk+.
Wasn't C# and the CLI created because Microsoft needed Java to stop cross platform development?
I don't give a damn about Java or why Microsoft created C#. C# is a nice language to use with Gnome on Linux, that's all I care about.
You also have Microsoft ready to push you on that third rail at any moment. It just doesn't sound like a smart thing to chance and a waste of a whole lot of development time and effort.
Tell me: do you people get paid for spreading this kind of FUD or do you simply not know any better?
Even for a Linux enthusiast, the Visual Studio/Winforms stack is much more tempting for ambitious projects.
All Mono desktop applications that ship with Ubuntu are based on Gtk#. Winforms isn't even usually installed.
I'm a Windows developer by day and a Linux user by night, and I've got probably half and half MonoDevelop and Visual Studio projects at home. Pick the best tool for the job, they say.
VisualStudio and Winforms are proprietary and simply aren't a choice for Linux desktop applications (even if they didn't suck).
All the OP said was that right now if you want to play it safe with patents you pretty much have to avoid using most of the features that probably drew you to Mono/.NET in the first place.
I doubt it. Monodevelop doesn't even support Winforms and the.NET compatibility libraries aren't even installed on Debian and Ubuntu. You have to jump through hoops in order to use them.
Furthermore, none of the end-user Mono applications on Ubuntu use.NET compatibility libraries. Evidently, all the people who actually develop Linux desktop applications in Mono do so using native Linux APIs.
It's not FUD. One of the goals of the Mono project is compatibility with.NET applications and that means supporting things like Windows Forms.
So? Do you stop programming in C or C++ because Wine offers Windows compatibility?
The existence of.NET-compatibility libraries in Mono affect the average Linux programmer no more than the existence of Wine libraries affects C or C++ programmers.
Its not just that its 'promised' to be added to the Community Promise, its only the ECMA 334 and 335 standards that will be added (possibly).
That is all that's needed because that's all regular Mono applications use.
So really, even if MS adds the 2 standards to their Community Promise, that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine. If you want DB access, or web serving, or a GUI.. you're still in the same problem as before.
Mono uses Gnome for the GUI, sqlite and MySQL as a database, etc.
ASP.NET, ADO.NET, Winforms etc. are provided by Mono only for Microsoft compatibility, but most people don't use them or even install them.
C# is not Java and it's not intended to be like Java. C# is more like C and C++: a programming language and a standard library, with different platform specific libraries on different platforms. That's one of the things that many people like about C# compared to Java. The fact that Microsoft may claim intellectual property on Winforms and ADO.NET is no more relevant to Linux programmers than the fact that Microsoft may claim intellectual property on Win32.
No, it (QtCore part) can be used throughout the stack.
You could use Perl "throughout the stack" if you worked hard enough at it; that doesn't make it a good idea.
Or so you would believe. Have you ever actually tried Qt? Or is all of this based on Java/C# propaganda you've read & bad C++ experience with crappy frameworks?
I've been programming in C++ for more than 20 years and in C for more than 25 years, as my primary languages. My dislike of those languages is based on intimate familiarity with it.
Don't forget that things will only get better as the new C++ standard rolls in (we'll get lambdas, auto,...).
The problem with C++ isn't what it lacks, it's that it's so complicated that people don't manage to produce good results in reasonable time. Although the new C++ standard fixes some things, it makes the basic problem with C++ worse--its complexity.
We'll see about that. I have to say my enthusiasm for Android waned the second I heard of Nokia buying Trolltech.
How is buying Trolltech going to fix the problem that Nokia's engineers apparently don't know how to organize a menu, organize a dialog, perform user testing, or perform bug tracking?
Admittedly, C++ is much less productive than Python & other dynamic languages, but that's not the issue at table here; we are comparing against Java, C#, ObjC.
That is exactly the issue. Objective-C is a dynamic language, and the CLR and JVM support dynamic languages. Java is a lousy language, but even it has garbage collection, full RTTI, and reflection.
This applies even more so to "platform" level stuff.
Qt is an application and GUI toolkit.
If you write more of that in C++ than Java, you'll have a faster platform, given equivalent algorithms.
But the "algorithms" aren't equivalent because the C++ programmer aren't even catching up with the level of functionality that users of better languages can implement in the same amount of time.
It seems Nokia was able to turn a profit with Symbian, even if Symbian is widely dreaded as the least productive programming environment in existence
Nokia phones succeed because Nokia makes great phone hardware. Their software is consistently rated poorly, and it is slow. And there is no real mainstream third party application market. I know: I use a couple of Nokia phones daily.
With Qt, Nokia is betting on the wrong horse. They should either switch to Android or buy Palm or do something entirely new.
Actually, I think this will end up being a competitive advantage in the long run. If Nokia smartphones end up being the *only* smartphones that run (mostly) raw native code compiled straight for the metal, they will end up being the fastest in the long run, given equivalent hardware.
No, they won't. C++ is fast for small inner loops because programmers there can take full advantage of its features. Big applications end up being slow and bloated in C++ because programmers simply cannot manage the complexity anymore: all their time goes into chasing pointer bugs and dealing with include files, and little remains for performance tuning and algorithms.
And what is this "long run" you're speaking of anyway? If it takes 5 years for Nokia to optimize their current C++ applications, do you think anybody will care? Few of the PDA applications from five years ago are even remotely up to date today. There is no "in the long run" for software; what counts is what you can deliver in 3-6 months, not in a few years.
I own one and it's horrible: slow screen refreshes, slow and confusing navigation, and it runs out of power at inconvenient times. I don't think the Kindle or Sony are much better, although I have only tried them briefly. Although the Iliad is hobbled by bad software, I think even the best software can't compensate for the limitations of e-ink.
Get some kind of tablet with a touch screen. A tablet-converted Macbook may be a reasonable choice, as may be the new EEE PC T91. In about a year, you can get a laptop with a Pixel Qi screen (the same you can find on an OLPC).
Nokia has its own lightweight GUI library that they use with Symbian--and their UIs suck. They have built applications with Gtk+--and their UIs suck. They have build Windows and OS X desktop apps--and their UIs still suck. I think the problem Nokia has with GUIs and software has to do with how they develop software, not whether they use Gtk+ or Qt.
Another problem with their choice is that it ties them to C++; the trend in mobile development, however, is towards other languages, like Javascript (Pre), Java (Android), Objective-C (iPhone), and C# (Windows Mobile). Only Symbian steadfastly clings to C and C++. That would be fine if Symbian actually ended up being the fastest and having the best UI of the bunch, but it's actually the slowest and least responsive of the bunch.
It was to be programmed in Smalltalk, which Kay created over the next few years.
Smalltalk what Objective-C and Cocoa were modeled on. However, even Smalltalk-80 (as in 1980) was more advanced in many ways than Objective-C and Cocoa are in 2009.
Slashdot Mirror
Splitting applications into multiple processes... it's like the 1980's all over again.
Look at Core Image Filters and Core Animation.
I have. They are the obvious, plodding, boring software engineering solutions to image filtering and animation--not even invented at Apple. And in order to use them, applications usually need to be modified. Now have a look at what Linux compositing window managers manage to do, without any kind of modifications to applications.
I have an iMac on my desk, right next to my Ubuntu machine. For a brief while, Apple had the lead on desktop effects and usability, but these days, the OS X interface seems dull, limiting, and cumbersome to me.
I'd really like to see some innovation there, much like OSX created an amazing GUI layer on top what is essentially Mach/BSD
The OS X GUI layer is essentially NeXTStep on a revised Display Postscript. It's slower and more resource intensive than X11, its graphics is targeted primarily at desktop usage. Where is the innovation?
X11 has been innovative from its inception, and it continues to be amazingly innovative today. For example, the kinds of visual effects Compiz delivers effortlessly and cleanly are much harder to achieve in OS X.
this will be a wake-up call to Gnome/KDE
What exactly do you think will be the "wake-up call"? Both Gnome and KDE have non-X11 backends, but people don't use them because there really is no benefit associated with getting rid of X11.
A non-X11 backend may make sense for Chrome OS because Chrome OS probably needs less functionality than X11 provides and it makes writing drivers easier. But in terms of innovation and functionality, X11 is second to none.
So what you are saying is this...I don't like MSFT .NET but I DO like the Linux version of....well MSFT .NET. I'm sorry, but that really makes no sense.
No. What I'm saying is that I like ECMA C# and I like the Gnome and Linux APIs. And that's what Mono delivers and that's what ships by default with Linux distributions.
Here [wikipedia.org] is the Wiki on Mono, which as you can read is pretty much centered around being .NET compatible.
You shouldn't believe everything in Wikipedia.
So while your interest may truly be in the EMCA parts alone, you might want to tell that to Mr. Icaza who is building the thing and pretty much has a serious thing for .NET.
Icaza is running a company. They want to sell .NET compatibility to companies that have invested a lot of money in .NET apps but find Windows too expensive to deploy. That's why they keep talking about .NET compatibility. That's not the way FOSS users use Mono.
Lets be honest here-if MSFT truly didn't want it to be a "gotcha" that could have added such in writing. It isn't like they don't have some major IP lawyers on staff or that this wasn't brought to their attention.
I see far fewer legal concerns with Mono than I see with most other platforms right now: Microsoft has made a legally binding commitment to keep ECMA C# free and open, and if any third party holds any patents on ECMA C#, they are going to go after Microsoft, not Mono. And I don't have a problem if they go after anybody for the non-ECMA parts. That's Icaza's business risk; it doesn't affect me or most Linux users.
Java, in contrast, is heavily patented by Sun and Sun has been going after other implementations legally. With the new C, C++, Python, Perl, Ruby, etc., it's anybody's guess what submarine patents people may hold on them.
Well, the frontier had to do with it indirectly: it was more a labor shortage, vast distances, and a huge wealth of natural resources.
We can push ourselves and technology even better if we send robots instead of ugly bags of mostly water.
Now, rationally and factually, without your own personal bias and agenda, please explain to us why they aren't a choice for Linux apps and why they suck.
For VisualStudio: it's hard to learn, needlessly complex, commits numerous user interface sins (modal dialogs, bad layouts, etc.), and developers are not very productive in it. For Winforms: apart from numerous niggly technical issues, they are not native to Linux and don't work quite right on Linux. It's the same problem Java has on Linux (and then some). Furthermore, Gtk# is natural and familiar for Linux programmers while Winforms is not.
But, in any case, neither of them are a choice on Linux anyway because they aren't distributed with Linux distributions.
If you have an out right oversion to proprietary apps then you're just a dipshit.
I don't have an "outright aversion". I just think VisualStudio and Winforms are bad. There is some proprietary software I use, despite the hassles.
and think you've probably not used VisualStudio if you're going to make such statements.
There's another thing you're wrong on.
I can see how you may prefer Monodevelop over VS
Fortunately, the world doesn't come down to just those two choices. But, yes, given the choice, I prefer Monodevelop.
Do know we are talking about a language controlled by MSFT who just now went out of their way to very carefully spell out that the EMCA parts and ONLY the ECMA parts are covered by their "do not sue" yes?
That's all I care about.
Do you think that they went so far out of their way to cover ONLY the EMCA parts is to protect freedom and puppies?
I assume they may sue over the non-ECMA parts. Good for them. It doesn't affect me or most other Mono users.
And if you want to write .NET so badly,
I don't want to write .NET code at all.
Is .NET and Mono really so damned good that it is worth taking that risk? Really?
I think .NET sucks. I like Mono.
If MSFT truly believes they will not use their patents on .NET to crush Linux at a later date, then set the whole stack free.
I think .NET sucks, so I'm happy with the current situation, where ECMA C# is free and the non-ECMA parts are not. That's pretty much the same situation as with C and C++ today.
If the non-ECMA parts were free, then C# would turn into the same kind of turd as Java, with people trying to write "cross-platform code" using .NET APIs and the result applications would look and work horribly on Linux.
I don't see hybrids like the Prius going anywhere. Serial hybrids and electric cars are the future.
Yes, it is. .NET is Windows-specific and Mono is Linux-specific.
If Microsoft resolves the patent problem I am sure many will go and adopt Mono.
There is no "patent problem", and many people are already adopting Mono.
So in other words Mono is useless as it won't be able to run that program originally written for .NET on Windows without jumping through tons of hoops
Bullshit. Mono applications on Linux don't use .NET, they use Gnome and other FOSS libraries.
Seriously I am curious to understand what the appeal is.
It's a good language with an open standard and excellent Linux libraries.
If you don't get it, just don't use it. Stop spreading FUD about it.
And it is a good idea to use this compiler and runtime to develop software for Linux?
Sure. C and C++ worked the same way.
Isn't this like using the Java JVM but not use any of the java.* libraries?
No, it's like using C with Gtk+.
Wasn't C# and the CLI created because Microsoft needed Java to stop cross platform development?
I don't give a damn about Java or why Microsoft created C#. C# is a nice language to use with Gnome on Linux, that's all I care about.
You also have Microsoft ready to push you on that third rail at any moment. It just doesn't sound like a smart thing to chance and a waste of a whole lot of development time and effort.
Tell me: do you people get paid for spreading this kind of FUD or do you simply not know any better?
If it has platform specific libraries which many people use and are encouraged to use, then the end result is anything but cross platform...
Good. That's a big advantage of Mono over Java.
It's just another form of lock-in.
I'd rather be locked into Linux than locked into Java.
I have never been bitten by the complexity of the language. That problem is a bit overhyped.
It's not a problem if you develop by yourself. It's a problem if you try to run software projects with dozens of programmers.
Subjective.
Usability is objectively measurable, and Nokia's is objectively bad.
Even for a Linux enthusiast, the Visual Studio/Winforms stack is much more tempting for ambitious projects.
All Mono desktop applications that ship with Ubuntu are based on Gtk#. Winforms isn't even usually installed.
I'm a Windows developer by day and a Linux user by night, and I've got probably half and half MonoDevelop and Visual Studio projects at home. Pick the best tool for the job, they say.
VisualStudio and Winforms are proprietary and simply aren't a choice for Linux desktop applications (even if they didn't suck).
I agree, but I recommend just holding your nose; the technology is worth it.
Linux had the stench of AT&T and caught on anyway, and Java has the stench of Sun and IBM. Did that stop you?
All the OP said was that right now if you want to play it safe with patents you pretty much have to avoid using most of the features that probably drew you to Mono/.NET in the first place.
I doubt it. Monodevelop doesn't even support Winforms and the .NET compatibility libraries aren't even installed on Debian and Ubuntu. You have to jump through hoops in order to use them.
Furthermore, none of the end-user Mono applications on Ubuntu use .NET compatibility libraries. Evidently, all the people who actually develop Linux desktop applications in Mono do so using native Linux APIs.
It's not FUD. One of the goals of the Mono project is compatibility with .NET applications and that means supporting things like Windows Forms.
So? Do you stop programming in C or C++ because Wine offers Windows compatibility?
The existence of .NET-compatibility libraries in Mono affect the average Linux programmer no more than the existence of Wine libraries affects C or C++ programmers.
Its not just that its 'promised' to be added to the Community Promise, its only the ECMA 334 and 335 standards that will be added (possibly).
That is all that's needed because that's all regular Mono applications use.
So really, even if MS adds the 2 standards to their Community Promise, that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine. If you want DB access, or web serving, or a GUI.. you're still in the same problem as before.
Mono uses Gnome for the GUI, sqlite and MySQL as a database, etc.
ASP.NET, ADO.NET, Winforms etc. are provided by Mono only for Microsoft compatibility, but most people don't use them or even install them.
C# is not Java and it's not intended to be like Java. C# is more like C and C++: a programming language and a standard library, with different platform specific libraries on different platforms. That's one of the things that many people like about C# compared to Java. The fact that Microsoft may claim intellectual property on Winforms and ADO.NET is no more relevant to Linux programmers than the fact that Microsoft may claim intellectual property on Win32.
No, it (QtCore part) can be used throughout the stack.
You could use Perl "throughout the stack" if you worked hard enough at it; that doesn't make it a good idea.
Or so you would believe. Have you ever actually tried Qt? Or is all of this based on Java/C# propaganda you've read & bad C++ experience with crappy frameworks?
I've been programming in C++ for more than 20 years and in C for more than 25 years, as my primary languages. My dislike of those languages is based on intimate familiarity with it.
Don't forget that things will only get better as the new C++ standard rolls in (we'll get lambdas, auto, ...).
The problem with C++ isn't what it lacks, it's that it's so complicated that people don't manage to produce good results in reasonable time. Although the new C++ standard fixes some things, it makes the basic problem with C++ worse--its complexity.
We'll see about that. I have to say my enthusiasm for Android waned the second I heard of Nokia buying Trolltech.
How is buying Trolltech going to fix the problem that Nokia's engineers apparently don't know how to organize a menu, organize a dialog, perform user testing, or perform bug tracking?
Admittedly, C++ is much less productive than Python & other dynamic languages, but that's not the issue at table here; we are comparing against Java, C#, ObjC.
That is exactly the issue. Objective-C is a dynamic language, and the CLR and JVM support dynamic languages. Java is a lousy language, but even it has garbage collection, full RTTI, and reflection.
This applies even more so to "platform" level stuff.
Qt is an application and GUI toolkit.
If you write more of that in C++ than Java, you'll have a faster platform, given equivalent algorithms.
But the "algorithms" aren't equivalent because the C++ programmer aren't even catching up with the level of functionality that users of better languages can implement in the same amount of time.
It seems Nokia was able to turn a profit with Symbian, even if Symbian is widely dreaded as the least productive programming environment in existence
Nokia phones succeed because Nokia makes great phone hardware. Their software is consistently rated poorly, and it is slow. And there is no real mainstream third party application market. I know: I use a couple of Nokia phones daily.
With Qt, Nokia is betting on the wrong horse. They should either switch to Android or buy Palm or do something entirely new.
Actually, I think this will end up being a competitive advantage in the long run. If Nokia smartphones end up being the *only* smartphones that run (mostly) raw native code compiled straight for the metal, they will end up being the fastest in the long run, given equivalent hardware.
No, they won't. C++ is fast for small inner loops because programmers there can take full advantage of its features. Big applications end up being slow and bloated in C++ because programmers simply cannot manage the complexity anymore: all their time goes into chasing pointer bugs and dealing with include files, and little remains for performance tuning and algorithms.
And what is this "long run" you're speaking of anyway? If it takes 5 years for Nokia to optimize their current C++ applications, do you think anybody will care? Few of the PDA applications from five years ago are even remotely up to date today. There is no "in the long run" for software; what counts is what you can deliver in 3-6 months, not in a few years.
I own one and it's horrible: slow screen refreshes, slow and confusing navigation, and it runs out of power at inconvenient times. I don't think the Kindle or Sony are much better, although I have only tried them briefly. Although the Iliad is hobbled by bad software, I think even the best software can't compensate for the limitations of e-ink.
Get some kind of tablet with a touch screen. A tablet-converted Macbook may be a reasonable choice, as may be the new EEE PC T91. In about a year, you can get a laptop with a Pixel Qi screen (the same you can find on an OLPC).
Nokia has its own lightweight GUI library that they use with Symbian--and their UIs suck. They have built applications with Gtk+--and their UIs suck. They have build Windows and OS X desktop apps--and their UIs still suck. I think the problem Nokia has with GUIs and software has to do with how they develop software, not whether they use Gtk+ or Qt.
Another problem with their choice is that it ties them to C++; the trend in mobile development, however, is towards other languages, like Javascript (Pre), Java (Android), Objective-C (iPhone), and C# (Windows Mobile). Only Symbian steadfastly clings to C and C++. That would be fine if Symbian actually ended up being the fastest and having the best UI of the bunch, but it's actually the slowest and least responsive of the bunch.
Alan Kay imagined the Dynabook in 1968. Have a look here:
http://en.wikipedia.org/wiki/Dynabook
It was to be programmed in Smalltalk, which Kay created over the next few years.
Smalltalk what Objective-C and Cocoa were modeled on. However, even Smalltalk-80 (as in 1980) was more advanced in many ways than Objective-C and Cocoa are in 2009.