Sixteen Languages

2009-03-19T12:00:00.001-04:00

Paul has gone off to grad school to study programming languages up close. As time goes on, the things he said in the past seem ever more misleading and uninformed; that is how he knows he is learning.

Variations on the curly bracket

2008-02-24T17:44:00.010-05:00

I've been experimenting with exorcising the curly bracket, which, uh, bothers me somewhat. I've been coding in Envy Code R and Inconsolata, whose curly brackets I've been tweaking in FontForge.

Here are some renderings of the variations I've tried out:

Inconsolata, unmodified:

Envy Code R, with my first variation:

Inconsolata, with my second variation:

Inconsolata, with my current variation:

None of these completely satisfies me, but I feel like I'm making some progress. (Anyone with actual experience with type will probably tear me to pieces for these.) It's amazing how much room there is for variation with that one stupid character.

Programming by not programming

2008-01-27T22:24:00.000-05:00

My other project, the one that has put this one on hold (or perhaps just intense slow motion), is going along fine. Or so I think. My collaborator and I seem to have a rather nice collection of bits and pieces that we're slowly integrating in the direction of a useful application. The thing is, I don't seem to remember working on it. I've touched a little bit of Python that uses web.py, but mostly I've just been fiddling with CSS (which I don't really know), and looking at graphs in R (which I also really don't know).

For example, I'm not even really sure why the first little bit of AJAX stuff that I did started working because I didn't know why it wasn't working in the first place. But there are so few moving parts that I'm not too worried about it being fragile. If necessary, we could rewrite it, and it wouldn't take too long. In fact, there just isn't that much code. We've been spending most of our time discussing minutiae. That's a good thing, though, because it kept us from coding, and code is a liability. Not only did it not take us too long to get here, but we also aren't carrying the weight of a huge and complicated codebase, just a scattering of parts and some baling wire that we're slowly working with.

Getting further distracted: R

2008-01-13T20:34:00.000-05:00

Well, I'm going further off track, but it's an interesting track. I'm now (again for outside reasons) learning R. It's a language made for mathematics and statistics, and, having seen someone who knows what he's doing operate it, I'm very impressed with its tools for succinctly exploring data. It's an interactive language, so the focus is a bit different, but it's apparently got most of the nice functional features that I'm learning to know and love. Also: it's very vector-oriented, with lots of tools to create and manipulate vectors. In fact, I'm pretty sure there's just no distinction between a number and a one-element numerical vector:


> 4 == 4
[1] TRUE
> 4 == c(4)
[1] TRUE
> 4 == c(4, 5)
[1]  TRUE FALSE

It'll be an interesting world to live in.

Frameworks

2008-01-04T18:57:00.000-05:00

I'm working on two things in Python right now, a simple physics-based game, and a frontend for a web application (the later is part of an unrelated project that just seemed best to do in Python). I'm using pygame and web.py respectively. From my limited experience, I'm very impressed by both. The main way that I measure my impressedness is that I keep on getting stuck on problems that are actually hard problems in the things I'm trying to write. In fact, it's kind of frustrating, because I'm just jumping from problem to problem as I start to lay out my programs, with only occasional breaks for figuring out how the framework works.

Moving off the schedule

2007-12-22T23:08:00.000-05:00

Well, I've really been neglecting Python. This season turns out to be kinda hectic, which I incorrectly figured that I could absorb with my slack more easily. So I'm dropping the 16 days on/7 days off schedule so I can give these languages the attention they deserve. My XO is coming with me on vacation, and I'll see if I can work on Python some over the next week.

It's a shame because I'm usually rather deadline-motivated, so this will make everything take longer. Oh well.

Cities and roads in python

2007-12-17T00:57:00.001-05:00

Here's what I've been working on (on and off — I have to admit I haven't devoted too much time to it) in Python.

The blue squares are cities, which emit workers. The workers build roads, and a complicated decision procedure determines whether the workers actually follow the roads or not. (Approximately, they'll do it if they're going in the same direction, and haven't hit a road in a while.) The original plan was to do some more city-building and resource-gathering simulation, but I wound up focusing of making the lines look nice, which was probably more on-task anyways. A neat hack: the workers could only move in 8 directions, which gave chunky lines. But the directions themselves were stored as floating-point numbers, so I nudged rounding back and forth every other timestep, which gave pretty nice and smooth lines.

It's funny how the things we will or won't do in the name of performance are so influenced by syntax. It's a lot easier to bring myself to write something O(n) in the middle of a tight loop if it's a list comprehension than if it's a for loop.

Settling in with Python

2007-12-12T19:41:00.000-05:00

Dude, Python needs forward declares? That's a shame.

It's vaguely disconcerting that it seems like nothing is checked until runtime, and that all kinds of errors don't get caught unless the code actually gets executed. It totally confuses my traditionaly ways of reasoning about what is wrong. I bet it's more intuitive for beginners, though, to think of parsing/typechecking/execution as happening all at the same time.

Ada is really subversive. In Ada, you can call a zero-argument function by stating its name. In Python, with first-class functions, that is a legal syntax for the wrong thing, but it doesn't stop me from using it. (The solution, of course, is that functions must not have zero arguments. If you have referential transparency, there's no point in zero-arg functions.)

Doing object-oriented design in Python is a lot like doing it in Smalltalk, except that I can work in just one text file easily. It's quite pleasant.

Clerical error

2007-12-11T00:38:00.000-05:00

Forgot to actually put up the post about starting Python. Oops. Abandoning the file metaphor (as Blogger does) for autosaved, no-management-needed drafts is a big improvement in usability, but it causes me to lose important bits of things whose brain cells atrophied a while back.

Quick TPK update

2007-12-11T00:22:00.001-05:00

With help from a friend of mine who knows Python, here's an edit to make TPK a bit more Pythonic:


from math import sqrt

def f(x):
    return sqrt(abs(x)) + 5.0*(x**3)

a = [input() for i in xrange(11)]
a.reverse()
for e, res in [(e, f(e)) for e in a]:
    if res > 400:
        print e, "TOO LARGE"
    else:
        print e, res

xrange is a nifty tool, returning an object that is somewhere between a lazy array and a function. Well, I guess it is one or the other, but it's a nice conceptual place. Also, is it just me, or is it the case that the name doesn't make any sense, and it's better than any name that does?

Also, creating tuples for my loop state is bringing back memories of FP... I think I may prefer the more imperative style for that part of the task. Either that, or I just don't like the look of list comprehension. Introducing a variable name in the middle? What's wrong with just making a function for that does both filter and map?

You know, doing without curlies is perhaps less strange than doing without semicolons. Maybe it's just habit, but it's real strange to leave statements unpunctuated, ready to float off to the right.

Python begins

2007-12-08T21:24:00.000-05:00

Python: 9:13 PM December 8th, 2007 through 9:13 PM December 8th, 2007

print "hello, world"

As XKCD points out, it really is pretty simple.

TPK is not hard, either.


from math import sqrt

def f(x):
   return sqrt(abs(x)) + 5.0*(x**3)

a = [input() for i in range(0, 10)]
a.reverse()
for e in a:
   res = f(e)
   if res > 400:
       print e, "TOO LARGE"
   else:
       print e, res

I made a couple mistakes in writing it. First, I a.append without defining a. Not sure how variable declarations work in Python (isn't it not supposed to have any?), so I just used a list comprehension. (Because of my predispositions, it feels vaguely sinful to put side-effects in what is effectively a map, but maybe this is my Rumspringa.)

The second is more interesting. I attempted to do for e in a.reverse(), which gave me a slightly cryptic error. (Having worked with an FP implementation with exactly two error messages, I am not complaining. For that matter, having used the STL in C++, I am not complaining.) When I was retyping it to put a.reverse on its own, a note popped up (I'm using Editra, which, it turns out, provides as-you-type Python documentation. I'm going to be spoiled!), documenting reverse as "L.reverse -- reverse *IN PLACE*". I think this is significant.

This is my fastest zero-to-TPK time so far. (I should point out that I already knew a bit of Python beforehand. Not nearly enough to implement TPK, though.) It'll probably be all downhill from here. Heck, I don't know if 16 days is enough to implement TPK in some of the languages I have coming up.

Looking at it over again, I wonder if I have introduced a subtle bug. Is the order of evaluation of list comprehensions defined?

Defensely Engineered: Ada Retrospective

2007-12-04T20:56:00.000-05:00

Ada doesn't really deserve the reputation that it's gotten. I was expecting a language that was clunky, verbose, and unmanageable, but it really wasn't bad. I did wind up writing a lot of ugly clumps of code, but I'm fair sure that, with a little more time it would have been a lot better. I certainly wouldn't be writing code this nice this far into, say, C++. If D is the language that C++ should have been (so I have heard, anyhow), Ada is the language that Java should have been. Ada has the same flaws and features that Java (at least the later versions) has: it's safe, generic, and consistent, but pedantic, verbose, and unfocused. But the flaws are less deep, and the features are closer to working (because what language actually is "safe, generic, and consistent"?)

Types

Ada is strongly-typed. I think that Java has given static explicit type systems a bad name. Ada's type system is kind of bewildering, but it's much more flexible, and the verbosity is more manageable. Also, generic packages (though I haven't really used them) seem like a great way to have type-independent functionality without tying it to one class, or requiring the full parameterized type name to be scattered all over code.

Lightweight numeric types of a limited range are also really cool. Sadly, I don't think that they are necessarily lightweight enough. Also, I understand that there isn't any significant compile-time typechecking for them.

Syntax

I don't like curly braces. This may be a minor thing, but, since it lacks them, Ada code just looks better to me. Python (my next language on the list) removes block delimiters entirely in favor of indentation, which I like, and I figured would be more important, but perhaps it not the presence of block delimiters but their prominence that bothers me.

You see, in C-syntaxed languages, when I'm off-balance and dumbly staring at some code trying to collect my wits, the only thing I'm ever aware of is "This code has some blocks in it." It's the utter obviousness of it that bothers me: with those ugly markings around each visual group of lines, the code is saying "Okay now, these lines, and only these lines will be grouped for the purpose of a control structure! Got it?", and I'm just sitting there, repeating the words back without any understanding, because I don't care since what I'm really worried about is how I can't concentrate on figuring out the significance of the funny squiggles that I think spell out "w h i l e", which, if I recall correctly, is a preposition that has some significance in whatever language it is that I was programming in before my mind ran out of memory and crashed trying to store all those little punctuation delimiters that have all of these weird points and curves, and they don't look right together, and it's like it's not really sure whether it wanted to be a nice curvy parenthesis or a solid, well-build square bracket, and it wound up with like a billion control points just to define its shape, which was all to no avail, because I'm programming in a font that's too small to make the points stand out from the body and they come out looking like some kind of badly-drawn vertical pipes, I mean, look at this:

{
What is it even supposed to look like? Sheesh. No wonder we have a software crisis.

Uh, so, Ada is very much a verbose language, but the lack of extraneous punctuation makes up for a great deal.

Data structures

There's no way this could actually be true, but to all appearances, the following is the case: Ada did not have, in its default library, any data structures that could be resized after creation, until 2005. In Ada '05, they added nice generic containers to the standard library, which, for technical reasons, cannot be used unless you create an additional source file for each declaration of a container.

I'm sure there is a better way. I'm sure there was a better way in the eighties. I couldn't figure it out, so I rolled my own linked-lists, one for each type I wanted.

Syntax again

Oh, I forgot that I had more to say about Ada syntax. For a lot of the errors I made in Ada, the compiler would helpfully tell me something along the lines of "You meant to use a ; instead of a , here.", or "You need to have a with declaration in order to use this package.", etc. Error messages like this are very helpful, but if you deal with them long enough, you start to want to say to the compiler, "Look, who's the programmer here, me or you? If you know so much, why don't you just write the stupid program yourself, huh?". Basically, there's a lot of Ada syntax which exists mainly as error-correcting codes. These things force you to convey your intent in multiple ways, so the compiler knows what you really meant.

Theoretically, this sort of thing could prevent certain errors from escaping human review. However, I seriously doubt that it saves the programmer from much more than the occasional typo.

Conclusion

I better wrap this up before it gets even later, and I fall further off my rocker. I suspect that, if Ada had been more popular, more languages that came after it would have tried to build effective and/or shiny static type systems. And that would have been pretty nice.

Ada done (kind of)

2007-12-01T21:08:00.000-05:00

Well, I have something that resembles a static type checker right now. I'll take a break now, and revisit my work at some point later to flesh it out. In my defense, I ran into a couple compiler bugs in GNAT that slowed me down as I rooted out the code that triggered them (one time it was a repeated declaration, another was something that I was about to replace anyways). I don't even have enough capabilities to test it properly right now -- I need to allow declarations of functions in order to do interesting things, and I should also read some predefined functions from a file, since there will be magic functions that create the POV-Ray scene elements in the first place.

But I think it works mostly. The code came out pretty smoothly, despite a few restructurings of certain parts of the code.

Why doesn't Ada 95 have some kind of runtime-variable-sized container as part of its default library? Even FP has that! I had to roll my own linked lists, because specifying a generic list from the Ada 2005 just wouldn't work.

Oops.

2007-12-01T10:04:00.000-05:00

So, I wasn't paying attention, and didn't realize that my 16 days for Ada were almost up. Today will be a mad dash to complete Ada's part of the POV-Ray frontend project. I decided that it would be most appropriate to build the static type checker in Ada, so that's what I'll be doing today.

This project has been a really interesting exploration of my tendency to procrastinate. Dang it, I have to stop using phrases like that. What I mean is, it's a good thing that I set strict deadlines for myself, or I wouldn't get anything done.

Making Bars

2007-11-28T20:58:00.000-05:00

This little graphics generator is based on a pretty simple concept. It takes a swath of vertical space and randomly assigns it one of four types:

Color is a random shade of grey.
Pair is two equal-sized swaths.
Dupe is a pair of equal-sized swaths with the same content.
Swirl is two equal-sized swaths, twisted together.

It's partially inspired by Boodler, a "soundscape" tool that can, among other things, generate random mutating drum rhythms with (what I think is) a similar technique. It's also kind of inspired by the moodbar in Amarok; I started out imagining the images as being much narrower, and completely 1-dimensional.

Object-orientation in Ada is, as I may have hinted earlier, powerful but has confusing syntax. And this is from someone who writes in C++ for a living. I guess that it's not fair to do this to Ada: it only has a few days, and I've been learning C++, on and off, for the last six years or so. (It feels like longer.) I wonder how much it matters how learnable a language is? Consider that languages with enthusiastic user communities are often said (albeit by those same communities) to be good first languages for new programmers (I'm thinking of Smalltalk, Python, and Scheme, here).

Whew!

2007-11-28T09:03:00.001-05:00

I think I may have finally figured out how to make packages work in Ada. Explanation for the images will come later.

Okay, I lied.

2007-11-27T20:58:00.000-05:00

It turns out that I hardly got any work done on vacation. Go figure!

'Class is strange to get used to, but it's a neat feature, because it distinguishes between things that are exactly typed and things that can hold anything of a subtype.
Okay, I think I've found something about Ada to complain about. In fact, it's a big part of why I don't have anything more to show right now. Making the code work right now is kind of a guessing game. I guess it's a lot like C++ like this, having lots of complicated rules that ultimately have a reason behind them, but C++ can get away with a lot more because it's more popular. Also, Ada really oughtn't be like C++ in this way. A C++ program is like a huge contraption made of wires and gears and relays, ranging in size from the enormous to the minuscule. There are no panels or gates or guards, so that the maintainers can access any part as quickly as possible. An Ada program is, well, more like a military submarine, with everything carefully screwed into place, labels on every part, all in a consistent industrial style. But once you pull off the panels, you discover that what a part looks like and what a part is used for are not always related.
In other words, Ada's syntax lulls you into a false sense of security with all of its alphabetic friendliness, and then strangles you with details.

On break

2007-11-20T00:56:00.000-05:00

Learning per se never sleeps, but Internet access is irregular, so updates will be suspended for a week. Here's a preview of what the Ada graphics project is looking like so far:
It needs some work compositionally, but the complexity is nice to see from a rather small source file and simple idea. The image is divided up vertically by a binary tree. Nodes in the tree can be all black, all while, two nodes next to each other, or two nodes overlayed and mixed diagonally.

2007-11-20T00:55:00.000-05:00

I'm getting close to finished with the graphics hack, but there's a typing syntax issue that's driving me crazy.

I totally don't understand why .all dereferences a pointer. It's just really strange.
.all seems to be opposed to .constant access, which makes some sense, I guess.
I'm using examples from http://sandbox.mc.edu/~bennet/ada/examples/index.html as guides. They're pretty good.
bars2.adb:30:26: R "enames" expected is the strangest error message in the world. Is it trying to tell me to use the keyword "renames"?
Using aggregates instead of writing a full constructor makes banging out a lightweight class hierarchy much simpler.

2007-11-17T23:26:00.000-05:00

For some reason, Ada's error messages always seem to be really informative. I suppose that some of this is by comparison with FP's error messages (the complete set of which are as follows: syntax error, ?), but it also seems to quite often actually point me to the right place.
It's surprisingly useful to have an exponentiation operator.
I like not having to parenthesize the conditions in an if. For some reason, typing then feels a lot cheaper than adding the extra parens. I guess perhaps they mush up with the parentheses that inevitably are a part of the condition?
Also, the named-argument style for constructors Font := (Face => Helvetica, Weight => Bold, Size => 12) is pretty neat. Constructors never have any sensible ordering for their arguments, anyways.
I really feel kinda guilty for liking Ada like this, like there's something that I'm ignoring. I hope I figure out what it is soon, so I don't spend the next two weeks trying to figure out if I have Stockholm Syndrome or something.

TPK Ada

2007-11-15T22:52:00.000-05:00


with Ada.Text_IO;
with Ada.Numerics.Generic_Elementary_Functions;

procedure tpk is

  package FMath is new Ada.Numerics.Generic_Elementary_Functions(Float);
  package F_IO is new Ada.Text_IO.Float_IO(Float);

  function F(X : Float) return Float is
  begin
     return FMath.Sqrt(abs(X)) + 5.0 * X ** 3;
  end F;

  A : array (Integer range 0 .. 10) of Float;
  Res : Float;
begin

  for I in A'Range loop
     F_IO.Get(A(I));
  end loop;
  for I in reverse 0 .. 10 loop
     Res := F(A(I));
     Ada.Text_IO.Put(Integer'Image(I));
     if Res > 400.0 then
        Ada.Text_IO.Put_Line(" TOO LARGE");
     else
        Ada.Text_IO.Put_Line(Float'Image(Res));
     end if;
  end loop;
end;

I'm working from Wikibooks, which has a pretty good-looking tutorial. It does, however, contain the sentence "Because the use of a goto needs the declaration of a label, the goto is in fact twice as readable than the use of return.", which is rather unsettling.
Ada is kinda verbose, especially with regards to those with and using lines. I'm not sure that that's worse than Java though. On the other hand, I'm not sure that less verbose than Java means anything. Somehow, Ada's verbosity seems friendlier, if that's even possible. I guess Ada.Text_IO.Get is better than BufferedInputReader in = new BufferedInputReader(InputReader(System.in));, or whatever you have to do in Java. Maybe it's because the definitions that take up half the file feel like they're more reusable, and would wind up being a smallish part of a real program.
C++ had me convinced that generics were inherently ugly. Ada has the slight problem that I had to think about generics in order to write TPK, but the solution for delivering them seems elegant in some way. I'm not sure how, though. Maybe I just don't like angle brackets, either?
- It seems like one way to make a complicated abstract feature tolerable is to require it for the most basic of operations. That way, people will find a way to make it less obtrusive.
There's a distinction between functions and procedures, which is cool. I tend to feel that the mushing of the two together is rather random. Sadly, however, functions are not referentially transparent.
Now that I'm back to static typing, it feels really unusual to have to declare all my variables at the top of the local procedure/function.

Final evaluation: Judging by a pre-existing implementation, I didn't do too badly. I didn't need generics after all, and I could have taken the reverse of the range of the array, rather than dealing with the indices directly. Thinking of which: array index types are cool.

Now I better go to bed...

Ada begins

2007-11-15T21:46:00.000-05:00

Ada 9:13 PM November 15th, 2007 through 9:13 PM December 1st, 2007


with Ada.Text_IO;

procedure Main is
begin
  Ada.Text_IO.Put_Line("hello, world");
end;

Ada ... Ada is kind of a normal language. Actually, it was my first language. I remember making some really simple Scorched Earth-like computer game... but back then, I was still kind of unclear on the distinction between the underscore and the period, so I'm mostly starting from a blank slate here.

What I currently know about Ada:

It's strongly, statically typed.
It tends to forgo symbols for English reserved words. (As someone who doesn't really like the way {} look, I cannot object.)
It's associated with the Department of Defense, and was commissioned for building reliable systems.
Lots of people really don't like it. This is possibly correlated with the above.

I also found out recently that one of the more famous software-related space accidents, the Ariane 5 test flight, was destroyed because of a numerical conversion problem in Ada code, which was guarded by a run-time check that had been removed for performance reasons. I'm not sure whether that's a point for or against Ada.

Anyways, I'm about to go write TPK in Ada. I'm excited, since I know that TPK already exists in Ada, so it couldn't be that insane.

Life without names: FP retrospective

2007-11-14T21:29:00.000-05:00

Some of the languages I'm working in for this project are esoteric languages, that have no direct practical use, like FP. This isn't really FP's fault, since it's only a proof-of-concept language. FP has some descendants that are (I assume) much more useful. But working in a simple language is possibly more instructive. Specifically:

It is possible to live without names. I'll admit that I often felt like I was translating imperative programming to sequences of lists, changing over iterations of while, but I think that, for some problems that is a bit inevitable. Not having names did help me break my programs down into smaller bits, but I'm not sure how I feel about such a draconian restriction.
One of the questions that bugged me about FP is "What makes FP so much different than other functional programming languages?". Reading Backus's paper doesn't make it terribly clear, but this sentence is telling: "For example, pure Lisp is often buried in large extensions with many von Neumann features." The context is about machine efficiency, but I get the sense that Backus feels that Lisp is conceptually muddled by the (potential) presence of side-effects.
Ah-ha! Haskell, the only major side-effect-free programming language I can think of, appeared in 1990, which is 13 years after Backus's Turing Award. I guess that FP introduced the concept of pure functional programming. This could very well explain Backus's emphasis on provability, because pure functional languages are much easier to prove things about.
In fact, I think this property turned out to be useful while I was working in FP. I didn't have access to a debugger, or even error messages other than "?", so I wound up cutting up pieces of the program and trying them out alone. I could do this with confidence, because the flow of information in and out of an FP function is always explicit.
Working on esoteric languages in esoteric environments is ... different. I'm reminded of this statement from the author of Unlambda: "Writing Unlambda programs isn't really as hard as it might seem; however, reading Unlambda programs is practically impossible." As I was working with simple problems, FP's low readability wasn't a problem. In fact, it kinda felt more easy than Smalltalk because the scale of the problems. This reminds me of what Garrison Keillor said: "Intelligence is like four-wheel drive: it only lets you get stuck in more remote places."

FP: finished

2007-11-08T23:30:00.000-05:00

So, here's topological sort in FP. It went pretty smoothly, and didn't take too long (which is fortunate, because I dallied, and wound up sort of rushing on the final debugging). The good news is that, when finished with one part, the others could be built on it with confidence. (Not shown are the test cases built into the source code, interspersed between functions).

Topological sort, incidentally, is an important small piece of my project to write a compiler for the POV-Ray SDL: it's needed to sort out the order that declarations should appear in the file, based on their interdependencies.


{
  inDegreeZero # -> bool
  (null@2 -> =@[%1 %1] ;
   (=@[1 2@1@2] -> =@[%0 %1] ;
     inDegreeZero@[1 tl@2] ) )
}

{  #Oh, for a _filter_ functional form!
  eligibles
  3@(while not@null@1
    [tl@1 2 (inDegreeZero@[1@1 2] -> apndl@[1@1 3] ; 3)]
  )@[1 2 iota@%0]
}  #oops... really should've done that recursively

{
  in
  (null@2 -> =@[%1 %0] ;
    (=@[1 1@2] -> =@[%1 %1] ;
      in@[1 tl@2] ))
}

{
  dropEdgesFrom
  (null@2 -> 2 ;
    (in@[1@1@2 1] -> dropEdgesFrom@[1 tl@2] ;
          apndl@[1@2 dropEdgesFrom@[1 tl@2]] ))
}

{
  drop
  (null@2 -> 2 ;
    (in@[1@2 1] -> drop@[1 tl@2] ;
        apndl@[1@2 drop@[1 tl@2]] ))
}

{
  toposort
  (null@2 -> 1 ;
    concat@[3 toposort@[drop@[3 1] dropEdgesFrom@[3 2] ]]@[1 2 eligibles]
  )
}

Thursday, 9:13 PM, next week, I start in on Ada. Before then: thoughts on FP.

Simple regex engine

2007-11-07T18:58:00.000-05:00

It's pretty simple: the only special things that it handles are "dot", representing any character, and alternation, which without some form of grouping, is basically just character classes. It wouldn't be that hard to add on some other features, except that I realized that I didn't have a good way to represent grouping, seeing as I had already given a meaning to array-within-an-array. I recall certain problems in Lisp being a pain as the lists-within-lists structures became more complicated. I suppose that the solution, in both cases, is to have many definitions of the form (defun timeout caadar) or whatever (I don't remember much syntax: that's supposed to be setting the function (timeout x), an accessor for a data member, to (car (car (cdr (car x)))), the place it's located in some data structure). I stumble over my procedural background again!


{dot %-1}

{
  match #
  (
    null@2 -> null@1 ;
    or@[startmatch match@[1 tl@2]])
}

{
  startmatch #
  (
    or@[null@1 null@2] ->
      null@1   #if the pattern's empty, it's a match
               #otherwise, it's not.
    ;
    #does this character match?
    (atom@1@1 ->
      (or@[
            =@[1@1 dot]
            =@[1@1 1@2]
          ] -> startmatch@[tl@1 tl@2]
          ; =@[%0 %1] #no match, return a fake False
      )
      ; # it's an alternation
      |or@&(startmatch)@distr@[&concat@&([[1] 2])@distr@[1@1 tl@1]  2]
    )
  )
}

Doing this with first-class functions would have been more cool, I think. It should be possible to represent the various syntactic elements of the regex as functions on partial strings that return the set of possible remaining strings. Hm. Lazy evaluation would be essential for reasonable performance. I may have to reconsider my feelings about lazy/eager if I keep on thinking lazily like this.

It was interesting to see that idea evolve while I was considering it, by the way. First, I thought of the functions as functions that returned a boolean (for match or not) and a number, for the number of characters consumed. But multiple return values are a pain, so I figured on some hack like returning null to represent "no match". I also realized that it'd be more elegant to return a string of characters remaining, as that follows the problem more tightly. Then I realized that the problem naturally requires not just one continuation but a set of possible continuations, and the empty set is the natural way to represent "no match".

Anyways, I have to say that the purity of FP expressions makes debugging them easier, which partially compensates for the often infuriating simplicity and lack of features. It's surprisingly easy to use for being essentially an esoteric language, which I think may partially be Backus's point.

2007-11-05T22:29:00.000-05:00

You know, lazy evaluation would be kind of nice to have. It means being able to write ors instead of ifs without having infinite loops and horrible performance characteristics. Those issues are funny things. Running time is definitely a side-effect, right? A truly functional language shouldn't have any, then...

2007-11-04T23:16:00.000-05:00

FP still drives me a bit batty. I want my first class functions back! Okay, I've never extensively used first-class functions before, but FP feels an awful lot like it had them, and then they were removed. I was about to blame it on syntax, but I realized that there is no natural way to apply an object as a function. However, I would claim that the syntax of functionals is ad-hoc and kinda awkward as a result.

Nice long chains of function application @ are pretty neat, but there's always a limit to how useful they wind up being, because programs are never linear in any way for long. Does that make any sense?

Anyways, I'm currently stumped on a puzzle: how do I take < <a1 a2 a3 ...> b to < <a1 b> <a2 b> <a3 b> ...>? Oh, got it, it's distr, a function that does exactly that. I feel that distr is a sign of trouble though: it's used to mush information around that would be better off with a name.

Shiny gradient!

2007-11-03T12:44:00.000-04:00

So, I thought it would be a neat idea to make a cover for In Rainbows, the new Radiohead album that doesn't have an official cover yet. I figured I could make something neat and rainbow-oriented in FP. Turns out this was a dumb idea, since I'd mock something up in the Gimp, and then continue mocking at it until it was two hours later and I had a completed image that had nothing to do with FP. But I finally got my goal, which was a neat rainbow-oriented image to serve as the basis of something. I had to write a converter from RGB to HSV, which was sort of lame, but I got to use functional programming techniques for pixel-level operations. I made a grid of number pairs, where the numbers were coordinates, and then mapped gradients over it to create the image, and then mapped the converter across it to get RGB. I used a Perl script to turn the triplets into a PPM image, which looked like this:

After some fiddling in the Gimp, I got this:

The source code, which is pretty short, if dense. It'd be shorter still if my implementation had abs or a properly-working mod:


{      
  grid
  &(distl@[1 iota@2])@distr@[iota id]
}

{
  abs
  (>@[1 2] -> - ; -@[2 1])
}

{
  ipqtv  #intermediate numbers for hsv-to-rgb conversion
  [
    +@[mod@[1 %6] %1]
    *@[4 -@[%1 3]]
    *@[4 -@[%1 *@[3 2]]]
    *@[4 -@[%1 *@[3 -@[%1 2]]]]
    4
  ] @ [2 -@[/@[1 %60] 2] 3 4] @ [1 div@[1 %60] 2 3]
}
 
{
  rgb
  (=@[2 %0] -> [%0 %0 %0] ;
    pick@[ 1 [
      [5 4 2]
      [3 5 2]
      [2 5 4]
      [2 3 5]
      [4 2 5]
      [5 2 3]
    ]]@ipqtv
  )
}

{
  gradient
  +@[ +@[*@[1@1 2] *@[2@1 3]] 4]
  #+@[1@1 2@1]
}

{
  genmod  #mod that works on non-integers.  Slow.
  1@(while <@[1 %0] [+@[1 2] 2])@(while >@[1 2] [-@[1 2] 2])
}

{
  bump
  -@[%1 *@[id id]@-@[%1 id]]
}

&(&(rgb@[
  #hue:
  gradient@[[1 2] %3 %4 %180]
  #saturation:
  bump@genmod@[gradient@[[1 2] /@[%3.3 %360] /@[%4.4 %360] %0] %1.0]
  #value:
  %1.0
  ] ))@grid:800

Square root in FP

2007-10-29T19:41:00.000-04:00

My implementation of FP doesn't have a square root function (and I need one for TPK), so I cribbed an algorithm from somewhere and got the following:


{
  abs
  (>@[id %0] -> id ; -@[%0 id])
}

{
  sqrt  #by Newton's Method
  2@(while >@[abs@-@[2 3] %0.01]
    [1 *@[%0.5 +@[2 /@[1 2]]] 2]
  )@[id id %0]
}

It's short, but obtuse. It turns that the funky functional while isn't bad, once you start thinking about lists as the wads of state that you carry around. I wonder if there's another way to look at it, a way that isn't so ... imperative.

Distinguishing between 2, the second parameter, and %2, the number is a pain. As is the special case of 1-parameter functions. But at least the resulting code is nice and short. And the functional style of testing a program, breaking it in to bits and testing each bit, is pretty neat.

TPK complete in FP

2007-10-28T21:56:00.000-04:00


{
  abs
  (>@[id %0] -> id ; -@[%0 id])
}


{
  sqrt  #by Newton's Method
  2@(while >@[abs@-@[2 3] %0.0001]
    [1 *@[%0.5 +@[2 /@[1 2]]] 2]
  )@[id id %0]
}

{
  f
  +@[sqrt@abs |*@[%5 id id id]]
}

&([1 (>@[2 %400] -> %0 ; 2)])@
&([1 f@2])@reverse@&([id *@[id %0.45]])@iota:11

It's sort of TPK, anyhow. I don't have a properly working input, so I just take the index multiplied by 0.45. And, instead of printing "TOO LARGE", it just emits 0, since it doesn't have strings. But it's surprisingly easy to write, once you get the hang of it, and the motivation. I sure wouldn't want to come back and debug these programs after a week, though.

2007-10-27T20:05:00.000-04:00

Here are a few little tidbits of FP:

Construct a list of the results of the four basic operations, applied to two numbers. [- + * /] : <6> →

<-1 13 42 0.857142857>

iota constructs lists from 1 to the parameter: iota:5 →

<1>

I suspect that map (spelt &) will be very useful with it: &(%1)@iota:9 → <1>

I want a function that creates a 2D array of coordinate pairs. It looks like dist[lr] is pretty useful: distl@[%42 iota]:5 → <<42> <42> <42> <42> <42>>

Okay, I've got it: &(distl@[1 iota@2]@[id %5])@iota:5 gives me a 5 by 5 array of coordinates. The interpreter I'm using is a little buggy -- that was giving me incorrect results.

But that needs to be generalized: &(distl@[1 iota@2])@distr@[iota id]:5
It turns out that generalizing got rid of that ugly double@[], but required an extra distl, which is an unnecessary performance cost. Programming without using names feels awkward, like I need to manage the shape of all the information I need at any given point.

And now comes the cool part. If I want to make the pairs into triplets where the third element is the distance between them, I just tack on &(&([1 2 -]))@ to the front.

(Oh, I get what [...] means now; FP applies each function in the brackets to the given arguments, creating a list of the results. It's like the opposite of a map.)

Reading "Can Programming be Liberated?"

2007-10-25T18:34:00.001-04:00

Instead of writing code just yet, I've decided to read Backus's paper that introduced FP, Can Programming be Liberated from the von Neumann Style?. He delivers a well-argued (though I would argue, incorrect) deconstruction of von Neumann languages (imperative languages, approximately), claiming that they are entirely accidents of the physical structure of computers, and that functional languages are inherently better suited to representing formal human thought. What I haven't seen yet is why he favors a compositional approach. I've seen hints of that: I think that he thinks that parameter names are mental baggage that should be avoided if possible, but I suspect that I'm missing something about the big picture.

FP begins

2007-10-23T23:14:00.000-04:00

FP: 9:13 PM October 23rd, 2007 through 9:13 PM November 8th, 2007

id:<104 101 108 108 111 44 32 119 111 114 108 100>

And now my madness begins in earnest. FP is a language that, to the best of my knowledge, has no modern implementation. In fact, the implementation that I'm using does not seem to have actual string literals at all, so I'm using a vector of ASCII. Why would I choose this language?

Well, my brother likes it. Also, I kinda like the drawing I did of a mysterious, brooding John Backus, just daring the foolish coder to program in the von Neumann style. And FP is really unusual. As far as I can visualize it, it's like a cross between Forth and Haskell. Well, maybe Forth and Lazy K. So it's really hard to imagine what it's like. Which will make it a learning experience. But not right now. I didn't have much time tonight, so TPK is for tomorrow.

Smalltalk retrospective

2007-10-21T18:10:00.000-04:00

The following are my inexperienced and judgmental feelings about Smalltalk. Undoubtedly, they would be different if I knew more of the language. If only I knew how!

Syntax

It's amazing how much matters of syntax are matters of taste.

I really like programming language syntax. One of the coolest things about Smalltalk, to me, is the function call syntax. The idea that a method name can be interspersed with its arguments has far-reaching effects: it means that it's easier to have many similar methods that differ in the interpretation of arguments (which, in turn, means that Smalltalkers don't miss having argument overloading), and it also means that method names are sometimes more natural, and 10-argument methods are less confusing.
Also regarding function calls, the message-passing syntax object method: arg is rather strange in the way it places the colon. I'm not sure how I feel about it. Its lightweightness is nice (especially if you're using a 10-argument method), but it feels unbalanced in that it doesn't point out the object of invocation, which I think makes it a bit harder to read and write. For example, I just looked at the following code and noticed it was incorrect:
```
target location connectedTo: destination ifTrue: [
```
However, inserting parentheses is a one-time cost, and a nice clean look is worth a lot.
The character syntax ($a represents the letter 'a') is something I never got used to. I guess I see character literals as being like string literals, and don't want them escaping out the right side. I'm not sure that's a real reason to dislike something, though.
;, the syntax for sending multiple methods to the same object, is an unsung hero. It's hard to notice using it because it leaves code nice and clean, which is just the way syntactic sugar should be.
I really miss having operator precedence. But perhaps not as much as I could have. There's even a sense in which lack of precedence is a good thing — it encourages the programmer to write expressions that can be read from left to right. Huh. I never realized that before. That's kind of cool. Nonetheless, I will be happy to have my a + b*c back.

Idioms

I found myself scattering methods whose name began with "init" all over the place. I realize that I could have rolled the same functionality into a class method starting with "new", but the init methods would still have to exist, which bothered me.
In Smalltalk, local variables are frequently-used:

The good news: Lack of explicit variable types means that changing your mind about how you're going to use a variable is easy.
The bad news: there's no way to declare and initialize a variable in one statement.

Blocks

Having real blocks is really nice. On the other hand, I'm really missing break and continue. Perhaps the solution is to write utility iterators like findFirst:? As an aside, why is it that I never actually wind up writing things like that that would make my life easier?
At first I was confused about the meaning of ^ — did it return from the current block or the current method? It turns out that returning from the current method is almost always what you want. But at some level, it feels inelegant.

Expressions versus statements

The dicotomy between side-effects and return values has been on my mind lately. Return values are less important in Smalltalk than side-effects, and it shows in the syntax. I'm afraid that my prexisting radical views, that side-effecting procedures and value-returning functions should be totally separated and have different syntaxes, are unchanged. This is no less a problem in ... well, any other language that has both statements and expressions, so I should probably stop worrying about it so much.

Dynamic types

I surprised myself with how often I wound up changing the type of a variable I had already named. With a good debugger, the lack of compile-time typechecking is usually not much of a problem. Also, Squeaks compile-time pop-up indicating that a method name does not exist globally is surprisingly useful: no matter how bad namespace pollution gets, there will probably never be a method named asStirng.
Still, I have a soft spot for static types. (hm, that seems like the wrong turn of phrase; it's dynamic types that feel soft) Most of the time, anyhow, the compiler can tell you what type something is, so I'd appreciate it trying.
I ran into a number of OO dilemmas, where I found myself trying to decide whether a particular kind of state was best represented with a symbolically-valued variable or a new class. Those problems are just difficult! It'd be nice if there were more of a continuum between the two options.

Overall thoughts

Smalltalk did feel a little old to my fingers: the overall lack of syntax bothered me some. I guess that's something of a matter of taste. The tools available were very impressive, even if I wound up denying myself access to them because I couldn't stand using my mouse to navigate between methods. (It occurs to me that part of the reason was perhaps that I often use a graphics tablet for mousing, which has a very high time cost associated with switching between mouse and keyboard. (You know what would be neat? A tablet which had little robotic arms that pick up the stylus when you drop it on the tablet, and hold it upright until you grab it again.))

I can see why a thriving Smalltalk community exists. For certain tasks (say graphically-oriented simulations), Smalltalk really welcomes designing and fiddling and tinkering. And the way the design of the language cooperates with reflective tools is amazing to behold. I suspect I'll be wanting to have that debugger back for some time to come.

One language down: postmortem

2007-10-18T23:06:00.000-04:00

"A language that doesn't affect the way you think about programming, is not worth knowing" —Adam Perlis

So, now I know Smalltalk! Or, in a sense, I can use Smalltalk. I haven't yet touched exceptions, or continuations, or designed any particularly large systems. However, I would dare to say that I've allowed it to change the way I think about programming, at least a little (a post discussing exactly in what way this happened will follow later).

Thanks to online resources, and some helpful comments, I was usually able to grasp the concepts I needed reasonably quickly. What I really missed from having personal instruction was the ability to have someone criticize my style, point out idioms that I miss, or tell me to throw out my Java-addled design and build something that fits my medium better. Sometimes I was able to do that to myself, though: it's often possible to guess that that I'm not doing something right, and sometimes a moment's reflection will suggest a better way to do things. Other times, I'm not so sure.

People who stopped by and left notes, especially Paolo Bonzini, the maintainer of GNU Smalltalk, were a big help. As is my brother who's currently working on a Haskell implementation of FP, since the language simply does not have a modern implementation.

Sixteen days sounds like a longer time than it turns out to be. Between getting stuck on little things (like how to take a substring!), having other things to do, going back and rewriting things that were really lousy the first time, I didn't get too much implementation done. However, I think it may be just the right amount of time for a self-driven project like this. If I were to continue much further, I might risk ingraining my own misunderstandings of the language. Nonetheless, I've started to notice the absence of Smalltalk in my day job. Some of it is just wanting to use a period instead of using a semicolon at the end of statements, but some of it is the different attitude towards variable typing, and how much cooler debugging in Smalltalk is, as opposed to using gdb. Typing has already given (and I suspect it will continue to give) me much to mull over. I had to reread this essay about type systems, which is definitely worth rereading.

Done with Smalltalk.

2007-10-16T21:17:00.000-04:00

As of 9:13 PM, my proscribed period for learning Smalltalk is over. After a one-week break, I'll be attacking FP.

I was intending to complete some other part-of-a-project before finishing, but I kept on flipping back and forth between things I figured I didn't have enough time left to complete (stupid! stupid!), so I wound up converting the code generator for POV-Ray to use strings rather than write to the Transcript, for modularity reasons. So I didn't complete any part of the grand cross-language game that I had been thinking about. (Partially, this reflects the fact that I'd realized that I don't have much of an overall plan for it. I had some neat components, though, that I'd still like to try to fit into something.) The conversion isn't complete -- I'll have to debug it later.

Coming up later: final thoughts on Smalltalk, and thoughts on the learning process itself.

The clock is ticking down...

2007-10-15T22:47:00.000-04:00

Well, I still remember how to work the cycle of procrastination from college. I won't have too much time tomorrow night, so I need to get everything substantive done tonight. The good news is that the code generator for POV-Ray seems to be mostly working. I'll try gradually expanding its scope (it doesn't generate everything: mainly, it's applied around the areas that are kind of weird corner cases in POV-Ray).
The name for your variables changes depending on how much type information you give. If something's used as a stack for parsing, but stored as an OrderedCollection, it makes sense to call it stack, sometimes. Other times, programming in an explicitly-typed language, I've felt like it's stupid to give something a name other than it's type: "I want to reheapify the heap. The only thing in scope that can be reheapified!" Maybe I should just break down and use the name the in cases like that. It seems classier than theHeap.
I'm now learning XQuery at work. I wonder how much interference there will be between XQuery and Smalltalk, given that they are basically each other's opposites.
I still haven't gotten used to duck typing, and not having to make type relationships explicit. It's certainly nice to not have to share implementation to share interface — this seems to need to happen more than one would expect.
I have to admit that 1-based arrays aren't as strange as I had feared.
This ad-hoc approach to writing a compiler seems to be working suprisingly well, 1/16th the way in. It's suprisingly easy to say "Oh, I can push that functionality up/down a level." It remains to be seen how I feel when I write the other sides of these kind of jagged interfaces.

2007-10-14T13:34:00.000-04:00

The parser, slightly cleaned-up and bug-fixed, is at http://16languages.googlecode.com/svn/smalltalk/PParser.st

I'm working on a backend code generator for the POV-Ray Scene Description Language. It's kinda a quirky language, with a lot of constructs representing graphical primitives, and the syntax is kinda complicated in weird ways. It's actually Turing-complete, by virtue of some preprocessing commands, but it's a little bit bulky to use. That's the reason for this project in the first place.

I've never really seen this, writing in accessor-full languages like Java and C++, but I guess it really is true that sometimes you want a method that, for most classes, simply returns a class variable, but for some has a "real" implementation. Dealing with the POV-Ray SDL, there are gray areas between things that should be expressed as subclasses, and things that should be expressed with instance variables.

I randomly ran into allOwners, and thought "What a ridiculous method!" And then I figured out a use for it: a hackish way to decide whether an item of syntax (in the POV-Ray SDL) was frequently-used, and therefore should be given a name and predefined to save space.

Parser: finally properly working

2007-10-10T00:02:00.000-04:00

This entry was accumulated over a long time, so it's a mite disjoint. Also, I'm playing with the syntax, so I've kinda overused italics.

The "deeper" method names in Smalltalk make it easier to make more methods that do similar things differently: i.e. substring:len: vs. substring:until:.
Except that there isn't any substring in GNU Smalltalk! The choice of methods is a little maddening, especially since I decided not to use regular expressions for the parsing. (In fact, this is based on a grammar that I had previously which was parsed entirely by Perl regular expression replacements.
I'm utterly flummoxed by the lack of substring:. I wound up using indexOfRegex:from:to: to do matching, and changing the syntax to not use any regex metacharacters. I think I'm missing something big here.
copyFrom:to: on SequenceableCollection is the substring I was looking for. Arggggh! It took me sooooo long to figure that out. Argggh!
I realized that it was easier to use copyFrom: instead, which has even worse performance implications than what I originally tried. When I saw that even my little test program incurred a garbage collection, I decided to implement a method that only matches against a substring. (turns out that such a thing exists: matchSubCollection:startingAt: on SequenceableCollection)
Final score: I was frustrated for a long time by the nonexistence of something that existed and I turned out not to want to use! If one flaw in my abilities as a programmer stands out above all the others, its my myopic obsession with attacking a problem in only one way.
I have one excuse: I was reluctant to tack on a new message to SequenceableCollection or String, out of resistance to namespace pollution. It's not a good excuse, I know.
Anyways, I'm finally pretty happy with the parser. In fact, this entry was written in its syntax and converted with it. ~~Except for one strange bug: For the items of syntax that consist of three characters in a row.~~ Turns out that matchSubCollection:startingAt: wasn't doing quite what I wanted it to, so I had to rewrite it. Still kinda myterious.
~~Oh, I guess I could have used indexOf:startingAt: also.~~ Oops, no. That's the index of an element, not a substring. I hadn't noticed that such dual meanings could occur (indexOf:matchCase:startingAt: does operate on substrings, though, demonstrating that, sometimes, coming up with a good name for a method is just hard.
The syntax is as follows (I'm using preformatted text to suppress parsing, 'cause I haven't made any syntax for suppressing it yet.):

* bulleted
* list
** nested
*** deeper
*# mixed
*# with
*# numbers
///Italic///, ***Bold***, [=teletype=], -s-strikethrough-s-
///Nesting ***is [=allowed=]***///
Link to Wikipedia article: [[Pet eye remover]]
 Start lines with a space 
 to make them preformatted,
^or a '^' to make a blockquote.
mdash:---  arrows:<-- --> <->

Becomes:

bulleted
list
- nested
  - deeper
1. mixed
2. with
3. numbers

Italic, Bold, teletype, ~~strikethrough~~
Nesting is allowed
Link to Wikipedia article: Pet eye remover

Start lines with a space 
to make them preformatted,

or a '^' to make a blockquote.

mdash:— arrows:← → ↔

I'm pretty happy with the code I've written for this. It's a little long, but it's pretty nicely-structured; I should easily be able to add more elements, elements that nest with themselves, sanity checks, different kinds of syntax. I intend to post the code later. Turns out there are a couple minor flaws in the HTML it emits, still...

Parser partially completed.

2007-10-08T19:32:00.001-04:00

I've found myself creating kind of unreadable logical predicates by the process of accretion. I guess I should get more comfortable with temporaries.
Having your own testing code accumulate at the end of your source file is kind of like having unit tests! Often the hardest thing about deploying something useful is tricking people into using it...

Working on the command line has definitely improved my productivity. I'm writing better code, and faster. Maybe I'm allergic to the mouse? Actually, it could be because I use a graphics tablet, so it takes extra time to start and stop mousing.

Here's the parser so far: it does pre, blockquote, and arbitrarily nests uls and ols. Syntax is like this:


Normal text
 two lines of
 preformatted text
* bullet
** nested further
**# nested deeper 
**# with numbered
**# list
# starting a new ordered list
^quoted text

The code for the method that does most of the work:

parseLine: line


| first inLists charPosition envTag |
first := line at: 1.

envTag := self environFromMarker: first.

envTag = nil ifTrue: [
    curEnv = nil ifFalse: [
        Transcript show:'</pre>'. curEnv := nil.
    ].
] ifFalse: [
    curEnv = nil ifTrue: [
        Transcript show:'<', envTag ,'>'.
    ] ifFalse: [
        curEnv = envTag ifFalse: [
            Transcript show: '</', 
              curEnv, '<>', envTag, '>'.
        ]].
    curEnv := envTag.

    curEnv = 'pre' ifTrue: [ 
        "preformatted text is taken literally"
        Transcript showCr: (line allButFirst).
        ^nil
    ].
].

inLists := true.
charPosition := 1.
line do: [:char |
    inLists ifTrue: [
        | listType |
        listType := self listFromMarker: char.
        inLists := (listType = nil) not.

        lists size < charPosition
           or: 
        [((lists at: charPosition) = listType) not ]
             ifTrue: [
               "The rest of the symbols (if any) 
                are no longer relevant"
               self unwindUntil: charPosition.
        ] .

        (listType = nil) not & 
          (lists size < charPosition) ifTrue: [
            lists add: listType.
            Transcript show: '<', 
              (self tagFromList: listType), '>'.
        ].

        "ending the stack of list symbols?"
        inLists not & (lists size > 0) ifTrue: [
            Transcript show: '<li>'.
        ].
    ].

    charPosition := charPosition + 1.
    Transcript show: char asString.
].
Transcript cr.

Back to the command line

2007-10-07T23:00:00.000-04:00

Gone are the pretty colors. I'm back to fixed-width white text on two black windows.

I don't have syntax-highlighting, a debugger, or access to any of the fancy runtime-modification features I've admitted are pretty nice, but I can finally think this way. It seems like my whole weekend-long mental block was not caused by my relationship with Smalltalk, but my relationship with the Browser. I think it might be an attitude problem, but since my goal is to learn the language, rather than learn the environment, I'll keep my bad attitude for now, since my ability to concentrate has gone way up.

I'm writing code in Emacs and running it in GNU Smalltalk. Later, I'll see if I can get "file in" to work in one of the environments and start doing proper debugging, and maybe get syntax highlighting to work. Ooh, they explain exactly how to do that. Nice.

2007-10-06T10:53:00.000-04:00

Currently working on a simple parser to take a barebones ASCII markup and emit HTML.

I've found that it takes surprisingly little rewriting to change a design decision, because of the lack of static type declaration. This is kind of unintuitive, but I've seen it doing C++ at work. Why does it so often happen that the type of variable changes, but not its use? I suppose that in statically-typed OO languages, the excuse is that you're supposed to abstract all the way up to type out only what you care about.
Still, I feel like I'm moving slowly. "Think twice, code once" is a good rule, but I often feel a little disoriented by Smalltalk's organizational scheme. On the other hand, I think that this feeling is called "learning" in some circles.
Hm. I feel like I want to have multiple return values. Or pass-by-reference for the purpose of modification. I suspect that I need to rethink my strategy slightly to use more encapsulated state, and less of parameters/return values.
There's something just wrong about public/private/protected. Although I've sometimes wished that I could access instance variables from methods on other objects, I feel that the problem is with me, not with Smalltalk. In Java and C++, those limitations are tacked on to the language, and so there is no way that they can avoid causing trouble sometimes.
I keep on changing the format of this page. Sheesh. I think it's a good thing I got rid of that rectangle on the right side, though.
I need to remember to save before testing something that could loop infinitely. Good news: Cmd-period interrupts it in Squeak. Bad news: lagginess in Squeak, or some UI weirdness makes it really hard to regain control afterwards. Killing an infinite loop in writing to the Transcript seems to have broken it -- now any attempt to write to it hangs on a semaphore.
I don't like switching between source files. I think I may just "File out" everything and start working in Emacs. Possibly related to that: I don't like writing large quantities of code in Smalltalk. I think that my avoidance of that is counterproductive -- eventually I give up refactoring because I'm not making progress simplifying things, and look at other stuff for a while.
Delaying typechecking until runtime seems to have the effect of making the type system feel more "real", more connected to the Platonic data structures, in a sense. It also has the effect of causing you to try an awful lot of arithmetic on booleans. A weakly-typed, dynamically-typed language would be impossible to debug! I think.
Hm. It'd be kind of neat to have a symbol-forming operator called "the": you'd say elementType = the sodium. Maybe you could use it to force interning of strings and such, too?

2007-10-06T01:19:00.000-04:00

I went to a Jonathan Coulton concert tonight [Those of you who know me: yes, I really went to a concert. See, I'm getting cultured!], which is why I don't really have anything to show tonight. But I have been doing a little.

GNU Smalltalk takes some getting used to, as it's missing some features that Squeak has. In particular, I miss keyboard shortcuts for "do it" and "save". I think that there may be such things; I just may not have figured them out yet. And error messages aren't very clear. I'll try again with version 2.95d, which I'm compiling right now, after running into a known issue.
Nice things: windows that mingle with my "real" environment. A language shell on the command line. A basic library that's small enough to navigate and find stuff in. (The hierarchical organization helps too, though it's not as important.) Syntax highlighting. "File out", which emits a plaintext source file. The absence of a bajillion menu items. (Though, to be fair, Squeak would occasionally have just the thing that I wanted in them.)

Okay, time for bed!

Stupid simulation!

2007-10-04T22:34:00.000-04:00

I mean that in a good way. I've been fiddling around with it even more. The mechanic of balancing water-to-food-to-cities-to-workers in the geometry of a pixel-based simulation has been neat. It was also made much easier by the format — since red, green, and blue can overlap each other, there are no obstacles in the simulation.

(blue = water, green = farm, red = city. Workers (not visible) carry water from rivers to establish and irrigate farms, and carry food from farms to establish and feed cities. Cities can produce more workers. The simulation runs away into increasing population, since nothing dies.)

However, the mechanics have been distracting me from learning the language itself. In fact, I've been neglecting to properly abstract out common elements between, e.g. Water, Farm, and City classes. I'll need to go back and do that, before I take a look at performance, which is kinda terrible. I suspect that that's because I'm consuming random numbers all over the place.

I've found myself strangely reluctant to use the reflection features I have available to me. I'm not sure why I keep restarting the simulation, when I just need to continue it to see if what I've implemented is working.

However, they're helping me in subtle ways anyways. In fact, running the simulation from the Workspace means that I can shuffle harness code around without thinking about it. And when (as just happened now) I accidentally get the syntax for a Transcript command wrong, I don't have to redo all the simulation that's passed already. Speaking of that, here's a longer run with a larger field:

(somehow the last image got blurred.)

Anyways, instead of fiddling with this any more, I'll go off and play with a new toy: GNU Smalltalk, now working on my computer thanks to one helpful maintainer who happened to stop by.

Fiddling with my simulation.

2007-10-03T22:51:00.001-04:00

All this time, I had been reading "Is it okay to cancel these changes?" as "Is it okay to save these changes?", and wondering why I kept losing work. Is there a version of Squeak for people who can't read?

Well, it's getting late, so here's a screenshot of my current work. It's an abstract simulation: blue is water, green is farm, and red are workers. The workers carry water to irrigate farms, and then carry food to (not yet implemented) cities. (The cities will be red, and the workers invisible, as the point is to make a pretty picture.)

I've been gleefully fiddling around with simulation parameters and algorithms. I feel that I haven't been using inheritance as much as I should have — I'll have to go back and refactor soon.


step: world
  water := water + (world blueAt: pos).
  world blueAt: pos put: (world blueAt: pos * 0.8).

  food := food + (world greenAt: pos).
  world greenAt: pos put: (world greenAt: pos * 0.8).

  world redAt: pos put: 0.0.
  pos := (pos x + dirx)@(pos y + diry).
  world redAt: pos put: 1.0.
  
  world rnd next < 0.3 
    ifTrue: [dirx := 2-(world rnd nextInt:3). diry := 2-(world rnd nextInt:3).].

  ((world greenAt: pos) > patience) 
    ifTrue: [world irrigate: pos by: water.  water := 0.  patience := 0.5.].
  
  "((world redAt: pos) > patience) 
    ifTrue: [world feed: pos by: food.  food := 0. patience := 0.5.]."
 
  patience := patience * 0.9.
 
  (patience < 0.01) ifTrue: [world plantFarm: pos].

Hm... I oughta make planting a farm contingent on having some food...

Smalltalk: getting comfortable with Squeak

2007-10-03T20:33:00.000-04:00

I think that it'll take too much trouble to make the Worm program that I was working on viable. There's no good way to keep it from getting stuck in dead ends. I toyed with making it cross its path only when it had to, and thought I had a good plan, but didn't like how much effort it'd take to implement.
I've been working from Squeak by Example, thanks to a suggestion from the comments. I may have to take back the bad things that I said about tutorials, because it's really good so far.
The "Method Finder" is an amazing tool, sort of. I typed in 'pop'. 'POP', and sure enough, it found asUppercase for me. Then I tried 1. 2. 3, which was a mistake because, I suppose, there are a lot of methods that could be applicable. And some of them might run arbitrarily long. I'm still really impressed, though, because it's a really good idea.
Actually, I tried some other arithmetical expressions in Method Finder, and they returned instantly. Am even more impressed. There's an argument for extensive static analysis here, though -- it'd be neat to restrict your search to things that were known to terminate in O(n^2) or less, for example. Of course, that would require reflection, which would totally mess up static analysis. You could always, after all, just kill the methods after a certain period of time. Maybe that's what Squeak does, and there's a bug.
Creating methods named redAt:, blueAt:, and greenAt: made me realize that copy-and-paste programming is harder with a more mouse-oriented interface. I have no idea whether that's a good thing or not.
I am very much a static-types programmer. I'm used to having my compiler enforce method names and types (Squeak does enforce names at compile-time, but against a global list of method names), which helps prevent a large proportion of errors. I guess that's why I'm internally resistant to test-driven development: I instinctively think it's not worth it for small tasks.
I can't be sure of this, but I think that the fact that binary operators (well, methods with operator-like syntax, since "operator" means something special in Smalltalk) have precedence between unary named methods and named methods with arguments is tripping me up. I have one mental category each for "named" and "symbolized" operations, I guess.
I used to think otherwise, but I think that having to make choices about how to lay out code is possibly a good thing. In C++, e.g., indenting and spacing is more or less mechanizable. But getting to reshape code allows one to change what aspects are emphasized.
Repairing code while it runs = sweet.

2007-10-03T09:36:00.000-04:00

I didn't have much time for Smalltalk last night, but I spent more than I really should have before work this morning.

I guess that's a good sign. Code to follow.

2007-10-01T23:33:00.000-04:00

I searched the Web for an implementation of TPK in Smalltalk. Results: everybody else has more sense than me, and hasn't done it. I feel a little bit better about my version now, even though I haven't found a way to substantively improve it.

Working from A Development Example for Squeak 3.9, I've started in on little graphics project, this time, properly creating methods in the Browser. Outline of the project: a worm moves forward, turning more and more tightly, until it it's about to collide with itself, when it starts to follow itself for a while more before turning. Continue until stuck in a dead end.

There are still a few things I have no idea about, like how to create a constructor (it's a class method, I think, but the browser warns me against overwriting the existing new).

I'm also learning about the benefits of face-to-face teaching here. In a classroom, the students can deliver subtle cues about how fast the material is going, and ask questions to fill in the gaps. Without any kind of feedback, the author of a tutorial has to decide whether to cover everything, and move really slowly, or to move at a normal pace, and leave people confused.

Smalltalk: TPK, round 2

2007-10-01T18:50:00.000-04:00

Reading deeper into "Smalltalk: Getting the Message", which gets more exciting later on, I discovered that, without side-effects, you usually use map to edit collections, or, as Smalltalk calls it, collect.
The same source has a very important point that explains why I was having such trouble defining f:
Each method declaration is an independent compilation unit; there is no standard syntax for declaring a sequence of methods, so that the text of one method may be syntactically distinguished from that of one that precedes or follows it. Above the level of individual methods, Smalltalk programs are defined by dynamic, living objects—and not by static statements residing in flat text files.

Now, graphical languages are just bad. But Smalltalk isn't bad. Therefore, it's not the ability to use grep to search source files, or the filesystem to organize them that's important. Maybe it's got something to do with the power of text to represent (in an easily editable form) hierarchical structures. Possibly it has something to do with the brain's amazing ability to deal with that kind of structure in a linear form.
Smalltalk shows some of the TPK algorithm's bias: since f is really just arbitrary, it's not meaningful to attach it to Number. Smalltalk encourages you to carefully contemplate the context in which a method is meaningful. On the other hand, there are some times when the system seems to break down — timesRepeat seems to be attached to Integer rather than BlockContext because it's more natural to write it that way.
The Blogger editor is a pain to use if you want a lot of fixed-width or preformatted text, or em dashes, a favorite punctuation of mine. Project for the future: write a wiki-like-markup-to-HTML converter. Yeah, such things exist already.
The inline error-as-selected-text thing that Squeak does is neat and easy-to-use. Also, it works inside the string passed to compile:!. Disconcerting, though, and it might become problematic when one needs to keep the error around while editing.

Alright, here's another TPK:


TPK compile:
'f: x  "answer an arbitrary demo function"
  ^ x abs sqrt + (5 * (x raisedToInteger: 3))'
classified: #math.

TPK compile:
'go  "execute the TPK algorithm"
|inp result|
11 timesRepeat: [
  self add: ((FillInTheBlank request: ''Number:'')
               asNumber).].
11 to: 1 by: -1 do:
  [:idx |
    inp := self at: idx.
    result := self f: inp.
    Transcript cr; show: inp; show: $ .
    result > 400
      ifTrue: [Transcript show: ''TOO LARGE''.]
      ifFalse: [Transcript show: result.].
  ].'
classified: #demo.

TPK new go.

It's all in strings, 'cause I still haven't figured out the proper way to add methods to a class. Of course, I forgot about escaping the inner strings, and that was most of my troubles. I feel like this solution is a bit Java-y. I'll try to do better after dinner.

Smalltalk begins

2007-09-30T20:32:00.000-04:00

Smalltalk: 9:13 PM September 30th, 2007 through 9:13 PM October 16th, 2007

Transcript show:'hello world'.
Transcript cr.

Smalltalk's Hello World is unique. In most languages, the task is to emit the string "hello, world" on standard output. In most Smalltalk implementations, there is no such thing, because Smalltalk is not intended for interoperability with the Unix shell or with other programming languages. Traditional Smalltalk programs are GUI applications, embedded in a complete environment. Although this is kinda a pain, it also is related to the very powerful reflection features Smalltalk has: it's incredibly simple to tear off the covers of a running Smalltalk program and start tinkering.

I've had some experience with Smalltalk, but I've forgotten most of it.

Having a read-eval-print loop is great if you're trying to puzzle out syntax stuff. Also, "inspect" is neat, and a good sanity check sometimes.
There's arbitrary-precision math by default. There's a surprising downside to this: I can't (easily) use the REPL as a calculator, because Transcript show:16/7 emits (16/7). Of course, it's possible just to change the default textual form.
There isn't font antialiasing. My beginner mess in the "Workspace" window is all the sadder-looking, and harder to read.
The concept of a "symbol" is still rolling off my head. It appears to be similar to, but more complicated than a symbol in Lisp. I created an array, and printed it, and it came out with a # in front of it. Does that mean something?
I keep on messing up the syntax. I guess it's just my C++ training that puts punctuation in different parts of a method call. I guess it's the absence of any symbol between the recipient and the method selector that trips me up.
Iteration is called "do". It strikes me as a little weak for a name, but it is a really basic operation.
Dang. The block in-parameter created in iteration is an l-value, but not for the actual array element. I guess that you can't do that in Smalltalk. Hm. That's a useful idiom, but how does one make it work in side-effect-skimpy languages?
I watched Squeak progress over an 11 element array, writing out each element. That's slow. I suppose it must be an I/O refresh thing, because the user interface would be molasses otherwise.
It's strange to have the methods like String decodeMimeHeader. It makes sense, though, because Smalltalk doesn't really have source code files corresponding to the methods in a class.
Wait, Smalltalk doesn't have source code files.
"Workspace" is a text editor, in which you can select lines, and tell Squeak to execute them. The natural thing to do, usually, is to keep on entering commands, and keep it as a log, but you can get revisionist real fast. This is good and bad.
I have a hard time anticipating where parens are going to be needed. I wonder whether that ever becomes natural. I can believe that Lisp gets easier, but Smalltalk syntax rules? That's crazy.
I had joked to my brother that there was such a thing as dynamic explicit typing: whenever the runtime needs to know the type of something, it emails the programmer. Well, when Squeak gets a runtime error, it asks the user if they'd like to fix the problem. All programs are dynamically correct, even if they are statically incorrect! For certain values of "user".
Developing code, it's really nice to select a block of text and see what happens when you execute it.
Dude, my dad's page is the first hit in Google for "TPK algorithm".
You can create an anonymous block with one parameter, but how do you use it? Is it necessary to attach it to the class hierarchy?
"Exit Music (For A Film)" is such a good track.
Got it. The block (a BlockContext) needs to be sent the message value in order to get it to evaluate. There are versions of it value for up to four arguments. Ugh! This is what I get for not making it part of the class hierarchy.
Dang. Got burned by lack of operator precedence already. That's a feature that's easy to attempt to use without realizing it.

Thank goodness. It's possible to copy/paste out of Squeak. I'm done with TPK.


f := [:x | (x abs sqrt) + (5 * (x raisedToInteger: 3))].

ar := Array new: 11.
1 to: 11 do: [:i |
  ar at: i put: ((FillInTheBlank request:'Number:') asNumber).].
11 to: 1 by: -1 do: [:i |
  val := f value: (ar at: i).
  val > 400
  ifTrue: [ Transcript show: (ar at: i); show: ' TOO LARGE'; cr.]
  ifFalse: [ Transcript show: (ar at: i); show: $ ; show: val; cr.]
]

It's really unidiomatic. I made the usual mistakes regarding array indices as a result. There's also got to be a better way to define f. I'm not sure what the right approach is — should it be attached to Number? Thanks to the "inspect" command, I think it's possible to just compile it and tack it onto the method dictionary, but that's just ugly, even ignoring the namespace pollution.

Bedtime now. A better TPK tomorrow, hopefully.

Resources consulted:

Smalltalk: Getting the Message (Rather slow-moving and involved, going too deep into history too early for my tastes.)
SmallTalk Tutorial for Java Programmers (About as amateurish as it sounds: among other things, it claims that Smalltalk doesn't have types. Still useful, though.)
GNU Smalltalk Tutorial (Sadly, I can't get GNU Smalltalk to build, so I don't get to use standard in and standard out.)

The rules

2007-09-25T23:41:00.000-04:00

The purpose of this journal is mainly to record my thoughts and keep myself honest.

Languages
I've chosen a set of 16 programming languages. Most are general-purpose languages which are well-liked by their respective communities. Some are more specialized, restrictive, or disliked. Two are abstract esoteric languages, impractical for ... well, anything.

In the partially-random order I will visit them, the languages are: Smalltalk, FP, Ada, Python, OCaml, BrainF***, i86 assembly, Prolog, Erlang, Forth, D, Lazy K, Haskell, FORTRAN, Lua, and Scheme.

Time
For each language: 16 days
Break between languages: 7 days
Total time: 361 days

Learning
Learning a language, (or learning almost anything, really) is a continuous process. In 16 days, it'll be hard for me to say that I really know most of the languages in question. And what counts as the language is itself debatable -- it's possible to learn all the syntax and semantics of Scheme in one day, but that doesn't really seem to count. And on the other end of things, I'm not sure if anyone really knows all of C++. So my goal is to be familiar enough with the language that it is no longer alien to me. I want to visit, see the sights, and do as the natives do for long enough that I can sympathize with their point of view.

Tasks
For each language, I have to write a Hello, World program, implement the TPK algorithm, and do some kind of graphics hack. For a couple of the languages, that alone might take a significant portion of the 16 days, and require exploration of deep concepts and idioms. Others will require more motivating tasks. I've collected a list of tasks, mostly games of some form or another, which I think could be suitable. There are two large projects, a compiler to the POV-Ray Scene Description Language and some kind of game, that I hope to write at least one part of in each language.