Tiny difference... Linus actually had some running code when he posted for the first time. One of my metrics for telling whether a project will go anywhere: is there some code to start off with, or is it all just theorizing and high-flown design?
For my account, see July 20-22 in my online diary. I agree with Emmett; it was a superb techie conference, though I'd like to see more userspace-related topics.
People will have to calculate how much a feature is worth to them. If feature X would be really useful to you, you could either 1) hope someone else will pay for feature X, and live without it while you wait and hope, or 2) pay for it *now*, and get use out of it *now*. It's like deciding to buy a new computer; sure, the same amount of money will buy a faster system in 6 months, but if you buy it now, you get 6 months usage of a faster machine; you have to figure out at what point the expenditure is worth it.
Zope is usually run as a long-running process that's accessed through either Persistent CGI or FastCGI (though the FastCGI was still unstable when I tried it). A FastCGI module is also available if you just want to run regular CGI scripts a bit faster, and mod_python is available as an Apache module.
Supporting Unicode shouldn't be that big a deal, though there are still things to argue over, and it's slated for 1.6. The current interface is documented in this Unicode proposal; what's described there is mostly already implemented in the 1.6 alpha releases and CVS tree. Outstanding issues still remain: 1) the default encoding to use, 2) a Unicode-aware regex engine (partially there in 1.6a2, with a new version about to hit the CVS tree) and 3) declaring an encoding for Python source files (probably going to be left to 1.7). If you want to see good Unicode support in 1.6, I'd recommend compiling the CVS tree, trying it out on your application, and complaining loudly if you find shortcomings. Experience with an actual application is worth dozens of vague speculations.
Python 3000 is the vaporware future version of Python in which Guido will not feel constrained to preserve backward compatibility. In other words, it's Guido's last chance to fix the language. Currently development is supposed to start around 2002, after Python 1.6, 1.7, and maybe even 1.8 release. (It was originally called Python 2.0, then renamed as sort of an MST3K reference.)
I work on a semiconductor-related project, and it's amazing how poorly written the fabulously expensive layout tools are. Take L-Edit as an example; the interfaces are ugly and poorly designed, the software quality is doubtful (it dumps core when you try to run it on a 16-bit X display). A free version, written to modern standards, would have a serious chance at winning out over the commercial stuff, or at least provide them with some competition.
Only alphas of 1.6 have been released; things aren't at a beta stage yet.
This week I checked in a relevant change; the old curses module has been replaced with a greatly expanded version that provides many ncurses features, such as colour. This means that you can no longer use the module with BSD curses implementations, but everyone has switched to SYSV curses (which is what ncurses implements), so there's no great loss except for people on really ancient platforms. The Curses HOWTO might help, though it needs extensive updating for the new module.
I don't think client-side scripting is the goal here; instead, they're more likely to work on making it possible to write XPCOM components in Python and Perl. Client-side is apparently a problem because there are various sections of code in Mozilla that are really JavaScript-specific. It's possible to fix this, but it's too big a job to do before Mozilla 1.0. Instead, you could prototype an XPCOM component in Python, get the interface right, and then translate the code to C++ once you're convinced the idea is practical, the interface is correct, and can deal with the slower development speed of c++. For an IDE, you'd probably never translate to C++. For example, the XML-RPC component that just went into Mozilla isn't accessible from JavaScript in a Web page at all, only to chrome and to other components, which are already sitting on your disk.
Miguel, what's the plan for handling security? Some data formats are safe, such as text/plain or SVG, since they don't have enough power to do anything dangerous. Other formats, such as PostScript, aren't necessarily safe to interpret. How is this handled? Do rendering components for SVG, PS, etc. have an interface where the mailer can find out how dangerous they are, or is there some other scheme?
"Python as a standard teaching language?" Not going to happen. Using python as a teaching language was a popular topic at the most recent Python conference, in two papers by Jeffre y Elkner and Fra nk Stajano. But there is no standard programming language used in US high schools. The closest is, astoundingly, C++, because the standardized tests switched from Pascal to C++ a few years ago, and many schools teach only with an eye on the test. Wonder if this is giving students the impression that programming is painfully difficult, and frightening them away from the field?
"When Bad Design Elements Become the Standard", on some de facto Web site design standards, is an excellent (and a useful) essay. However, it only touches on page design. Form fill-in is even more important, since forms are common and usually critical to a Web interaction.
My question: do you see any emerging conventions for form fill-in? (Highlighting erroneous fields, allowing corrections, etc.)
One of the nice things about the Python community is that it contains a lot of people who just like programming languages; you often see people proposing to add some cool feature from Icon or Haskell to the language. (The answer's usually "no", but that's another story, and we get some interesting discussions in the meantime.) The author of Ruby has shown up on comp.lang.python and participated in some low-flame-content threads. Ruby's certainly interesting, but talk of it killing off Python is rather optimistic.
For example, as pointed out in the c.l.p thread, the DeveloperWorks article says "For example, Perl's use of "@", "$", and "%" often causes considerable grief and confusion." The root problem the article's talking about is more the presence of explicit references, not the arbitrary syntax characters, but anyway... Later on, the article explains some of Ruby's syntax: ""var" specifies a local variable, "@var" specifies an instance variable, "$var" specifies a global variable." Hmm...
I remember postings years ago where people argued that Java would probably kill off Python, though Perl would survive. Thanks to JPython, Java now represents a growth area for Python, and one where Perl doesn't yet have anything comparable, so things turned out just the opposite. Neither Perl nor Python have killed off Tcl. Don't go talking about Ruby replacing other languages, because it certainly won't, and because such hype leads to bitter disappointment later. (See Java, again, for an example of that.)
There's actually a third, experimental Python implementation: Vyper, written in OCaml by Max Skaller. Skaller's interested in compiling directly to OCaml, doing type inference, and experimenting with new scoping rules and keywords. Still quite alpha, and obviously there are incompatibilities with CPython and JPython (but then, that's the point).
I think it's neat that Python is small enough so that you stand a reasonable chance of implementing it on top of your system language of choice, be it C, Java, OCaml, Modula-3, or whatever.
I don't think the problem is debug code. Rather, there are probably still unoptimized hot-spots in the code. Check out the.performance newsgroup; people will report that profiling shows a method is getting called 2000 times a second, and the function is either optimized or code rearranged to call it less often.
I read Stoll's book a month ago; here's my capsule review:
A remarkably repetitive book that would have been good at the length
of, say, 50 pages or so, but instead is padded out to 239 pages.
Stoll's basic points are nothing novel: 1) Information is not wisdom.
2) Computers are expensive and get outdated really quickly. 3) Because
you're on the computer right now, you're not doing some other activity
that Stoll considers more worthy. There are a few amusing anecdotes
scattered through the text, but mostly this book is one long
complaint; at
times justifiable, at times not, but irritating throughout.
Seconded. Michael Hart's been working on PG's etexts since the early 70s, yet it gets amazingly little recognition in the middle of all the open source hype.
I think it's really difficult for database vendors to compete with the large enterprise databases. Sybase and Informix both have declining market share in favor of Oracle, IBM, and SQL Server, and midrange databases such as Solid and Interbase have the same problems. Solid enraged many users who argued for Solid over other systems such as Oracle, and then were left with egg on their face when Solid said they were no longer interested in small purchasers, and an open-sourced Interbase would stand to gain many of those users.
It's really too early to tell anything at this point; we haven't seen the code to judge its quality, we don't know if Inprise is orphaning the product or planning to support it, and don't know what licence it'll be under. Mostly this thread is just speculation; we really have to wait for more information before making a final judgement. Still, I'll be looking forward to seeing it...
It's because of the volunteer nature of the reviews; sometimes you'll read a book, think "Wow, this is really good! I want to evangelize it to others!". If the book was indifferent, there's no such impulse. For example, I read David Gelertner's Machine Beauty a while back, and thought it made some good points, but lost its focus and ultimately was a disappointment. Not much impulse to write a review that says just "Enh."
The idea is: you write programs which offer services, and other programs can locate services that match a set of given criteria. (The use of the word "service" might be a bit misleading. One example used in the docs is a company that sells computers; they'd create a single service object for each model they offer, and other software could then find computers with the right features.) Services are offered by connecting to an e-speak core, which is a server that provides the basic e-speak functions. Cores can be connected to other cores, similar to how IRC servers are connected together. Basically e-speak is an attempt at infrastructure building; if it catches on, organizations would have a set of e-speak servers, in much the same way that they have DNS, mail, and file servers.
The architectural docs do explain all this, though they're not an easy read, and sometimes terminology is a bit strange. (For example, "contracts", as used in the docs, seem a lot like the common meaning of "interface".)
Agreed. Other people have said that mailing lists are public, and thus anything posted to a list is fair game, but mailing lists and the better Usenet groups are more akin to a conversation than a public notice board. Opinions shift over the course of a thread, things are sometimes posted in the heat of anger, and off-the-cuff remarks are made which sometimes prove to be inaccurate. For example, I've often posted "I should have a new release of XYZ out by the weekend," and then other events intervene and make me miss the promised date. That's of no great account, but I'd certainly be annoyed to find my spur-of-the-moment estimate posted as a story under the headline "New XYZ release this weekend".
Considering all postings as fair game will damage the community's openness, because discussion will have to migrate from publicly available lists like debian-legal to closed, private lists that aren't archived and aren't accessible to the public, making the development community more insular and secretive. I don't want to see the honest technical discussion driven into hiding, just so that Slashdot can maintain a reputation for carrying breaking news. Roblimo is wrong; Slashdot was irresponsible in posting the article so quickly.
In the webshell/embed/gtk/ directory of the Mozilla source tree, there's a widget that lets you embed the Mozilla layout engine in GTk+ software. There are also some examples in webshell/embed/xlib/ for GTk+, Qt, Motif, and Xt, but I don't know if they're still maintained or not.
There already are; the Python/Qt bindings are very nice, for example, but few people seem to have started writing KDE applications in anything other than C++.
Slashdot Mirror
Tiny difference... Linus actually had some running code when he posted for the first time. One of my metrics for telling whether a project will go anywhere: is there some code to start off with, or is it all just theorizing and high-flown design?
For my account, see July 20-22 in my online diary. I agree with Emmett; it was a superb techie conference, though I'd like to see more userspace-related topics.
People will have to calculate how much a feature is worth to them. If feature X would be really useful to you, you could either 1) hope someone else will pay for feature X, and live without it while you wait and hope, or 2) pay for it *now*, and get use out of it *now*. It's like deciding to buy a new computer; sure, the same amount of money will buy a faster system in 6 months, but if you buy it now, you get 6 months usage of a faster machine; you have to figure out at what point the expenditure is worth it.
Zope is usually run as a long-running process that's accessed through either Persistent CGI or FastCGI (though the FastCGI was still unstable when I tried it). A FastCGI module is also available if you just want to run regular CGI scripts a bit faster, and mod_python is available as an Apache module.
Supporting Unicode shouldn't be that big a deal, though there are still things to argue over, and it's slated for 1.6. The current interface is documented in this Unicode proposal; what's described there is mostly already implemented in the 1.6 alpha releases and CVS tree. Outstanding issues still remain: 1) the default encoding to use, 2) a Unicode-aware regex engine (partially there in 1.6a2, with a new version about to hit the CVS tree) and 3) declaring an encoding for Python source files (probably going to be left to 1.7). If you want to see good Unicode support in 1.6, I'd recommend compiling the CVS tree, trying it out on your application, and complaining loudly if you find shortcomings. Experience with an actual application is worth dozens of vague speculations.
Ever heard of a little show called Mystery Science Theater 3000? (Python, the first language named after two great comedy shows!)
Python 3000 is the vaporware future version of Python in which Guido will not feel constrained to preserve backward compatibility. In other words, it's Guido's last chance to fix the language. Currently development is supposed to start around 2002, after Python 1.6, 1.7, and maybe even 1.8 release. (It was originally called Python 2.0, then renamed as sort of an MST3K reference.)
I work on a semiconductor-related project, and it's amazing how poorly written the fabulously expensive layout tools are. Take L-Edit as an example; the interfaces are ugly and poorly designed, the software quality is doubtful (it dumps core when you try to run it on a 16-bit X display). A free version, written to modern standards, would have a serious chance at winning out over the commercial stuff, or at least provide them with some competition.
This week I checked in a relevant change; the old curses module has been replaced with a greatly expanded version that provides many ncurses features, such as colour. This means that you can no longer use the module with BSD curses implementations, but everyone has switched to SYSV curses (which is what ncurses implements), so there's no great loss except for people on really ancient platforms. The Curses HOWTO might help, though it needs extensive updating for the new module.
I don't think client-side scripting is the goal here; instead, they're more likely to work on making it possible to write XPCOM components in Python and Perl. Client-side is apparently a problem because there are various sections of code in Mozilla that are really JavaScript-specific. It's possible to fix this, but it's too big a job to do before Mozilla 1.0. Instead, you could prototype an XPCOM component in Python, get the interface right, and then translate the code to C++ once you're convinced the idea is practical, the interface is correct, and can deal with the slower development speed of c++. For an IDE, you'd probably never translate to C++. For example, the XML-RPC component that just went into Mozilla isn't accessible from JavaScript in a Web page at all, only to chrome and to other components, which are already sitting on your disk.
Miguel, what's the plan for handling security? Some data formats are safe, such as text/plain or SVG, since they don't have enough power to do anything dangerous. Other formats, such as PostScript, aren't necessarily safe to interpret. How is this handled? Do rendering components for SVG, PS, etc. have an interface where the mailer can find out how dangerous they are, or is there some other scheme?
Lingua Franca ran an article on academic reactions to Rand that was pretty interesting.
"Python as a standard teaching language?" Not going to happen. Using python as a teaching language was a popular topic at the most recent Python conference, in two papers by Jeffre y Elkner and Fra nk Stajano. But there is no standard programming language used in US high schools. The closest is, astoundingly, C++, because the standardized tests switched from Pascal to C++ a few years ago, and many schools teach only with an eye on the test. Wonder if this is giving students the impression that programming is painfully difficult, and frightening them away from the field?
My question: do you see any emerging conventions for form fill-in? (Highlighting erroneous fields, allowing corrections, etc.)
For example, as pointed out in the c.l.p thread, the DeveloperWorks article says "For example, Perl's use of "@", "$", and "%" often causes considerable grief and confusion." The root problem the article's talking about is more the presence of explicit references, not the arbitrary syntax characters, but anyway... Later on, the article explains some of Ruby's syntax: ""var" specifies a local variable, "@var" specifies an instance variable, "$var" specifies a global variable." Hmm...
I remember postings years ago where people argued that Java would probably kill off Python, though Perl would survive. Thanks to JPython, Java now represents a growth area for Python, and one where Perl doesn't yet have anything comparable, so things turned out just the opposite. Neither Perl nor Python have killed off Tcl. Don't go talking about Ruby replacing other languages, because it certainly won't, and because such hype leads to bitter disappointment later. (See Java, again, for an example of that.)
I think it's neat that Python is small enough so that you stand a reasonable chance of implementing it on top of your system language of choice, be it C, Java, OCaml, Modula-3, or whatever.
I don't think the problem is debug code. Rather, there are probably still unoptimized hot-spots in the code. Check out the .performance newsgroup; people will report that profiling shows a method is getting called 2000 times a second, and the function is either optimized or code rearranged to call it less often.
Seconded. Michael Hart's been working on PG's etexts since the early 70s, yet it gets amazingly little recognition in the middle of all the open source hype.
It's really too early to tell anything at this point; we haven't seen the code to judge its quality, we don't know if Inprise is orphaning the product or planning to support it, and don't know what licence it'll be under. Mostly this thread is just speculation; we really have to wait for more information before making a final judgement. Still, I'll be looking forward to seeing it...
It's because of the volunteer nature of the reviews; sometimes you'll read a book, think "Wow, this is really good! I want to evangelize it to others!". If the book was indifferent, there's no such impulse. For example, I read David Gelertner's Machine Beauty a while back, and thought it made some good points, but lost its focus and ultimately was a disappointment. Not much impulse to write a review that says just "Enh."
The architectural docs do explain all this, though they're not an easy read, and sometimes terminology is a bit strange. (For example, "contracts", as used in the docs, seem a lot like the common meaning of "interface".)
Considering all postings as fair game will damage the community's openness, because discussion will have to migrate from publicly available lists like debian-legal to closed, private lists that aren't archived and aren't accessible to the public, making the development community more insular and secretive. I don't want to see the honest technical discussion driven into hiding, just so that Slashdot can maintain a reputation for carrying breaking news. Roblimo is wrong; Slashdot was irresponsible in posting the article so quickly.
In the webshell/embed/gtk/ directory of the Mozilla source tree, there's a widget that lets you embed the Mozilla layout engine in GTk+ software. There are also some examples in webshell/embed/xlib/ for GTk+, Qt, Motif, and Xt, but I don't know if they're still maintained or not.
There already are; the Python/Qt bindings are very nice, for example, but few people seem to have started writing KDE applications in anything other than C++.