Thursday, July 17, 2003

Russell Batie is learning Python, but I wonder if he has really tried Jython...

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.

Tuesday, July 15, 2003

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.)

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.

About Me

I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer.
Contact me at my gee mail account, username patrickdlogan.