Dynamic constness

I've been thinking about how 'const' (C++ style) seems like a good idea but can cause pain in practice. It leads to duplicate definitions of methods (termed a "shadow world" by Anders Hejlsberg). It is really is hard to enforce statically.

See here for some great summaries.

Personally, I think the "bit" idea might work. That is, pointers are usually aligned to 4-byte boundaries. That gives two bits to play with. One of those bits might serve well for indicating constness in a dynamic fashion.

Two different pointers to the same object. One carries const. The other doesn't. Enforcement happens at runtime. Sounds maybe doable.

I'd need to think more about the container issue, though. First thought is that any const pointer is just deeply const.

Course pre tests

I was just wondering what the value might be of testing folks at the beginning of a course on the subject matter. Some people come in with more knowledge than others.

I'm afraid that without that, it's harder to see who's actually learning. And without that, it's harder to know when teaching has been effective.

Or in other words, when evaluating learning, I'd like to subtract out those who already knew a lot.

Exceptions, Processes, Java, & Go

My opinions on exception/error handling is like so: I (and I believe most other programmers) don't want to spend the time to carefully analyze every possible unlikely error case as I go. Some cases should be carefully handled. But if things go bad in an unexpected fashion, I believe this is what should happen: clean up all resources safely and then crash.

Seriously. And that's what exception handling does, if you design your code right. Either nice automatic resource cleanup (such as what's common in C#, Ruby, Python, C++, or upcoming in Java 7) or somewhat manual work such as Java finally blocks can take care of cleanup during crash.

But crash? Yes. The question is the scope of the crash.

The crash should affect the current request. For a web server, yep, that's the HTTP request. For a database, it would be the current query. For a GUI, it's the current user action.

In olden Unix days, processes were designed to do one thing and do it well. Globals were less (though still somewhat) evil, since every process was sort of like its own object. Global death was also less evil. Therefore, the old-timey C 'assert' feature was somewhat reasonable. If you kill the process, it generally kills the whole pipe chain, which also effectively kills the user command-line request. Quite reasonable in most cases.

If each response to a GUI command ran as its own process (interesting thought and probably been done by someone before), then killing that process by assert wouldn't be so evil.

But most of us seem to have decided that multi-process is too heavy and slow. We don't really need all that process weight. Even to the extent of "stackless" and subthread coroutines like in Erlang, Stackless Python, and now Go. But in any case, whether threads or smaller, killing processes by assert is clearly scary. Instead of kill the "request", you crash the whole system. Bad news.

Enter exception handling, which works well enough that almost all recent programming languages use very similar models with equivalents of 'throw' and 'catch'.

What doesn't work is expecting that everyone will want to pay attention to every possible unlikely error case along the way. Checked exceptions in Java and manual error code checking in C lead to the same problem that people ignore errors. Checked exceptions lead to ignored errors? Yes. I've seen it a lot, especially in the pre-chaining days in Java. And still it's an easy thing to do today. Why? Because I don't know what to do with the checked exception, but I have to catch it. So I catch it. And um, if I'm extra lazy (and surely no one's lazy, right?), I just ignore it. Maybe I'm nice enough to log it or wrap it.

But manual error code checking is just begging to be ignored instead of likely to be ignored.

And if you ignore errors, instead of crashing the request (and cleaning up resources), you end up in an unstable, dangerous program state.

So, the fine folks behind Go (and yes, some them obviously have many more years under their belts than me) say they don't need exceptions and can't make them work with serious parallelism anyway. Nice and well, but expect most programmers to create unstable, buggy code.

You can't expect programmers to write "a good error message now", emphasis on the now. If do, expect instead that laziness will lead to extreme bugs.

Seriously, figure out how to crash a specific "request" with automatic cleanup when errors happen, or expect bugs.

Oh, and figuring out how to produce only one error report in the logs for each failure is also awesome. Those of you who've worked in complex Java software (checked exceptions everywhere) can imagine what I mean by this. Similar issues seem easy to come by in a land of extreme parallelism, if you don't draw that "request" circle well.

Fan language now Fantom

The Fan programming language (targeting the JVM, JavaScript, and the .NET CLR) has been officially renamed to Fantom to improve searchability.

New domain name: fantom.org

Happily, file name extensions and tool names remain unchanged.

It's a great language, and here's wishing them some good times ahead!

Replicating vs. Understanding

In reading a recent dialog in an IEEE Autonomous Mental Development newsletter, they are discussing the principles vs. black art of developmental robotics. I tend to think of it as a question:

Do you want to focus more on creating intelligent robots or on understanding the details of intelligent beings actually operate? Both are meaningful questions, but principles of self-organization are not necessarily the same as the principles used in the end by a self-organized system. These topics sometimes get blurred, I think.

But principles perhaps can be found in relation to either question. So maybe I blurred the original topic myself.

So like Google's Go is from Mars: A first glance

Well, I heard about the new language Go this afternoon, and it sucked a bit of time that I'm really short on. First note is that Go is from Mars. Take this sample from the tutorial:

for i := 0; i < flag.NArg(); i++ {
    if i > 0 {
        s += Space
    }
    s += flag.Arg(i);
}

Personally, I've never seen curly-based syntax without parens on fors and ifs. Just doesn't seem right to me. There's some other style in the language that's new to me. It looks so strange that I'd almost think it were an April Fools joke ... if it were April 1st, I guess.

But to get past the initial shock of alien appearance, here's my take at a first glance. This is based on their docs. I haven't actually tried it out.

The good:

• Pure interface, simple struct, no-inheritance, straight functions OO. If you've read other posts on my blog, you can imagine I'd love this. I'm glad someone was brave enough to try it out.


• Super fast compiler. C and C++ stink in this arena.


• Fast execution, supposedly near native.


• Lightweight threads and message passing, a la Erlang. Scalability should be sweet.


• Normal goodies like closures and type inference.


• Opinionated in some things: UTF-8 source, public/private by naming convention (caps for public).


• Fairly simple namespacing.


• BSD licensing.


• It's from Google. Google has $$$$$$. They can push things forward.

The bad:

• The syntax. It's just grating to me at this point.


• Too much focus on ad hoc solutions rather than general principles.


• No concept for nullable pointers vs. not.


• No operator overloading.


• No easy interfacing to C++.


• Is it cross-platform (meaning at least Windows, Mac, and Linux) yet? I'm not sure.

The ugly:

• Um, no exception handling. Seriously. So, um, expect to have to manually check for errors all the time. Which means, expect average programmers to ignore lots of errors and write buggy code.


• Well, I'd complain about this if there were exceptions, but there's no mechanism for automatic resource cleanup (beyond garbage collection) that I could find. Less need without exceptions, but it still seems like a glaring hole to me. Also, if the closures and
  anonymous functions are good enough, maybe I'm also overstating this one.

Probably forgetting something.

Between the ugly and the fact that they aren't really production-ready yet, I think I'll just keep a watch on it for now. What I really want is language that IDE-friendly and human-friendly, compiles and runs like lightning (including fast starts and low memory usage), and instantly consumes C and C++ libraries. Oh, and doesn't make it painfully easy to ignore errors.

GPGPU in the browser

This winning entry in the Mozilla Labs Jetpack competition might get many of the details wrong (as examples, why part of Jetpack instead of as its own extension and how it uses Nvidia CUDA instead of a cross-vendor solution), but I'm still super excited that it has drawn attention to putting GPGPU in the browser. So, three cheers for Alexander Miltsev!

Inverse Programming Assignments

I was just wondering today if there was a good way to let students play the part of the computer instead of the programmer. That is, they would be given a program and be required to push and pop off the stack, change variable values, allocate objects on the heap, deal with arrays, handle conditionals and loops, choose which line to execute next, and so on.

It might be possible on paper, in board game format, or maybe more reasonable as a video game of sorts. Increasing levels of complexity (introducing new language features and machine concepts) might be nice.

Just wondering if playing the computer would help some folks with understanding the system better.

Liberally licensed embeddable web server for C or C++?

I've done some searching in the past but couldn't find a liberally licensed embeddable web server for C or C++. That surprised me. I'm so used to having multiple good options in Java (such as Jetty) or built-in web servers say in Fan or Ruby.

Two options I've looked at are libmicrohttpd (but it's LGPL which causes too much bother) and lighttpd (but it's not really designed to have an embedded option so far as I can tell, which rather surprises me). Anything else out there?