"Which is almost definitely true that they would work under whatever license they were paid to. The difference is that most of the code they wrote to get those paychecks would have stayed locked up as has happened with OSX."
Whether or not it would have stayed locked up has no bearing on the assertion that the GPL is important to Linux's success. All that matters to those paid developers is that _they_ have access to the source code, and source code to just about anything can be obtained legally by the likes of IBM, for whom a few million in licensing fees is chump-change.
"As for there being any chance that Linux would have been as successful under another license, that's kind of a no brainer. There's almost no way it could have been. Just look at what has happened to the BSDs. Sure they're around and people work on them and use them, but they're not nearly as big a deal as Linux "
And Linux is not nearly as big a deal as Windows, so by your logic, Windows must have a license that is far superior to the GPL, and Apple's iTunes store owes its success to licenses that are that are just a bit nicer than those of the competition.
Ballmer: "it's about licenses, licenses, licenses!".
Jobs: "The next thing I'm going to show you is a new license that we've been working on for quite a while. You're going to love this...".
"I didn't say it would not have existed without the GPL. I said I think GPL licensing had a significant positive factor in it's rapid growth."
If you said "was a significant factor in its rapid development", I would be in full agreement.
"Above and beyond developers' passion, it's worth noting that - as you know - GNU existed before Linux, and having Linux GPLed means that they are very easy bedfellows."
It did indeed, although it should be noted that GNU tools have also been used for a wide variety of non-GPL projects over the years, mainly due to the fact that they capable of targeting a wide variety of platforms and architectures (which is of course due to their profoundly open nature).
"GNU has vocal proponents in the shape of Stallman and the FSF, while the BSD arena doesn't seem to have a similar counterpart."
This is very true. However, most non-Geeks haven't heard of the FSF or RMS, and a good many of those who have regard RMS in particular as being a fringe loony with a cabal of social misfits who worship him and therefore believe everything he says. Linus Torvalds is far more famous outside geekdom (and indeed inside it), and has I think done far more for Linux in particular than RMS because he presents it as something that has concrete benefits rather than part of a social movement consisting of what the public at large thinks of as people who get nosebleeds arguing about Star Trek and whether Spiderman could beat the Green Lantern.
So perhaps it would be more accurate to say that what the BSDs lack is an equivalent for Linus, i.e. a person who is not only quite well known by both geeks and non-geeks, but also respected by both groups because he can talk to each of them in terms they understand without pissing many people off.
"None of the examples you cite are developed under the BSD license."
Where did I say they were? I stated that they are available under _less restrictive_ licenses than the GPL, period.
"Mozilla is GPL'd (the MPL is also available, which is also copyleft)".
You are correct -- I was wrong in this case.
"Apache is also under a copyleft license (see 4. Redistribution) which is effectively viral as any licensing must not conflict with the APL"
BSD code cannot be used in ways that conflict with the BSD license either, so by your definition it is also viral, and so are all other licenses apart from those of public domain works. And when one considers that the entirety of the APL basically states that compliance is a matter of leaving any copyright notices in source code (which does not have to be made available to others in any shape or form), and distributing a text file containing this copyright information to end-users, it begins to look very much like the BSD license indeed, where one is also required to maintain the original copyright info in source files that don't have to be made available to anyone else, and tell end-users about said copyrights.
Thus, while I was wrong about the MPL, you are also wrong about the APL, which is as close to a BSD license as it is possible to get without being a BSD license: score 1-1.
"I think you're really missing the point. Consider the reasons why Open Darwin failed as a project."
Indeed. But as you'll see in a moment, it is you who is missing the point.
"So why was nobody interested in Open Darwin? Because it's Apple's product."
Open Darwin had nothing to do with Apple -- It was an entirely third party effort at making a fork of Apple's Darwin. The rest of your comments about sense of community etc. do not therefore require answering, because they are entirely based on your own misconceptions about Open Darwin.
"It's naive to believe that GPL vs BSD has nothing to do with the failure of Open Darwin"
Not as naive as failing to read the article, and thus assuming that Open Darwin and Apple Darwin are one and the same. Again, the rest of your comments are irrelevant, because they address points that are not pertinent to any issue surrounding Open Darwin's closure.
I severely doubt that Linux would have ceased to exist (or be still-born) without the GPL, because the sheer number of thriving open source projects with much more liberal licenses indicates that there are a lot of hackers who don't like the FSF or anyone else telling them what they can do with stuff they write. Would it have been as successful under a different license? Nobody can really say for sure, but not being GPL hasn't stood in the way of Apache becoming the most popular web server, and Apple have managed to put at least as many primarily BSD-based UNIX-like systems on desktops as all the Linux distros put together. Note also that Linux as a system rather than merely a kernel originally lifted a lot of BSD code, so BSD also played a significant role in its genesis (and portions of it are still there), as did Minix, which Linus used to write and test Linux in the early days (but did not, as some primarily MS-paid shills have claimed, copy any Minix code).
The creation, subsequent amplification, and promotion of Linux is therefore rather more complex in licensing terms than certain GPL advocates like to pretend, especially nowadays, when Linus Torvalds is telling us that most of the significant contributions to the Linux kernel come from paid programmers working in companies such as IBM, RedHat, and Novell/Suse, most of whom would work under any license that had a pay-check on the end of it.
Ah, so BSD-style licenses explain why Apache, the various Mozilla projects, and Python have been total flops that nobody uses for anything.
Let's get real for a moment. Linux has become popular on servers for the same reason Java did, i.e. it generated a lot of press buzz, and has companies like IBM and HP pushing it to their customers (which they call "partners" to make things look cosy and pally). This means that the majority of corporate Linux setups (and by corporate, I mean any corporation, big or small) were chosen by people who don't know or care what the GPL is, have never heard of Stallman or the FSF, think a Gnu is a type of ungulate that lives in Africa, and would be happily using one of the BSDs if that was what their big "we take care of everything" hand-holding "partner" was telling them to use instead. Geeks within such companies have zero real-world input into any money based decision-making process, and use what they're told to use, hence the fact that Microsoft can sell them Windows and MS-Office for their their desktops, server-side Windows with Exchange for departmental services, Visual Studio for development, while Linux with Apache etc. live on their web server farms. If these people gave a fart about things like the GPL or what their pet geeks think is great, they wouldn't let anything from MS within a mile of their corporate buildings, and would be using open source tools to build their Linux-hosted webs instead of costly proprietary stuff like WebSphere and Tivoli, which are just incidentally supplied by those same "partners" who recommend, install, and support Linux.
The GPL is therefore no more relevant to Linux's success than a lack of it has been to the immeasurably greater success of Microsoft's products. It is popular on servers because it works, is free as in beer, leverages existing corporate UNIX expertise, and a lot of business people have heard of it thanks to their everything-including-the-kitchen-sink IT service "partners", whereas few have heard of the various BSD variants. By the same token, it is a flop on the desktop because, for far too many non-geeks without access to a geek, it doesn't work properly with the hardware they have, fails to leverage their (albeit minimal) expertise with other operating systems and software, and most consumers either haven't heard of it, or know the name but are extremely hazy about what it is.
"many of the problems to be solved require massive computational power"
This may be the case for true intelligence of a human-like level, but many of the tasks that are grouped under the general category of AI research should not be particularly computationally intensive because creatures of very limited intelligence manage them with ease. It is the fact that some of these things are proving difficult despite the application of massive computing power which convinces me that any real breakthroughs will come from outside the computer-based AI community.
"I expect most of a fruit fly's capabilities could be replicated, but few think the investment would be worth it"
I doubt we could replicate the way their visual systems work, because there is no artificial vision system that allows an autonomous machine to move around in three dimensions as well as a fruit fly. As I said above, the fact that we cannot do this despite the application of massive computing resources would seem to indicate that massive computing resources are not the answer, because fruit flies obviously do not use massive computing resources to solve that particular problem (or for that matter, any other problem).
"The AI in games gets limited development resources"
Everything has limited development resources.
"After the DARPA Grand Challenge I'm surprised at how well they've done with the limited computational power available (though I think they may have made it a little easier this year)"
I don't think they've done very well at all. Insects routinely handle much more complex challenges as part of their daily lives, and insects have remarkably little in the way of raw processing power. There is obviously a fairly simple and extremely robust solution to this sort of problem that nature found many hundreds of millions of years ago, so perhaps we should be spending a lot more time and money investigating and trying to duplicate that ancient and massively successful solution instead of wasting our time trying to crack it with brute computing force.
"If we manage to make them truly logical, that alone may make them difficult for many people to understand:)"
I don't think that logic will be the barrier, but rather the fact that the first "intelligent" systems will be designed to solve a specific narrow set of problems, and will therefore "think" in terms that fit the problem domain. IMO general purpose intelligence of the sort we have will take a quite a long time to appear because we do not understand enough about the way our own brains work to even begin the task of modeling their functionality, even if we did have enough computing power to do so. And the fact of the matter is that there is no real reason to bother making an "artificial human", because real humans can be produced very easily and cheaply. There are however many applications for specialised "intelligent" systems capable of performing certain tasks that require humans today, but doing so more quickly and / or reliably (e.g. reading documents, verifying signatures, piloting vehicles of all types, exploring hostile environments without supervision, controlling advanced weapons systems, etc., etc., etc.).
Agreed in full. However, I doubt that such a breakthrough will come from the AI research community, who have consistently failed to match the advances made in virtually all other fields of computing. It is I think more likely that intelligent machines will emerge from some other research area, possibly as a side-effect of technology that is at best only tangentially related to our current concepts of computing. Research into cognition and behaviour indicates that animals (including humans) process their environment using non-deterministic predictive mechanisms that require a minimal set of "cues" to act as prediction branch keys (and can therefore be "tricked" by things like optical illusions, sleight of hand, and camouflage). Trying to emulate such mechanisms using deterministic reactive processes is thus a blind alley that will demand ever more computing power to approximate what nature has achieved using small portions of fairly simple creatures such as fruit flies, with materials that carry and process signals at a tiny fraction of the speed that today's computers are capable of, and that have minimal energy requirements.
I also doubt that the first truly intelligent machines will be "human emulators" that can pass the Turning test -- indeed, I think it is likely that their very nature will mean that their "thought processes" are quite alien to us, although we will obviously require some method of interacting with them, just as we (for example) have ways of interacting with working dogs, who also "think" in ways that are quite distinct from our own. This will of course be used by some to "prove" that such machines are not intelligent at all, because a lot of goal-post moving has gone into arguing that anything a machine can do is simply a mechanical process that requires no intelligence whatsoever. If you'd asked someone from the 19th century whether something that can play chess at international Grand Master level, solve complex mathematical formulae, and compose music and poetry (admittedly badly, but then the same can be said of nearly all humans!) was intelligent, they would have undoubtedly replied in the affirmative, but each of these tasks has been progressively removed from the ever-shortening list of "intelligent stuff" whenever someone demonstrates a machine that can do them.
So when (and I do believe it is a when rather than an if) machine intelligence does appear, the "it's not really intelligent" crowd will be left with an ever-shrinking Adamsian list of things that "prove" it's just an algorithm after all ("Intelligent? No way! When was the last time you saw a machine go out and spend money it didn't have on something it didn't need because of an advertisement, lay in the sun long enough to damage itself severely, claim to have seen Elvis working as a waiter in a Chinese restaurant, or set fire to itself and everyone around it trying to light a barbecue with gasoline?").
"Do you really think you are well justified in such a high level of confidence, when there are probably people who are more intelligent and more well informed about AI than you or I, and who also think we are close to strong AI?"
Unfortunately, it's a case of crying wolf once too often. As the GP says, clever people who are extremely well informed about AI have been telling us that we're close to it for four decades. All that was required, they'd say, was an order of magnitude more computing power, and we'd be there. And when they had that extra order of magnitude, we saw computers solve the N Queens and Traveling Salesman problems a whole order of magnitude faster than they did on the old computers. Then, some "expert" would trot out, and tell us that, given an extra order of magnitude of computing power, they could lick the whole AOI problem. Lather, rinse, repeat.
Well, we now have machines that are pretty amazing. They can render graphics in real-time that used to take hours per frame on a Cray-1, and the Cray-1 was several orders of magnitude better than the computers they were using when they first started telling us that, given an extra order of magnitude, they'd have the old AI chestnut cracked. Meanwhile, back in the real world, we have computers that, despite all those extra orders of magnitude, have so-called "AI" in games that gets stuck behind rocks or takes some stupid, long way around things because it can't solve a path-finding problem that a blow-fly wouldn't even think about; we're so far from anything approaching true natural language interfaces that it's better to wheel a silly little box around and click buttons just like they were doing at MIT in the 1960s than try and talk to the things, and they can't even make much sense of stuff we take the time and effort to type in; and "machine vision" is so pathetic that it can't drive a wheeled vehicle slowly without bumping into things, falling down holes, and generally behaving like it is blind.
So basically, the great triumph of AI research to date is that somebody's built a bipedal robot which can walk down stairs without falling over, kick a ball not very far without falling over, but unlike an ant, can't identify stuff and then pick it up, or negotiate even a simple obstacle course under its own steam without (you guessed it!) falling over. The culmination of four decades of telling us that true AI is just around the corner is an expensive electronic version of those slinky springs that bionged down stairs and ended up neatly coiled at the bottom, but hey, _this_ time it's _really_ just around the corner because some really intelligent people who study AI are pretty sure of it. All we need is another order of magnitude more computing power, and we'll have robots that can walk down stairs _carrying a cup_!!!.
"I meant that because of the dynamic despatch, it was slower... I still think it's worth it."
I do too. There are few cases where the performance hit is noticeable in practice, but many where the extra flexibility and ease of development pays dividends.
"I think memory management in ObjC is pretty easy though - easier than in C++ I think."
I'm not sure this is the case with modern C++ if one actually writes C++ rather than C with the odd sprinkling of "++" for flavour. Note also that there are some excellent free add-on garbage collectors for C++, so manual memory management isn't mandatory.
"Most of my problems in "the old days" were (ie: before smart pointers came along) were of memory-management issues"
Which is why a lot of work has gone into reducing them. It isn't the fault of C++ that far too many programmers still write what boils down to enhanced C instead of using better features that have been there for around a decade. I'm not saying that memory management issues have been eliminated (far from it), but they can be reduced significantly by the simple expedient of learning to use what's there instead of continuing with the same old bad practices (note that this is not a personal criticism, but a general observation based on a lot of the so-called C++ code that I've seen).
"I wonder if ObjC would have been chosen at all if had been more-similar to Smalltalk / Oberon (I don't know Dylan). For all their flexibility, they are a lot slower than ObjC"
Smalltalk is slower because it is a byte-code compiler that runs on a VM. Note though that the Self project at Sun (long since abandoned, although some of its technologies ended up in "Hotspot" versions of Java VMs) had great success with optimising Smalltalk, resulting in a number of significant speed enhancements.
As for Oberon and Dylan, both are compiled languages whose performance is comparable to Objective-C. Like C, Oberon was designed for (among other things) writing operating systems, so it is capable of producing extremely efficient code from quite simple compiler designs; Dylan on the other hand was originally put together by Apple to provide an efficient dynamic OO language for programming the Newton (which wasn't exactly brimming with CPU power and RAM). Both have full garbage collectors, so memory management isn't an issue (although Oberon can eschew its use for system-level work.
"It's possible the reason we have ObjC is precisely the compromises that were made."
The reason we have ObjC on Macs is because NeXT decided to use it. One fundamental reason for wanting an OO C dialect was ease of interfacing with the headers and libraries of the NeXT cube's underlying Unix, which is something that other OO languages couldn't do, irrespective of how wonderful they might have been in other ways. As is the case today, this left them with a toss-up between (a primitive version of) C++ and Objective-C. Given the fact that ObjC is a true C superset whereas C++ isn't, the choice would have been an easy one even if ObjC hadn't had dynamic message dispatching, categories, and all the other goodies, especially when there was no indication at the time that C++ would achieve the dominant position that it's in now.
"I think the class-library is an intrinsic part of the language - it's hard to tell where ObjC leaves off and NSObject starts"
Some of the old OpenStep can now probably be regarded as part of the standard _system_ since the GNU project settled on its non-visual classes as part of their generic Objective-C class libraries (note though that these are maintained separately from the Objective-C compiler front-end, which can be used quite happily without them). AFAIK there are no longer any commercial Objective-C implementations anymore, and Apple use the GNU compiler, so this is probably as close to a reference implementation as we have today.
"certainly ObjC never really got anywhere on non-Mac platforms until Openstep started to make some headway, and it's
Because that's all a manufacturer can usually report due to the fact that most of them ship to distributors, who in their turn send stuff to retailers -- final retail figures are therefore extremely difficult for them to estimate. Apple still work that way in many places outside the US (although the distributor is often an Apple subsidiary who also handles web sales via localized versions of their online store), where independent retailers still massively outnumber Apple's own outlets.
"Who is the government to tell microsoft that they can't dictate the terms of their licensing to companies?"
The same government that tells every other citizen, corporate or otherwise, that they have to obey laws or face punishment. The choice for citizens who don't like a particular set of laws is simple: break them, and risk being punished, or go somewhere else.
"Imagine what the computer landscape might look like today if compaq and IBM teamed up on OS/2 or even better if IBM jumped on the linux train much much earlier."
Nothing would be different, because Microsoft's DOS was already well established, so by then it was already too late. A better question would thus be: what would have happened if an ongoing anti-trust action against IBM hadn't made them look to outside sources for a PC OS, and they'd chosen instead to write their own one (which is something they were more than capable of doing)?. Without pressure from trust-busters, there would have not been any requirement for IBM to license said OS to their competitors, or use off-the-shelf components instead of unique own-brand ones that nobody else could buy, just like they'd done with all their previous computers. There would be be no clones, and Microsoft would still be peddling BASIC interpreters (or more likely, have ceased to exist by now); would we still have a single largely dominant system on both business and consumer desktops, or a variety of them competing in each segment like the 1980s?
"Everytime Microsoft tries to do this, someone sues them for Monopolizing."
Actually, they sue them for monopolizing when they fold their "it just works" functionality into their OS, thereby preventing it from being removed even if people don't want it, for using discriminatory pricing tactics and even outright threats to discourage ISVs from bundling third-party alternatives, and attempting to artificially divide markets up by forming cartels.
Microsoft could easily have avoided a lot of grief if they'd shipped IE and media player as applications that could be removed instead of folding them into their OS. I have yet to see one adequate technical reason for having such items irrevocably intertwined with the operating system itself, while conversely, the amount of grief caused to users by ensuring that security holes in either became security holes in Windows itself has demonstrated that there are many excellent technical reasons for not doing so. And with Vista, MS are pretty much admitting that there were no good technical reasons, which means that (gasps of shock) their motivation for doing so wasn't technical after all, which is what all those people who are unjustly victimizing them just for being successful have been saying all along.
Now of course, the Microsoft marketing machine is trumpeting about how separating the browser from the OS helps makes Vista more secure. Well blow me down, after years of telling everyone that they couldn't supply Windows with the necessary features if their OS didn't have IE tangled into it, they've discovered a new magic way of having a Windows with _more_ features whose browser behaves just like every other browser that is bundled with every other OS / machine / combination thereof. It obviously required oodles of special MS-brand innovation (similar to other types of innovation, sans the usual requirement for doing something new) to achieve this, but they managed it in the end. And I for one am glad that MS is so big and rich, because only those with access to massive resources could have managed the herculean labour of writing a browser that isn't also part of an OS in a mere three years.
And being from MS , it will let you unwittingly share strange little programs that connect with sites which look incredibly like the official ones, but send all your credit details to people in sub-Saharan Africa.
I thus have the ideal marketing slogan for Microsoft:
"The new Zune. It shares things, and its name rhymes with loon".
I agree with most of what you say, although I'd like to address a few points:
"it's a lot simpler than C++ and I've not found any situation where it restricted what I can do"
The only restriction that annoys me is the lack of user-defined operators. Smalltalk (which was the inspiration for Objective-C) has an extensible hierarchy of classes that represent numbers and all the operations that can be performed on them, so the "object and message" idea is completely pervasive; this allows Smalltalk to (among other things) have classes for extremely large integers and true fractions that inherit from and respond to exactly the same messages as those representing in-built CPU types. Unfortunately, one cannot implement such a hierarchy in Objective-C (a shortcoming shared by Java), whereas C++ allows it via the controversial "operator overloading" mechanism. I can understand the various technical reasons for not including it, but IMO this should be a choice for programmers rather than one that language designers make for us.
"It's not as fast, but nearly so."
Objective-C as a language is at least as fast as C++. The reason applications tend to be slower comes from the message dispatch system, which is dynamic and (in procedural parlance) binds calls at run-time instead of resolving them during the compilation phase. In most cases, the gains in terms of flexibility are worth the performance hit that this incurs, but there are some application areas where this is not the case. It is therefore fortunate that Objective-C lets us write C code for those occasions where speed is of primary importance, and that such code is compiled as C (which is not the case with C-like code in a C++ compiler).
"It doesn't have templates, but the dynamic method despatch can pretty much replace that."
Actually, it's more a case of templates adding some of the advantages of dynamic dispatch to languages that lack it, in a way that fits in with their statically-typed nature. This is why dynamic systems tend to have the facility designed into them from the beginning, while templates are usually added to static languages at a later date when it is found that certain types of programming become very complex and clumsy without them (C++, Java, and C# originally lacked templates).
"formal protocols are pretty much the same as Java interfaces"
They are similar at a conceptual level, but once again the dynamic nature of Objective-C means that formal protocols are less restrictive than interfaces. Tu use a Java interface, one must include it in a class's "implements" clause, whereas any class that has the required set of methods conforms to a formal protocol, irrespective of whether the compiler "knows about it" during the compilation phase. Thus, in Objective-C, the only difference between a class that merely conforms to a formal protocol and one that specifically implements it is an extra level of type safety (which is in most cases desirable), as the compiler will flag a specific implementor that doesn't fully conform to the protocol.
"I can define a category on a class which adds methods to the class, even without the source code to that class."
This is a very powerful feature that Dylan and Oberon share with Objective-C, but few other compiled imperative OO languages have. It really comes into its own when used in conjunction with protocols, because one can add the requisite methods of a protocol to existing framework classes without affecting the framework itself, or other applications that use it.
"It doesn't have garbage collection"
The original Objective-C had garbage collection, so the fact that Apple's version still lacks it can be regarded as an indication that Apple haven't as yet fully implemented Objective-C.
"it does intrinsically support reference counting"
But in an annoyingly manual way, much like Microsoft's COM. COM had to do this because it is a language-independent system that cannot make any assumptions about the host langua
" In C++, I have to create an object instance if I want to call any class function, even if it's not specific to a particular instance."
You obviously don't know how to program in C++:
class Silly {
public:
static const char *GetName() {return "SillyClass";} }...// Now call it, without an instance
printf("%s\n", Silly::GetName());
A couple of notes:
1) In general, C-style fixed length character arrays (and indeed C pointers of all types) should be avoided in C++, which together with the STL, has much more robust mechanisms that do most if not all of the same jobs. The example above is however excusable due to the fact that is is returning a pre-compiled constant via a constant pointer -- it is also both simple and understandable to those not familiar with the STL.
2) C library functions such as "printf" should also be avoided for the same reasons. It is only present in my example because the parent post used it, and things are generally clearer if a reply utilises the same idioms as the original.
Finally, it pays to learn at least the rudiments of a language before publicly claiming that it cannot do something. The use of the "static" keyword to declare class variables and methods is kindergarten C++, not "deep voodoo" that only gurus know about.
"the press called it a ranch because that's what they were told."
It probably has more to do with the fact that most of the journos from the mainstream press have never been near a ranch, and got their ideas of what one is from watching "Dallas", i.e. a house in the middle of a big piece of Texas land where people who got rich from oil walk around in cowboy hats trying to look like good ol' regulah peepuh. "Hey theah, m' name's Geeowge. Come ohn in, tek the weight off yo' feet, and stay awhaal. Aahl tell thuh li'l wom'n teh cook up a mess o' vittals, 'n' when ah bellies're good 'n full, we all can jus' sit on th' pawch an' chaw the fat fo' a whaal".
Theses guys want to use the latest greatest version of Windows to convince people that they need to buy new hardware."
You hit the proverbial nail right on its head. All of those predicting doom for MS because Vista has steep hardware requirements seem to be forgetting the fact that exactly the same things have been said about nearly every version of Windows. This, said the technocrati with predictable regularity, will be the year of Linux On the Desktop, because people are getting fed up with having to buy new hardware every time Microsoft bring out a new OS version that won't run on what they have, despite the fact that it has hardly any compelling new features to justify needing so much memory, HD space, CPU cycles, or whatever.
And so Vista approaches, and MS, as has been their habit for nearly two decades, once more relegate a slew of promised features to the vapourware bin while maintaining the steep hardware requirements, and the technicrati start singing the same old song, because they don't realise that Microsoft's real customers are the OEMs who actually pay for Windows licenses, not the people who buy from those OEMs.
Why has Vista sacrificed nearly everything except the eye candy? Because eye candy is something people who walk into a place that sells computers or see a friend's new machine will notice immediately, and ask why these new Windows boxes look so much better than the one they bought last year. And if that machine from last year lacks some component required to take full advantage of said eye candy, they'll have to buy a new one, with a legitimate, Genuine Advantage version of Vista on it. The OEMs make money, Microsoft make money, and Joe Blow has a machine that looks really great compared to his old one. Everybody is happy except for the technocrati, who will now have to wait for the first really nasty piece of Vista malware before proclaiming a new Year Of Desktop Linux.
"The ability to have intelligent free-form conversations with the computer, is far beyond current technology."
That's not what they did, though. In most cases, a very small selection of the crew asked what were generally quite simple questions, and the ability to respond to voice input from a limited group of people is not "far beyond current technology". The way people interacted with the HAL-9000 in 2001: A Space Odyssey is however probably a very long way off.
"Even voice synthesis is currently in a pretty bad state (ever listened to one of the commercial screen-readers for blind people?)"
Because there hasn't been any notable investment in specialist hardware for speech synthesis since the 1980s due to the fact that the market for it is very limited. I have a two decade-old Amiga which has a built-in hardware phoneme synthesizer that does at least as good a job of vocalizing from text files as any of the modern systems, so we can only imagine what things would be like if that technology had seen the same level of investment as has gone into graphics accelerators, for example. If that had been the case, the speech-driven UI on ST:TOG might well seem as primitive as those chunky "futuristic" computer graphics displays in SF movies and TV series' from the 1980s.
"the Mono inititive there will do much to initiate some quaking in Microsoft's boots."
It will not make Microsoft even blink, let alone quake, because:
1) mono is currently a partial.NET 1.1 implementation, while MS have shipped.NET 2, and are well on the way to.NET 3. Microsoft are therefore setting the agenda, while mono pants along several leagues behind, desperately trying to catch their coat-tails. Meanwhile, mono is an excellent way of making out that MS are a nice, public-spirited company: "look, we submitted C# and MSIL to a standards body, released usable source to both via our Rotor initiative, and these have allowed open source programmers to build versions of our flagship.NET system for Linux, Macs, FreeBSD, etc. Anti-competitive? Not us!".
2) Microsoft execs are making very supportive noises about mono. And why wouldn't they? Here are a bunch of people doing all the work of implementing something on Linux that helps fulfill the entire raison d'etre of.NET, i.e. killing Java. And once Java is dead, MS can pull out their trump card, and scupper the mono project using software patents. Companies who wrote.NET software for Linux will thus have to decide whether to rewrite everything in Python, Ruby, or whatever, or simply switch to Windows, where it will run with little or no modification. And of course, MS will be there to help them "migrate", while the stubborn ones who decided to stick with Linux or whatever and rewrite will effectively be on their own. Guess which option most companies will choose...
So what looks to you like MS execs quaking is actually them trying to suppress laughter and the urge to do little jigs of glee, because they can't believe how quickly and easily the open source community fell for such an obvious ploy.
IBM used to do the same thing when they were a monopoly, so it seems to be a standard monopoly tactic, at least in the IT world. And the strange thing is that it works over and over again on the same people, which brings to mind an old saying:
A wise man learns from the mistakes of others. Most others learn from their own mistakes. But a fool never learns.
To be fair, the fact that a typical UNIX sysadmin tends to be just a tad more knowledgeable than an average Windows user may have at least some bearing on this. IMO the people using a system are a fundamental component of that system, so a deficient user will result in a deficient system, irrespective of how well designed the technological bits are (this doesn't mean I think Windows is well designed!).
Slashdot Mirror
"Which is almost definitely true that they would work under whatever license they were paid to. The difference is that most of the code they wrote to get those paychecks would have stayed locked up as has happened with OSX."
Whether or not it would have stayed locked up has no bearing on the assertion that the GPL is important to Linux's success. All that matters to those paid developers is that _they_ have access to the source code, and source code to just about anything can be obtained legally by the likes of IBM, for whom a few million in licensing fees is chump-change.
"As for there being any chance that Linux would have been as successful under another license, that's kind of a no brainer. There's almost no way it could have been. Just look at what has happened to the BSDs. Sure they're around and people work on them and use them, but they're not nearly as big a deal as Linux "
And Linux is not nearly as big a deal as Windows, so by your logic, Windows must have a license that is far superior to the GPL, and Apple's iTunes store owes its success to licenses that are that are just a bit nicer than those of the competition.
Ballmer: "it's about licenses, licenses, licenses!".
Jobs: "The next thing I'm going to show you is a new license that we've been working on for quite a while. You're going to love this...".
"I didn't say it would not have existed without the GPL. I said I think GPL licensing had a significant positive factor in it's rapid growth."
If you said "was a significant factor in its rapid development", I would be in full agreement.
"Above and beyond developers' passion, it's worth noting that - as you know - GNU existed before Linux, and having Linux GPLed means that they are very easy bedfellows."
It did indeed, although it should be noted that GNU tools have also been used for a wide variety of non-GPL projects over the years, mainly due to the fact that they capable of targeting a wide variety of platforms and architectures (which is of course due to their profoundly open nature).
"GNU has vocal proponents in the shape of Stallman and the FSF, while the BSD arena doesn't seem to have a similar counterpart."
This is very true. However, most non-Geeks haven't heard of the FSF or RMS, and a good many of those who have regard RMS in particular as being a fringe loony with a cabal of social misfits who worship him and therefore believe everything he says. Linus Torvalds is far more famous outside geekdom (and indeed inside it), and has I think done far more for Linux in particular than RMS because he presents it as something that has concrete benefits rather than part of a social movement consisting of what the public at large thinks of as people who get nosebleeds arguing about Star Trek and whether Spiderman could beat the Green Lantern.
So perhaps it would be more accurate to say that what the BSDs lack is an equivalent for Linus, i.e. a person who is not only quite well known by both geeks and non-geeks, but also respected by both groups because he can talk to each of them in terms they understand without pissing many people off.
"None of the examples you cite are developed under the BSD license."
Where did I say they were? I stated that they are available under _less restrictive_ licenses than the GPL, period.
"Mozilla is GPL'd (the MPL is also available, which is also copyleft)".
You are correct -- I was wrong in this case.
"Apache is also under a copyleft license (see 4. Redistribution) which is effectively viral as any licensing must not conflict with the APL"
BSD code cannot be used in ways that conflict with the BSD license either, so by your definition it is also viral, and so are all other licenses apart from those of public domain works. And when one considers that the entirety of the APL basically states that compliance is a matter of leaving any copyright notices in source code (which does not have to be made available to others in any shape or form), and distributing a text file containing this copyright information to end-users, it begins to look very much like the BSD license indeed, where one is also required to maintain the original copyright info in source files that don't have to be made available to anyone else, and tell end-users about said copyrights.
Thus, while I was wrong about the MPL, you are also wrong about the APL, which is as close to a BSD license as it is possible to get without being a BSD license: score 1-1.
"I think you're really missing the point. Consider the reasons why Open Darwin failed as a project."
Indeed. But as you'll see in a moment, it is you who is missing the point.
"So why was nobody interested in Open Darwin? Because it's Apple's product."
Open Darwin had nothing to do with Apple -- It was an entirely third party effort at making a fork of Apple's Darwin. The rest of your comments about sense of community etc. do not therefore require answering, because they are entirely based on your own misconceptions about Open Darwin.
"It's naive to believe that GPL vs BSD has nothing to do with the failure of Open Darwin"
Not as naive as failing to read the article, and thus assuming that Open Darwin and Apple Darwin are one and the same. Again, the rest of your comments are irrelevant, because they address points that are not pertinent to any issue surrounding Open Darwin's closure.
I severely doubt that Linux would have ceased to exist (or be still-born) without the GPL, because the sheer number of thriving open source projects with much more liberal licenses indicates that there are a lot of hackers who don't like the FSF or anyone else telling them what they can do with stuff they write. Would it have been as successful under a different license? Nobody can really say for sure, but not being GPL hasn't stood in the way of Apache becoming the most popular web server, and Apple have managed to put at least as many primarily BSD-based UNIX-like systems on desktops as all the Linux distros put together. Note also that Linux as a system rather than merely a kernel originally lifted a lot of BSD code, so BSD also played a significant role in its genesis (and portions of it are still there), as did Minix, which Linus used to write and test Linux in the early days (but did not, as some primarily MS-paid shills have claimed, copy any Minix code).
The creation, subsequent amplification, and promotion of Linux is therefore rather more complex in licensing terms than certain GPL advocates like to pretend, especially nowadays, when Linus Torvalds is telling us that most of the significant contributions to the Linux kernel come from paid programmers working in companies such as IBM, RedHat, and Novell/Suse, most of whom would work under any license that had a pay-check on the end of it.
Ah, so BSD-style licenses explain why Apache, the various Mozilla projects, and Python have been total flops that nobody uses for anything.
Let's get real for a moment. Linux has become popular on servers for the same reason Java did, i.e. it generated a lot of press buzz, and has companies like IBM and HP pushing it to their customers (which they call "partners" to make things look cosy and pally). This means that the majority of corporate Linux setups (and by corporate, I mean any corporation, big or small) were chosen by people who don't know or care what the GPL is, have never heard of Stallman or the FSF, think a Gnu is a type of ungulate that lives in Africa, and would be happily using one of the BSDs if that was what their big "we take care of everything" hand-holding "partner" was telling them to use instead. Geeks within such companies have zero real-world input into any money based decision-making process, and use what they're told to use, hence the fact that Microsoft can sell them Windows and MS-Office for their their desktops, server-side Windows with Exchange for departmental services, Visual Studio for development, while Linux with Apache etc. live on their web server farms. If these people gave a fart about things like the GPL or what their pet geeks think is great, they wouldn't let anything from MS within a mile of their corporate buildings, and would be using open source tools to build their Linux-hosted webs instead of costly proprietary stuff like WebSphere and Tivoli, which are just incidentally supplied by those same "partners" who recommend, install, and support Linux.
The GPL is therefore no more relevant to Linux's success than a lack of it has been to the immeasurably greater success of Microsoft's products. It is popular on servers because it works, is free as in beer, leverages existing corporate UNIX expertise, and a lot of business people have heard of it thanks to their everything-including-the-kitchen-sink IT service "partners", whereas few have heard of the various BSD variants. By the same token, it is a flop on the desktop because, for far too many non-geeks without access to a geek, it doesn't work properly with the hardware they have, fails to leverage their (albeit minimal) expertise with other operating systems and software, and most consumers either haven't heard of it, or know the name but are extremely hazy about what it is.
"many of the problems to be solved require massive computational power"
:)"
This may be the case for true intelligence of a human-like level, but many of the tasks that are grouped under the general category of AI research should not be particularly computationally intensive because creatures of very limited intelligence manage them with ease. It is the fact that some of these things are proving difficult despite the application of massive computing power which convinces me that any real breakthroughs will come from outside the computer-based AI community.
"I expect most of a fruit fly's capabilities could be replicated, but few think the investment would be worth it"
I doubt we could replicate the way their visual systems work, because there is no artificial vision system that allows an autonomous machine to move around in three dimensions as well as a fruit fly. As I said above, the fact that we cannot do this despite the application of massive computing resources would seem to indicate that massive computing resources are not the answer, because fruit flies obviously do not use massive computing resources to solve that particular problem (or for that matter, any other problem).
"The AI in games gets limited development resources"
Everything has limited development resources.
"After the DARPA Grand Challenge I'm surprised at how well they've done with the limited computational power available (though I think they may have made it a little easier this year)"
I don't think they've done very well at all. Insects routinely handle much more complex challenges as part of their daily lives, and insects have remarkably little in the way of raw processing power. There is obviously a fairly simple and extremely robust solution to this sort of problem that nature found many hundreds of millions of years ago, so perhaps we should be spending a lot more time and money investigating and trying to duplicate that ancient and massively successful solution instead of wasting our time trying to crack it with brute computing force.
"If we manage to make them truly logical, that alone may make them difficult for many people to understand
I don't think that logic will be the barrier, but rather the fact that the first "intelligent" systems will be designed to solve a specific narrow set of problems, and will therefore "think" in terms that fit the problem domain. IMO general purpose intelligence of the sort we have will take a quite a long time to appear because we do not understand enough about the way our own brains work to even begin the task of modeling their functionality, even if we did have enough computing power to do so. And the fact of the matter is that there is no real reason to bother making an "artificial human", because real humans can be produced very easily and cheaply. There are however many applications for specialised "intelligent" systems capable of performing certain tasks that require humans today, but doing so more quickly and / or reliably (e.g. reading documents, verifying signatures, piloting vehicles of all types, exploring hostile environments without supervision, controlling advanced weapons systems, etc., etc., etc.).
Agreed in full. However, I doubt that such a breakthrough will come from the AI research community, who have consistently failed to match the advances made in virtually all other fields of computing. It is I think more likely that intelligent machines will emerge from some other research area, possibly as a side-effect of technology that is at best only tangentially related to our current concepts of computing. Research into cognition and behaviour indicates that animals (including humans) process their environment using non-deterministic predictive mechanisms that require a minimal set of "cues" to act as prediction branch keys (and can therefore be "tricked" by things like optical illusions, sleight of hand, and camouflage). Trying to emulate such mechanisms using deterministic reactive processes is thus a blind alley that will demand ever more computing power to approximate what nature has achieved using small portions of fairly simple creatures such as fruit flies, with materials that carry and process signals at a tiny fraction of the speed that today's computers are capable of, and that have minimal energy requirements.
I also doubt that the first truly intelligent machines will be "human emulators" that can pass the Turning test -- indeed, I think it is likely that their very nature will mean that their "thought processes" are quite alien to us, although we will obviously require some method of interacting with them, just as we (for example) have ways of interacting with working dogs, who also "think" in ways that are quite distinct from our own. This will of course be used by some to "prove" that such machines are not intelligent at all, because a lot of goal-post moving has gone into arguing that anything a machine can do is simply a mechanical process that requires no intelligence whatsoever. If you'd asked someone from the 19th century whether something that can play chess at international Grand Master level, solve complex mathematical formulae, and compose music and poetry (admittedly badly, but then the same can be said of nearly all humans!) was intelligent, they would have undoubtedly replied in the affirmative, but each of these tasks has been progressively removed from the ever-shortening list of "intelligent stuff" whenever someone demonstrates a machine that can do them.
So when (and I do believe it is a when rather than an if) machine intelligence does appear, the "it's not really intelligent" crowd will be left with an ever-shrinking Adamsian list of things that "prove" it's just an algorithm after all ("Intelligent? No way! When was the last time you saw a machine go out and spend money it didn't have on something it didn't need because of an advertisement, lay in the sun long enough to damage itself severely, claim to have seen Elvis working as a waiter in a Chinese restaurant, or set fire to itself and everyone around it trying to light a barbecue with gasoline?").
"Do you really think you are well justified in such a high level of confidence, when there are probably people who are more intelligent and more well informed about AI than you or I, and who also think we are close to strong AI?"
Unfortunately, it's a case of crying wolf once too often. As the GP says, clever people who are extremely well informed about AI have been telling us that we're close to it for four decades. All that was required, they'd say, was an order of magnitude more computing power, and we'd be there. And when they had that extra order of magnitude, we saw computers solve the N Queens and Traveling Salesman problems a whole order of magnitude faster than they did on the old computers. Then, some "expert" would trot out, and tell us that, given an extra order of magnitude of computing power, they could lick the whole AOI problem. Lather, rinse, repeat.
Well, we now have machines that are pretty amazing. They can render graphics in real-time that used to take hours per frame on a Cray-1, and the Cray-1 was several orders of magnitude better than the computers they were using when they first started telling us that, given an extra order of magnitude, they'd have the old AI chestnut cracked. Meanwhile, back in the real world, we have computers that, despite all those extra orders of magnitude, have so-called "AI" in games that gets stuck behind rocks or takes some stupid, long way around things because it can't solve a path-finding problem that a blow-fly wouldn't even think about; we're so far from anything approaching true natural language interfaces that it's better to wheel a silly little box around and click buttons just like they were doing at MIT in the 1960s than try and talk to the things, and they can't even make much sense of stuff we take the time and effort to type in; and "machine vision" is so pathetic that it can't drive a wheeled vehicle slowly without bumping into things, falling down holes, and generally behaving like it is blind.
So basically, the great triumph of AI research to date is that somebody's built a bipedal robot which can walk down stairs without falling over, kick a ball not very far without falling over, but unlike an ant, can't identify stuff and then pick it up, or negotiate even a simple obstacle course under its own steam without (you guessed it!) falling over. The culmination of four decades of telling us that true AI is just around the corner is an expensive electronic version of those slinky springs that bionged down stairs and ended up neatly coiled at the bottom, but hey, _this_ time it's _really_ just around the corner because some really intelligent people who study AI are pretty sure of it. All we need is another order of magnitude more computing power, and we'll have robots that can walk down stairs _carrying a cup_!!!.
"I meant that because of the dynamic despatch, it was slower ... I still think it's worth it."
I do too. There are few cases where the performance hit is noticeable in practice, but many where the extra flexibility and ease of development pays dividends.
"I think memory management in ObjC is pretty easy though - easier than in C++ I think."
I'm not sure this is the case with modern C++ if one actually writes C++ rather than C with the odd sprinkling of "++" for flavour. Note also that there are some excellent free add-on garbage collectors for C++, so manual memory management isn't mandatory.
"Most of my problems in "the old days" were (ie: before smart pointers came along) were of memory-management issues"
Which is why a lot of work has gone into reducing them. It isn't the fault of C++ that far too many programmers still write what boils down to enhanced C instead of using better features that have been there for around a decade. I'm not saying that memory management issues have been eliminated (far from it), but they can be reduced significantly by the simple expedient of learning to use what's there instead of continuing with the same old bad practices (note that this is not a personal criticism, but a general observation based on a lot of the so-called C++ code that I've seen).
"I wonder if ObjC would have been chosen at all if had been more-similar to Smalltalk / Oberon (I don't know Dylan). For all their flexibility, they are a lot slower than ObjC"
Smalltalk is slower because it is a byte-code compiler that runs on a VM. Note though that the Self project at Sun (long since abandoned, although some of its technologies ended up in "Hotspot" versions of Java VMs) had great success with optimising Smalltalk, resulting in a number of significant speed enhancements.
As for Oberon and Dylan, both are compiled languages whose performance is comparable to Objective-C. Like C, Oberon was designed for (among other things) writing operating systems, so it is capable of producing extremely efficient code from quite simple compiler designs; Dylan on the other hand was originally put together by Apple to provide an efficient dynamic OO language for programming the Newton (which wasn't exactly brimming with CPU power and RAM). Both have full garbage collectors, so memory management isn't an issue (although Oberon can eschew its use for system-level work.
"It's possible the reason we have ObjC is precisely the compromises that were made."
The reason we have ObjC on Macs is because NeXT decided to use it. One fundamental reason for wanting an OO C dialect was ease of interfacing with the headers and libraries of the NeXT cube's underlying Unix, which is something that other OO languages couldn't do, irrespective of how wonderful they might have been in other ways. As is the case today, this left them with a toss-up between (a primitive version of) C++ and Objective-C. Given the fact that ObjC is a true C superset whereas C++ isn't, the choice would have been an easy one even if ObjC hadn't had dynamic message dispatching, categories, and all the other goodies, especially when there was no indication at the time that C++ would achieve the dominant position that it's in now.
"I think the class-library is an intrinsic part of the language - it's hard to tell where ObjC leaves off and NSObject starts"
Some of the old OpenStep can now probably be regarded as part of the standard _system_ since the GNU project settled on its non-visual classes as part of their generic Objective-C class libraries (note though that these are maintained separately from the Objective-C compiler front-end, which can be used quite happily without them). AFAIK there are no longer any commercial Objective-C implementations anymore, and Apple use the GNU compiler, so this is probably as close to a reference implementation as we have today.
"certainly ObjC never really got anywhere on non-Mac platforms until Openstep started to make some headway, and it's
"Everyone in the industry reports units shipped"
Because that's all a manufacturer can usually report due to the fact that most of them ship to distributors, who in their turn send stuff to retailers -- final retail figures are therefore extremely difficult for them to estimate. Apple still work that way in many places outside the US (although the distributor is often an Apple subsidiary who also handles web sales via localized versions of their online store), where independent retailers still massively outnumber Apple's own outlets.
"Who is the government to tell microsoft that they can't dictate the terms of their licensing to companies?"
The same government that tells every other citizen, corporate or otherwise, that they have to obey laws or face punishment. The choice for citizens who don't like a particular set of laws is simple: break them, and risk being punished, or go somewhere else.
"Imagine what the computer landscape might look like today if compaq and IBM teamed up on OS/2 or even better if IBM jumped on the linux train much much earlier."
Nothing would be different, because Microsoft's DOS was already well established, so by then it was already too late. A better question would thus be: what would have happened if an ongoing anti-trust action against IBM hadn't made them look to outside sources for a PC OS, and they'd chosen instead to write their own one (which is something they were more than capable of doing)?. Without pressure from trust-busters, there would have not been any requirement for IBM to license said OS to their competitors, or use off-the-shelf components instead of unique own-brand ones that nobody else could buy, just like they'd done with all their previous computers. There would be be no clones, and Microsoft would still be peddling BASIC interpreters (or more likely, have ceased to exist by now); would we still have a single largely dominant system on both business and consumer desktops, or a variety of them competing in each segment like the 1980s?
"Everytime Microsoft tries to do this, someone sues them for Monopolizing."
Actually, they sue them for monopolizing when they fold their "it just works" functionality into their OS, thereby preventing it from being removed even if people don't want it, for using discriminatory pricing tactics and even outright threats to discourage ISVs from bundling third-party alternatives, and attempting to artificially divide markets up by forming cartels.
Microsoft could easily have avoided a lot of grief if they'd shipped IE and media player as applications that could be removed instead of folding them into their OS. I have yet to see one adequate technical reason for having such items irrevocably intertwined with the operating system itself, while conversely, the amount of grief caused to users by ensuring that security holes in either became security holes in Windows itself has demonstrated that there are many excellent technical reasons for not doing so. And with Vista, MS are pretty much admitting that there were no good technical reasons, which means that (gasps of shock) their motivation for doing so wasn't technical after all, which is what all those people who are unjustly victimizing them just for being successful have been saying all along.
Now of course, the Microsoft marketing machine is trumpeting about how separating the browser from the OS helps makes Vista more secure. Well blow me down, after years of telling everyone that they couldn't supply Windows with the necessary features if their OS didn't have IE tangled into it, they've discovered a new magic way of having a Windows with _more_ features whose browser behaves just like every other browser that is bundled with every other OS / machine / combination thereof. It obviously required oodles of special MS-brand innovation (similar to other types of innovation, sans the usual requirement for doing something new) to achieve this, but they managed it in the end. And I for one am glad that MS is so big and rich, because only those with access to massive resources could have managed the herculean labour of writing a browser that isn't also part of an OS in a mere three years.
"WHY THE FUCK IS FORBES BOTHERING TO REPORT THIS?!?"
Because Forbes is written by an accomplished player of the pink oboe.
And being from MS , it will let you unwittingly share strange little programs that connect with sites which look incredibly like the official ones, but send all your credit details to people in sub-Saharan Africa.
I thus have the ideal marketing slogan for Microsoft:
"The new Zune. It shares things, and its name rhymes with loon".
Hi Simon,
I agree with most of what you say, although I'd like to address a few points:
"it's a lot simpler than C++ and I've not found any situation where it restricted what I can do"
The only restriction that annoys me is the lack of user-defined operators. Smalltalk (which was the inspiration for Objective-C) has an extensible hierarchy of classes that represent numbers and all the operations that can be performed on them, so the "object and message" idea is completely pervasive; this allows Smalltalk to (among other things) have classes for extremely large integers and true fractions that inherit from and respond to exactly the same messages as those representing in-built CPU types. Unfortunately, one cannot implement such a hierarchy in Objective-C (a shortcoming shared by Java), whereas C++ allows it via the controversial "operator overloading" mechanism. I can understand the various technical reasons for not including it, but IMO this should be a choice for programmers rather than one that language designers make for us.
"It's not as fast, but nearly so."
Objective-C as a language is at least as fast as C++. The reason applications tend to be slower comes from the message dispatch system, which is dynamic and (in procedural parlance) binds calls at run-time instead of resolving them during the compilation phase. In most cases, the gains in terms of flexibility are worth the performance hit that this incurs, but there are some application areas where this is not the case. It is therefore fortunate that Objective-C lets us write C code for those occasions where speed is of primary importance, and that such code is compiled as C (which is not the case with C-like code in a C++ compiler).
"It doesn't have templates, but the dynamic method despatch can pretty much replace that."
Actually, it's more a case of templates adding some of the advantages of dynamic dispatch to languages that lack it, in a way that fits in with their statically-typed nature. This is why dynamic systems tend to have the facility designed into them from the beginning, while templates are usually added to static languages at a later date when it is found that certain types of programming become very complex and clumsy without them (C++, Java, and C# originally lacked templates).
"formal protocols are pretty much the same as Java interfaces"
They are similar at a conceptual level, but once again the dynamic nature of Objective-C means that formal protocols are less restrictive than interfaces. Tu use a Java interface, one must include it in a class's "implements" clause, whereas any class that has the required set of methods conforms to a formal protocol, irrespective of whether the compiler "knows about it" during the compilation phase. Thus, in Objective-C, the only difference between a class that merely conforms to a formal protocol and one that specifically implements it is an extra level of type safety (which is in most cases desirable), as the compiler will flag a specific implementor that doesn't fully conform to the protocol.
"I can define a category on a class which adds methods to the class, even without the source code to that class."
This is a very powerful feature that Dylan and Oberon share with Objective-C, but few other compiled imperative OO languages have. It really comes into its own when used in conjunction with protocols, because one can add the requisite methods of a protocol to existing framework classes without affecting the framework itself, or other applications that use it.
"It doesn't have garbage collection"
The original Objective-C had garbage collection, so the fact that Apple's version still lacks it can be regarded as an indication that Apple haven't as yet fully implemented Objective-C.
"it does intrinsically support reference counting"
But in an annoyingly manual way, much like Microsoft's COM. COM had to do this because it is a language-independent system that cannot make any assumptions about the host langua
"my understanding is that most of those bridges are being maintained outside of Apple, whereas the Java-Cocoa bridge was an Apple-funded project"
I read somewhere that Apple are at least partially funding the Python/Objective-C bridge.
" In C++, I have to create an object instance if I want to call any class function, even if it's not specific to a particular instance."
... // Now call it, without an instance
You obviously don't know how to program in C++:
class Silly
{
public:
static const char *GetName() {return "SillyClass";}
}
printf("%s\n", Silly::GetName());
A couple of notes:
1) In general, C-style fixed length character arrays (and indeed C pointers of all types) should be avoided in C++, which together with the STL, has much more robust mechanisms that do most if not all of the same jobs. The example above is however excusable due to the fact that is is returning a pre-compiled constant via a constant pointer -- it is also both simple and understandable to those not familiar with the STL.
2) C library functions such as "printf" should also be avoided for the same reasons. It is only present in my example because the parent post used it, and things are generally clearer if a reply utilises the same idioms as the original.
Finally, it pays to learn at least the rudiments of a language before publicly claiming that it cannot do something. The use of the "static" keyword to declare class variables and methods is kindergarten C++, not "deep voodoo" that only gurus know about.
"the press called it a ranch because that's what they were told."
It probably has more to do with the fact that most of the journos from the mainstream press have never been near a ranch, and got their ideas of what one is from watching "Dallas", i.e. a house in the middle of a big piece of Texas land where people who got rich from oil walk around in cowboy hats trying to look like good ol' regulah peepuh. "Hey theah, m' name's Geeowge. Come ohn in, tek the weight off yo' feet, and stay awhaal. Aahl tell thuh li'l wom'n teh cook up a mess o' vittals, 'n' when ah bellies're good 'n full, we all can jus' sit on th' pawch an' chaw the fat fo' a whaal".
Thanks Bertie, I'll certainly have a look. NB, I do speak some Spanish (European variety), so it'll be interesting.
"Dell, Gateway, Lenovo, HP.
Theses guys want to use the latest greatest version of Windows to convince people that they need to buy new hardware."
You hit the proverbial nail right on its head. All of those predicting doom for MS because Vista has steep hardware requirements seem to be forgetting the fact that exactly the same things have been said about nearly every version of Windows. This, said the technocrati with predictable regularity, will be the year of Linux On the Desktop, because people are getting fed up with having to buy new hardware every time Microsoft bring out a new OS version that won't run on what they have, despite the fact that it has hardly any compelling new features to justify needing so much memory, HD space, CPU cycles, or whatever.
And so Vista approaches, and MS, as has been their habit for nearly two decades, once more relegate a slew of promised features to the vapourware bin while maintaining the steep hardware requirements, and the technicrati start singing the same old song, because they don't realise that Microsoft's real customers are the OEMs who actually pay for Windows licenses, not the people who buy from those OEMs.
Why has Vista sacrificed nearly everything except the eye candy? Because eye candy is something people who walk into a place that sells computers or see a friend's new machine will notice immediately, and ask why these new Windows boxes look so much better than the one they bought last year. And if that machine from last year lacks some component required to take full advantage of said eye candy, they'll have to buy a new one, with a legitimate, Genuine Advantage version of Vista on it. The OEMs make money, Microsoft make money, and Joe Blow has a machine that looks really great compared to his old one. Everybody is happy except for the technocrati, who will now have to wait for the first really nasty piece of Vista malware before proclaiming a new Year Of Desktop Linux.
"The ability to have intelligent free-form conversations with the computer, is far beyond current technology."
That's not what they did, though. In most cases, a very small selection of the crew asked what were generally quite simple questions, and the ability to respond to voice input from a limited group of people is not "far beyond current technology". The way people interacted with the HAL-9000 in 2001: A Space Odyssey is however probably a very long way off.
"Even voice synthesis is currently in a pretty bad state (ever listened to one of the commercial screen-readers for blind people?)"
Because there hasn't been any notable investment in specialist hardware for speech synthesis since the 1980s due to the fact that the market for it is very limited. I have a two decade-old Amiga which has a built-in hardware phoneme synthesizer that does at least as good a job of vocalizing from text files as any of the modern systems, so we can only imagine what things would be like if that technology had seen the same level of investment as has gone into graphics accelerators, for example. If that had been the case, the speech-driven UI on ST:TOG might well seem as primitive as those chunky "futuristic" computer graphics displays in SF movies and TV series' from the 1980s.
"the Mono inititive there will do much to initiate some quaking in Microsoft's boots."
.NET 1.1 implementation, while MS have shipped .NET 2, and are well on the way to .NET 3. Microsoft are therefore setting the agenda, while mono pants along several leagues behind, desperately trying to catch their coat-tails. Meanwhile, mono is an excellent way of making out that MS are a nice, public-spirited company: "look, we submitted C# and MSIL to a standards body, released usable source to both via our Rotor initiative, and these have allowed open source programmers to build versions of our flagship .NET system for Linux, Macs, FreeBSD, etc. Anti-competitive? Not us!".
.NET, i.e. killing Java. And once Java is dead, MS can pull out their trump card, and scupper the mono project using software patents. Companies who wrote .NET software for Linux will thus have to decide whether to rewrite everything in Python, Ruby, or whatever, or simply switch to Windows, where it will run with little or no modification. And of course, MS will be there to help them "migrate", while the stubborn ones who decided to stick with Linux or whatever and rewrite will effectively be on their own. Guess which option most companies will choose...
It will not make Microsoft even blink, let alone quake, because:
1) mono is currently a partial
2) Microsoft execs are making very supportive noises about mono. And why wouldn't they? Here are a bunch of people doing all the work of implementing something on Linux that helps fulfill the entire raison d'etre of
So what looks to you like MS execs quaking is actually them trying to suppress laughter and the urge to do little jigs of glee, because they can't believe how quickly and easily the open source community fell for such an obvious ploy.
IBM used to do the same thing when they were a monopoly, so it seems to be a standard monopoly tactic, at least in the IT world. And the strange thing is that it works over and over again on the same people, which brings to mind an old saying:
A wise man learns from the mistakes of others.
Most others learn from their own mistakes.
But a fool never learns.
To be fair, the fact that a typical UNIX sysadmin tends to be just a tad more knowledgeable than an average Windows user may have at least some bearing on this. IMO the people using a system are a fundamental component of that system, so a deficient user will result in a deficient system, irrespective of how well designed the technological bits are (this doesn't mean I think Windows is well designed!).