Older blog entries for graydon (starting at number 86)

remove tonsils, get icecream!

A fab month. Graduated with surprisingly higher marks than I thought I deserved, got married and spent the weekend playing skee-ball and air hockey and mini-golf, and am now happily settled into my den of evil at redcygnushat.

Still basically obsessed with the prospects presented in hehner's book which has been consuming my free time since I found it in february. Many new things afoot, but increasingly unable to talk about them. poo.

school's out

submitted final version of the compiler for school, kicked coffee for a week to see if my eye would stop twitching. had last day of uneventful classes. saw "the third man" a couple weeks ago, which was really good, and "of human bondage" (the bette davis version) which was really not. sent out a whack of wedding invites, got some new shoes.

slepnir ran up to me last night and coughed up a roach exoskeleton on my face. then she pissed in my shoe. she hates me. this is because I clean her cage out, and rats like mess.

went out to john's italian with frances, got a nice panini and a glass of wine. got my "program completion" notice from the university and a large tax refund from the government. start work at RH on monday. looking forward to some perverted hacking and having my evenings free again.

splork: imho dynamically typed languages are really not your friend for large projects. the arguments put forth in this article are really wrong-headed.

  • testing probes individual cases for correctness. it's important for making sure your assumptions are correct. type systems prove entire categories of flaw do not exist in your code, i.e. an infinite number of test cases. I do not for a minute believe the claim that normal unit tests will find "every" error a typecheck will find. tests and types do different things.

  • moreover they are fast. a typecheck is faster than all but the most utterly trivial test. the argument he makes against lengthy compile times is surprising considering how much longer a really strong regression suite will take to run.

  • really, the compile time argument is an argument against compiling C++, which involves both extensive machine-level optimization and a hiddeously poor declaration management strategy (textual inclusion). this is not a valid critique of static type systems. if you want near-instant builds of programs in typed languages, get a native non-optimizing bytecode compiler for a language with binary declarations like ocamlc.opt or jikes. they cook.

  • in fact, if you are trying to produce optimized code, your compile time with a dynamically typed language is almost always going to be longer, because you have to do far more extensive partial evaluation. type systems save you the hassle, and make it much easier to write optimizing compilers.

  • modern HM-based languages infer nearly all their types from the data constructors anyway, so you don't actually have to enter them into the source code. so unless you're actively avoiding a strong type system, you can basically get one for free. it doesn't affect "agile processes" like XP's "aggressive refactoring" any worse than pointing out when you make an inconsistent change, which is generally something you want to know about.

  • redeploying software is always a fragile affair. I can just as easily change a "base class" or some other central dependency bottleneck and break a typeless language as a typed one. the solution in any case is to reduce coupling around the points which are likely to change. It's slightly hard in C++ because it computes vtbl offsets explicitly (again, for speed) but you can get around it with a compiler firewall or some componentware if you think your implementation is going to change its layout.

I agree with his assertion that "scripting languages" are becoming more important, but not because they're good for producing robust software. they're important because a lot of people want to write one-off programs, and languages with "simple syntax" lower the barrier to entry. this is good. this de-thrones the high priests of programming and puts automation in the hands of normal people. it's ok to have some failures in a one-off program to automate a task you would have done sloppily, by hand anyways. nonetheless, with friendly enough syntax, you can slip a good type system in while nobody's looking, and some people will appreciate the extra error checking. perhaps mondrian will actually introduce legions of windows slaves to haskell. doubt it, but who knows?

spring cleaning

called it quits with zeroknowledge; best of luck to everyone there.
frances and I are getting married on may 18, one month after I start work at redhat and 5 days after I graduate.
we're thinking of some place with waterslides and mini golf for our honeymoon.
may's going to be a nutty little month.

21 Feb 2001 (updated 21 Feb 2001 at 06:18 UTC) »

new toys: another wagon release, an evil stdio-to-.so adaptor, a stupid yet pleasing binary visualizer, another mindless makefile maker, the beginnings of a parser for the maddeningly context-sensitive iupac organic chemistry nomenclature.

aside: despite the fact that Objective Caml is currently turning up the heat in the usable-functional-language wars, and even has a passable emacs clone, there is new competition (with slightly cleaner syntax) in the most recent O'hugs release. the async reactive objects thing is pretty well developed, and it even manages to introduce ":=" in a way which is not an awful hack circumventing the denotational semantics. functionalists rejoice, the time for writing non-academic programs may nearly be at hand!

jdybnis: I think the cheeky answer is to be found in r5rs wrt. the disjointness of types. however, evaluation as boolean is polymorphic, such that anything which is not #f is coerced to #t. so your code can be written as:

(define (breadth . trees)
 (or trees
  (cons (map car trees) 
   (apply breadth 
    (apply append (map cdr trees)))) 
  '()))

but the perhaps-valid question you could then ask is: why isn't '() coerced to #f, and conversely why there isn't a coerce-to-list form for booleans. dunno. MIT scheme treats them the same, so perhaps they didn't see the logic in it either.

creepers!
#!/usr/bin/scm  
 
(define (f str)  
  (lambda (them)  
    (let loop ((rest them) (ls (string->list str))) 
      (if (pair? ls)  
          (begin (write-char (car ls)) 
                 (loop (call-with-current-continuation  
                     (lambda (us) (rest us)))  
                    (cdr ls))) 
          (newline))))) 
                 
((f "Js nte ceeWnae")(f "utAohrShm anbe")) 
^D

04:27:13 graydon> ./f.scm Just Another Scheme Wannabee >

ModernRonin raised the "how could C be improved" issue (without sacrificing its simplicity and minimalism, I assume), and the language geek in me can't resist commenting:

  1. hygenic macros or at least inline functions (some in c99)
  2. explicit sized integer types (in c99)
  3. namespaces & imports rather than #include
  4. pointer restrictions (some in c99)
  5. runtime-variable length arrays without resorting to alloca (in c99)
  6. a backtick operator
  7. a jump convention without resorting to setjmp/longjmp
mars retreats

as some of the vegetarians in the audience may know, putting soy milk in a good strong cup of coffee often results in suboptimal results: the soy curdles and you get a sort of splotchy, aesthetically displeasing fluid resembling miso. rather than accept her fate however, my 1337 protein-haxx0r girlfriend stared at it, scratched her head, pulled out some baking soda, added a pinch and stirred. the pH raised, the globular proteins dissociated, and the coffee returned to being creamy.

other stuff: binary decision diagrams are extremely cool, as is <bigwig>. found a cool archive of more noam chomsky than you could shake a stick at, and saw some films: oh brother where are thou (good), do the right thing and bamboozled (spike lee double bill, ++good), state and main (good), and crouching tiger (turbo-good).

the 187 skillz

Been playing with modular monadic interpreters and compilers recently. The monad keeners are really clever: the idea is to separate out "facets" of a language processor (a la action semantics) into separate monads, such that (if you get the liftings right) you can do a modular proof of your rewrite semantics for that facet irrespective of the other facets you may have enabled. This is cool: you can develop a working call/cc system or lambda abstraction or calling convention in isolation, test it out, then just sorta graft it into an existing compiler / interpreter. The math gets a little ghastly but it's miles better than plain denotational semantics.

Monads are one of those things like pointers or closures. You bang your head against them for a year or two, then one day your brain's resistance to the concept just breaks, and in its new broken state they make perfect sense. I've only constructed a UA parser and 2-level interpreter at the moment but the fact that I could do so in a couple pages of haskell is rather amazing. Parsec makes Bison look like a sad joke.

er, um. otherwise I've been on vacation. watched a lot of television, ate a lot of waffles, and read a lot of ACL2 examples. went for walks in the snow with frances, played with baby rissa, slept, perused the various available open cores, listings for FPGA's on PCI cards (and DIMMS!) read up on current leftist media and browsed the libstdc++ design notes.

77 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!