Myself, I use KDE on Linux because it gives me the best environment to code in. I used to use Windows, and have a Mac OS X laptop, and find them both awkward compared with KDE.
KDE is good, but it is probably not the best example of open source success because it is built on a commercial toolkit and because you are dependent on a commercial vendor for that toolkit.
Dependence on vendors ultimately translates into high costs; they simply are hidden.
With most proprietary software, there is a high cost of switching to a different vendor, and software vendors use that "pain threshold" to charge more than they would in a competitive market.
Another cost resulting from vendor dependencies are the costs and risks associated with forced upgrades by the vendor, or, worse, the vendor going out of business altogether.
So, the survey is right: less vendor dependence is a big advantage of FOSS, in addition to lower TCO. One just shouldn't forget that less vendor dependence isn't just a convenience, it, too, translates into dollars and cents.
C++ because we all know that more buffer overflows and random craziness is what OpenOffice needs to compete with Microsoft Office?
Given that such a huge page of OOo is already written in C++, adding a bit of Java into the mix doesn't make much of a difference in terms of reliability.
It does make a difference in terms of introducing a dependency on a 50M install and a proprietary runtime that exists on only a limited range of platforms.
So seriously, of all of the major language choices, which would be better?
C++ plus a scripting language. C++ is and will always be primarily a C++-based implementation.
I do agree that getting rid of C++ would be nice, but adding a few percent of Java code to OOo is not going to accomplish that.
Java is a free language just like Adobe's PDF product is.
According to Sun, Java is not a "free" language--you can't just implement it any way you like, they control it.
The only non free issue surrounding Java is SUN's implementation...
In roughly the same sense that "the only non free issue surrounding Windows is Microsoft's implementation".
If you don't mind Sun owning Java, why don't you just become an all Microsoft shop? Their technology these days is at least as good as Sun's, and you end up having fewer hassles.
Java is very powerful, albeit coming from Sun and not from the OSS community. Until the OSS community can deliver, can anyone provide an alternate to using Sun's Java?
The OSS community already has numerous languages that are far better than Java.
The reason Java is so hard to reimplement by the OSS community is the same reason Windows is: a big company keeps fiddling with it in order to maintain control.
Would any of that change my ability, in the real world, to use Open Office instead of MS Office? Probably not.
Yes. If it has a dependency on Sun Java, it won't run on many versions of Linux or BSD because Sun Java doesn't.
Furthermore, anything that depends on Sun Java becomes orphaned and unmaintainable should Sun go out of business, get acquired by the wrong company, or change directions.
Free Software people will keep grumbling as long as we aren't building everything from a completely "Free as in Free-as-long-as-you-play-by-OUR-rules" standpoint.
Exactly.
Idiots!
Many of those idiots came to open source after first investing years in some platform only to have it yanked out from under them. And the same can happen to you if you use Java because there is no substitute for Sun Java (or its proprietary derivatives).
it seems to me that the Java source code would at least be open, right?
There are a lot of VB and MFC source code floating around; you still have to use a proprietary piece of software from Microsoft to do anything with them. Basically, that VB and MFC source code is just a marketing thing for Microsoft's proprietary products. Well, the same is true for any open source Java code that requires Sun Java to run.
If you don't like Java just because the implementation is proprietary, you could always find the offensive Java code and port it to something you like more. Am I way off here?
Yes, you are, because the offensive Java code relies on features of com.sun.* classes, which are even more proprietary and even more poorly specified than the classes in java.*. In different words, there is no such thing as "Java" or "porting"--there is Sun's implementation and its derivatives and that's it.
Hey ASSHOLES, the current Java source code can be downloaded here, and the latest development version can be downloaded here
Yes, and how long will you be able to do that? Sun can make Java completely proprietary any time they choose because they own it, lock, stock, and barrel.
And if that's not enough for you, your precious Kaffe, gcj, GNU Classpath, and other "Open Source" projects are working on reimplementing the JVM.
Yes, but those aren't working well enough. Furthermore, they probably violate several of Sun's patents, and they certainly violate the license on the Sun Java specs (whether that is enforceable is another question). Until all of those things are fixed, Sun Java is as proprietary as Microsoft Windows.
Not to mention that OpenOffice is Sun's baby.
Not anymore: it's open source and people can do with it what they want. That includes RMS forking it. That's the deal with open source software.
Apparently, it's fine for Sun to milk the term "open source" for all its PR value, but when people actually try to call Sun on their commitment, people like you start whining and belly-aching.
You've been given a gift and all you can do is look it in the mouth.
A sick horse is a bad gift that may cost you dearly. Besides, neither OOo nor Java are "gifts"; Sun had specific business goals in doing what they did, and those business goals may well include screwing the open source community over.
Apologies for the abrasiveness of this post, but crap like this deserves it.
Well, all you have done is that you are an ignorant cad.
OOo cannot remain dependent on Sun Java: Sun Java just runs on too few systems and configurations. Either OOo gets hacked to remove dependencies on Java altogether, or it needs to be packages with a small, open source Java implementation that works well enough to let OOo function.
Of course, none of this is particularly surprising: Sun is trying to introduce dependencies on their proprietary software in many pieces of software. It's an evil master plan, and it won't work, but that won't stop Schwartz and McNealy from trying until their company is bankrupt.
ALl of the most intersting apps I've seen are Cocoa based. Given that, why would they NOT be written in XCode and Objective-C?
Many apps that go through Cocoa APIs seem to be based on code that wraps Cocoa in other languages or libraries. I think neither Office X, nor Mozilla, nor Safari are really Objective-C and Cocoa apps (although they may contain some).
But in practice if you're even a little careful it just really doesn't happen, or the results are so spectacular it's fixed quickly. The end result is still a solid stable app for the user.
But why even make the compromise? Smalltalk on Windows avoids all the type errors, gives you a better programming environment, and reaches a much larger market. Ditto for C#/.NET and many other languages and development environments.
The comparison of 100000 C lines vs. 250000 lines of other code is WAY overblown. EVen if you are looking at code between Java and ObjectiveC,
For Java, it is; for Java, the ratio is about 1:1. But there are many other excellent languages. Python is easily much smaller than Java or Objective-C.
Sorry, I meant good in addition to experienced. And yes they make mistakes but on the whole a lot less. The error I think lies in the assumption that you can make a lnaguage so safe programmers cannot fail within in.
You are thinking of this as a binary decision, but this is a question of numbers. If a language eliminates 90% of the places where people can make mistakes without making the code more complex, then they will only make 10% as many errors as they would otherwise. That's true for good programmers as much as it is true for bad programmers. And the smaller number of errors means that they have even more time for tracking down the errors that actually remain.
The fundamental question with saftey is - what are you protecting the code FROM. The answer is - yourself!!!
Of course. And I know I can write 100000 lines of C code and make them work reliably because I have done that. I also know that doing so is a complete waste of time because there are tools that let me write the same code in 25000 lines of code with a few percent of the debugging effort involved. I like being protected from myself because it means I have to think less about things that aren't relevant to solving the problem at hand, and that's a good thing.
But again in real life it appears to be working out quite well with a LOT of very high quality small shop apps for the Mac. The average Mac app is WAY better than the standard thrown-together-in-VB app that you see on Windows. As they say, the proof is in the pudding so obviosuly problems you have with the language are turning out not to be a big deal in practical use.
Well, I think there are many things wrong with that argument, starting with the fact that the average Mac app probably isn't even written in Objective-C.
In my experience a high degree of saftey and type checking in a language is overrated. While it is useful it can also lead to inflexibility.
You appear to think that this is an argument about static vs. dynamic type checking, but I have no problem with dynamic type checking. The problem with Objective-C isn't that its object system is dynamically typed, the problem with Objective-C is the unsafe, inflexible, static type system it inherited from C.
Again showing you can only think in the standard mode of programming and are not really getting your head into the message-passing realm. What you just laid out is so clumbsy really compared to message passing as a first class citizen...
I got my head around that 25 years ago. I just think a programming language should get typing and memory management right before it attempts to support message passing OOP. Java is not the world's best OOL, but at least its type system and runtime are sound.
Holes as you see them may be vanishingly small in real-world use, especially if you have expeirenced developers...
Experienced programmers clearly are incapable of avoiding these holes, otherwise programs on Windows, Macintosh, Linux, and UNIX wouldn't be full of buffer overflow problems and pointer errors.
That's a neat hack, but the basic idea is pretty simple: you scan a dot of light across a surface and see how much gets reflected from it: if a lot of light gets reflected, the spot the light was shining on was bright, otherwise it was dark.
Oh, XAML. Yes very interesting - I was doing that about seven years ago by hand in Java
XAML is just one of many such approaches. Mozilla and Gnome have been based on XML GUI declarations for years. Gnome has GUI designers for that. Before that, there have been dozens of other languages, going back nearly two decades.
You see, declaritive design by hand is fun but only goes so far - eventually it's useful to have a GUI over it. And essentially XCode is that GUI over resource bundles,
Yes, just not a very good one, not even by historical standards.
And as the other poster pointed out, message passing as a first-class feature of the Objectsive C language is literally NOTHING like what Java or C# has to offer.
Well, and that's a good thing because Objective-C's support is incomplete and unsafe. Java and C#'s support is complete and safe. Unlike Objective-C, Java and C# also support persistence, inspection, remoting, and a host of other advanced features safely and completely.
Incidentally, the traditional way of doing message passing is to define an explicit data type and pass it around:
receiver.send(new MyEvent(a,b,c));
The traditional way documents the intent better, supports better type checking, and works in many different languages. Having the language automatically turn method calls into data structures is a gimmick.
Let those godless commie pinko Europeans freeze under dozens of feet of snow in their hovels, as long as we can keep driving our SUVs with oil "imported" from the middle east. It's our goddamn right--I'm a libertarian and nobody is gonna tell me what not to drive. And they hate us anyway, so what do we care?
Nothing good comes from there anyway. Those people just keep buying dollars and real estate and all that, and they are sneakily devaluing the dollar by refusing to buy our products and dumping their wine on us. Travel there hasn't been much fun either: they still speak all those funny languages, and the waiters are surly. And technologically, they live in the stone age--I mean, we invented it all anyway, the telephone and television and everything.
And what are they gonna do about it? Our army is bigger than theirs and there isn't a damned thing they can do other than complain in their funny accents.
Besides, until the gulf stream is dead in its tracks, it might just be a false alarm. And even if it does happen, who is to prove that we caused it? It might be cow farts that stopped the gulf stream, or too much hot air from politicians.
And technology can fix it. We're just gonna dump some industrial waste into the ocean and it's gonna fertilize the algae, and then they are going to eat up all the CO2, and then everything is gonna be alright. Or maybe we'll just build some spaceships and colonize space. Yeah, that's what we'll do--space elevators, interstellar travel, and Orion slave girls, and we can still keep driving our SUVs.
What they detected was a gamma ray burst and an afterglow. Everything else is speculation; they are basically saying "if all our theories are correct, then the explanation that this is two neutron stars merging into a black hole is the most plausible explanation". The observation does not provide any additional evidence that black holes exist.
when you say that method calls are not typed checked at runtime - well that's the whole point really!
What I'm referring to is that the argument types are not checked; you can call "foo:(int)" and it gets passed to a method that expects "foo:(char*)"; that is simply a hole in the Objective-C type system, not a useful feature.
I am trying to think what DO means in this context but it is not ringing any bells, can you fill that one out?
DO=Distributed Objects
I don't think your claim of whatever dynamic system you are thinking of not being possible in Obejctive-C is correct, a more concrete example would be nice.
Well, assume I do a "foo:(void*)", a "foo:(char*)", or even a "foo:(int*)"; how is Objective-C going to send the argument? Objective-C makes a set of choices and assumptions in these cases that are driven by the limitations of the C runtime. Java, C#, Python, Smalltalk, and lots of other languages don't limit you in that way: they can handle every built-in type correctly. That's why those languages not only can do DO better, you can also write better debugging, inspection, and other tools in them.
I like reflection more than most people. but really lets be honest and admit those parts of Java or C# are not all that approachable to most people.
Neither is Objective-C reflection, really: you have to deal with C pointers, pointer casts, and type descriptors. To make it truly usable, you have to use libraries.
Actually, lots of people use those capabilities, through Beanshell or Jython, for example. That's why people like to combine scripting with low-level programming. And unlike Objective-C, this stuff works correctly, safely, and completely in Java and C#.
Again another reason to approeciate the practicality Objective-C birngs to the table in this regard - who cares where it stole the idea from if it works?
I didn't say they "stole" it, I said they "copied" it; reuse of language features is perfectly legitimate. On the other hand, one should also remember that a lot of the functionality Apple touts as "innovative" actually wasn't developed by Apple and is decades old; it comes from Stepstone and Smalltalk, among others.
The problem with reflection in Objective-C is that it just doesn't work correctly: reflection is incomplete and method calls are not type checked even at runtime. In Java, you can write a DO system that works correctly no matter what objects you throw at it. In Objective-C, you can't.
Sorry, but this is standard molecular biology and polymer chemistry, the way it's been done for decades. It has nothing to do with "nanotechnology".
Nanotechnology, as in the Diamond Age, refers to a new class of self-replicating molecular devices. Nanotechnology was overhyped, has delivered no scientific insights, and has been a complete failure. That is why its proponents are now going around and trying to relabel work in material science and biology, work that happens to be at the right scale, as "nanotechnology".
This ultra-dynamically-bound method-call approach is what enables magic like Interface Builder, [...] No, you can't assemble something even REMOTELY as pretty in Python, Java, or C#.
Dynamic method forwarding is quite convenient, and many dynamic languages (Smalltalk, Python, CLOS, Ruby, Dylan,...) support it. Perhaps suprisingly, even though Java and C# are statically typed OOLs, they also support it well because their reflection capabilities are so powerful (e.g., Javassist).
Objective-C copied the feature from Smalltalk, but it lacks the reflection capabilities to support it properly. Unfortunately, that's the whole story of Objective-C: it copied ideas from dynamic languages but doesn't implement them correctly.
but I really feel like once up to speed XCode is probably the best GUI design app around
I did look at XCode to see whether there were any good ideas one could copy; I didn't find much. Eclipse, VB, and XCode each have their problems, but Eclipse seems better for experienced programmers and VB seems better for novices, and commercial Smalltalk environments still beat them all.
I think the future is declarative GUI design (usually, XML GUI specifications these days) combined with high-level languages. Linux and Windows are far ahead of Macintosh there technologically and in terms of tools.
Again the message passing nature of the language underneath really helps since you're basically building a stub GUI that you then flesh out the code behind.
And how do you think Objective-C is "message passing" in a way that Java, C#, Smalltalk, or Python are not? Those "message passing patterns" Apple talks about are standard OOP techniques and designs, techniques and designs which Apple (via NeXT) incidentally also copied from Xerox PARC.
But the NeXT foundation and Objective-C together are actually very pertient to the world we live in today. [...] Objective-C is actually where the industry should have gone instead of C++.
Objective-C is indeed better for GUI and application programming than C++. It would have been great if people had adopted it in the 1980's, because it might have allowed C programmers to find out about, and transition to, better approaches to programming. But even in the 1980's, Objective-C was not state of the art; it was an uncomfortable and not particularly well-conceived compromise between C programming and OOP. Today, it offers little that Java or C# don't offer in a better, more convenient way.
It's easier to learn and use than C++ (I've done both) and might be a little behind Java or C#, but then again it's also not really been overhauled for a while.
I think that's an understatement: Objective-C hasn't changed significantly in 20 years.
The rapid degree of progress Apple has managed to make in the OS and with other programs is a good demonstrator for how efficient Objective-C can be.
I don't believe that's true. The thing that makes Macintosh so attractive to many people is its apparent simplicity, and that is achieved by keeping the user interface simple. So, the progress on Macintosh is due to careful design, not due to heroic programming efforts.
If you give, say, the iTunes design to a Cocoa programmer and a programmer using, say, Java/Eclipse or VisualBasic programmer, you'll probably find that the Cocoa programmer will take longer to implement it.
Slashdot Mirror
Myself, I use KDE on Linux because it gives me the best environment to code in. I used to use Windows, and have a Mac OS X laptop, and find them both awkward compared with KDE.
KDE is good, but it is probably not the best example of open source success because it is built on a commercial toolkit and because you are dependent on a commercial vendor for that toolkit.
Dependence on vendors ultimately translates into high costs; they simply are hidden.
With most proprietary software, there is a high cost of switching to a different vendor, and software vendors use that "pain threshold" to charge more than they would in a competitive market.
Another cost resulting from vendor dependencies are the costs and risks associated with forced upgrades by the vendor, or, worse, the vendor going out of business altogether.
So, the survey is right: less vendor dependence is a big advantage of FOSS, in addition to lower TCO. One just shouldn't forget that less vendor dependence isn't just a convenience, it, too, translates into dollars and cents.
C++ because we all know that more buffer overflows and random craziness is what OpenOffice needs to compete with Microsoft Office?
Given that such a huge page of OOo is already written in C++, adding a bit of Java into the mix doesn't make much of a difference in terms of reliability.
It does make a difference in terms of introducing a dependency on a 50M install and a proprietary runtime that exists on only a limited range of platforms.
So seriously, of all of the major language choices, which would be better?
C++ plus a scripting language. C++ is and will always be primarily a C++-based implementation.
I do agree that getting rid of C++ would be nice, but adding a few percent of Java code to OOo is not going to accomplish that.
Java is a free language just like Adobe's PDF product is.
According to Sun, Java is not a "free" language--you can't just implement it any way you like, they control it.
The only non free issue surrounding Java is SUN's implementation...
In roughly the same sense that "the only non free issue surrounding Windows is Microsoft's implementation".
If you don't mind Sun owning Java, why don't you just become an all Microsoft shop? Their technology these days is at least as good as Sun's, and you end up having fewer hassles.
Java is very powerful, albeit coming from Sun and not from the OSS community. Until the OSS community can deliver, can anyone provide an alternate to using Sun's Java?
The OSS community already has numerous languages that are far better than Java.
The reason Java is so hard to reimplement by the OSS community is the same reason Windows is: a big company keeps fiddling with it in order to maintain control.
Would any of that change my ability, in the real world, to use Open Office instead of MS Office? Probably not.
Yes. If it has a dependency on Sun Java, it won't run on many versions of Linux or BSD because Sun Java doesn't.
Furthermore, anything that depends on Sun Java becomes orphaned and unmaintainable should Sun go out of business, get acquired by the wrong company, or change directions.
Free Software people will keep grumbling as long as we aren't building everything from a completely "Free as in Free-as-long-as-you-play-by-OUR-rules" standpoint.
Exactly.
Idiots!
Many of those idiots came to open source after first investing years in some platform only to have it yanked out from under them. And the same can happen to you if you use Java because there is no substitute for Sun Java (or its proprietary derivatives).
it seems to me that the Java source code would at least be open, right?
There are a lot of VB and MFC source code floating around; you still have to use a proprietary piece of software from Microsoft to do anything with them. Basically, that VB and MFC source code is just a marketing thing for Microsoft's proprietary products. Well, the same is true for any open source Java code that requires Sun Java to run.
If you don't like Java just because the implementation is proprietary, you could always find the offensive Java code and port it to something you like more. Am I way off here?
Yes, you are, because the offensive Java code relies on features of com.sun.* classes, which are even more proprietary and even more poorly specified than the classes in java.*. In different words, there is no such thing as "Java" or "porting"--there is Sun's implementation and its derivatives and that's it.
Hey ASSHOLES, the current Java source code can be downloaded here, and the latest development version can be downloaded here
Yes, and how long will you be able to do that? Sun can make Java completely proprietary any time they choose because they own it, lock, stock, and barrel.
And if that's not enough for you, your precious Kaffe, gcj, GNU Classpath, and other "Open Source" projects are working on reimplementing the JVM.
Yes, but those aren't working well enough. Furthermore, they probably violate several of Sun's patents, and they certainly violate the license on the Sun Java specs (whether that is enforceable is another question). Until all of those things are fixed, Sun Java is as proprietary as Microsoft Windows.
Not to mention that OpenOffice is Sun's baby.
Not anymore: it's open source and people can do with it what they want. That includes RMS forking it. That's the deal with open source software.
Apparently, it's fine for Sun to milk the term "open source" for all its PR value, but when people actually try to call Sun on their commitment, people like you start whining and belly-aching.
You've been given a gift and all you can do is look it in the mouth.
A sick horse is a bad gift that may cost you dearly. Besides, neither OOo nor Java are "gifts"; Sun had specific business goals in doing what they did, and those business goals may well include screwing the open source community over.
Apologies for the abrasiveness of this post, but crap like this deserves it.
Well, all you have done is that you are an ignorant cad.
OOo cannot remain dependent on Sun Java: Sun Java just runs on too few systems and configurations. Either OOo gets hacked to remove dependencies on Java altogether, or it needs to be packages with a small, open source Java implementation that works well enough to let OOo function.
Of course, none of this is particularly surprising: Sun is trying to introduce dependencies on their proprietary software in many pieces of software. It's an evil master plan, and it won't work, but that won't stop Schwartz and McNealy from trying until their company is bankrupt.
ALl of the most intersting apps I've seen are Cocoa based. Given that, why would they NOT be written in XCode and Objective-C?
Many apps that go through Cocoa APIs seem to be based on code that wraps Cocoa in other languages or libraries. I think neither Office X, nor Mozilla, nor Safari are really Objective-C and Cocoa apps (although they may contain some).
But in practice if you're even a little careful it just really doesn't happen, or the results are so spectacular it's fixed quickly. The end result is still a solid stable app for the user.
But why even make the compromise? Smalltalk on Windows avoids all the type errors, gives you a better programming environment, and reaches a much larger market. Ditto for C#/.NET and many other languages and development environments.
The comparison of 100000 C lines vs. 250000 lines of other code is WAY overblown. EVen if you are looking at code between Java and ObjectiveC,
For Java, it is; for Java, the ratio is about 1:1. But there are many other excellent languages. Python is easily much smaller than Java or Objective-C.
I suspect this will not affect IP-only voice communications, but only services that involve voice-to-IP gateways.
I still am not convinced it's the right thing to do, but I think it's probably fairly harmless and I can understand why they are doing it.
Sorry, I meant good in addition to experienced. And yes they make mistakes but on the whole a lot less. The error I think lies in the assumption that you can make a lnaguage so safe programmers cannot fail within in.
You are thinking of this as a binary decision, but this is a question of numbers. If a language eliminates 90% of the places where people can make mistakes without making the code more complex, then they will only make 10% as many errors as they would otherwise. That's true for good programmers as much as it is true for bad programmers. And the smaller number of errors means that they have even more time for tracking down the errors that actually remain.
The fundamental question with saftey is - what are you protecting the code FROM. The answer is - yourself!!!
Of course. And I know I can write 100000 lines of C code and make them work reliably because I have done that. I also know that doing so is a complete waste of time because there are tools that let me write the same code in 25000 lines of code with a few percent of the debugging effort involved. I like being protected from myself because it means I have to think less about things that aren't relevant to solving the problem at hand, and that's a good thing.
But again in real life it appears to be working out quite well with a LOT of very high quality small shop apps for the Mac. The average Mac app is WAY better than the standard thrown-together-in-VB app that you see on Windows. As they say, the proof is in the pudding so obviosuly problems you have with the language are turning out not to be a big deal in practical use.
Well, I think there are many things wrong with that argument, starting with the fact that the average Mac app probably isn't even written in Objective-C.
In my experience a high degree of saftey and type checking in a language is overrated. While it is useful it can also lead to inflexibility.
You appear to think that this is an argument about static vs. dynamic type checking, but I have no problem with dynamic type checking. The problem with Objective-C isn't that its object system is dynamically typed, the problem with Objective-C is the unsafe, inflexible, static type system it inherited from C.
Again showing you can only think in the standard mode of programming and are not really getting your head into the message-passing realm. What you just laid out is so clumbsy really compared to message passing as a first class citizen...
I got my head around that 25 years ago. I just think a programming language should get typing and memory management right before it attempts to support message passing OOP. Java is not the world's best OOL, but at least its type system and runtime are sound.
Holes as you see them may be vanishingly small in real-world use, especially if you have expeirenced developers...
Experienced programmers clearly are incapable of avoiding these holes, otherwise programs on Windows, Macintosh, Linux, and UNIX wouldn't be full of buffer overflow problems and pointer errors.
That's a neat hack, but the basic idea is pretty simple: you scan a dot of light across a surface and see how much gets reflected from it: if a lot of light gets reflected, the spot the light was shining on was bright, otherwise it was dark.
XAML is just one of many such approaches. Mozilla and Gnome have been based on XML GUI declarations for years. Gnome has GUI designers for that. Before that, there have been dozens of other languages, going back nearly two decades.
You see, declaritive design by hand is fun but only goes so far - eventually it's useful to have a GUI over it. And essentially XCode is that GUI over resource bundles,
Yes, just not a very good one, not even by historical standards.
And as the other poster pointed out, message passing as a first-class feature of the Objectsive C language is literally NOTHING like what Java or C# has to offer.
Well, and that's a good thing because Objective-C's support is incomplete and unsafe. Java and C#'s support is complete and safe. Unlike Objective-C, Java and C# also support persistence, inspection, remoting, and a host of other advanced features safely and completely.
Incidentally, the traditional way of doing message passing is to define an explicit data type and pass it around:The traditional way documents the intent better, supports better type checking, and works in many different languages. Having the language automatically turn method calls into data structures is a gimmick.
What they detected was a gamma ray burst and an afterglow. Everything else is speculation; they are basically saying "if all our theories are correct, then the explanation that this is two neutron stars merging into a black hole is the most plausible explanation". The observation does not provide any additional evidence that black holes exist.
when you say that method calls are not typed checked at runtime - well that's the whole point really!
What I'm referring to is that the argument types are not checked; you can call "foo:(int)" and it gets passed to a method that expects "foo:(char*)"; that is simply a hole in the Objective-C type system, not a useful feature.
I am trying to think what DO means in this context but it is not ringing any bells, can you fill that one out?
DO=Distributed Objects
I don't think your claim of whatever dynamic system you are thinking of not being possible in Obejctive-C is correct, a more concrete example would be nice.
Well, assume I do a "foo:(void*)", a "foo:(char*)", or even a "foo:(int*)"; how is Objective-C going to send the argument? Objective-C makes a set of choices and assumptions in these cases that are driven by the limitations of the C runtime. Java, C#, Python, Smalltalk, and lots of other languages don't limit you in that way: they can handle every built-in type correctly. That's why those languages not only can do DO better, you can also write better debugging, inspection, and other tools in them.
I like reflection more than most people. but really lets be honest and admit those parts of Java or C# are not all that approachable to most people.
Neither is Objective-C reflection, really: you have to deal with C pointers, pointer casts, and type descriptors. To make it truly usable, you have to use libraries.
Actually, lots of people use those capabilities, through Beanshell or Jython, for example. That's why people like to combine scripting with low-level programming. And unlike Objective-C, this stuff works correctly, safely, and completely in Java and C#.
Again another reason to approeciate the practicality Objective-C birngs to the table in this regard - who cares where it stole the idea from if it works?
I didn't say they "stole" it, I said they "copied" it; reuse of language features is perfectly legitimate. On the other hand, one should also remember that a lot of the functionality Apple touts as "innovative" actually wasn't developed by Apple and is decades old; it comes from Stepstone and Smalltalk, among others.
The problem with reflection in Objective-C is that it just doesn't work correctly: reflection is incomplete and method calls are not type checked even at runtime. In Java, you can write a DO system that works correctly no matter what objects you throw at it. In Objective-C, you can't.
Sorry, but this is standard molecular biology and polymer chemistry, the way it's been done for decades. It has nothing to do with "nanotechnology".
Nanotechnology, as in the Diamond Age, refers to a new class of self-replicating molecular devices. Nanotechnology was overhyped, has delivered no scientific insights, and has been a complete failure. That is why its proponents are now going around and trying to relabel work in material science and biology, work that happens to be at the right scale, as "nanotechnology".
This ultra-dynamically-bound method-call approach is what enables magic like Interface Builder, [...] No, you can't assemble something even REMOTELY as pretty in Python, Java, or C#.
...) support it. Perhaps suprisingly, even though Java and C# are statically typed OOLs, they also support it well because their reflection capabilities are so powerful (e.g., Javassist).
Dynamic method forwarding is quite convenient, and many dynamic languages (Smalltalk, Python, CLOS, Ruby, Dylan,
Objective-C copied the feature from Smalltalk, but it lacks the reflection capabilities to support it properly. Unfortunately, that's the whole story of Objective-C: it copied ideas from dynamic languages but doesn't implement them correctly.
Now, we don't have to argue about it anymore--they are telling us themselves that they are after world domination through villainy.
but I really feel like once up to speed XCode is probably the best GUI design app around
I did look at XCode to see whether there were any good ideas one could copy; I didn't find much. Eclipse, VB, and XCode each have their problems, but Eclipse seems better for experienced programmers and VB seems better for novices, and commercial Smalltalk environments still beat them all.
I think the future is declarative GUI design (usually, XML GUI specifications these days) combined with high-level languages. Linux and Windows are far ahead of Macintosh there technologically and in terms of tools.
Again the message passing nature of the language underneath really helps since you're basically building a stub GUI that you then flesh out the code behind.
And how do you think Objective-C is "message passing" in a way that Java, C#, Smalltalk, or Python are not? Those "message passing patterns" Apple talks about are standard OOP techniques and designs, techniques and designs which Apple (via NeXT) incidentally also copied from Xerox PARC.
But the NeXT foundation and Objective-C together are actually very pertient to the world we live in today. [...] Objective-C is actually where the industry should have gone instead of C++.
Objective-C is indeed better for GUI and application programming than C++. It would have been great if people had adopted it in the 1980's, because it might have allowed C programmers to find out about, and transition to, better approaches to programming. But even in the 1980's, Objective-C was not state of the art; it was an uncomfortable and not particularly well-conceived compromise between C programming and OOP. Today, it offers little that Java or C# don't offer in a better, more convenient way.
It's easier to learn and use than C++ (I've done both) and might be a little behind Java or C#, but then again it's also not really been overhauled for a while.
I think that's an understatement: Objective-C hasn't changed significantly in 20 years.
The rapid degree of progress Apple has managed to make in the OS and with other programs is a good demonstrator for how efficient Objective-C can be.
I don't believe that's true. The thing that makes Macintosh so attractive to many people is its apparent simplicity, and that is achieved by keeping the user interface simple. So, the progress on Macintosh is due to careful design, not due to heroic programming efforts.
If you give, say, the iTunes design to a Cocoa programmer and a programmer using, say, Java/Eclipse or VisualBasic programmer, you'll probably find that the Cocoa programmer will take longer to implement it.