I'm not sure how current his information is; for example, he states that there's no IPv6 and IPSEC support for Linux. This is incorrect; IPv6 was added in 2.1, and IPSEC was recently announced (though it's not in the kernel distribution).
Pad++ was a zoomable user interface written in Tcl/Tk. It grew and grew and got unmaintainable, so its successor is a Java library called Jazz, which looks very promising. It's alpha work at the moment, though, requires Java 2, and still needs more optimization work.
I'll cheerfully agree with most of Tom C.'s points on garbage collection, scoping, and the absence of super(). To correct some minor factual misstatements:
With python, the object is the way, the truth, and the light. Let no man cometh unto his data save through the object. In perl, OO is an option, not a requirement.
Hmm? You can quite happily store your data in interwoven dictionaries, lists, and tuples if you like, and never write a single class. If you want to talk about classes being a requirement, talk about Java.
With python, you cannot generate C code to compile into an a.out.
There's a Python-to-C translator, though it seems very experimental and I'm not familiar with its status; the author claims it will handle almost all Python code, but you know what those programmers are like. Of course, you can compile Python to Java bytecodes quite nicely using JPython.
With python, the pattern matching is not tightly integrated into the language. It is merely loosely bolted on, which introduces inefficiencies and quoting clumsinesses.
True, but it also means you can leave it out if pattern matching isn't of interest to your application domain. People who want to run massive numeric simulations, build virtual environments, or run a large online role-playing game may not care about processing text. (Coincidences are funny things; while checking the third link, I went to reference.com and was startled when my search pulled up Python code on my screen -- someone forgot to make a CGI script executable, I suppose. reference.com is an application that does care about text searching, I would imagine.)
The greatest problems with regexes in Python 1.5 are:
Parts of re.py are still written in Python, not C, and are therefore slow. Fixing that is on my list for 1.6.
PCRE doesn't do a lot of optimizations and analyses. Mostly this is because the compiler doesn't build a parse tree and traverse it, but instead tries to construct a string of bytecodes in a single pass.
Unicode regexes are an open issue at this point. I've been casting longing glances at the regex engine in Mozilla, which does build a nice parse tree and supports Unicode, and hope to work on splitting it out into a separate library.
With python, you cannot determine your calling context, nor behave differently dependent upon the same.
Python doesn't have the idea of scalar/array/etc context, so I don't see the relevance.
With python, writing an eval string is a pain in the royal butt due to the insane whitespace problem.
If you're generating multiple blocks of code, then generating curly brackets and indentation are isomorphic problems; replace { with \n + indentation-level spaces, and replace '}' with newlines.
With python, you have no equivalent to Apache's mod_perl.
PyApache (don't ask me why it's not called mod_python). Zope is more interesting still.
Originally Wired was just about the only magazine that had any clue about on-line mores, and they covered the technical aspects and often got them right. Today, though, their reporters are no more clueful than anyone else's, which is saying little indeed. (In one story on Hotwired not too long ago, Usenet cancel messages were referred to as "programs that delete offensive messages".)
Another favorite Wired memory in retrospect: in one very early issue, one item on the overhyped list was Mosaic. The commentary was something like "With Mosaic you can see people's home pages, except now with pictures. Who cares?" and predicted the Mosaic hype would die off soon. Very funny, when viewed with the benefit of hindsight.
The trend is toward greater diversity in languages, not less -- and I don't mean languages designed for academic purposes, but languages that are actually being used. Look at the last few years: Python, Perl, and Tcl all have growing communities; Java, of course, is still to be reckoned with; in the Web-specific space we have PHP, Frontier, the various Apache modules for different languages, and there are dark horses like Guile, Dylan, or REBOL that may or may not become important. I can't think of a language that I would consider to be "dying" ("holding steady" is a different question). I know people who are turning away Python-related consulting jobs because they already have more than enough work.
When Java was first introduced, there was much excited chatter about it killing off other languages; I think Sun is still half-heartedly arguing that. Yet interpreted languages have adapted to Java quite nicely, thank you -- consider Jacl and, of course, JPython. So get used to the diversity -- it doesn't look like it'll be going away, particularly since component architectures like COM and CORBA grant a lot more flexibility in choosing a language.
Umm... Hackish OO features are a strange brickbat to throw at Perl, because Perl5's OO-features were strongly influenced by Python's, except the syntax has been Perlized (reasonably enough).
And I wish PCRE was as optimized as Perl's regex code, or that the regex code was available as a standalone library; unfortunately that seems very difficult to do, and unlikely to happen.
Zope is a cool system, because it's highly flexible, and you benefit from the variety of available extensions for Python; you can use things like PIL, LDAP modules, whatever, etc. (This is why it's often a good idea to use a general programming language for tasks instead of inventing a little language that gets clumsily extended.) If you're going to have multiple users maintain different chunks of a Web site, Zope's management screens provide much of the infrastructure that you need.
The downside at the moment is that, because Zope's fore-runner was an internal product used by Digital Creations, the DC people didn't have a lot of documentation for it. They've been working on getting more docs written, but the picture is still somewhat scattered. If you end up reading the source code, it would be difficult for a Python newbie because the code so full of cutting-edge technique. Luckily, you can do a lot without having to dive into the source code; it only matters for more complicated things like writing a new product or DTML tag for it.
While you're at it, check out Squishdot, which is still in really early alpha; it'll be astoundingly cool when it's finished.
An excellent technical (though not a
very technical) book. Greenspun's interest lies in creating online communities that are useful and vibrant enough to survive for long periods of time. Greenspun understands that such utility doesn't arise from trivia such as micro-tweaked HTML or the latest hyped plug-in; instead, it comes from permitting people to connect in ways that aren't possible without the connectivity and information accumulation made possible by the Internet and by database software. I highly recommend this book, and its principles will probably guide my future plans for the MEMS Exchange site.
An online version of the book is available, and is definitely worth a browse; the photographs will look better in the printed version, though that probably isn't reason enough to buy the printed version. Reason enough to buy the book, though, is simply to encourage such an enlightened approach to Web design and to freeing a book's content.
It's refreshing to see a computer-related book that concentrates on technical opinions, instead of just how-to details. I skipped over the AOLserver code, since Zope would be my choice for an implementation environment (some of the Zope Portal Toolkit ideas seem inspired by Greenspun's book, in fact), but that doesn't materially affect the important ideas of the book, which relate to nurturing online communities. It's not platform-specific in that way; while Greenspun has his preferences for Tcl and Oracle, he repeatedly emphasizes that the specific tool used is of secondary importance.
Henstridge maintains the Python/GTk+ bindings and various other GNOME-related things; he was probably a tech reviewer on drafts of the book. Practically all publishers send manuscripts to tech reviewers, and they usually try to get other notable developers in the community as reviewers.
Yes, but LWN and LinuxToday both do better jobs of collecting news stories than Slashdot does; they're quicker, more complete, and offer excerpts of the article that let you decide whether to bother reading the whole article. Why should Slashdot duplicate their efforts, and duplicate them poorly at that?
See LWN's news summary; it frankly blows Slashdot out of the water when it comes to collecting news stories.)
I don't know why so many Slashdot items these days are concerned with articles in other publications. Slashdot's appeal always stemmed from the fact that it covered topics that weren't covered in places like ZDnet. Yet today we often see/. items that are just pointers to stories on ZDnet or wherever. Now, if you want to know about every media mention of Linux, either Linux Weekly News or LinuxToday do much better and more complete jobs than Slashdot does.
Part of the problem is that discussions on/. can tend to hysteria, causing authors to be bombarded with flames. So, Rob, why not simply drop such items, since other places are doing better jobs, and concentrate on what/. does best -- amusing and interesting stuff that's off the beaten path? Discussions of technical topics on Slashdot are still often quite good, modulo the occasional flamewar over GNOME/KDE or Linux/*BSD.
Re:Honest questions...
on
RMS Responds
·
· Score: 1
Software can be replicated in ways that a physical object can't be. If I give away my bicycle, I no longer have a bicycle to ride myself. But if I give away software or documentation in the form of bits, I still have the bits I started with. Software and reference documentation also need to be modified to meet changing circumstances, which is not true of a persuasive essays or a musical composition. You could GPL the score for a piece of music and might do so as a gesture of support, but no one needs to modify the score to keep it working; music won't break on a new platform the way a program might. (On the other hand, new arrangements of scores -- Rite of Spring for string quartet and piano, or Bach for the Moog -- are somewhat akin to porting music to a new platform...)
ASCII output from nroff looks much the same; maybe that's how the flat ASCII was produced. Just view it using 'more' or 'less', which turn A^H_B^H_ into 'AB' and underlines it.
Why not just grab it out of the CVS repository? I follow the CVS tree and compile a new version every few days; since around M5, the tree is usually always compileable without difficulty.
KDE the only one that supports OO languages? Hardly -- the GTk/GNOME module for Python is well-maintained and quite good. A Python Qt/KDE module exists, and is also pretty good, though all the glue code required for Qt -- C++, remember -- results in an extension module that's a startling 5Mb large. (They're working on reducing the code size.) The GNOME modules add up to around 2Mb in all. So it's quite possible to write programs for either toolkit in Python, though documentation is still scarce.
I also read this book recently, and my capsule review was:
An introduction to writing GUI programs using the Qt toolkit. The book is almost exactly what I want from a programming book; it gives enough background to get started and to understand the reference documentation, but doesn't lose itself in trivia. Nor does it lose itself in dozens of pages of code; there are only a few examples, and none of inordinate length.
IMHO that's precisely what a good book should do; give you enough of a grounding to understand and use the documentation and source code. Don't bury me in hundreds of pages of code; don't duplicate the on-line documentation; do cover the basic design ideas underlying the topic.
It's probably more productive to form contacts inside other organizations, and use them to gain special attention from the people doing the hiring. Developing free software is helpful, because it gives you a track record and brings you to people's attention. My last two jobs were both acquired through contacts made on Usenet.
My current project, the MEMS Exchange, is looking for good developers, and placement services aren't much help, because the people we've interviewed often seem to be clueless. (Write me if you'd be interested -- we're in the DC area, and are a research-oriented non-profit.) We've had horrifying experiences where a candidate's CV looked good, but it all fell apart at the interview, where we found they couldn't write pseudocode for reading a file line-by-line. If we knew a person could at least design and code reasonably, because we knew they'd maintained a non-trivial software package, that would be a good foot in the door. Similarly, a while back Digital Creations got a bunch of new employees, hiring practically everyone who had done a significant project using Zope. This is another good reason to hack on free software; it can earn you a reputation, and that reputations can lead to better offers and more interesting jobs.
Agreed; it's always more interesting when you can hear the voice of an an author or an editor, rather than the bland predigested output of a committee. The Cluetrain manifesto is a good argument that companies shouldn't be homogeneous and faceless on the Web.
A while back I heard about a workshop held by DARPA on alternative computers. I think DARPA's interest stems from environments where electronic computers are unsuitable -- high radiation environments where electronics would be unreliable, for example. Alternatives might be optical, mechanical, or hydraulic computers. Mechanical and hydraulic computers would almost certainly still be implemented as microstructures on silicon.
And Perl is far more buggy than/bin/true -- kernels are simply more complicated than language interpreters, which don't have to interact with buggy IDE/SCSI/whatever chipsets, dodgy motherboards, or eccentric TCP/IP stacks because -- guess what? -- the updated-daily kernel worries about the problem and provides abstractions for userland code to sit on top of.
This reminds me of a language I once briefly used in university -- some sort of constraint-solving mini-language -- where the only help available was a few screenfuls of text printed out by the "help" command. It printed out the BNF grammar for the language. And the semantics of the language are...?
Seriously, reading the code may tell you what it does (with much struggle); it doesn't tell you that what it does in one case is actually a bug.
This assumes that writing one book will kill off the market for future books about the same topic. Just look at how there's only one book about Java, Linux, or C++!
In fact, the opposite is true; as books on a topic come out, other publishers notice and say "Gee, we should really cover this topic too." We're seeing this happen with Python books now; for a long time there were only two books on Python, one from O'Reilly and one from MIS Press. This year, two more O'reilly books have come out and there are at least two more in preparation; another publisher is working on two books, and there are two or three more one-shot projects. (I've written a bit of documentation, and occasionally get e-mails asking me if I want to write a book, which I have to always decline -- not enough spare time.)
So, the more GNOME books, the better for GNOME. It's not going to kill off GNOME books from other publishers.
(Since when is Eiffel a scripting language? Tsk, tsk, MJR...)
I was more surprised to see Wall focus on the rather minor feature of whitespace; syntax is only part of design philosophy, and Python's primary feature isn't its use of whitespace, any more than Algol-68's primary feature was its introduction of the "fi" keyword. Instead, Python's primary idea is really namespaces. Modules are namespaces. Classes are a bunch of namespaces with rules on how to look through them, and instances are namespaces on top of classes. It's noteworthy that Python's object model could be mapped to Perl fairly straightforwardly, influencing Perl 5's OO features.
I find more disturbing the fact that there are Linux exhibitors hiring models and cheesecake ads, both perfect illustrations of sizzle-over-substance marketing. This is particularly ironic for a Linux show; Linux has gotten as far as it has by being a better system, not by slick marketing.
Back in October when REBOL first came out, there was an interesting, and surprisingly even-handed, thread about it in comp.lang.python. The consensus was that REBOL is basically Scheme -- Scheme dressed up in an infix format to avoid triggering parenthephobia.
Personally, I can't imagine why anyone in 1999 is bothering to release a new language without making the source code available. Haven't we learned better by now?
Slashdot Mirror
I'm not sure how current his information is; for example, he states that there's no IPv6 and IPSEC support for Linux. This is incorrect; IPv6 was added in 2.1, and IPSEC was recently announced (though it's not in the kernel distribution).
Pad++ was a zoomable user interface written in Tcl/Tk. It grew and grew and got unmaintainable, so its successor is a Java library called Jazz, which looks very promising. It's alpha work at the moment, though, requires Java 2, and still needs more optimization work.
Hmm? You can quite happily store your data in interwoven dictionaries, lists, and tuples if you like, and never write a single class. If you want to talk about classes being a requirement, talk about Java.
There's a Python-to-C translator, though it seems very experimental and I'm not familiar with its status; the author claims it will handle almost all Python code, but you know what those programmers are like. Of course, you can compile Python to Java bytecodes quite nicely using JPython.True, but it also means you can leave it out if pattern matching isn't of interest to your application domain. People who want to run massive numeric simulations, build virtual environments, or run a large online role-playing game may not care about processing text. (Coincidences are funny things; while checking the third link, I went to reference.com and was startled when my search pulled up Python code on my screen -- someone forgot to make a CGI script executable, I suppose. reference.com is an application that does care about text searching, I would imagine.)
The greatest problems with regexes in Python 1.5 are:
- Parts of re.py are still written in Python, not C, and are therefore slow. Fixing that is on my list for 1.6.
- PCRE doesn't do a lot of optimizations and analyses. Mostly this is because the compiler doesn't build a parse tree and traverse it, but instead tries to construct a string of bytecodes in a single pass.
- Unicode regexes are an open issue at this point. I've been casting longing glances at the regex engine in Mozilla, which does build a nice parse tree and supports Unicode, and hope to work on splitting it out into a separate library.
Python doesn't have the idea of scalar/array/etc context, so I don't see the relevance. If you're generating multiple blocks of code, then generating curly brackets and indentation are isomorphic problems; replace { with \n + indentation-level spaces, and replace '}' with newlines. PyApache (don't ask me why it's not called mod_python). Zope is more interesting still.Another favorite Wired memory in retrospect: in one very early issue, one item on the overhyped list was Mosaic. The commentary was something like "With Mosaic you can see people's home pages, except now with pictures. Who cares?" and predicted the Mosaic hype would die off soon. Very funny, when viewed with the benefit of hindsight.
When Java was first introduced, there was much excited chatter about it killing off other languages; I think Sun is still half-heartedly arguing that. Yet interpreted languages have adapted to Java quite nicely, thank you -- consider Jacl and, of course, JPython. So get used to the diversity -- it doesn't look like it'll be going away, particularly since component architectures like COM and CORBA grant a lot more flexibility in choosing a language.
And I wish PCRE was as optimized as Perl's regex code, or that the regex code was available as a standalone library; unfortunately that seems very difficult to do, and unlikely to happen.
The downside at the moment is that, because Zope's fore-runner was an internal product used by Digital Creations, the DC people didn't have a lot of documentation for it. They've been working on getting more docs written, but the picture is still somewhat scattered. If you end up reading the source code, it would be difficult for a Python newbie because the code so full of cutting-edge technique. Luckily, you can do a lot without having to dive into the source code; it only matters for more complicated things like writing a new product or DTML tag for it.
While you're at it, check out Squishdot, which is still in really early alpha; it'll be astoundingly cool when it's finished.
It's refreshing to see a computer-related book that concentrates on technical opinions, instead of just how-to details. I skipped over the AOLserver code, since Zope would be my choice for an implementation environment (some of the Zope Portal Toolkit ideas seem inspired by Greenspun's book, in fact), but that doesn't materially affect the important ideas of the book, which relate to nurturing online communities. It's not platform-specific in that way; while Greenspun has his preferences for Tcl and Oracle, he repeatedly emphasizes that the specific tool used is of secondary importance.
Henstridge maintains the Python/GTk+ bindings and various other GNOME-related things; he was probably a tech reviewer on drafts of the book. Practically all publishers send manuscripts to tech reviewers, and they usually try to get other notable developers in the community as reviewers.
See LWN's news summary; it frankly blows Slashdot out of the water when it comes to collecting news stories.)
Part of the problem is that discussions on /. can tend to hysteria, causing authors to be bombarded with flames. So, Rob, why not simply drop such items, since other places are doing better jobs, and concentrate on what /. does best -- amusing and interesting stuff that's off the beaten path? Discussions of technical topics on Slashdot are still often quite good, modulo the occasional flamewar over GNOME/KDE or Linux/*BSD.
Software can be replicated in ways that a physical object can't be. If I give away my bicycle, I no longer have a bicycle to ride myself. But if I give away software or documentation in the form of bits, I still have the bits I started with. Software and reference documentation also need to be modified to meet changing circumstances, which is not true of a persuasive essays or a musical composition. You could GPL the score for a piece of music and might do so as a gesture of support, but no one needs to modify the score to keep it working; music won't break on a new platform the way a program might. (On the other hand, new arrangements of scores -- Rite of Spring for string quartet and piano, or Bach for the Moog -- are somewhat akin to porting music to a new platform...)
ASCII output from nroff looks much the same; maybe that's how the flat ASCII was produced. Just view it using 'more' or 'less', which turn A^H_B^H_ into 'AB' and underlines it.
Why not just grab it out of the CVS repository? I follow the CVS tree and compile a new version every few days; since around M5, the tree is usually always compileable without difficulty.
KDE the only one that supports OO languages? Hardly -- the GTk/GNOME module for Python is well-maintained and quite good. A Python Qt/KDE module exists, and is also pretty good, though all the glue code required for Qt -- C++, remember -- results in an extension module that's a startling 5Mb large. (They're working on reducing the code size.) The GNOME modules add up to around 2Mb in all. So it's quite possible to write programs for either toolkit in Python, though documentation is still scarce.
IMHO that's precisely what a good book should do; give you enough of a grounding to understand and use the documentation and source code. Don't bury me in hundreds of pages of code; don't duplicate the on-line documentation; do cover the basic design ideas underlying the topic.
My current project, the MEMS Exchange, is looking for good developers, and placement services aren't much help, because the people we've interviewed often seem to be clueless. (Write me if you'd be interested -- we're in the DC area, and are a research-oriented non-profit.) We've had horrifying experiences where a candidate's CV looked good, but it all fell apart at the interview, where we found they couldn't write pseudocode for reading a file line-by-line. If we knew a person could at least design and code reasonably, because we knew they'd maintained a non-trivial software package, that would be a good foot in the door. Similarly, a while back Digital Creations got a bunch of new employees, hiring practically everyone who had done a significant project using Zope. This is another good reason to hack on free software; it can earn you a reputation, and that reputations can lead to better offers and more interesting jobs.
Agreed; it's always more interesting when you can hear the voice of an an author or an editor, rather than the bland predigested output of a committee. The Cluetrain manifesto is a good argument that companies shouldn't be homogeneous and faceless on the Web.
A while back I heard about a workshop held by DARPA on alternative computers. I think DARPA's interest stems from environments where electronic computers are unsuitable -- high radiation environments where electronics would be unreliable, for example. Alternatives might be optical, mechanical, or hydraulic computers. Mechanical and hydraulic computers would almost certainly still be implemented as microstructures on silicon.
And Perl is far more buggy than /bin/true -- kernels are simply more complicated than language interpreters, which don't have to interact with buggy IDE/SCSI/whatever chipsets, dodgy motherboards, or eccentric TCP/IP stacks because -- guess what? -- the updated-daily kernel worries about the problem and provides abstractions for userland code to sit on top of.
Seriously, reading the code may tell you what it does (with much struggle); it doesn't tell you that what it does in one case is actually a bug.
In fact, the opposite is true; as books on a topic come out, other publishers notice and say "Gee, we should really cover this topic too." We're seeing this happen with Python books now; for a long time there were only two books on Python, one from O'Reilly and one from MIS Press. This year, two more O'reilly books have come out and there are at least two more in preparation; another publisher is working on two books, and there are two or three more one-shot projects. (I've written a bit of documentation, and occasionally get e-mails asking me if I want to write a book, which I have to always decline -- not enough spare time.)
So, the more GNOME books, the better for GNOME. It's not going to kill off GNOME books from other publishers.
I was more surprised to see Wall focus on the rather minor feature of whitespace; syntax is only part of design philosophy, and Python's primary feature isn't its use of whitespace, any more than Algol-68's primary feature was its introduction of the "fi" keyword. Instead, Python's primary idea is really namespaces. Modules are namespaces. Classes are a bunch of namespaces with rules on how to look through them, and instances are namespaces on top of classes. It's noteworthy that Python's object model could be mapped to Perl fairly straightforwardly, influencing Perl 5's OO features.
I find more disturbing the fact that there are Linux exhibitors hiring models and cheesecake ads, both perfect illustrations of sizzle-over-substance marketing. This is particularly ironic for a Linux show; Linux has gotten as far as it has by being a better system, not by slick marketing.
Personally, I can't imagine why anyone in 1999 is bothering to release a new language without making the source code available. Haven't we learned better by now?