I think hardware support simply isn't sufficient: the semantics of sharing data structures is simply too complex to be implemented meaningfully in hardware, and programs written in C/C++ don't even give the system enough information to set up the hardware bits automatically.
I agree that it's politically difficult to get people to use safe languages. My point is just that: Miguel shouldn't complain about UNIX if he is part of the problem. My point is also that the myriad of workaround (COM+, CORBA, etc.) that are supposedly "in C/C++" are actually much worse and more complex than the alternatives. The extensions Objective-C makes to C are trivial compared even to just IDL. And mastering Java or Modula-3 is much simpler than learning COM, IDL, CORBA, plus their numerous libraries even for an expert C++ programmer.
With Java, things are changing slowly. But I won't hold my breath for a mass conversion. Miguel's attitude is exemplary of the irrational views of most of the industry.
The problem isn't the function call itself, it's the data (things that pointers you pass around point to). Either you share the data between the two things that call each other, in which case it can get corrupted if you are using C/C++, or you don't share the data, in which case you need to copy and things are slow.
You might add hardware support to keep C/C++ from corrupting such shared data. Essentially, you'd be putting Purify or other pointer checking in hardware. That would be an OK solution, although it would be suboptimal: if you address the problem in general, you'd be spending a lot on hardware to support the C/C++ pointer model, without a commensurate benefit.
The best technical solution is to dump C/C++. Languages like Modula-3 (and many others) give you the same efficiency without the problems, and they run well on existing hardware.
I think the most important of your points is UNIX IPC sucks. You are right that you want a procedure call, but what you get is an I/O operation. And the reason for that is that unsafe languages like C/C++ require hardware memory protection to keep them from crashing each other. So, to move any data, you have to go through the kernel or fiddle with shared memory.
To fix this, the only way is to ditch C/C++. There are plenty of simple, efficient alternatives, including Modula-3, Oberon, Eiffel, Limbo, and Sather. Java may eventually make it as well.
As for text-file based administration, people use it because it works. Registry-like mechanisms have been tried even before Windows, and they have numerous problems, in particular for server machines. Program files that bundle up more than code are easy to implement under UNIX, and some frameworks use them extensively, but they are also very desktop oriented. To put it differently, Windows and MacOS can do better in these areas because they are solving a more specific problem: desktop applications and simple business server applications. UNIX has been used extensively for supercomputing, engineering, data mining, server farms, and there, those desktop mechanisms are more of a nuisance than a help.
As for naming, Plan 9 does what you suggest, and I hope a bit more of it will move into Linux.
GTK is indeed quite flexible when it comes to binding to other languages, but that's not the point.
Miguel is frustrated with development and lack of componentization, and that's a problem with the tools he develops in, foremost C. Adding foreign language bindings to a messy, complex, difficult to extend system doesn't make the system itself less messy, complex, and difficult to extend. And binding C APIs to a safe language merely makes the safe language potentially unsafe.
I do prefer GTK with its C-based foreign language bindings to other toolkits that are much more biased towards C++. But to really address the problems Miguel is complaining about, you have to ditch C altogether, from bottom to top. Bonobo will not fix things.
Yes, C/UNIX has ceased to be a platform for innovation. In fact, arguably it never was a platform for innovation.
But if Miguel wanted to help improve the situation, why did he go off developing such a huge software project in C on UNIX? It is C that makes component based development such a pain. C lacks even minimal support for component based development (e.g., no dynamic typing, no reflection), and it is impossible to make large, component based systems in C both robust and efficient: there is no fault isolation--a bad pointer in one component will crash other components unless you put them in separate processes.
The answers to these problems are well known. Systems like Smalltalk-80 and the Lisp machine were fully integrated, component based environments where everything talked to each other. And almost any language other than C and C++ is better for component-based development and provides reuse.
Microsoft does not have the answer. Microsoft's component model, COM, has very serious problems. It's complex because the languages it is based on don't have any support for component based development. And despite its complexity, it is still dumbed down because anything else would be umanageable in C/C++. And it has no fault isolation, meaning that if you load a bunch of COM components and your program dies, you have no idea what went wrong.
In fact, UNIX had an excellent, reusable component model: command line programs that interchange data with files. That's no good for building a graphical desktop, but it was excellent for the UNIX user community--people manipulating lots of data. And that model has been extended to graphical desktops and networked systems in Plan 9 and Inferno, which also address many of the other problems with C/C++ through Alef and Limbo. Or, alternatively, Objective-C and OpenStep managed to build something that support powerful reuse and component based development on top of UNIX. And Java is excellent at supporting both component-based programming, reuse, and fault isolation.
If Miguel genuinely wants to improve the situation, why isn't he using the tools that will let him do so? Why isn't he learning from the long history of component-based development that preceded both him and Microsoft? Why is he copying Microsoft's mistakes and mediocrity? Why isn't he supporting tools that genuinely make a difference rather than encouraging the use of tools (C/C++) that were never intended for this kind of work?
People say about democracy that "it is the worst form of government, until you have tried the others". I think the same is true about UNIX. Gnome and GTK help improve the usability of a flawed tool. As such they are really welcome. But by not addressing the root causes of the problems, we'll probably be here discussing the very same problems again in another 15 years, because everything people complain about UNIX was known 15 years ago, nobody fixed it, and it (and its clone--Windows) still became immensely popular.
This is science by press release again. There's no link from the press release to any technical report, and the language of the press release seems to be written to attract attention.
There are several papers by Arkani-Hamed on arXiv, if you want to get technical details (although it's hard to tell whether the work referred to in the press release actually has already been published).
Modeling the universe with more than 3+1 dimensions to account for the various forces has been common since the 20's, and it's already a big part of string theory. If the press release reflects what's in the papers, it appears, however, that Arkani-Hamed and co-authors are claiming that the extra dimensions are spatially extended.
3rd party X11 server == MacOS X as desktop client
on
MacOSX and X11
·
· Score: 2
As a local desktop window system, X11 is both overkill and limited in some areas. That's why we see all these complaints about poor font support, lack of antialiasing, etc.
But the real importance of X11 is in scientific and engineering environments, as well as large server farms. There, people run GUI-based and visualization software on big machines in machine rooms and display and steer it from their client workstations/PCs on their desktop. Despite the various attempts at providing such functionality on top of MacOS and Windows (CarbonCopy, Timbuktu (?), etc.), X11 is still the best for that: it allows application writers to write applications that are client/server aware and work well across lots of platforms. Having a good, commercial X11 server available for MacOS X makes MacOS X a good desktop client platform in such environments.
But because MacOS X (presumably) cannot use the X11 protocol for displaying its native applications and administration tools on remote X11 displays, this still doesn't let MacOS X compete on equal footing with X11-based servers. Making MacOS X a client of an X11 display server in that way could be feasible, though difficult. More likely, we are going to see a passable VNC server adaptation, just like we did with Windows.
Re:Misguided anti-Aqua sentiment
on
MacOSX and X11
·
· Score: 2
People run X11 because there are lots of tools for it, because the API is standardized and stable, and because it works well for distributed computing. And people run Tk because they need to put together GUIs quickly, not because it's pretty.
Windows, MacOS OS, and their toolkits may be nice for the consumer market, but they have all sorts of problems for the scientific and engineering market. One size doesn't fit all, and environments (like Win32 and Aqua) that are designed for making the prettiest consumer applications are not the best for science and engineering applications. X11 is here to stay because it works well for lots of people and because there is nothing on the horizon that fills its niche.
Is it "entirely true"? I don't know. There may be loopholes. But I have advocated open source software at several corporations and talked to a number of corporate lawyers, and ambiguity of the term "distribution" did not come up as a serious concern when they reviewed the GPL.
I also can't tell you definitively what RMS's beliefs are, but he has repeatedly stated that the right not to distribute anything at all is important.
And I'd say that, if not for philosophical reasons, it's important for practical reasons. Many research and development projects that ultimately become open source start off as internal projects. Having some obligation to publish is often not acceptable even in environments committed to open source. That means that the QPL isn't applicable, and it means that, for practical purposes, Qt is an expensive commercial toolkit to such organizations.
There are so many basic things wrong with current UI and systems software that incorporating this kind of technology seems very premature.
With the current level of reliability and interoperabilty, you'll probably be able to conjure up a BSOD or dozens of dialog boxes just by staring at the wrong part of the screen. You know, something like "Cannot notify InstantMessenger of your inactivity. Click [OK] to continue.", or "You aren't paying enough attention to me. Look at me, dammit. (beep) [OK]".
As for the idea itself, sure, it's good research. But the ideas have been around for a number of years, and lots of people are using Bayesian modeling, decision theory, user modeling, and affective computing, so this is not some kind of breakthrough hatched at Microsoft Research.
Adding mlock to zillions of applications that may buffer your password in virtual memory is not feasible (and typing "man mlock" will accomplish nothing).
In the short term, if it's important, you can turn off swapping. But a better long term choice is probably to encrypt swap space with a key that is created at boot time, held in kernel memory, and discarded when the system shuts down/crashes. That addresses the problem once and for all.
The QPL is still seriously restricted for commercial entities (from the QPL FAQ on Troll Tech's site):
11.Using the Free Edition, can I write software for internal use in my company/organization?
The Qt Free Edition is not intended for such use; it is our policy that when you are using Qt for free, you should in return contribute to the free software community. If you cannot do that, you must get Professional Edition licenses instead.
The QPL is still in contradiction to the principles that the GPL was written to uphold, which includes the freedom to use the software for internal purposes. Furthermore, I think the QPL is not suitable for most internal research and developmen use; you must license the commercial version. Be sure you understand exactly what the QPL and Troll Tech require you to do before you invest any time or effort in Qt.
If Troll Tech wanted to have "GPL with a commercial exception", they could simply license Qt under the GPL and offer a separate commercial license for sale like other companies do.
Java is a statically typed, batch-compiled language with existing implementations that perform generational garbage collection and dynamic compilation to efficient native code. Python is a dynamically typed language with reference counting and a highly dynamic object model that is hard to compile to native code. Java has an extensive library (including GUI) that is platform independent that is almost completely written in pure Java, while Python at best has bindings to Tcl/Tk and wxWindows. Java and Python are about as different as languages come.
As for the "Sun-control-freak-mentality", I don't see how Sun's control over Java is any different from the control Guido exercises over Python.
Python is a nice scripting language and a passable extension language. Java is a nice applications programming language and a lousy extension language. Neither is a replacement for the other, and both have their limitations and problems.
There is no way to guarantee that you can delete data by repeatedly overwriting it: there are too many places where they old data may remain duplicated. Hardware simply isn't designed for reliable deletion. The best you can do is to destroy the disk physically when you are done with it.
However, if you use cryptography, for example, the Steganographics File System, and if you implement it securely, then it doesn't matter what people can retrieve.
Of course, with cryptography, you run into some of the same issues. In particular, keeping your keys secure is, in itself, not trivial. For example, if you type in your key and the program that reads the key gets swapped out, your plaintext key will have been written to disk.
Talking to vendors of Linux office suites, one of the biggest problems seems to have been that commercial vendors have been reluctant to implement some features in MS Office clones (foremost, VB/VBScript compatibility) for fear of getting sued on intellectual property grounds. Putting StarOffice under GPL and creating a plug-in architecture may be a good way of addressing this.
Microsoft's documentation is one of the main reasons I loathe developing on their platforms: to me, it's a lot of verbiage with very little actual content.
I think we see different programming styles here. Microsoft's platforms seem great for hacking, experimenting, and poking around, but as far as I'm concerned, they aren't great for planning and implementing software in a well-defined, logical manner.
As for their "releasing source code", you make it sound like they are an open source company. Nonsense. The examples they publish are solely for getting people to be able to do anything at all with their messy APIs. The source code they publish is completely useless outside their environment, and (usually) the license prohibits any other use anyway.
Saving state across machines is hardly a big deal: many web applications do it trivially because they save state in a client/server relational database. Object/relational mappers or client/server object oriented databases automate the process for languages like Java and C++.
As for Eiffel, I think the importance you attribute to it is greatly exaggerated. Meyer didn't invent the concept of "design by contract", and it was widely used before Eiffel ever saw the light of day (and is widely used in Java and C++ today). Eiffel is a simple, efficient, if somewhat limited and flawed, OOL, but it isn't a major milestone of language design or computer science. To me, the co-appearance of Meyer and Gates, however, reflects poorly on Eiffel: it looks like Eiffel is now driven by fashion than by principle.
The reasons why functional languages are not more widely used are the same reasons why other "minority" languages aren't more widely used: lack of training and lack of vendor adoption. Also, the creators of functional programming languages make adoption hard by picking somewhat unusual syntactic features.
It's hard to explain in a paragraph or two why functional programming is so great. Suffice it to say that it allows for much more reuse than object-oriented programming, opens up whole new ways of abstracting out functionality, and prevents one of the most common sources of bugs--aliasing.
Not all functional programming languages are purely functional. In fact, many programmers program in such functional programming languages like they do in Perl or Python. That can be both bad and good. On the one hand, because functional programming languages are powerful even for procedural programming, they may never be encouraged to learn how to take advantage of functional features. On the other hand, it may be a good way of getting work done.
My recommendation for people wanting to use a statically typed, efficient functional programming language would be OCAML. It has a full object system, yet also offers a full set of functional programming primitives. SML/NJ is another excellent implementation supporting both procedural and functional programming, and very lightweight threads (as an alternative to objects; cf. the GUI system).
Scheme and CommonLisp are also great languages. As a procedural or OO programmer, you can think of them as Python with a different syntax and a much better compiler. MzScheme is an excellent Scheme system for learning, and Bigloo is a powerful Scheme compiler. You can find more information at schemers.org.
For heavy-duty programming, CommonLisp is still better than Scheme, IMO, but it's significantly more complex. You can find a bunch of implementations at cons.org. I recommend CMU CommonLisp highly. For experimentation, CLISP by Haible is a good small interpreter. There are also a few "scripting" implementations of CommonLisp around.
Haskell is absolutely amazing for distilling programs down to 1/10 or 1/100 their size. However, it really requires a very different way of approaching programming. I'm not sure whether to recommend starting programming with it or not, in particular if you come from other languages.
There are also some special-purpose functional programming languages for high-performance computing. Those languages give performance similar to Fortran or C on numerical problems and can actually be parallelized more easily.
Of course, whether any of these links help you depends on whether you can get started using a new language with a reference manual, user manual, short tutorial, and implementation. If not, there are lots of textbooks around. The Haskell site in particular also has lost of link for FP-related resources. Also search Fatbrain.
So, in summary: functional programming languages are definitely ready for many applications. If you want to get started, there are lots of resources available. Try to find a book that you like and experiment. MzScheme or OCAML are fairly traditional ways of getting started (you still get a lot of the features you are used to from procedural languages). I suspect that functional programming is going to be the "next big thing" in programming after OOP, and I also think it's a lot more useful than OOP and a lot more well-founded.
So when elected officials violate their mandate, and do not act in the interest of those that elected them, it is the voters that are in the wrong, not the officials? Brilliant thinking, Sherlock.
Oh, please. With many politicians, it's pretty predictable how they are going to act. In fact, my point was "the Bay Area wanted this". People understood who they were voting for then, just as much as they understand who they are voting for when they vote for Brown, Bush, or Gore these days.
This is the most cynical thing I've seen in a long while.
No, your beliefs are the most cynical I have seen in a long time. You seem to think that voters are presented with a fixed menu of corrupt choices, and no matter who they vote for, they'll get screwed. How cynical can you get?
The fact is: this is a participatory democracy. It has numerous flaws and could be improved, but it is still reasonably workable. Any US citizen can run for office, and any US citizen can vote for whoever they believe in.
Yes, it takes a lot of work to get an alternative candidate elected, disproportionate compared to the mainstream candidates, who have money, media access, and a party machinery. But it is possible.
There probably weren't any really good choices in many of the local elections. But in a democracy, it is everybody's duty not just to vote, but also to create choices to vote for.
Sorry, but this kind of dirty dealing in local governments happens all the time despite what the residents want.
That's probably because a lot of residents are apathetic and vote their pocketbook.
I have lived in places where people put in urban growth boundaries, voted down highway expansion, converted parts of the city to pedestrian-only use, and stopped industry from moving in all over the place. It is possible.
Heck, though this isn't the same issue, look at this year's presidential election. I wanted it to come down to ANYONE other than Bush and Gore. Now I'm stuck with no choice but to vote for one or to not vote. I can't even vote for Ralph Nader as an alternative because the Greens don't have enough signatures in my state to get on the ballot. Real democracy right there, huh? I guess it's all my fault, huh?
There are lots of things you could have done, like gathering signatures for alternative candidates and helping out with their campaigns. If enough people do that, things change. If not enough people do that, they evidently don't care enough.
The city and county governments, over the LOUD objections of the residents, basically went on a no holds barred campaign to attract new industry to the region. [...] and it was all ushered in by fairly corrupt government officials.
This is a democracy, and those governments were elected by the people who lived here, not by industry or outsiders. Apparently, the people who lived here wanted things that those corrupt politicians promised, otherwise they would have elected other officials.
Democracy is hard, and things go wrong all the time. I hope the Bay Area will be a good lesson to people when it comes to issues of urban planning and who to vote for. Maybe other areas can learn from it and be spared a similar fate.
Again, I'm sorry about what happened to the Bay Area; it must have been a beautiful place. But I don't accept it if movies like the one under discussion try to put the blame on new arrivals like myself. We just followed the jobs, and the jobs are here because local politics attracted industry. Many of us would much rather be elsewhere, and we are struggling hard to pay ridiculous amounts for substandard homes in, as you aptly put it, "an ugly megalopolis".
There are lots of major corporate research labs in or around SV, a bunch of excellent universities, most of the venture capital, and a culture where technical people move around freely and talk to each other. And all within a convenient drive (if you manage to avoid traffic). No other place even comes close, although a few other places (Boston, NYC, maybe Seattle) may get honorable mentions.
Economic development doesn't happen by accident or natural disaster, it's a planned process. If the Bay Area hadn't wanted this kind of development, its residents could have adopted urban growth boundaries, resisted highway development, and zoned for residential development. Instead, they did virtually no planning and left a complete mess when it comes to infrastructure and zoning.
People who move to SV do so because that's where the jobs in their field are. Not jobs to get rich, just "the jobs". Most of us would much rather be elsewhere, in well planned communities, with decent public transportation, out of the way of earthquakes, and not driving along a ridiculously inconvenient peninsula.
So, here is my message to long time SV residents: I'm sorry that your neighborhood got destroyed. But that was your choice, or at least your political inaction. Be happy that you can sell your home, move to a nice little community along the coast that's like the Bay Area used to be, and never have to work another day in your life. The rest of us have to pay high mortgages and make the best we can with the mess you left us. Believe me, we'd rather be somewhere else, too.
The OSS projects you list are as innovative as closed source projects, perhaps more so. The problem is: that's not saying a lot. The whole industry, open source or not, is aiming very low. It's the year 2000, and we still use tools that were oudated 20-30 years ago.
Take a look at the Simula-67 and Algol-68 manuals (yes, those numbers refer to dates in the 20th century). Simula-67 looks not all that different from Delphi or FreePascal. Take a look at Smalltalk-80, Cedar, and the Xerox PARC workstations. Take a look at the MIT Lisp machines from the early 80's. They had powerful, easy to extend window systems, component based development, runtime safety, incremental development, and a lot of other features that even today, almost every environment lacks.
Yes, those systems had limitations and problems. But instead of fixing those problems, the whole research community and industry went on a C/C++/UNIX binge. The end result is that 20-30 years later, C/C++/X11/UNIX (and its inferior clone, Microsoft Windows) is still the only realistic choice for real systems. Alternatives like ML, Smalltalk, and Lisp aren't feasible because only a handful of people has invested any significant efforts in them over the last few decades. Java is the only effort to bring at least some of those technologies out into the mainstream, and you know what most OSS hackers seem to think about it.
The aims of the research and development community seem so low now that reinventing WYSIWYG word processing, computer algebra, or component-based software in C/C++ is considered innovation. Unless R&D starts aiming even just a little higher, things will continue to bloat and stagnate.
It's the approach and language, not X11.
on
X Windows Must Die!
·
· Score: 3
The problems with X11 are intrinsic to the languages and tools used for building it. The same is true of the Linux kernel (which is also pretty bloated and hard to extend), as well as alternatives like MS Windows. And it will also be true for new efforts like Berlin, and to some degree GNU Step.
Until people move to languages and methodologies that emphasize runtime safety, runtime type information, and component based programming, these problems aren't going to get fixed. In fact, that's the real point of the UNIX Hater's Handbook.
Of course, people try to use dynamic loading in XFree86, the Linux kernel, and Microsoft Software. In fact, MS COM probably represents the best attempt at doing this kind of thing, but without language support, it is ultimately too complex to be really useful. Plan 9 has a different take on modular software composition, but they have not demonstrated that it scales (Plan 9 is pretty simplistic, IMO), and it pays for the use of C in a lot of context switches.
As long as the mainstream of free software writes in C/C++, this simply isn't going to change. Any new attempt is just going to get as bloated and complex as the previous systems when it hits the real world.
But as far as 1970's style, C/C++ systems go, X11/Linux is the best there is, and I'll continue using it until I see anything better come along.
Slashdot Mirror
I agree that it's politically difficult to get people to use safe languages. My point is just that: Miguel shouldn't complain about UNIX if he is part of the problem. My point is also that the myriad of workaround (COM+, CORBA, etc.) that are supposedly "in C/C++" are actually much worse and more complex than the alternatives. The extensions Objective-C makes to C are trivial compared even to just IDL. And mastering Java or Modula-3 is much simpler than learning COM, IDL, CORBA, plus their numerous libraries even for an expert C++ programmer.
With Java, things are changing slowly. But I won't hold my breath for a mass conversion. Miguel's attitude is exemplary of the irrational views of most of the industry.
You might add hardware support to keep C/C++ from corrupting such shared data. Essentially, you'd be putting Purify or other pointer checking in hardware. That would be an OK solution, although it would be suboptimal: if you address the problem in general, you'd be spending a lot on hardware to support the C/C++ pointer model, without a commensurate benefit.
The best technical solution is to dump C/C++. Languages like Modula-3 (and many others) give you the same efficiency without the problems, and they run well on existing hardware.
To fix this, the only way is to ditch C/C++. There are plenty of simple, efficient alternatives, including Modula-3, Oberon, Eiffel, Limbo, and Sather. Java may eventually make it as well.
As for text-file based administration, people use it because it works. Registry-like mechanisms have been tried even before Windows, and they have numerous problems, in particular for server machines. Program files that bundle up more than code are easy to implement under UNIX, and some frameworks use them extensively, but they are also very desktop oriented. To put it differently, Windows and MacOS can do better in these areas because they are solving a more specific problem: desktop applications and simple business server applications. UNIX has been used extensively for supercomputing, engineering, data mining, server farms, and there, those desktop mechanisms are more of a nuisance than a help.
As for naming, Plan 9 does what you suggest, and I hope a bit more of it will move into Linux.
Miguel is frustrated with development and lack of componentization, and that's a problem with the tools he develops in, foremost C. Adding foreign language bindings to a messy, complex, difficult to extend system doesn't make the system itself less messy, complex, and difficult to extend. And binding C APIs to a safe language merely makes the safe language potentially unsafe.
I do prefer GTK with its C-based foreign language bindings to other toolkits that are much more biased towards C++. But to really address the problems Miguel is complaining about, you have to ditch C altogether, from bottom to top. Bonobo will not fix things.
But if Miguel wanted to help improve the situation, why did he go off developing such a huge software project in C on UNIX? It is C that makes component based development such a pain. C lacks even minimal support for component based development (e.g., no dynamic typing, no reflection), and it is impossible to make large, component based systems in C both robust and efficient: there is no fault isolation--a bad pointer in one component will crash other components unless you put them in separate processes.
The answers to these problems are well known. Systems like Smalltalk-80 and the Lisp machine were fully integrated, component based environments where everything talked to each other. And almost any language other than C and C++ is better for component-based development and provides reuse.
Microsoft does not have the answer. Microsoft's component model, COM, has very serious problems. It's complex because the languages it is based on don't have any support for component based development. And despite its complexity, it is still dumbed down because anything else would be umanageable in C/C++. And it has no fault isolation, meaning that if you load a bunch of COM components and your program dies, you have no idea what went wrong.
In fact, UNIX had an excellent, reusable component model: command line programs that interchange data with files. That's no good for building a graphical desktop, but it was excellent for the UNIX user community--people manipulating lots of data. And that model has been extended to graphical desktops and networked systems in Plan 9 and Inferno, which also address many of the other problems with C/C++ through Alef and Limbo. Or, alternatively, Objective-C and OpenStep managed to build something that support powerful reuse and component based development on top of UNIX. And Java is excellent at supporting both component-based programming, reuse, and fault isolation.
If Miguel genuinely wants to improve the situation, why isn't he using the tools that will let him do so? Why isn't he learning from the long history of component-based development that preceded both him and Microsoft? Why is he copying Microsoft's mistakes and mediocrity? Why isn't he supporting tools that genuinely make a difference rather than encouraging the use of tools (C/C++) that were never intended for this kind of work?
People say about democracy that "it is the worst form of government, until you have tried the others". I think the same is true about UNIX. Gnome and GTK help improve the usability of a flawed tool. As such they are really welcome. But by not addressing the root causes of the problems, we'll probably be here discussing the very same problems again in another 15 years, because everything people complain about UNIX was known 15 years ago, nobody fixed it, and it (and its clone--Windows) still became immensely popular.
But the real importance of X11 is in scientific and engineering environments, as well as large server farms. There, people run GUI-based and visualization software on big machines in machine rooms and display and steer it from their client workstations/PCs on their desktop. Despite the various attempts at providing such functionality on top of MacOS and Windows (CarbonCopy, Timbuktu (?), etc.), X11 is still the best for that: it allows application writers to write applications that are client/server aware and work well across lots of platforms. Having a good, commercial X11 server available for MacOS X makes MacOS X a good desktop client platform in such environments.
But because MacOS X (presumably) cannot use the X11 protocol for displaying its native applications and administration tools on remote X11 displays, this still doesn't let MacOS X compete on equal footing with X11-based servers. Making MacOS X a client of an X11 display server in that way could be feasible, though difficult. More likely, we are going to see a passable VNC server adaptation, just like we did with Windows.
Windows, MacOS OS, and their toolkits may be nice for the consumer market, but they have all sorts of problems for the scientific and engineering market. One size doesn't fit all, and environments (like Win32 and Aqua) that are designed for making the prettiest consumer applications are not the best for science and engineering applications. X11 is here to stay because it works well for lots of people and because there is nothing on the horizon that fills its niche.
I also can't tell you definitively what RMS's beliefs are, but he has repeatedly stated that the right not to distribute anything at all is important.
And I'd say that, if not for philosophical reasons, it's important for practical reasons. Many research and development projects that ultimately become open source start off as internal projects. Having some obligation to publish is often not acceptable even in environments committed to open source. That means that the QPL isn't applicable, and it means that, for practical purposes, Qt is an expensive commercial toolkit to such organizations.
With the current level of reliability and interoperabilty, you'll probably be able to conjure up a BSOD or dozens of dialog boxes just by staring at the wrong part of the screen. You know, something like "Cannot notify InstantMessenger of your inactivity. Click [OK] to continue.", or "You aren't paying enough attention to me. Look at me, dammit. (beep) [OK]".
As for the idea itself, sure, it's good research. But the ideas have been around for a number of years, and lots of people are using Bayesian modeling, decision theory, user modeling, and affective computing, so this is not some kind of breakthrough hatched at Microsoft Research.
In the short term, if it's important, you can turn off swapping. But a better long term choice is probably to encrypt swap space with a key that is created at boot time, held in kernel memory, and discarded when the system shuts down/crashes. That addresses the problem once and for all.
The QPL is still in contradiction to the principles that the GPL was written to uphold, which includes the freedom to use the software for internal purposes. Furthermore, I think the QPL is not suitable for most internal research and developmen use; you must license the commercial version. Be sure you understand exactly what the QPL and Troll Tech require you to do before you invest any time or effort in Qt.
If Troll Tech wanted to have "GPL with a commercial exception", they could simply license Qt under the GPL and offer a separate commercial license for sale like other companies do.
As for the "Sun-control-freak-mentality", I don't see how Sun's control over Java is any different from the control Guido exercises over Python.
Python is a nice scripting language and a passable extension language. Java is a nice applications programming language and a lousy extension language. Neither is a replacement for the other, and both have their limitations and problems.
However, if you use cryptography, for example, the Steganographics File System, and if you implement it securely, then it doesn't matter what people can retrieve.
Of course, with cryptography, you run into some of the same issues. In particular, keeping your keys secure is, in itself, not trivial. For example, if you type in your key and the program that reads the key gets swapped out, your plaintext key will have been written to disk.
Talking to vendors of Linux office suites, one of the biggest problems seems to have been that commercial vendors have been reluctant to implement some features in MS Office clones (foremost, VB/VBScript compatibility) for fear of getting sued on intellectual property grounds. Putting StarOffice under GPL and creating a plug-in architecture may be a good way of addressing this.
I think we see different programming styles here. Microsoft's platforms seem great for hacking, experimenting, and poking around, but as far as I'm concerned, they aren't great for planning and implementing software in a well-defined, logical manner.
As for their "releasing source code", you make it sound like they are an open source company. Nonsense. The examples they publish are solely for getting people to be able to do anything at all with their messy APIs. The source code they publish is completely useless outside their environment, and (usually) the license prohibits any other use anyway.
As for Eiffel, I think the importance you attribute to it is greatly exaggerated. Meyer didn't invent the concept of "design by contract", and it was widely used before Eiffel ever saw the light of day (and is widely used in Java and C++ today). Eiffel is a simple, efficient, if somewhat limited and flawed, OOL, but it isn't a major milestone of language design or computer science. To me, the co-appearance of Meyer and Gates, however, reflects poorly on Eiffel: it looks like Eiffel is now driven by fashion than by principle.
It's hard to explain in a paragraph or two why functional programming is so great. Suffice it to say that it allows for much more reuse than object-oriented programming, opens up whole new ways of abstracting out functionality, and prevents one of the most common sources of bugs--aliasing.
Not all functional programming languages are purely functional. In fact, many programmers program in such functional programming languages like they do in Perl or Python. That can be both bad and good. On the one hand, because functional programming languages are powerful even for procedural programming, they may never be encouraged to learn how to take advantage of functional features. On the other hand, it may be a good way of getting work done.
My recommendation for people wanting to use a statically typed, efficient functional programming language would be OCAML. It has a full object system, yet also offers a full set of functional programming primitives. SML/NJ is another excellent implementation supporting both procedural and functional programming, and very lightweight threads (as an alternative to objects; cf. the GUI system).
Scheme and CommonLisp are also great languages. As a procedural or OO programmer, you can think of them as Python with a different syntax and a much better compiler. MzScheme is an excellent Scheme system for learning, and Bigloo is a powerful Scheme compiler. You can find more information at schemers.org.
For heavy-duty programming, CommonLisp is still better than Scheme, IMO, but it's significantly more complex. You can find a bunch of implementations at cons.org. I recommend CMU CommonLisp highly. For experimentation, CLISP by Haible is a good small interpreter. There are also a few "scripting" implementations of CommonLisp around.
Haskell is absolutely amazing for distilling programs down to 1/10 or 1/100 their size. However, it really requires a very different way of approaching programming. I'm not sure whether to recommend starting programming with it or not, in particular if you come from other languages.
There are also some special-purpose functional programming languages for high-performance computing. Those languages give performance similar to Fortran or C on numerical problems and can actually be parallelized more easily.
Of course, whether any of these links help you depends on whether you can get started using a new language with a reference manual, user manual, short tutorial, and implementation. If not, there are lots of textbooks around. The Haskell site in particular also has lost of link for FP-related resources. Also search Fatbrain.
So, in summary: functional programming languages are definitely ready for many applications. If you want to get started, there are lots of resources available. Try to find a book that you like and experiment. MzScheme or OCAML are fairly traditional ways of getting started (you still get a lot of the features you are used to from procedural languages). I suspect that functional programming is going to be the "next big thing" in programming after OOP, and I also think it's a lot more useful than OOP and a lot more well-founded.
Oh, please. With many politicians, it's pretty predictable how they are going to act. In fact, my point was "the Bay Area wanted this". People understood who they were voting for then, just as much as they understand who they are voting for when they vote for Brown, Bush, or Gore these days.
No, your beliefs are the most cynical I have seen in a long time. You seem to think that voters are presented with a fixed menu of corrupt choices, and no matter who they vote for, they'll get screwed. How cynical can you get?
The fact is: this is a participatory democracy. It has numerous flaws and could be improved, but it is still reasonably workable. Any US citizen can run for office, and any US citizen can vote for whoever they believe in.
Yes, it takes a lot of work to get an alternative candidate elected, disproportionate compared to the mainstream candidates, who have money, media access, and a party machinery. But it is possible.
There probably weren't any really good choices in many of the local elections. But in a democracy, it is everybody's duty not just to vote, but also to create choices to vote for.
That's probably because a lot of residents are apathetic and vote their pocketbook.
I have lived in places where people put in urban growth boundaries, voted down highway expansion, converted parts of the city to pedestrian-only use, and stopped industry from moving in all over the place. It is possible.
There are lots of things you could have done, like gathering signatures for alternative candidates and helping out with their campaigns. If enough people do that, things change. If not enough people do that, they evidently don't care enough.
This is a democracy, and those governments were elected by the people who lived here, not by industry or outsiders. Apparently, the people who lived here wanted things that those corrupt politicians promised, otherwise they would have elected other officials.
Democracy is hard, and things go wrong all the time. I hope the Bay Area will be a good lesson to people when it comes to issues of urban planning and who to vote for. Maybe other areas can learn from it and be spared a similar fate.
Again, I'm sorry about what happened to the Bay Area; it must have been a beautiful place. But I don't accept it if movies like the one under discussion try to put the blame on new arrivals like myself. We just followed the jobs, and the jobs are here because local politics attracted industry. Many of us would much rather be elsewhere, and we are struggling hard to pay ridiculous amounts for substandard homes in, as you aptly put it, "an ugly megalopolis".
There are lots of major corporate research labs in or around SV, a bunch of excellent universities, most of the venture capital, and a culture where technical people move around freely and talk to each other. And all within a convenient drive (if you manage to avoid traffic). No other place even comes close, although a few other places (Boston, NYC, maybe Seattle) may get honorable mentions.
People who move to SV do so because that's where the jobs in their field are. Not jobs to get rich, just "the jobs". Most of us would much rather be elsewhere, in well planned communities, with decent public transportation, out of the way of earthquakes, and not driving along a ridiculously inconvenient peninsula.
So, here is my message to long time SV residents: I'm sorry that your neighborhood got destroyed. But that was your choice, or at least your political inaction. Be happy that you can sell your home, move to a nice little community along the coast that's like the Bay Area used to be, and never have to work another day in your life. The rest of us have to pay high mortgages and make the best we can with the mess you left us. Believe me, we'd rather be somewhere else, too.
Take a look at the Simula-67 and Algol-68 manuals (yes, those numbers refer to dates in the 20th century). Simula-67 looks not all that different from Delphi or FreePascal. Take a look at Smalltalk-80, Cedar, and the Xerox PARC workstations. Take a look at the MIT Lisp machines from the early 80's. They had powerful, easy to extend window systems, component based development, runtime safety, incremental development, and a lot of other features that even today, almost every environment lacks.
Yes, those systems had limitations and problems. But instead of fixing those problems, the whole research community and industry went on a C/C++/UNIX binge. The end result is that 20-30 years later, C/C++/X11/UNIX (and its inferior clone, Microsoft Windows) is still the only realistic choice for real systems. Alternatives like ML, Smalltalk, and Lisp aren't feasible because only a handful of people has invested any significant efforts in them over the last few decades. Java is the only effort to bring at least some of those technologies out into the mainstream, and you know what most OSS hackers seem to think about it.
The aims of the research and development community seem so low now that reinventing WYSIWYG word processing, computer algebra, or component-based software in C/C++ is considered innovation. Unless R&D starts aiming even just a little higher, things will continue to bloat and stagnate.
Until people move to languages and methodologies that emphasize runtime safety, runtime type information, and component based programming, these problems aren't going to get fixed. In fact, that's the real point of the UNIX Hater's Handbook.
Of course, people try to use dynamic loading in XFree86, the Linux kernel, and Microsoft Software. In fact, MS COM probably represents the best attempt at doing this kind of thing, but without language support, it is ultimately too complex to be really useful. Plan 9 has a different take on modular software composition, but they have not demonstrated that it scales (Plan 9 is pretty simplistic, IMO), and it pays for the use of C in a lot of context switches.
As long as the mainstream of free software writes in C/C++, this simply isn't going to change. Any new attempt is just going to get as bloated and complex as the previous systems when it hits the real world.
But as far as 1970's style, C/C++ systems go, X11/Linux is the best there is, and I'll continue using it until I see anything better come along.