Python just became that much more interesting for programmers not sold on it yet.
Word comes from Kevin Altis on work done by Ralph Thomas, Joerg Budischewski, and Christian Zagrodnick on "Python-UNO bridge for OO1.1", a Python integration with the Open Office API.
Great news for open source desktop software and developers.
Russell Batie is learning Python, but I wonder if he has really
Basically, I can't help thinking that Java could be made to work more like Python. I mean, there's Jython, but I don't want to talk about half-ass implementing Python on Java, I'm talking about making Java more programmer friendly like Python.
Jython is a complete Python. (Full-assed?) I would argue that Jython can also be considered a "Java made to work more like Python".
Java is established. I don't want to see the language change (much) at all. Jython is the Python way of programming with the Java class libraries. The two work together well, but one should not become too much like the other.
The distinction is beneficial and harmonious.
...and more to Henry Lieberman, himself one of the seven (or so) wonders of the software world.
A favorite from 1986's first and perhaps best OOPSLA, "Using Prototypical Objects to Implement Shared Behavior".
Another Lieberman classic not given nearly enough exposure, "There's More to Menus than Meets the Screen".
PLATO is one of the seven (or so) wonders of the software world. Not given nearly enough attention.
More than one of my favorite stories about programming comes from WyCash.
The number one item from the OSCON session by Robert Lefkowitz (r0ml) on "The Missing Open Source Projects" is...
Distributed CRON
I would look to the Erlang framework for this. Simple, distributed, robust, persistent, monitored, and integrated. I'd guess the Erlang OLTP is well above 80 percent of what is needed for an industrial strength distributed CRON.
More systems should be emulating the Erlang framework for distributed systems development. (Assuming programmers by and large are not going to adopt the Erlang language per se.)
Jon Udell is investigating Test-First (aka Test-Driven) Programming...
Test-first is quite radically different from test-later. And the most important difference I've discovered so far is that test-first... is as much a tool... exploration of the problem domain... as it is a way of protecting against regression.
You've got it Jon. I think of it this way...
Test-driven design tools are "command line interpreters" for Java, C#, and other "non-interactive" programming languages.
Programmers using Lisp, Smalltalk, APL, and other "interpreted" languages have been doing test-driven design for decades. The pattern here is to type little snippets of code for an idea, get immediate feedback, then gradually incorporate those snippets into a whole program.
Lisp has its read-eval-print loop. So does Python. Smalltalk traditionally has "workspaces" which are text editors that also evaluate highlighted code.
In either case, the end of a programming episode results in a transcript of code that is then allocated to two destinations... some of the code in the transcript are the objects or functions that go into the program itself. The rest of the code is edited into regression tests.
Looking at a test-driven incremental programming session using junit or nunit you see the very same result... the shell is the command line and xUnit is the "interpreter". You get a small idea, test it, and repeat.
The tests themselves are the "transcript" of the session, and are also the preserved regression tests.
This approach is so successful that it provides discipline for Lisp and Smalltalk programmers too. I think Kent Beck originated sunit (for Smalltalk) as a way to demonstrate to new Smalltalk programmers how to use workspaces effectively.
