From the Mind of Trevor Stone

It's October, which means I'm now allowing myself to start scheming about Advent of Code 2024. The last four years I've taken it as an opportunity to learn a new language. This year for some reason I'm inspired to learn a stack-oriented language, so I've been playing with PostScript. The world has generally moved on from PostScript: it gave birth to the wildly-popular PDF format without quite as much "Anything goes in this Turing-complete document presentation language," and even the latest version of macOS Preview.app can't read PostScript files. But if you set aside the fact that a majority of the language builtins are designed for using graphics, text, fonts, and printer hardware, it's a pretty slick language. You've basically got two things available: a stack of data and operands and a stack of dictionaries for dynamic name lookup. Both the programmer and the computer use basically the same model for evaluating code: read a token; if it's data then push it on the stack, if it's executable then run it, reading from the operator stack and writing to the same stack.

Programming language tutorials, particularly for functional languages, have a strong affinity for calculating the n'th Fibonacci number, but let's generate the whole sequence by just calling the same "function" over and over again (== is "print the source representation of the object on top of the stack and GS> is the Ghostscript prompt):

GS> /fib { 2 copy add } bind def
GS> [ 1 1 fib fib fib fib ] ==
[1 1 2 3 5 8]
GS> [ 1 1 15 { fib } repeat ] ==
[1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597]

Stack-based languages can have pretty simple syntax rules. That [ ] array syntax isn't "parse elements between the brackets as an array." Instead, the [ operator pushes a mark onto the stack and the ] operator builds an array with all the items on the stack until the first mark. Everything between the brackets is just normal PostScript code being executed on the stack. The following code builds an array of increasingly nested empty arrays by copying the whole array so far:

GS> [ 5 { counttomark [ exch 1 add copy pop ] } repeat ] ==
[[] [[]] [[] [[]]] [[] [[]] [[] [[]]]] [[] [[]] [[] [[]]] [[] [[]] [[] [[]]]]]]
% Or if you prefer some non-empty values to help read
GS> [ 42 5 { counttomark [ exch 1 add copy pop ] } repeat ] ==
[42 [42] [42 [42]] [42 [42] [42 [42]]] [42 [42] [42 [42]] [42 [42] [42 [42]]]] [42 [42] [42 [42]] [42 [42] [42 [42]]] [42 [42] [42 [42]] [42 [42] [42 [42]]]]]]

I've heard that some functional programming devotees might think of the non-negative numbers as a sequence of nested empty lists…

In PostScript, procedures are just arrays with the executable bit set, and you can construct and manipulate them as arrays. {} is syntax for an executable array, [] is syntax for a regular array, and cvx converts its operand to executable:

GS> { (hello world\n) print } exec
hello world
GS> % same thing:
[(hello world\n) (print) cvx] cvx exec
hello world

Since a procedure is just a mutable array of things to do, you can replace things in that array. Here's a self-modifying procedure that increments the first value inside itself, similar to a static int in a function in C:

GS> /selfmod { 1 (caller #) print == currentdict /selfmod get dup 0 get 1 add 0 exch put } bind def
GS> selfmod
caller #1
GS> selfmod
caller #2
GS> selfmod
caller #3

Page 115 of Thinking in PostScript defines a procedure by name including some initialization code; it then redefines itself without the initialization code the first time it's run. (The fact that the book is PDF file instead of a PostScript one says something indicative about the status of PostScript in the modern world.)

While PostScript has a couple hundred operators that are part of the language, a lot of those are for doing things like drawing on the page and selecting fonts. The parts of the "standard library" for working with strings and arrays is pretty spartan: even concatstrings is a Ghostscript addition, and I think people copy/pasted their own concatenation function all over the place for years. Since my Advent of Code interests don't include "Let's re-implement parsing a variable-width text file into fixed-size mutable strings each night," I've been getting some practice with the language by writing some core library functions that I'm certain will be used frequently.

I was about to work on the functional programming standbys like map and reduce, but I realized that with arrays constructed by "run all the code between brackets, then move everything from the stack between those brackets into an array" that having a separate function for map would just be extra noise and the basic iteration operator does the trick. Here's the PostScript equivalent of myarray.map { x -> x + 1 } and mydict.mapValues { i -> x * x }.

% Add 1 to each element of an array:
[ myarray { 1 add } forall ]
% Create a dictionary with the same keys as mydict, but square the values:
<< mydict { dup mul } forall >>

reduce (or fold depending on your dialect) is similarly straightforward if you supply with the accumulator rather than using the first array value. Here's myarray.reduce(0) { x, acc -> x + acc } (sum) and an implementation of myarray.all { x -> x % 2 == 0 } (are all items are even?).

0 myarray { add } forall
true myarray { 2 mod 0 eq and } forall

None of these need special handling for empty collections. They also work to iterate through bytes of a string (though there doesn't seem to be a short way to construct a string from an array of bytes). The all implementation can become an any by switching true to false and and to or. all becomes none by adding not before and. Short-circuiting can be added with dup { exit } if after the and/or.

I got involved in amateur radio in 2021 in part because it was a hobby I could do during pandemic stay-at-home periods that didn't involve staring at a computer screen. Getting a home station set up that's capable of transmitting on HF bands is kind of complicated, and involves making significant decisions like attaching masts to the roof and drilling holes through a wall. Fortunately, hams have come up with ways to encourage radio operation outdoors, with a temporary station setup. Parks on the Air awards fake Internet points to hams who set up in a state or national park and make contact with other amateur radio operators. I've found POTA to be a great motivation for getting out of the house and exploring some interesting places, while also improving radio skills and experimenting with emergency communication setup options.

After "activating" a park, the operator submits a log file of all their contacts to the Parks on the Air website so everyone can get credit. These log files use the ADIF format, commonly used for ham radio log interchange. ADIF uses a fairly simple format that predates general-purpose schemes like XML and JSON. Fields are encoded with a name, length, optional type, and value like <CALL:5:S>WT0RJ <NAME:6>Trevor <EOR>. These files are reasonably easy to read, but can be tricky to write by hand, since counting the number of characters in a string that's longer than about 7 is easy to get wrong. Hams typically use a logging program which can export an ADIF file for upload. But I don't really want to take a laptop on a camping trip, so I keep my Parks on the Air logs on paper in a notebook. Rather than transcribe that log directly into ADIF format I decided to enter them in Google Sheets, which makes it easy to fill in repeated fields like my park identifier, state, and the radio frequency where I called CQ. I then export the sheet to a CSV file.

There are a handful of CSV-to-ADIF converters that folks have published, but I wasn't particularly impressed by any of them. So of course I decided to make my own open source program. During the busy summer period that conversion was all it could do. Then after spending November organizing books and not spreading COVID and December staying up late writing Advent of Code, I was motivated to spend some time outside. Since Colorado got a lot of snow and cold air in January, "Go for a long hike" wasn't very attractive, but "brush the snow off the end of a picnic table and make ham radio contacts" was totally feasible. (Also "operate from the truck when the wind is too cold".) And since I wasn't camping, I had plenty of computer time to add more logging features in the evening, with park activations each weekend to provide insight on feature usefulness.

I decided to call the program ADIF Multitool, a "Swiss Army knife" that combines lots of single-use log processing tools into a convenient package. It's a command-line tool, written in the Go programming language, following the Unix pipeline philosophy. Several adifmt commands can be chained together; each prints a log file to standard output which is then consumed as standard input by the next command. My latest POTA CSV file had just the fields that varied for each contact; I then added all the repetitive details about my own station, fixed data formats, inferred some field values from others, ensured all fields matched the specification, and saved it as an ADI file with this pipeline:

adifmt edit --remove-blank --add qso_date=20230225 --add submode=USB
    --add my_pota_ref=K-1213 --add my_lat=39.644388 --add my_lon=-104.846254 \
    --add my_state=CO --add my_country="United States of America" \
    --add operator=WT0RJ mylog.csv \
  | adifmt fix \
  | adifmt infer --fields station_callsign,mode,band \
    --fields my_gridsquare,my_gridsquare_ext \
    --fields pota_ref,sota_ref,my_sig_info,dxcc,my_dxcc \
  | adifmt validate \
  | adifmt save --overwrite-existing ~/WT0RJ@K-1213-20230225.adi

Using Go for this tool has been a fairly positive experience. Go's I/O APIs provided useful levels of abstraction for handling the ADIF spec while also making it easy to provide my own fixed-string "filesystem" in test cases. Go strings are byte arrays, which is great for working with data interchange formats, while also providing robust Unicode support, which is great for working with user-provided text. The lightweight type system made it pretty easy to implement command line options like "a repeatable key=value flag that collects into a map." The field-tag approach to marshaling and serializing XML and JSON took some mental stretching to get used to (the simplistic examples in the package documentation contribute to this), but in practice they're quite nice and avoid the need to interact with a SAX or DOM parser. One of my main motivations for picking Go was the ability to generate code, which allowed me to convert the XML version of the ADIF specification into Go code for every data type, field, and enumeration value; when the next version of the spec is released I'll just need to run go generate again to add all of the additions and changes. Another expected benefit that I haven't tried yet: I can build releases for Windows and other operating systems I don't have access to, and distribute them without worrying that users might not have the latest version of Python or Java installed.

Advent of Code is an annual programming challenge. Every night at midnight EST from December 1st through 25th, a new problem is posted to the website, along with a participant-specific input file. Participants can use any programming language they want to solve the problem, using their input, and see if the output of their program matches the expected value. Once that's done, a second part of the problem becomes available. Part 2 uses the same input file and is generally a variation on the first part, such as changing the goal from "find the maximum" to "find the sum of all" or increasing the number of times an operation needs to be performed so that an inefficient algorithm will be far too slow. Problems are usually straightforward at the beginning of the month and get more challenging as the month progresses. There's a stats page measuring time-to-completion and a top-100 leaderboard, but no prizes; many folks pursue their own goals like learning a new language or minimizing program runtime which are somewhat at odds with quick finishes.

After having lots of fun and learning Kotlin with Advent of Code in December 2020, I decided to use Raku for this past year's edition (with code shared on GitHub). Raku is the new name of Perl 6, a "member of the Perl family of languages" which famously took a decade and a half of community experimentation before a finalized version was released. Perl, in turn, is a language originally focused on working with collections of text files which is famously easy to write or hard to read, depending on who you ask. Raku keeps many of Perl's basic syntactic elements—like scalar, array, and hash variables identified by $, @, and % sigils—but also brings to bear a lot of modern programming language developments like class-based object orientation, concurrency, type constraints, multi-dispatch, and just-in-time compilation. Raku is also what one might call Unicode-forward. Most languages these days allow Unicode literals in strings, and most languages made since the '90s allow Unicode letters in program identifiers. Raku takes this significantly further. First, Raku strings are sequences of graphemes rather than just bytes or Unicode code points, so both the single-code-point and the "combining diacritics" variants of "é" are identical in Raku. Second, Unicode characters aren't just limited to letters: the language and standard library provide $thing ∈ ($set1 ∪ $set2) for set operations, @words».uc to upper-case each element of an array, ⚛++ for atomic-increment, 25 ** ½ as another way to perform a square root, and quoting strings with arbitrary characters like say q༺hello world༻.uc. Additionally, Raku took one of Perl's big selling points in the '80s and '90s (terse and powerful regular expressions) and evolved them into grammars which are easier to read, modify, and compose, and likely also faster. This grammar support is what drew my interest to Raku, since I started a hobby project that involves parsing a small amount of information from source code written in a large number of languages, and the ability to quickly write but still maintain textual matchers would make that project more pleasant.

One of the driving principles in the design of Raku (and Perl before it) is There's more than one way to do it (TMTOWTDI). Another principle (repeated frequently by people who post in help forums, it seems) is that programming in Raku should be fun. Several times while working on an Advent of Code solution I tried to do something in a way that looked both elegant and reasonable, only to find out that There's More Than One Way To Do It, But Some Of Those Ways Are Wrong. (Furthermore, since TMTOWTDI, the documentation usually doesn't say "This isn't a good tool for X, use Y instead.") For example, I spent at least half an hour trying to understand why my memoization code didn't seem to be caching my Pair objects, despite all my experiments with the interactive interpreter looking like things should work just fine. It turns out that foo => 42 creates a Pair which uses value equality for both key and value, but my $key = 'foo'; my $val = 42; $key => $val creates a Pair that holds on to the $val scalar (but not the key scalar) and thus uses (half) reference equality. The documentation explains this behavior in an aside and explains that .freeze will result in an immutable Pair, but it's easy to encounter Pairs in documentation that doesn't mention that, and the half hour of WTF was not at all fun. (Another Way To Do It would be implementing a 2-value tuple class myself, which wouldn't have added fancypants scalar handling.) This discovery also reduced my confidence in the language a bit: when I look at a block of code, am I sure that my variables work as values, or might something else hold on to this funny scalar reference?

Another un-fun discovery was that for @first ∩ @second { … } doesn't iterate through the shared elements of two arrays, but instead iterates through Pairs, where the value is always True. I was aware that many set implementations are implemented as a hash table where the keys are set elements and the values are a placeholder value like a boolean. But most languages hide this implementation detail and present a set as akin to an unordered list which doesn't allow duplicate values. The workaround is easy (call .keys on the set when iterating over it), and it provides a nice symmetry with Bags (multisets) and Mixes (weighted sets), but it was still a big surprise. This was made worse by Raku's gradual typing discipline and implicit conversions; I think I was putting the set elements into a Hash, which converts keys to strings by default, so rather than a compile or runtime error complaining that I was using a Pair where a Str was expected I got a Hash with keys like foo<tab>True rather than just foo. Iteration and automatic conversion also combine in un-fun ways because the base class for most objects implements all the List methods by converting non-iterable objects into single-element lists. I would find it a lot more fun if the Raku compiler would tell me that sub answer(--> Int) { 42 } ; for answer() { … } was attempting to iterate over a non-iterable (maybe I changed answer from a List to an Int and forgot to update all the callers) rather than silently iterating over a single element. This annoyance is compounded by the fact that scalar references to iterable types (like a sequence, list, or array) are turned into single-element lists in this context, so changing my $x = nums => (1, 2, 3, 4); .say for $x.value (which prints four lines with one number each) to my $x = (1, 2, 3, 4); .say for $x changes the output to print a single line with four numbers and a pair of parentheses. This makes changing the shape of data structures while developing a program (like adding or removing a wrapper class) create surprising effects that aren't caught by the compiler. And maybe it's just me, but I think programming is more fun when the computer quickly tells you when you make a mistake, rather than losing an hour of sleep because you were debugging code that looked reasonable.

Working in Raku did have some fun elements. Contrary to my complaints about automatic conversions for container types, the ability to seamlessly work with numbers parsed from text was pretty nice for Advent of Code problems. Having a Complex number type that works as a hash key made several 2D grid traversal problems fairly convenient. And I even got to leverage Raku's nice Unicode property support on a problem about open/close punctuation balancing. I opted to use Raku this year as a way to try out grammars, and they were generally nice. They're way more readable than Perl regular expressions and the "Perl-compatible" regex implementations that have come along in the past three decades, and the ability to supply an Actions class to parse the relevant data from a match and bubble it up makes working with the result of a complex parse much nicer. Grammars are generally overkill for AoC inputs, but I found the structure pretty nice. The one downside to Raku grammars was the lack of helpful information when a parse failed. Unlike a typical programming language compiler that outputs the line and column where input didn't match expectations, a failed grammar parse just returns null, even though Raku has a Failure type that allows conveying additional information. So when my parsing rules were wrong I generally had to put output statements in the Action class and manually inspect what the next token should've been.

Contrary to last year, when I mostly focused on implementing the code and learning the language, I spent a lot of time on the social side of AoC this year. Last year I participated a bit in the Reddit community to provide hints to folks who were stuck. This year, after solving the problem and then participating in Google's group chat about the day's challenge, I frequently spent a couple hours on Reddit, reading through the "solutions megathread" and checking out people's visualizations. This meant a lot of 3am bedtimes this December, followed by another late night. Coupled with trying to actually get some work done, I spent far too much time staring at a screen this December. Also, unlike 2020, there were social reasons to leave the house this year—friends were amused that I was programming in Vim over SSH from a smartphone while semi-drunk at a holiday party while also chatting with folks. (There were just a couple small bugs by the time I got home, and Vim's terse modal editing proved to be a nicer phone-based development environment than I'd expected.)

Three weeks of late nights—including an all-nigher for day 19 because I'd incorrectly assumed that rotations in 3D were commutative—definitely caught up with me. I was pretty burned out by the time I got stuck and went to bed on day 23, which is kind of an interesting problems with a lot of little fussy ways to introduce bugs. I was extra toasty on day 24 (the night leading into Christmas Eve) when I discovered that what I thought would be a reasonable solution—a modified binary search—didn't work at all because in the possible solution space of about 20 trillion numbers, fewer than ten are even potentially the right answer. This fact about the input file wasn't at all clear from the problem statement, and the frustration was intensified by the fact that (contrary to every other AoC problem I've seen) there was no realistic example and expected output to experiment with. The fact that a seemingly reasonable solution can run for hours without providing any insight about the problem (other than "valid values are sparse") and that (as far as I can tell) an efficient solution to this otherwise NP-complete problem requires making assumptions based on a single input file, pretty much soured me on what had otherwise been an enjoyable month. That one day's problem (following a couple late nights) made me strongly question ever participating in "live" (i.e. during December) AoC ever again, which isn't a good feeling to have on Christmas Eve.

Raku's final un-fun factor played a role in this burnout too: slow execution speed. I'd seen folks who hang out on Raku help communities warn folks that Raku performance isn't great, but I figured it would be fine for Advent of Code, which has lots of folks working in languages like Python and more tortured environments like Bash or Google Sheets. But on days 19, 23, and 24 I discovered that my Raku code would spend tens of minutes running on the example input before producing a wrong answer, which is not a good situation in a "implement a program before bedtime" challenge. To more quickly test wrong hypotheses and spot bugs, I reimplemented those days in Go. The Go language is far more verbose and has many fewer features than Raku, but I could implement a Go solution and try it five times in the time it would take to run my Raku code twice. My day 19 solution in Go—using the same algorithm and only slightly optimized code paths—was about a hundred times faster than the Raku implementation. I recall noticing that one Go run took 45 seconds while Raku took 45 minutes. I spent more time optimizing the runtime of the day 23 solution (due to some discussion in the group chat at work) and ended up with a 2.5 second solution in Go and a 68 minute solution in Raku. I even spent some time with the Raku profiler (which amusingly produced about a gigabyte of output for 45 seconds of runtime and had to be analyzed with sqlite because the HTML profiler output crashes any browser tab) and was only able to get a maximum 10% speedup after playing with all of the hot code paths under my control. Two orders of magnitude in runtime is difficult to make up with even the most amazing language expressiveness.

Early in my experience with Unix-like systems I discovered fortune. This program would occasionally provide me with a clever passage attributed -- Stanislaw Lem, "Cyberiad" "Who is this Stanislaw Lem fellow and what is a Cyberiad," I wondered. And then, because it was the mid-90s and search engines didn't exist yet, I did nothing.

A few years later, I started collecting quotes to add to my random signature program. A great many of them came from fortune, since it gave me a quip every time I logged in or out. The first Cyberiad quote that made it on the list was [The brilliant Cerebron, attacking the problem analytically, discovered three distinct kinds of dragon: the mythical, the chimerical, and the purely hypothetical.] They were all, one might say, nonexistent, but each nonexisted in an entirely different way. Different modes of nonexistence, a fantastic puzzle for a philosophy minor like me. I wanted to find and read this book.

There are a few books and authors I keep in the back of my mind for eventual purchase. It gives me direction when I find myself in a bookstore: check the D section of Classics for The Vicomte de Bragelonne, check the A section of Sci-Fi for the HHGTTG radio series scripts, check the L section of Sci-Fi for Stanisław Lem… You would think it wouldn't be too hard to find a book by "the most widely read science fiction writer in the world," yet ten years went by without finding one of his books between Le Guin and Lewis. I was even a beta tester for Google Books on Android tablets, but couldn't buy an electronic Cyberiad. (It's available now, though.) Tantalizingly, Google ran a fantastic narrative doodle based on The Cyberiad. I finally found a copy when I chanced to stop in to Red Letter Books in Boulder, enticed by a book about mangoes on the shelf out front. "Before I buy this, I need to see if they happen to have any Lem." Sure enough, my Quixotic quest found its goal, wedged in a dense shelf of mass market paperbacks.

The Cyberiad is a book of short stories about machines who build machines. The central character is Trurl, a constructor. He and his good friend Klapaucius the constructor build all manner of robots and devices, often on commission from rulers of distant worlds. Unlike the science fiction school led by Asimov, the engineering details of the machines and their scientific mechanism of action are of little importance. The stories are not about the machines but about the philosophical considerations and allegorical implications of such a device in a world not entirely dissimilar from ours. The first story, How The World Was Saved concerns a machine that can create anything starting with N. After creating concrete and abstract nouns, they ask the machine to do Nothing, whereby it starts to eliminate the universe.

Originally written in Polish, the book has a lot of rhymes and wordplay with sciency terms which works surprisingly well in translation (to English, at least.) The sidebar to the right has a poem produced by Trurl's Electronic Bard. Lem has a great facility for technical naming in a way that's fun rather than dry: The second, newer trail was opened up by the Imperium Myrapoclean, whose turboservoslaves carved a tunnel six billion miles in length through the heart of the Great Glossaurontus itself.

What I like best about The Cyberiad is how it resonates with my experience as a constructor of sorts. The book was written in 1967, when hardware was still the king of technology, before we realized that software eats the world. Yet the story Trurl's Machine and other passages describe the foibles of building, debugging, and otherwise producing a computer program better than any software-focused essay I've read. Throughout the book, Trurl displays the three cardinal virtues of the programmer: laziness, impatience, and hubris. If more tales were added to the Cyberiad today, perhaps the constructors would be programs which write other programs.

All makers and builders and coders and creators would do well to read The Cyberiad: Fables for the Cybernetic Age. This hypermedia book report claims the book inspired Will Wright to create SimCity; what might it do for you? Acquire it in cybernetic digital form or via a musty-bookstore-quest for a well-loved copy not so overpriced as these.

Musing about Apple's mistake of pissing off developers with the App Store, Paul Graham wonders what a smart phone would have to offer to make developers want it instead of an iPhone. He wants to see someone make a software development environment worth using on a handheld device. It would have to be good enough that you'd want to program on your phone, with its small screen and limited keyboard,[1] rather than on a laptop or desktop with huge monitors and ergonomic keyboards.[2]

After using Eclipse for five years, I can't imagine doing significant Java development (particularly debugging) on a handheld device. Mobile device user interfaces are all about presenting only the immediately relevant information while an IDE[3] is really good at providing a bunch of information at once.

I still use a 24x80 text editor when writing in scripting languages, partly because the problems are usually small enough to fit in just a few files and the languages are high-level enough that a significant amount of code fits in a terminal window. I can imagine writing Python or Ruby on an iPhone or even Lisp if the editor had good parenthesis-matching. Perl and Haskell might be frustratingly symbol-heavy. But just because someone could write Python in a text editor on a handheld device, I don't think they would. It's just not as enjoyable as using a full keyboard on your desk.

A successful development environment on a mobile device should make use of the unique features a handheld offers. Typing on a phone may be less fun than using a laptop, but what if you could program with gestures? Tilt your phone to the left to generate an assignment. Move it in a circle to create a loop. Touch a variable to reference it again. Use multi-touch zooming and scrolling to select a function from an API.

Historically, attempts at visual programming languages haven't yielded many success at lower abstractions than GUI layout and UML, but I think a graphical language designed from the ground up to fit a handheld environment could be quite elegant. Text is very good at representing symbolic computation, but it's not the only way. Constraints often lead to beautiful art; if the crutch of an easy keyboard wasn't available, I'll bet someone would come up with something really clever. A lot of programmers are good at spatial reasoning, so let's try breaking nonlinear programs out of the linear medium of text.

Developing on a handheld would obviously be handy when you're working on an application for that device. Make a change to the tilt response code, then tilt your device to test it. Take a picture[4] and feed it straight to a test case. With lots of sensor input, mobile devices seem like an ideal platform for neural nets and other fuzzy techniques. On the development side, you could present an example to the device and immediately classify it, quickly building a model.

These are all hand-wavy suggestions of possible directions. I've hardly ever used a cell phone, let alone developed a mobile app, so my conceptions may be off base. Yet I think my key message is valid: to make handheld development attractive, it needs to be approached from the ground up. The metadeveloper needs to focus on solving a class of problems[5] and find ways to do so using things small computing devices are really good at. I've focused on sensor input here, but mobile devices have other unique features. Would dictating pseudocode to your phone be useful? Maybe there are ways to take advantage of location information and remote networking in programming. In the end, I think successful handheld development will be as different from desktop IDE development as that is from simple interactive text editors as that is from programming with punchcards.


[1] Not owning a smart phone, I'm assuming that typing on a handheld device is more of a chore than using a full keyboard. I know Apple and others have done some clever things with predictive text, automatic spelling correction, and other clever techniques to make typing easier on a phone. Unmodified, I suspect those would not work well when programming where function names deliberately deviate from proper spelling and punctuation has very special meanings that differ between languages. You could build language models for programming languages, of course, but you could also implant such models in IDEs (most already do) and use a full keyboard. I think dropping the keyboard metaphor would be preferable for handheld input. Why not leverage the motion and orientation sensors and use arm and wrist motions to "paint" your words in thin air? This seems like it would work particularly well for Chinese. Nonetheless, I don't think it would be faster than using a desktop keyboard.

[2] I actually hate ergonomic keyboards; I'm most comfortable on a laptop or Apple keyboard. The most RSI-inducing computer input I've done is use the scroll wheel on a cheap Microsoft mouse. But the key (hah!) feature of an extended keyboard for programming in rich environments is hot keys, which are hard to accomplish with a keyboard interface like the iPhone's.

[3] For the non-programmers in the crowd, IDE stands for Interactive Development Environment. Here's a screenshot of the information overload I'm talking about.

[4] Why do phones come standard with (crappy) cameras these days? My camera can't make low-quality phone calls, I don't need my phone to take low-quality pictures. The benefit I see to cell phone cameras is (a) you've always got it on you and (b) it's immediately connected to software and the network. This makes it ideal for things like taking a picture of a barcode and comparison shopping instantly. The picture quality only has to be good enough to make out black and white lines.

[5] The best programming languages are the result of somebody thinking "There's got to be a better way" to solve a set of problems he was working on. Perl is really good at working with text because that's was the itch bugging Larry Wall. Dennis Ritchie created C to work on Unix and it's still the most popular language for writing operating systems. Guido adds new features to Python by trying out the syntax on a sample of existing code and deciding which produces the most readable result.

If you're wondering why you have no data, it's entirely possible you haven't written that part of the code yet.

I created a fairly simple programming exercise for job candidates. It's not trivial, but it's not super hard. Someone who's written programs before and can figure out the solution should be able to write the program in two hours or less. The problem description says "Your program should read from standard input (stdin) and write to standard output (stdout). Sample input and output are available."

I'm rather dismayed by the number of submissions which don't read from standard input or output. The most common violation is using a hard-coded path like C:\input.txt (tip: I'm not running Windows, I don't have a C: drive; even if I did, I wouldn't have the sample input there). Other violations include requiring filenames on the command line (not terrible), prompting for all values interactively in such a way that I can't just run cat input.txt | program, and one submission in PL/SQL that hard-coded the sample input as a bunch of INSERT statements. Tip: I put "use stdin and stdout" in the instructions so that you didn't have to bother with all the file opening and closing details. Also, do they not teach students to run their programs before submitting them? Running a submission on input bundled with the problem shouldn't throw an error before producing any output. Maybe students don't know how to use a command line environment any more and I/O redirection is a foreign concept.

Do today's computer science students really not know what standard input and output are? Do they really have assignments that say "Read this file from C:\Homework\Problem1?" My hope was to create an evaluation script that ran several files through submitted programs and report a correct answer rate. But when correct programs are little more likely to read from stdin, I can't even write a script capable of getting an answer.

Punks.