Fortran: 50 Jahre go to
Und immer noch kein Ende in Sicht
Bei heise online news gibts den Originalartikel.
programmierung - 26.8.2004 - 20.9.2004
LISA - Intelligent Software Agents for Common Lisp - AI-Regelsystem in Common Lisp, ähnlich CLIPS
Logilab.org - Constraint - Constraint Satisfaction Problem Solver in Python
pirate (python on parrot) - Ansätze eines Python Compilers für Parrot
PyLog -- Eine Bibliothek für die Prädikatenlogik erster Ordnung in Python - So etwas wie Prolog in Python
Vorwurf des Code-Diebstahls an Mambo-Projekt
Hmm. Blosses technisches Unverständnis, oder der Versuch der Abzocke?
Bei heise online news gibts den Originalartikel.
Edgewall | Trac - Projektwerkzeug mit Webinterface - Subversion, Wiki, Timeline, Bugtracking
Ian Bickings Wiki - Interessantes Wiki in Python und Webware auf Basis von reStructuredText
Factor Beispielserver
Chris Double hat einen Factor Server aufgesetzt, mit dem jeder rumspielen kann. Factor ist deshalb interessant, weil es eine komplett auf Webbrowser aufgebaute Entwicklungsumgebung mit Inspektoren, Browsern und Editoren hat - man kann also alles über einen Webbrowser ändern, auch den laufenden Code des Servers. Allerdings ist es nicht wie bei Zope - also eine CMS Oberfläche. Statt dessen sind es eher Smalltalk-angelehnte Werkzeuge, also low-level Programmierwerkzeuge. Sehr nett das ganze. Die Sprache trifft auch einen Nerv bei mir: eine Mischung aus Joy, Lisp und Forth. Bei meiner Affinität zu Lisp und Forth ist es klar, das ich mich mit sowas auseinandersetzen muss Bei Planet Lisp gibts den Originalartikel.
IO auf Symbian Nokia Handys
Chris Double hat auch eine IO Implementierung für Nokia Handys mit Symbian System. Lauffähig ist das ganze derzeit auf dem 7610. Sehr interessant - IO ist eine Sprache, die sich stark an Smalltalk, NewtonScript, Lisp, Self und anderen Sprachen orientiert und überall interessante Ideen ausleiht. Es handelt sich um eine Sprache mit Prototyp-basierter Objektorientierung und diversen Ideen aus der Funktionalen Programmierung. Die Sprache ist auch ganz ohne Handy also durchaus interessant Bei Planet Lisp gibts den Originalartikel.
The GBBopen Project - Blackboard-Software die auch unter OpenMCL läuft
GOO
Goo ist ein ebenfalls sehr interessanter Lisp-Dialekt. Stark beeinflusst von Dylan und mit einer sehr kompakten Syntax. Allerdings kompiliert der Kram nicht auf Jaguar - hat jemand das schon hingekriegt und ein paar Patches parat? Ich hab im Netz nix gefunden.
Aquarium - Web Framework für Python - auch unter mod_python. Mal vormerken.
::jamesoff:: » Check RBL for WordPress 0.1 - Zugriffe auf Kommentare über RBLs prüfen - möglicherweise interessant, um von vornherein Zugriffe von Spammern zu filtern?
lemonodor: Lisp for the Mindstorm
Way cool: ein Lisp, das direkt auf dem Mindstorm RCX läuft. Nicht über den PC, sondern ein automnomes Lisp-System mit Aktoren und Sensoren. Leider hat er etwas wenig Speicher, der RCX, aber trotzdem - das hat was.
Bei Planet Lisp gibts den Originalartikel.
MrEd Designer - GUI Builder für PLT Scheme
The Robinson House | RSS and Delta Encoding - Delta Encoding für RSS - als WP Hack. Möglicherweise auch bei PyCS implementieren?
elephant - einfache Objektdatenbank für Common Lisp
newLisp: A better Lisp/Scheme Fusion...
Notiert, muss ich mir mal genauer angucken. Ich bin ja schon lange am Grübeln, was ich nach Python machen soll - Scheme wäre eine Alternative, aber irgendwie ist mir das nach meiner längeren Python-Zeit doch zu geschwätzig
Irgendwie ein nicht ganz unwichtiger Faktor, der gerne in der Lisp-Community ignoriert wird: die Namen sollten nicht zu lang sein, sonst tippt man sich den Wolf. Klar, mit Makros kann man das dann kompakter machen, aber das ist nicht der Sinn der Makros. Eine Sprache mit Script-Orientierung sollte einem helfen schnell sein Programm zu formulieren. In scsh zum Beispiel ist das alles andere als der Fall.
Wenn ich mir allerdings so die Sprachdefinition ansehe, ein bischen strange ist die Sache ja schon. Viele Bereiche wirken etwas unfertig und un-lispig. Auch sind einige der Konzepte (z.B. das Exception-Handling) eher primitiv. Auch die Basis auf stark seiteneffektiges Programmieren (dadurch das Symbole als Aufhänger für alles und jedes benutzt werden) ist unschön. Und last but not least der Todesstoss: dynamisches Scoping. Zwar durch lexikalische Namespace-Zuordnungen abgefedert, aber trotzdem: dynamisches Scoping ist fast immer mehr Grund zu Ärger als zu Freude.
Andere Aspekte aber gefallen durchaus gut, vor allem der sehr schlanke Sprachumfang und die wenigen aber effizienten Grunddatentypen.
Die Syntax sollte etwas logischer werden - z.B. alle destruktiven Funktionen mit ! kennzeichnen, alle Eigenschaftsprüfungen mit ? kennzeichen - das ist kompakt zu schreiben und gut zu merken. Zum Beispiel die Wahl von set-nth für die nicht-destruktive und nth-set für die destruktive Variante das n-te Element einer Datenstruktur zu ändern ist nicht wirklich gut zu merken und schreit nach Verwechslern.
Alles in allem eine witzige Idee, aber wohl weniger der weite Wurf als der es dargestellt wird. Eher in der Klasse von Emacs-Lisp anzusiedeln - Script-Lisp, aber ein bischen hackig.
Bei Lambda the Ultimate - Programming Languages Weblog gibts den Originalartikel.
Schwächen im MIME-Standard
Oh Kinners, die Heise-Heinis haben auch nicht wirklich viel Ahnung. Ja, der Standard definiert nicht alle unmöglichen Fälle. So what? Machen RFCs nie. Ist auch nicht notwendig - nur weil ein Standard nicht haarklein jede mögliche Situation definiert, heisst das nicht, das die Programmierer ihr Hirn wegwerfen dürfen und einfach irgendwas einbauen, was dann Ärger macht. Nicht der Standard ist defekt oder hat Schwächen - sondern die Implementierungen in den Programmen. Ein Standard ist möglicherweise nicht vollständig - aber das würde bedeuten, das Funktionalität in Bezug auf den Inhalt des Standards nicht ausreichend definiert ist. Nicht aber, das nicht alles was nicht Bestandteil des Standards ist nicht ausreichend definiert ist. Oder so.
Bei heise online news gibts den Originalartikel.
2 GB Daten hochgeladen
Schon witzig. Heute hat mein Blog die Grenze von bisher 2 GB Daten hochladen erreicht. Ich hab also durch die ganzen Änderungen, neuen Postings, Bilder etc. insgesamt 2 GB Daten auf den Server geschaufelt seit Existenz meines Blogs. Da es im Python Community Server einen Lebenszähler für hochgeladene Bytes gab, durfte ich für ein Weilchen nicht mehr mitspielen, bis ich den Community Server entsprechend gepatched habe
Collations and Linguistic Sorting - Wie Unicode Sortierung funktioniert
Emacs on Aqua - Und hier wird eine Aqua-Version gezimmert - aber noch recht buggy
mindlube software / developer / revclips - Einbindung von CLIPS - Expertensystemshell - in Runtime Revolution
mindlube software / developer / revzeroconf - Rendevouz Library für Revolution - sogar Plattformübergreifend
mindlube software / emacs for os x - Noch eine Emacs-Version für OS X - diesmal nur als .APP
Porkrind Dot Org: Carbon Emacs Port - Emacs 21 für OS X
Vim (Vi IMproved) for Mac OSX - VI Improved gibts auch für OS X - mit Aqua Interface
RFC 2229 - RFC zum Dict Protokoll
Squawks of the Parrot: Suboptimal optimizing - PostgreSQL hat einen Bug beim Optimieren von LIKE Ausdrücken
HyperPAD - Application Development Software published by Brightbill-Roberts and IQ Technologies.
Beim Stöbern in alter Software und der Suche was daraus geworden ist bin ich auf die jetzt freie - wie in Freibier - Verfügbarkeit von HyperPad gestoßen. HyperPad war eine stark von HyperCard inspirierte Programmierumgebung für DOS Rechner. Keinerlei Grafik, aber eine ziemlich gute Nachbildung dessen was HyperCard ausgemacht hat - und eine fast identische Kopie der Programmiersprache. Ganz witzig für die damalige Zeit, als integrierte Entwicklungsumgebungen mit GUI Buildern noch Utopien aus dem Workstation-Markt waren.
Smalltalk/X - das vergessene Smalltalk
Vergessen deshalb, weil ich nie dran denke das es das ja auch noch gibt. Dabei ist es eine der interessanteren Implementierungen: frei wie Freibier, auch für kommerzielle Ziele. Support kostet aber Geld (ist ja auch ok). Gute Portabilität - leider nicht auf OS/X verfügbar - wenn man Windows und diverse Unixe betrachtet. Und ein Compiler, der native direkt ausführbare Programme erzeugt - gerade für klassische Anwendungsentwicklung sehr praktisch. Bedingt durch die Art der Compilation (über einen C-Compiler) ist auch die Integration externer C-Libraries gut. Wenn man also mit der Plattformeinschränkung leben kann, ist es sicherlich eine sehr interessante Implementierung.
WebHome - Cookbook - s c h e m a t i c s : c o o k b o o k - Kochbuch für praktische Scheme-Anwendung
Project Schematics - Diverser Scheme-Code für MzScheme, unter anderem Datenbanktreiber, Wiki, PDF-Writer ...
spgsql - PostgreSQL Treiber der komplett in Scheme geschrieben ist
Zach Beane
Elephant klingt interessant - eine Datenbank für Lisp-Objekte auf der Basis von Sleepycat-DB. Wäre ein weiterer möglicher Baustein für einen Lisp-Rewrite von PyDS oder ähnliche Projekte, bei denen man eine direkt eingebettete Datenbank braucht.
Bei Planet Lisp gibts den Originalartikel.
Io - nette kleine protypbasierte objektorientierte Programmiersprache
Visual Studio Magazine - Guest Opinion - Save the Hobbyist Programmer
Ein schon älterer, aber interessanter Artikel der auf ein wichtiges Problem hinweist: Hobby-Programmierer werden immer mehr ausgeschlossen aus der Erstellung von kleinen Hacks und einfachen Lösungen durch die immer komplexeren Systeminterfaces und ständigen Wechsel von APIs und Programmierwerkzeugen in der Windows Welt. Und das ist nicht nur die Windows Welt, die davon betroffen ist. Linux und OS X leiden teilweise genauso darunter.
Klar, es gibt immer noch kleine Helfer mit einfacher Programmiermöglichkeit. Oder Scriptsprachen, die leicht zu lernen und zu benutzen sind - z.B. Python. Aber das ist nicht wirklich eine Lösung für diese Bastler. Was für Hobby-Bastler früher das omnipräsente Basic war, oder zum Beispiel die - wenn auch kranke - Sprache in DBase, das fehlt heute. Kaum noch eine Programmierumgebung die nicht ohne Objektorientierten Ansatz daher kommt. Kaum noch Lösungsansätze die nicht versuchen gleich eine allgemeine Entwicklungsumgebung für komplette Programme zu sein.
Nette Ausnahmen gibts noch - FileMaker auf dem Mac versucht immer noch den Hobby-Hacker anzusprechen. Aber es stimmt trotzdem: die einfachen Einstiege werden weniger.
Selbst AppleScript ist auf dem Mac mitlerweile dermaßen komplex und überfüllt worden, das es kaum noch einem Seiteneinsteiger möglich ist damit gleich mal loszulegen. Einige Ecken von AppleScript sind selbst für alte Programmierhasen wie mich obskur und kompliziert. Dazu kommt natürlich, das es für die ganzen Scriptsprachen zwar viele tolle Möglichkeiten der Integration von Anwendungen gibt - aber gerade diese Teile ausgesprochen mies dokumentiert sind.
Um beim Beispiel AppleScript zu bleiben: zwar gibt es die Anwendungsdictionaries, in denen die AppleScript-Fähigkeit eines Programms dokumentiert wird, aber nahezu alle dort abgelegten Beschreibungen die ich bisher gelesen habe gingen davon aus, das der Nutzer schon komplettes und weitgehendes Wissen über AppleScript und die AppleScript-Strukturen hat (was sind Objekte in AppleScript, wie arbeitet man mit Containern etc.). Obwohl also diese Dictionaries genau dem Hobby-Programmierer als Startpunkt dienen könnten, werden sie von den Erstellern (und das sind die Profi-Programmierer in den Softwarehäusern) so gestaltet, das oftmals sogar nur sie selber damit was anfangen können.
Ähnlich in der Linux-Welt. TCL war mal die Standardscriptsprache für den einfachen Einstieg mit simpler Struktur, geradezu primitivster Erweiterungsschnittstelle und der Möglichkeit selbst für Nicht-Programmierer schnell zu Lösungen zu kommen. Heute besteht TCL in der Standardauslieferung (die dann netterweise oft Batteries-Included heisst - nur dummerweise fehlt die verständliche Anleitung) schon aus Bergen von Paketen, von denen eine ganze Reihe sich mit Metasprachenaspekten beschäftigen (z.B. incrTCL und den darauf und auf TK aufbauenden Widget-Libraries - herrjeh, allein in diesem kurzen Hinweis auf den Inhalt sind mehr für einen Einsteiger unverständliche Wörter drin als Füllwörter), die ein Einsteiger nie kapieren wird.
Und auf die desolate Situation unter Windows mit dem Scripting-Host und den OLE Automation Schnittstellen (oder wie auch immer die Dinger heute heissen werden) brauche ich garnicht eingehen - wer da einmal einen Versionswechsel einer Anwendung mitgemacht hat und seine komplette Lösung komplett neu schreiben durfte dank des totalen Wechsels des Scripting-Modells von zum Beispiel Access, der weiss wovon ich rede.
Letzten Endes nehmen wir (wir == professionelle Programmierer) damit den Endanwendern ein Stück Freiheit weg - die Freiheit rumzuspielen und ja, auch die Freiheit sich selbst in den Fuss zu schiessen. Und ich denke, das gerade in der Welt der freien Software die Programmierer anfangen sollten hieran wieder mal ein paar Gedanken zu verschwenden. Es ist ja nett, das nahezu jedes grössere Programm irgendeine Scripting-Sprache einbettet. Aber weniger nett ist, das nahezu garkeine dieser Einbettungen eine vernünftige Dokumentation ihrer Möglichkeiten hat und nur primitivste Beispiel sowie Komplettlösungen sehr komplexer Anwendungen als Startpunkt fürs Lernen da sind. Gerade Hobby-Programmierer lernen nun mal am einfachsten durch das Lesen vorhandener Tools. Und ja, auch ich bin da nicht unbedingt ein gutes Beispiel, denn der Python Desktop Server hat zwar eine Reihe von Erweiterbarkeiten, die auch gerade für Endanwender gedacht sind - aber auch ich hab da viel zu wenig Dokumentation geschrieben. Irgendwie schade, denn so werden viele Projekte zu inzestuösen Veranstaltungen, weil die eigentlichen Endanwender aussen vor bleiben. Nein, eine echte Lösung hab ich keine - denn gerade bei freien Projekten ist nunmal die Dokumentationserstellung ein oftmals nerviger und unbeliebter Anteil des Projektes und wird deshalb stiefmütterlich behandelt. Ausserdem sind die meisten Programmierer sowieso nicht in der Lage allgemeinverständliche Dokumentationen zu erstellen. Vielleicht ist das aber auch eine Chance für Projekte, die versuchen die Aktivität in Grossprojekten der Open Source Gemeinschaft auf bisher geringer beteiligt sind. Mir fällt da spontan debian-women ein (da Jutta sich damit derzeit beschäftigt). Denn einer stärkeren Beteiligung von Frauen wäre sicherlich auch Dokumentation und Information die nicht unbedingt einen vollausgebildeten Master-Hacker voraussetzt hilfreich. Schliesslich hat nicht jeder Mensch Lust sein ganzes Leben auf das Lernen von immer neuen APIs und Tools zu verwenden ... Hier gibts den Originalartikel.
USB-Cams: Der K(r)ampf mit der GPL
Schade. Auch der Heise-Ticker hats nicht verstanden. Die Webcam-Nutzer müssten nicht auf dem Trockenen sitzen, wenn der Modul-Maintainer nicht beleidigte Leberwurst spielen und sein armes Ego pflegen würde. Denn als Modul ausserhalb des Kernels wäre es weiter ohne Probleme möglich den Support zu bieten (und wenn die Hardware wirklich so verbreitet ist, würden sicherlich Distributionen wie Suse etc. das in den Distributionskernel mit reinnehmen).
Niemand hat ein festes Anrecht im eigentlichen Kernelsource zu sein mit seinem Modul. Oft macht es nichtmal Sinn - denn manche direkte Kernelsource-Module sind nicht brauchbar gepflegt und damit ein steter Quell des Ärgernis bei Änderung von Kernelschnittstellen.
Und rein binäre Anteile eines Kernelmoduls sind nunmal ein Sicherheitsrisiko, da ihre Funktion nicht überprüft werden kann. Und sie widersprechen direkt der GPL - das hat nix mit überpenibler Auslegung zu tun. Binäre Kernelmodule oder auch nur Anteile daran sind immer ein Problem. Und Hooks, die nur dazu dienen einem solchen Teil den Zugang zum Kernel zu bieten sind nicht unbedingt das was ich unter sicherem Kerneldesign verstehe ...
Bei heise online news gibts den Originalartikel.
librep - Sehr schlanker Lisp-Interpreter speziell für einbettung von Lisp in Programme als Scriptsprache
Lush: Lisp Universal SHell - Interessanter Lisp-Dialekt mit eigenem statisch getypten Lisp-Derivat für effizienten Compiler
mod_rep - Integration von librep (Lisp-Interpreter) in Apache ähnlich mod_perl
SourceForge.net: Projektinfo - Common Lisp JPEG-Bibliothek - JPEG-Encoder/Decoder in Common Lisp
thunk webserver - interessanter Webserver komplett in Scheme - zur Portierung von TooFPy geeignet?
Bigloo homepage - Bigloo ist eine der mächtigsten Scheme Implementierungen mit verschiedenen Codegeneratoren (.NET, JVM und C-Code)
Entwickler und ihr Unverständnis von Open Source
Schon erstaunlich. Hier ist ein Entwickler eines Kerneltreibers für Phillips Webcams. Dieses Kernelmodul funktioniert, aber um vollständig die Kameras zu unterstützen, braucht es ein binary-only Modul. Die Kernel-Entwickler aber haben entschieden mit den binary-only Modulen aufzuräumen. Auch das Phillips Webcam Modul ist davon betroffen. Als Ergebnis hat der USB Subsystem Maintainer einen Hook aus dem Kernel-Modul rausgeworfen, über den das binary-only Modul sich an den Kernel anhängen kann.
Der Entwickler des Moduls heult jetzt rum, das sein Modul dann zum 2. Klasse Modul degradiert würde, weil es nur als extern verwaltetes Modul verteilt werden könnte, aber nicht im Kerneltree direkt - denn ohne den Hook kann ja sein binary-only Modul nicht geladen werden. Aus Trotz wirft er die Brocken hin und will das Modul garnicht mehr unterstützen.
Wo ist jetzt der Denkfehler? Bei den Kernel-Entwicklern, die binar-only Module ablehnen und auch keine Backdoors für binary-only Module im Kernel wollen? Wohl kaum.
Der Modulentwickler könnte einfach sein Modul ausserhalb des Kernels weiter betreiben und verteilen. Er kann nur nicht mit dem Hook direkt im Kernel verteilt werden. Er könnte Kernel-Patches verteilen, die den Hook in den Kernelsource patchen. Beide Möglichkeiten lehnt er ab.
Solche oder ähnliche Diskussionen kommen immer wieder hoch, wenn einzelne Entwickler mit ihrer tollen Idee scheitern - und ja, manchmal kommt das Scheitern erst nach ein paar Jahren, weil vorige Maintainer das ganze lockerer gesehen haben. Aber die binary-only Module im Linux-Kernel sind ein ständiges Ärgernis: nicht nur das man sie nicht reparieren kann, weil man den Source nicht hat. Man kann auch keine Security Reviews machen. Und sorry, aber Hooks über die sich unprüfbare binäre Module in den Kernel einklinken können, will ein anständiger Admin eh nicht auf seinem System.
Letzendlich läuft das ganze darauf hinaus, ob Linux jede Hardware unterstützen muss, auch wenn es keine Open Source Treiber für diese Hardware gibt. Das Linux auch proprietäre Schnittstellen bedienen kann, ist klar - einfach Subsysteme ausserhalb des Kernels entwickeln und in den Kernel integrieren. Der Support dafür ist im Kernel drin. Aber muss der Kernel selber solche Module unterstützen?
Meiner Meinung nach nein. Es ist natürlich eine Degradierung von Modulen mit rein binären Anteilen, wenn diese nicht im Kernel mitverteilt werden können. Aber Module mit rein binären Anteilen sind sowieso schon Module zweiter Klasse in einem Open Source System.
Klar, für den Anwender ist es unter Umständen komplizierter (wobei es z.B. bei Debian GNU/Linux ziemlich trivial ist, Modulsubsysteme zum Kernel dazu zu installieren), aber es kann kaum das Ziel eines Open Source Systems sein, seine eigenen Grundsätze aufzuweichen um etwas einfacher zu machen, das gar nicht im Fokus dieses Systems liegt.
Die wirkliche Ursache in dem Problem liegt nicht im Verhalten der Linux Subsystem Maintainer. Die wirkliche Ursache liegt in der Sturheit von Phillips, Teile des Treibers nicht freigeben zu wollen.
Das der Modul-Autor jetzt auf verbrannte Erde macht (löschen der Downloads, löschen der Mailbox, löschen der Sourcen, der FAQ etc.) beweist nur, das er es nicht kapiert hat. Nunja, irgendjemand anderes wird vermutlich den Source und das ganze Geraffel nehmen und weiter betreiben - vermutlich ausserhalb des Kernels. Auch das hat der Autor nicht kapiert. Statt dessen spielt er Trotzköpfchen.
Linda and Service Oriented Architectures - Beschreibung von TupleSpaces - PDF Version
Optimal syntax for Python decorators - eine deutlich bessere Alternative zur derzeitigen Decorator-Syntax in Python
Psyche - Ein Scheme in Python, das mit Python-Funktionen erweitert werden kann
QScheme - kompaktes und schnelles Scheme auf Basis einer eigenen VM