Snake Food
Och menno, and I still have Python 1.52 code in productive use
At Der Schockwellenreiter there is the original article.
Och menno, and I still have Python 1.52 code in productive use
At Der Schockwellenreiter there is the original article.
Hey! If they're making this thing native Aqua now, that's a real killer - because so far there's only Macintosh Common Lisp, since Allegro doesn't come with a GUI. However, Lispworks is unfortunately not exactly cheap, so you could almost just use MCL again.
Or OpenMCL, which costs nothing
At lemonodor there's the original article.
An interesting opinion from a Security Focus columnist on the topic of secure software. His basic thesis – the macho posturing of programmers who think their code in particular has no bugs, and the excessive use of low-level languages – is correct. It's really sometimes absurd with what primitive tools programs are created. And then people wonder why bugs occur that have been known for decades – well, of course tools are used that have existed just as long.
What he overlooks in his article, however, is the main motivation of many programmers in the open source area: fun. Many things come into being precisely because someone has fun doing them – but they only have fun because they use the tools of their choice.
From that perspective, we in the open source area will have to live with the fact that there are both bus drivers and fighter pilots among programmers – even if that means that parts of the system have holes from time to time. Because someone who simply enjoys C programming is not motivated by the fact that buffer overflows keep occurring to switch to Perl or Python. Even if that would eliminate entire classes of errors.
At WorldWideKlein - The Daily Durchblick I found the original article.
What always amazes me about all this virtual machine talk: why don't these people look at where virtual machines have actually been used for a long time before implementing such things? I mean, Smalltalk has had a virtual machine since its existence and since the mid-80s a highly efficient garbage collector as well as a whole range of advanced features. Same with Common Lisp implementations - many use internally portable code based on virtual machines. There's also corresponding experience with closures and continuations. It's not as if these topics were so terribly new - on the contrary, they're pretty old hat.
But instead of looking at where there are not only working implementations, but also the full source code for study, people prefer to tinker with their own stuff and at best refer to the JVM or the .NET CLR - two of the most pathetic implementations of virtual machines that exist (among other things because their designers make exactly the same mistake and think they know better and don't need to look at the code and ideas of old hackers).
What's really ridiculous is this continuations and closure debate. Both are essential features of Scheme and addressed in all Scheme implementations, because nothing would work without them. And many of them have highly efficient implementations for virtual machines or real CPUs.
People, please look at what others have already done decades ago before you think you have the great new idea. Or don't be too surprised if you're not taken very seriously by those who know these old systems ...
At Squawks of the Parrot there's the original article.
Of course we should focus more on the processes that create software than on alleged metrics for evaluating a project and abstract absolute values that are not tangible. This is a general problem in software development: at universities, the process of creating software itself is presented as unimportant, and only the results of analysis and design are considered important. As if analysis or design were independent of the implementation process, as if they could be directly derived from the former two. In some cases, programming itself is even separated from the normal realm of software development and packed into courses that are required as mandatory credits - but in actual teaching, it is pointed out that analysis and design predetermine the software solution, and you can do the programming in any language anyway. Absurd.
Software creation is accompanied by many components. Of course, analysis and design are among them - and not entirely unimportant ones. Preferably, these two components stand at the beginning of development. But they also accompany development during the process. But just as naturally, the actual implementation - often dismissively portrayed as mere coding, as if you were just converting one formal language into another and could hand it over to some trained monkeys - is an essential aspect that is crucially responsible for success and failure. The tools also play a role, specifically the degrees of freedom they offer, but also the degrees of freedom that programmers actively use in realization, are an essential aspect. This is not about my language being better than your language - that is banal and boring. No, it's about the fact that languages provide means of expression, just as natural languages do. Languages offer models of thinking - with 40 words for snow and ice, you can discuss snow and ice far better, but in the desert, you run out of conversation. The same is true in programming languages - they offer models of thinking that you can use. Or you can rape the language and discuss the meaning of desert with 2 words for sand.
In my opinion, it is infinitely sad that especially in the software engineering movement and in modern software development strategies (perhaps with the exception of the XP movement and the Pragmatic Programmer - but they are also often regarded as outsiders), the programming language is often dismissed as mere tool. My creed: the programming language is more than a tool. It is a way to communicate with the machine. And this communication is certainly not dry or banal or primitive. It is an intellectual challenge and a creative activity. The activity is not coding - it is communicating. The language used reveals the focus that a community has - this also applies to programming language. Its abstraction mechanisms, its degrees of freedom and expressive variety show what directions were envisioned, how the developers who designed this language see the software world. These directions and idea spaces in which a language moves are important - if I go against them in communication, I lack the words. I have to resort to circumlocutions - ugly, inelegant code is often the result.
In my now almost 20 years of programming, 16 of them professionally, I have read a lot of old code. This is essential when you spend 10 years of your working time working on an old inventory management system. And what always struck me was that inelegant code - in the sense mentioned above, but also in its most mundane form as incorrectly structured and formatted code - was almost always the code with the most bugs.
It is often a very clear sign that the failure to understand the culture of a programming language and its ethos is reflected in programming through a failure to understand complex processes - and that leads to bugs.
Ugly language designs then contribute to the fact that programs actually remind one more of curses at the machine than of what they should be (and in my opinion, are): Programs are poems for the computer!
Many programs in this context, however, remind one more of failed limericks with incorrect meter and non-rhyming lines, to which the poet has written 5 pages of explanations on how the discerning reader is supposed to interpret the poem...
At PragDave there is the original article.
Hah! If I had had that earlier, I could have written the whole Python Desktop Server in Common Lisp together with the portable allegro store and maybe a port of Woods
I found the original article at CLiki Recent Changes.
Reminds me that I wanted to port this to OpenMCL ...
At lemonodor there is the original article.
Reminds me that I wanted to try whether PyDS also works with Jython. Yes, I know, Metakit and a few other things cause problems. But there might be alternatives for that (no idea if that also applies to docutils, but you can find something there too).
At PragDave there's the original article.
Contracts for Python? Hmm. Could be interesting, especially since you can disable them to boost runtime performance later. Maybe that will help get a better handle on the problems that Python's highly dynamic environment presents. Let me take a look.
At PyPI recent updates there's the original article.
The linked page provides not only the software, but also Debian packages and explanations for setting up your own anonymous CVS server, which runs under its own user and in a chroot jail. Nice thing. I use it for the Python Desktop Server.
Noted and blogged. Could become interesting if I ever get the urge to dive back into Objective-C.
BBEdit 7.0, SSHPassKey, Python and CVS - that's what I use to build the Python Desktop Server when I'm sitting at my Mac (which I clearly prefer).
Since the CVS server isn't running locally but out on the net, ssh is set up as the transport (that's what SSHPassKey is for - it integrates SSH password prompts into Mac OS X's Keychain!).
On Linux I use VIM instead of BBEdit. Well...

At heise online news you can find the original article.
Really things get messy though when you throw HTML into the mix. Because in HTML 4, apos is no longer defined as an entity. In XHTML (since it's based on XML), on the other hand, it's of course mandatory. And in RSS (which is also XML) technically as well. What a bloody mess, that w3c, not even bothering to look at what other, similar languages do in HTML and aligning with them.
What happens? The Python Desktop Server originally also encoded the simple ' as an entity (namely apos). Most browsers do this too, only iCab and Omniweb don't. Actually those two are doing it right, because apos isn't defined in HTML 4 anyway.
But in the Python Desktop Server I only have a quoteXML routine, which I've been using for both so far. Actually I should now introduce a quoteHTML, and depending on the application, use the appropriate one. What a pain.
At Der Schockwellenreiter there's the original article.
Yeah! One of my favorite functional languages now under a usable free license. Once the Linux version progresses further, I can finally do something with it at work.
I found the original article at Lambda the Ultimate.
They're stupid, especially when you read the reasons mentioned by Paul Graham (the author of the original Lisp code) for Yahoo's decision:
Typical shallow-minded decision-making. Unfortunately there's more and more of this in software development. Afraid to learn a programming language? Pathetic.
At lemonodor you can find the original article.
No class. Once again bankers who are shameless enough to publicly advocate for "Security by Obscurity". How can one possibly go down this wrong path? Preventing public discussion does nothing to help security, since those who exploit security vulnerabilities don't participate in public discussion anyway, but instead rip people off in the dark. Public discussion, on the other hand, helps security, because through it security vulnerabilities are exposed on the one hand, but on the other hand the blind trust of people in alleged security is also reduced. We need public discussions of security vulnerabilities more urgently than ever, the more computer systems determine our everyday lives!
At heise online news you can find the original article.
Now there's an Objective-C Bridge for OS X. Hmm. Could be quite interesting to play around with.
Will the Schockwellenreiter start drooling now if I tell him that I have two Xerox Lisp machines (sister systems to the Xerox Star) standing in my room here?

(although I would still prefer the Symbolics XL1201 to the Xerox any day - at some point I really need to finally install the web server on the little fat one ...)
At Der Schockwellenreiter you can find the original article.
Yes. A pointless gimmick. That's why I also did it with the Python Desktop Server: "When is actually posted here?". Pointless, but perhaps quite interesting since the macro source is included. It's definitely advantageous to have the full capabilities of Python at your disposal.
At WorldWideKlein - The Daily Durchblick there's the original article.
Very interesting text, everyone working with OO languages should read it.
I found the original article at Lambda the Ultimate.
I could observe a similar effect with the Python Desktop Server as well: the Medusa web server, written entirely in Python, is easily capable of keeping up with Apache in terms of performance, and even in the main domain of a web server when serving static content! And Medusa doesn't even need threads for this; instead it works with multiplexing via the select() call. Quite impressive...
I found the original article at Lambda the Ultimate.
Got it. Could be quite fun if you want to spruce up marked text with Perl.
The original article is at blog.scriptdigital.com.
It's quite funny when internally at SUN there's a document circulating that explains why Java shouldn't be used internally at SUN

At Advogato there's the original article.
Hey, I used that back then to do the port of OCaml to DOS. Although it was still called Watcom C/C++ at that time. A long time ago ...
At heise online news you can find the original article.
Hihi, I'm glad I caught the calendar thing early enough, I'm just a lazy dog
By the way, the esteemed colleagues could also simply consider switching to the Python Desktop Server, for which I even have a – very rudimentary, but certainly could be expanded – migration script from Radio. After all, I had to do it myself.
I'll solve the ping issue by simply ignoring it. It doesn't matter which of the last 5 articles I show up as a change for on weblogs.com, it pings based on the weblog rather than individual articles. And the weblog really doesn't need to appear 10 times in 5 minutes just because someone can type and read quickly.
At Der Schockwellenreiter you can find the original article.
I'm seriously considering putting the Python Desktop Server under the GPL and using that. It would be worth an experiment. Hmm. At the moment the Python Desktop Server is under a BSD-like license. I'll sleep on it. Maybe I'll leave it as is.
At heise online news there's the original article.
Sorry folks, I bought myself a Zaurus today. It's eating up some of the time that would otherwise go to blogging.
Hmm. Python runs on the Zaurus, I know that. And the Python Desktop Server runs without problems under Linux. Will I soon solve MoBlogging simply by running the Python Desktop Server on the Zaurus? Once I have a usable network connection for the Zaurus, I can definitely do that. Weird
I like AppleScript well enough to take a look at it ...
You can find the original article at Der Schockwellenreiter here.
Hmm. I could take a look at that, lush sounds quite nice in particular. scsh is useful for scripts, but as an interactive shell it's not really the best ...
(Using CLISP as a shell, on the other hand, I find a bit perverse )
I found the original article at CLiki Recent Changes.
The Python Desktop Server can be extended with macros that, for example, can repair broken RSS feeds. This is a feature that was added in version 0.2.6. An example is the repair of the Dotcomtod feed at http://dotcomtod.de/backend.php - it has quite a number of bugs. The macro for this is here: "DotComTod is pretty broken when it comes to RSS".
The main problems with the feed lie in incorrect encoding of umlauts and special characters, which causes most XML parsers to either refuse to cooperate or, like the Python Desktop Server, simply produce strange results.
Another application is simpler: many feeds have no GUID, but use the link tag on the item for the same purpose. For example, Tagesschau and Telepolis. Now many of these feeds have the problem that articles are edited later - then there are problems because the articles keep reappearing in the aggregator. The following macro fixes this: "the link of an item is entered as a guid". This transfers the link to the GUID and the Python Desktop Server then uses this to identify articles that have already been seen.
Ok, I'll really dive deeper into this now and see what works with it. Because with Python 2.2 on OS X and Objective-C bindings, I could create an XML/RPC-based client for the Python Desktop Server that doesn't always require a web browser for all activities. It could certainly be faster, and the editor for posts and texts could get more features. Hmm.
I found the original article at bbums rants, code & references.
Hey, quite an interesting revival for Mumps - I could have come up with the idea of transforming it to Perl too, you could probably use tied hashes well for that. Might be quite fun to take a look at it sometime.
At search.cpan.org there's the original article.
Just because I've read it in other places too: nice that you mention the Python Desktop Server, but it's not planned for Linux, it's already been available for Linux for a long time. And Mac OS X. And BSD. Honestly.
At Industrial Technology & Witchcraft you can find the original article.
A couple of links to interviews with Guido about Python, its origins, etc. Very interesting. The interviews are to be continued on further topics.
At Kevin Altis Radio Weblog you'll find the original article.
Well, that's a typical frustration name for an HTML macro compiler that only a programmer could come up with after editing ugly HTML code for long enough
At freshmeat.net you can find the original article.
There is now a 0.2 Beta version of the Python Desktop Server. If you want to take a look at it, now is a good opportunity, since I certainly won't be making any more changes before Wednesday evening, as I'll be hanging around near Munich starting Monday. And the features are - when it comes to comparison with Radio - pretty well rounded.
Hmm. Sounds quite interesting, especially the pointer to the search functions could be quite useful for the Python Desktop Server - I definitely want to build a search engine in there, because eventually you won't find anything there anymore.
At Richard's stuff : /python there's the original article.
Hmm. I should check whether I want to switch to this version for the Python Desktop Server. However, I haven't had any serious problems with version 0.81.
The original article is available at freshmeat.net here.
Hmm. I should definitely check that out, especially if there's a chance it will support Cocoa.
At freshmeat.net you can find the original article.
Cincom has released its complete Smalltalk environment for private non-commercial use. This includes above all the complete VisualWorks Smalltalk system! A truly comprehensive programming environment for Smalltalk development, which now also runs natively on Mac OS X in a beta version. Of course, the GUI doesn't exactly look like Aqua, but that's more due to the cross-platform nature of VisualWorks - it looks equally poor everywhere. Why is this interesting? In my opinion, Smalltalk is one of the most beautiful object-oriented programming languages. And good Smalltalk systems are far more of a home for programmers than many other systems, simply because you can adapt virtually every aspect of the system - if necessary, you just reprogram the compiler or the GUI.
And VisualWorks Smalltalk has a large stack of finished parcels (packages with ready-made solutions) for the most diverse purposes, including a complete SOAP server and client environment. Ideal for interactively hacking around with web services.
Of course, you can do a lot of this with Python as well, but in the GUI area Python is simply very sparse - and the development environments for Python don't come close to what Smalltalk systems have to offer.
To be fair, it should be mentioned that Squeak is of course also an option, especially since it's truly free software and also contains a large stack of extensions. VisualWorks Smalltalk is for me much more integrated into the system and potentially also more performant (the virtual machine of VisualWorks Smalltalk is one of the most interesting ones, many features that Java is only just discovering and implementing now were already implemented there many years ago).
So folks, get up and talk some Smalltalk again! It's worth it.
Uh - Brainfuck. Debugger. IDE. Wait a minute. Did someone actually take Brainfuck seriously by accident?
You can find the original article on freshmeat.net.
Yep! That would be another Common Lisp environment for OS X. And there are already quite a few libraries available for it, since it's based on CMUCL, a rather old and mature implementation.
At lemonodor you can find the original article.
Who still wants to work with Oracle and Stored Procedures, please step forward
At Andrew Channels Dexter Pinion you'll find the original article.
Hmm. Somehow that sounds like I really want to take a closer look at this now. But probably it only works properly with 10.2, not with my 10.1.5 ...
At bbums rants, code & references I found the original article.
A new version of OpenMCL with a whole stack of bugfixes. I'll have to upgrade again in the near future.
I found the original article at lemonodor.
Sometime I wanted to take a look at that too. With xmlrpc that could work well as a GUI for the Python Desktop Server. Hmm.
At Andrew Channels Dexter Pinion there's the original article.
Possibly of interest for the Python Desktop Server? TAL does have the advantage of being well-compatible with GUI designers. Hmm. We'll see. Actually, I'm quite happy with Cheetah and StructuredText.
At Vaults of Parnassus there's the original article.
The Shock Wave Rider is also tinkering with a Python-powered weblog tool. Funny. He wants to build a mixture of Blossom and Radio. Let's see, if he open-sources it, one could go borrowing from it. With the Python Desktop Server things are progressing diligently, only for some reason it's currently having minor performance issues. Probably one of the background threads is implemented incorrectly, I think I already know who. grumble - was probably just too hectic today ... Here's the original article.
Lots of nice protocols that I could incorporate into the Python Desktop Server if I got bored.
The original article is at Ben Hammersley.com at this link.