Older blog entries for graydon (starting at number 88)

technik: the SICP text is still online here, though mirroring it might be wise.

work that body

frances and I just bought a small TV/VCR with which to pursue our mutual love of crass anime and high quality older films. lucky for us, suspect video carries lots of both. we're hoping this device will not lead to more actual broadcast TV watching, as we both lost sizable chunks of our childhood to that. so far we're seen keiko kamen and dead reckoning (bogart, 1947). going for joan or arc (bergman, 1948) tonight.

miscellaneous link-dropping: highly satisfied with the recent ghc 5.00.1 release. anyone who's held back from haskell for a while would do well to try it. It now includes a mixed-mode compiler/interpreter with dep chasing and an interactive mode not unlike hugs, only you get access to nice optimized copies of hslibs. It's a 5-minute fix to get emacs hooked up to it, then you have a nice ":reload" function at your fingertips. also pleased with unison, which does what you thought rsync was going to do when you first got it. counterbalance the amusingly pragmatic nature of dumbcode with some positive evidence that not all free software consists of broken instant messaging clients in python: boost, atlas, R, maxima and openDX. finally, was tuning nasty code with some nice profiling tools recently, worth pointing out: cacheprof, functioncheck, perfAPI, and jprof

obTechnicalPhilosophy: there is a delicate balance necessary between sticking with the things you know and can rely on, and exploring things which have the potential to be better. assuming that one or another of these strategies is the one true way is silly.

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

79 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!