Fortran: 50 Years of go to

And still no end in sight

At heise online news there is the original article.

LISA - Intelligent Software Agents for Common Lisp - AI rule system in Common Lisp, similar to CLIPS

Logilab.org - Constraint - Constraint Satisfaction Problem Solver in Python

pirate (python on parrot) - Approaches of a Python Compiler for Parrot

PyLog -- A first order logic library in Python - Sowas wie Prolog in Python

Accusation of Code Theft Against Mambo Project

Mere technical ignorance, or an attempt at rip-off?

At heise online news there's the original article.

Edgewall | Trac - Project tool with web interface - Subversion, Wiki, Timeline, Bug tracking

Ian Bickings Wiki - Interesting wiki in Python and Webware based on reStructuredText

Factor Example Server

Chris Double has set up a Factor server that anyone can play around with. Factor is interesting because it has a development environment completely built on web browsers with inspectors, browsers, and editors - so you can change everything via a web browser, including the running code of the server. However, it's not like Zope - so a CMS interface. Instead, they are rather Smalltalk-oriented tools, that is, low-level programming tools. Very nice overall. The language also strikes a chord with me: a mixture of Joy, Lisp, and Forth. Given my affinity for Lisp and Forth, it's clear that I have to engage with something like this. At Planet Lisp you can find the original article.

I/O on Symbian Nokia Mobile Phones

Chris Double has also implemented IO for Nokia phones running Symbian. The whole thing is currently functional on the 7610. Very interesting — IO is a language that draws heavily from Smalltalk, NewtonScript, Lisp, Self, and other languages, borrowing interesting ideas from everywhere. It's a language with prototype-based object orientation and various ideas from functional programming. The language is quite interesting even without a mobile phone. At Planet Lisp you can find the original article.

The GBBopen Project - Blackboard software that also runs under OpenMCL

GOO

Goo is also a very interesting Lisp dialect. Strongly influenced by Dylan and with a very compact syntax. However, the stuff doesn't compile on Jaguar - has anyone managed to get it working and have a few patches ready? I didn't find anything on the web.

Here's the original article.

Aquarium - Web Framework for Python - also under mod_python. Worth noting.

::jamesoff:: » Check RBL for WordPress 0.1 - Check comment accesses against RBLs - possibly interesting to filter spam access from the start?

lemonodor: Lisp for the Mindstorm

Way cool: a Lisp that runs directly on the Mindstorm RCX. Not via the PC, but an autonomous Lisp system with actuators and sensors. Unfortunately the RCX has somewhat limited memory, but still - that's pretty neat.

At Planet Lisp you can find the original article.

MrEd Designer - GUI builder for PLT Scheme

The Robinson House | RSS and Delta Encoding

Delta Encoding for RSS - as a WP hack. Possibly also implement at PyCS?

elephant - simple object database for Common Lisp

newLisp: A better Lisp/Scheme Fusion...

Noted, I need to take a closer look at that. I've been pondering for quite a while what I should move on to after Python - Scheme would be an alternative, but after my longer time with Python, it somehow feels too verbose to me.

Somehow a not entirely unimportant factor that the Lisp community likes to ignore: names shouldn't be too long, otherwise you'll wear out your fingers typing. Sure, with macros you can make things more compact, but that's not what macros are for. A language with a script orientation should help you formulate your program quickly. In scsh, for example, that's far from the case.

However, when I look at the language definition, the whole thing is a bit strange. Many areas feel somewhat unfinished and un-lispy. Some of the concepts (e.g., exception handling) are rather primitive. Also, the foundation on heavily side-effect-oriented programming (due to symbols being used as hooks for everything and anything) is inelegant. And last but not least, the death blow: dynamic scoping. While cushioned by lexical namespace assignments, still: dynamic scoping is almost always more reason for trouble than joy.

Other aspects, however, are quite appealing, especially the very lean language scope and the few but efficient basic data types.

The syntax should become somewhat more logical - for example, marking all destructive functions with !, marking all property checks with ? - that's compact to write and easy to remember. For instance, the choice of set-nth for the non-destructive and nth-set for the destructive variant of changing the nth element of a data structure isn't really memorable and begs for confusion.

All in all, a clever idea, but probably less of a grand slam than it's made out to be. More in the class of Emacs Lisp - script Lisp, but a bit hacky.

At Lambda the Ultimate - Programming Languages Weblog there's the original article.

Weaknesses in the MIME Standard

Oh Kinners, those Heise guys don't really know much either. Yes, the standard doesn't define every impossible case. So what? RFCs never do either. It's not necessary either - just because a standard doesn't define every possible situation down to the last detail, that doesn't mean programmers can throw their brains away and just build in whatever causes trouble. It's not the standard that's defective or has weaknesses - it's the implementations in the programs. A standard might not be complete - but that would mean that functionality in relation to the content of the standard is not sufficiently defined. But not that everything that's not part of the standard is not sufficiently defined. Or something like that.

At heise online news there's the original article.

2 GB Data Uploaded

Pretty funny. Today my blog reached the limit of 2 GB of data uploads. So through all the changes, new posts, images, etc., I've uploaded a total of 2 GB of data to the server since my blog's existence. Since the Python Community Server had a life counter for uploaded bytes, I wasn't allowed to participate for a while until I patched the Community Server accordingly.

Collations and Linguistic Sorting - How Unicode sorting works

Emacs on Aqua - And here an Aqua version is being built - but still quite buggy

mindlube software / developer / revclips - Integration of CLIPS - Expert System Shell - in Runtime Revolution

mindlube software / developer / revzeroconf - Rendezvous Library for Revolution - even cross-platform

mindlube software / emacs for os x - Another Emacs version for OS X - this time only as .APP

Porkrind Dot Org: Carbon Emacs Port - Emacs 21 for OS X

Vim (Vi IMproved) for Mac OSX - VI Improved is also available for OS X - with Aqua Interface

RFC 2229 - RFC for the Dict Protocol

Squawks of the Parrot: Suboptimal optimizing

PostgreSQL has a bug when optimizing LIKE expressions.

HyperPAD - Application Development Software published by Brightbill-Roberts and IQ Technologies.

While browsing through old software and investigating what became of it, I came across the now free — as in free beer — availability of HyperPad. HyperPad was a programming environment for DOS computers that was heavily inspired by HyperCard. No graphics, but a pretty good recreation of what made HyperCard special — and an almost identical copy of the programming language. Quite amusing for the time, when integrated development environments with GUI builders were still utopias from the workstation market.

Here's the original article.

Smalltalk/X - the forgotten Smalltalk

Forgotten because I never think about it being there. Yet it is one of the more interesting implementations: free as in free beer, even for commercial purposes. Support costs money (which is fine). Good portability - unfortunately not available on OS/X - when you consider Windows and various Unix systems. And a compiler that generates natively executable programs directly - especially practical for classical application development. Due to the nature of compilation (via a C compiler), integration of external C libraries is also good. So if you can live with the platform limitation, it is certainly a very interesting implementation.

Here you can find the original article.

WebHome - Cookbook - s c h e m a t i c s : c o o k b o o k - Cookbook for practical Scheme applications

Project Schematics - Diverse Scheme code for MzScheme, including database drivers, wiki, PDF writer ...

spgsql - PostgreSQL driver written entirely in Scheme

Zach Beane

Elephant sounds interesting - a database for Lisp objects based on Sleepycat-DB. Would be another possible building block for a Lisp rewrite of PyDS or similar projects where you need a directly embedded database.

At Planet Lisp there's the original article.

Io - nice little prototype-based object-oriented programming language

Visual Studio Magazine - Guest Opinion - Save the Hobbyist Programmer

An older, but interesting article that points to an important problem: hobby programmers are increasingly being excluded from creating small hacks and simple solutions by ever more complex system interfaces and constant changes to APIs and programming tools in the Windows world. And it's not just the Windows world that suffers from this. Linux and OS X suffer from it in part as well.

Of course, there are still small utilities with simple programming capabilities. Or scripting languages that are easy to learn and use - for example, Python. But that's not really a solution for these tinkerers. What was once the omnipresent Basic for hobby tinkerers, or for example the - admittedly problematic - language in dBase, is missing today. Hardly any programming environment that doesn't come with an object-oriented approach. Hardly any solution approaches that don't try to be a general development environment for complete programs right away.

There are still some nice exceptions - FileMaker on the Mac still tries to appeal to the hobby hacker. But it's still true: the simple entry points are becoming fewer.

Even AppleScript on the Mac has become so complex and bloated in the meantime that it's hardly possible for a newcomer to just get started with it. Some corners of AppleScript are obscure and complicated even for old programming veterans like me. And of course, while there are many great integration possibilities for all these scripting languages, the documentation for precisely these parts is downright terrible.

To stick with the AppleScript example: while there are application dictionaries that document an application's AppleScript capabilities, nearly all the descriptions I've read in them have assumed that the user already has complete and extensive knowledge of AppleScript and AppleScript structures (what are objects in AppleScript, how do you work with containers, etc.). Although these dictionaries could serve as a starting point for the hobby programmer, their creators (professional programmers in software companies) design them in such a way that often even they themselves can make sense of them.

It's similar in the Linux world. TCL was once the standard scripting language for simple entry with simple structure, an almost primitive extension interface, and the ability for even non-programmers to quickly arrive at solutions. Today, TCL in the standard distribution (which is then nicely called "Batteries Included" - only unfortunately the understandable instructions are missing) already consists of mountains of packages, many of which deal with metaязыage aspects (e.g., incrTCL and the widget libraries built on it and on TK - good grief, in just this brief mention of the content there are more incomprehensible words for a beginner than filler words), which a beginner will never understand.

And I don't need to go into the dismal situation under Windows with the scripting host and the OLE Automation interfaces (or whatever they're called these days) - anyone who has experienced a version change of an application and had to completely rewrite their entire solution due to a total change in the scripting model of, say, Access, knows what I'm talking about.

Ultimately, we (we == professional programmers) are taking a piece of freedom away from end users - the freedom to tinker around and yes, also the freedom to shoot themselves in the foot. And I think that precisely in the world of free software, programmers should start spending some thoughts on this again. It's nice that almost every larger program embeds some scripting language. But what's not so nice is that hardly any of these embeddings have decent documentation of their capabilities, and only the most primitive examples and complete solutions for very complex applications are available as starting points for learning. Hobby programmers in particular learn most easily by reading existing tools. And yes, I'm not exactly a good example myself, because the Python Desktop Server has a number of extensibilities that are also intended for end users - but I also wrote far too little documentation for it. Somehow a shame, because that's how many projects become incestuous affairs, because the actual end users are left out. No, I don't have a real solution - because especially with free projects, documentation creation is often an annoying and unpopular part of the project and is therefore treated like a stepchild. Besides, most programmers aren't able to create generally understandable documentation anyway. But maybe that's also an opportunity for projects that try to increase activity in large open source community projects that have had lower participation so far. debian-women comes to mind spontaneously (since Jutta is currently working on it). Because greater participation by women would certainly also be helpful for documentation and information that doesn't necessarily require a fully trained master hacker. After all, not everyone has the desire to spend their entire life learning new APIs and tools ... Here's the original article.

USB-Cams: The Battle with the GPL

Too bad. Heise News didn't understand it either. Webcam users wouldn't be left in the lurch if the module maintainer weren't acting like an offended crybaby and nurturing his poor ego. Because as a module outside the kernel, it would still be possible to offer support without problems (and if the hardware really is so widespread, distributions like Suse would certainly include it in the distribution kernel).

Nobody has a fixed right to be in the actual kernel source with their module. Often it doesn't even make sense - because some modules directly in kernel source aren't properly maintained and thus a constant source of trouble when kernel interfaces change.

And purely binary components of a kernel module are a security risk, since their function cannot be verified. And they directly contradict the GPL - that has nothing to do with overly pedantic interpretation. Binary kernel modules, or even just parts of them, are always a problem. And hooks that only serve to give such a component access to the kernel are not necessarily what I understand as secure kernel design...

At heise online news there's the original article.

librep - A very lightweight Lisp interpreter specifically designed for embedding Lisp in programs as a scripting language

Lush: Lisp Universal SHell - Interesting Lisp dialect with its own statically typed Lisp derivative for efficient compilation

mod_rep - Integration of librep (Lisp interpreter) in Apache similar to mod_perl

SourceForge.net: Project Info - Common Lisp JPEG Library - JPEG Encoder/Decoder in Common Lisp

thunk webserver - interesting web server entirely in Scheme - suitable for porting TooFPy?

Bigloo homepage - Bigloo is one of the most powerful Scheme implementations with various code generators (.NET, JVM, and C code)

Developers and Their Misunderstanding of Open Source

Quite remarkable. Here we have a developer of a kernel driver for Philips webcams. This kernel module works, but to fully support the cameras, it needs a binary-only module. However, the kernel developers have decided to clean up binary-only modules. The Philips webcam module is also affected. As a result, the USB subsystem maintainer removed a hook from the kernel module through which the binary-only module could attach itself to the kernel.

The module developer is now complaining that his module would be demoted to a second-class module because it could only be distributed as an externally maintained module, but not directly in the kernel tree—because without the hook, his binary-only module cannot be loaded. Out of spite, he throws in the towel and no longer wants to support the module at all.

Where is the logical error? With the kernel developers who reject binary-only modules and don't want backdoors for binary-only modules in the kernel? Hardly.

The module developer could simply continue operating and distributing his module outside the kernel. He just can't be distributed with the hook directly in the kernel. He could distribute kernel patches that patch the hook into the kernel source. He rejects both options.

Such or similar discussions come up repeatedly when individual developers fail with their great idea—and yes, sometimes the failure only comes after a few years because previous maintainers took a more relaxed view of the whole thing. But binary-only modules in the Linux kernel are a constant nuisance: not only can't you fix them because you don't have the source. You also can't do security reviews. And sorry, but any decent admin doesn't want hooks on their system through which unverifiable binary modules can plug into the kernel.

Ultimately, the whole thing comes down to whether Linux must support every piece of hardware, even if there are no open source drivers for it. That Linux can also serve proprietary interfaces is clear—simply develop subsystems outside the kernel and integrate them into the kernel. The support for this is built into the kernel. But must the kernel itself support such modules?

In my opinion, no. It's certainly a downgrade for modules with purely binary components when they can't be distributed along with the kernel. But modules with purely binary components are already second-class citizens in an open source system anyway.

Of course, it may be more complicated for the user (although with Debian GNU/Linux, for example, it's quite trivial to install module subsystems to the kernel), but it can hardly be the goal of an open source system to compromise its own principles to make something easier that isn't even a focus of that system.

The real cause of the problem doesn't lie in the behavior of the Linux subsystem maintainers. The real cause lies in Philips' stubbornness in not wanting to release parts of the driver.

The fact that the module author is now scorching the earth (deleting downloads, deleting the mailbox, deleting sources, FAQs, etc.) just proves that he doesn't get it. Well, someone else will probably take the source and all the stuff and continue operating it—probably outside the kernel. The author didn't get that either. Instead, he's acting like a stubborn child.

Here's the original article.

Linda and Service Oriented Architectures - Description of TupleSpaces - PDF Version

Optimal syntax for Python decorators - a significantly better alternative to the current decorator syntax in Python

Psyche - A Scheme in Python that can be extended with Python functions

QScheme - compact and fast Scheme based on its own VM