Conversation

Me:  Math.floor(6530219459687219.0)
Mozilla:  6530219459687220
Me:  (sigh)

Small, complete environments

If I were to design a programming language today, I wouldn't.

Instead, I would design a programming environment. The basic requirements would be something like this:

• It's generally pleasant and productive. To me, this means the environment itself is small, simple, and fast.

• It produces the kind of programs people like (featureful, unburdensome, fast enough, small enough, easy to use, and on time :)).

• It interoperates. You can drop in external stuff (source code, binary libraries, editors, tools) and it'll work smoothly. And vice versa: you can drop your project into an existing environment that has lots of other stuff going on, and it'll work.

What would this environment look like? I'll know it when I see it. In the meantime, here are some thoughts. It would have:

1. A language with these properties:

   1. I can compile it to a raw executable that doesn't require the end user to install a VM. The simplest deployment model is, end user drops a single executable file into a directory of his or her choosing. End of story. (Almost nobody attempts this these days, since it's hard to reconcile this with rich libraries, portability across hardware, and good high-level language features. But it can be done.)

   2. I can add a third-party library to my project just by dropping it into the appropriate place in the source tree. (The Java WAR deployment model gets this right.)

   3. It's easy to integrate with pieces written in other languages. (This is really hard to get right. Microsoft .NET interop comes closest, as far as I know.)

   4. Build dependencies are present in the source code. (I haven't thought much about this, but the build system needs it.)

   5. The ability to express basic metadata about a project in source code. If it's a program, as opposed to a shared library, the source code reflects that.

   6. ...And of course the various properties any good language should have, things like well-designed libraries, readable syntax, decent support for refactoring, stupid mistake checking, portability, similar behavior across operating systems and hardware architectures, debugability, and as few irritating features as possible. (Nobody has it all, but there are plenty of nice languages out there.)

2. A build system with these properties:

   1. It ordinarily works without any makefiles. Dependencies are determined by looking at the source code. Things like linker options are determined by looking at the metadata, which is also in the source code.

   2. You can type something ridiculously simple, like "build foo", and it builds foo, including dependencies, relatively quickly.

   3. It can handle generated code.

3. An installer system with these properties:

   1. Extremely basic, intentionally anemic compared to, say, MSI. Can't install e.g. registry keys. It only installs files; it's parameterizable. But it groks versions.

   2. You can type something ridiculously simple, like "build foo.msi", and it builds foo.msi. Creates an MSI file on Windows, an RPM on Linux, whatever.

   3. It's optional. You can always use the "simple deployment model" (see 1a.)

4. A decent IDE and debugger that work well without project files. (Microsoft Visual C++ 2003 and later score high marks here.)

The language requirements alone are nowhere near being met, but of course you pick the language of your choice and work toward implementing the features that are missing.

Small, complete programming languages hold appeal for lots of people. It seems weird that I haven't seen a small, complete programming environment since vi+cc+make.

Nixie tubes

Today I learned:

From the early 1950's to the 1970's Nixie tubes were the dominant display service.

They only display digits, and they look a little like neon signs and a little bit like the filament of a light bulb.

Inform 7

Inform 7 looks fantastic. I wish I had time to play with it.

Worksheets revisited

I'm convinced that worksheets have not just a place but a central place in IDEs.

Here's the idea. A worksheet is a document that contains code. It's not like Excel: the code is visible all the time. But like Excel, it's "live": it runs the code as needed and displays the results right there on the page. If you edit some code, the worksheet automatically recompiles it and recalculates any affected results throughout the sheet.

The worksheet runs in a sandbox. It has access to useful testing resources—read access to other files in the same project, write access to a temp directory, and so on—but nothing much else.

Unlike a source file, the code in a worksheet doesn't have to be complete classes. Just a statement or an expression is enough. If you type an expression, the worksheet automatically shows you the result. If it's an object, it's displayed as some kind of nicely expandable, inspectable GUI widget. It's integrated with the debugger, of course.

It's also integrated with a word processor, so you can mix text and pictures with your code. None of this is meant to replace traditional source code; you'll have worksheets in your project alongside source files.

I don't know of any existing IDEs that have anything like this. But it sounds ideal for proof-of-concept demonstrations, API documentation, teaching, and testing.

My next side project is going into this territory. I'm kind of excited about it.

tewald

I met tewald via La Leche League.

Tim has the following interesting properties:

• once worked on MSDN, at the software architect level, I think
• would be named time if he followed the old-school Microsoft convention of full first name followed by last initial
• has drunk more gallon jugs of the XML Kool-Aid than anyone else I know
• has tons of Lego trains in a box somewhere, waiting for his toddler's third birthday so it'll be safe to take them out.

Great guy to have a beer with and talk programming languages, something I hope to do in the not-too-distant future.

To do

• Write an article, "What do objects do all day?", talking about the various roles classes play in a program. Some classes are, in no particular order, (a) collections of data, all public except for details of memory management and such: ArrayList, BigDecimal, Point, AffineTransform, org.w3c.dom.Document, and I guess String; (b) handles to software entities that live in the kernel or out of process: Socket, Process, java.sql.Connection; (c) data sources and sinks: ResultSet, OutputStream, Iterator; (d) event handlers—these don't model anything at all, you just use them to hook into other objects; (e) representations of some random programming language concept that the language doesn't have special syntactic support for, like a logic variable, a closure, or a future; (f) models of real-world "things" in the problem domain.

  I'm interested in this because I'm interested in what code means. I think having a clear idea of what you mean gets your job done faster, leads to more readable code and a more flexible design, and reduces bugs.

  The few object-oriented textbooks I remember at all focused their abstract discussion of “what objects mean” entirely on (f). It was as though the authors didn't really think about the question. But I suspect (without substantiation) that different techniques—and different programming language features—matter in different cases.

• Find out if anyone does studies of questions like these: How many arguments does a method take, on average? (You get different answers if you count method declarations, method calls in source code, method calls at runtime.) What proportion of method calls take any complex arguments (I mean, arguments that can't be represented losslessly as smallish strings)? What proportion of methods simply delegate their job to some other object? What kind of changes do people make to existing code? Are there trends in these numbers over time?