Debu.gs

New Danged Blog

Pete Elmore — Mon, 07 Jun 2010 20:59:01 +0000

After living with a static dump of the blog for a long time, and with some partially pathological software running it before that, I've just rewritten the whole thing using "Watts":http://github.com/pete/watts , "Hoshi":http://github.com/pete/hoshi , and "Sequel":http://sequel.rubyforge.org/ . It *should* be the case that I start updating this thing a little more. The code is really simple, the blog is really fast (seriously, I've not hit a rendering time approaching 0.01 seconds yet), and so there should no longer be this big mental wall between me and posting. Well, it's not quite as fast as the static dump of the old page, but I won't be too picky here. I didn't even really change how things looked, except that I've put the rounded corners back and added a sidebar, which...uh... I may take these out, but there are "tags" now. I'm not sure how I feel about that; I may take them away.

Introducing Pez

Pete Elmore — Fri, 24 Jul 2009 00:00:00 +0000

I'm happy to announce the new language Pez! Pez is a fork of the Atlast project, and is still under development. It shares many of the same goals, although it is also going in a very different direction. If you'd like to follow the development and/or contribute code, the project is hosted on GitHub at "github.com/pete/pez":http://github.com/pete/pez . h3. About Atlast The Atlast codebase started life as an internal scripting engine for AutoDesk, and was implemented by "John Walker":http://fourmilab.ch/ in 1990, and later released into the public domain. The main goal of Atlast was very simple: produce a uniform internal scripting language that works cross-platform, sort of like LUA is today. The case for something like this is very strong. User scripting in any application of reasonable size is nearly essential; one only has to look at the success of AutoCAD, Emacs, vim, Photoshop, and countless others. The added bonus is that if your application also has a scripting language, you can use that same language for the configuration files. Unfortunately, the language used is often somewhat ad-hoc, having been built up from a small set of commands, gradually adding power to the language. Sometimes the developers end up using the language for tricky parts of the application logic. It smells remarkably like "Greenspun's Tenth Rule":http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule to me. Often, as is the case with my favorite editor vim, the language evolves along very odd lines, and scripting can be a pain. I think Mr. Walker makes a really excellent case for including a little language to embed in your program, which you can find as the introduction to the Atlast manual: "http://fourmilab.ch/atlast/":http://fourmilab.ch/atlast/ . So I won't belabor the topic, but do have a read if you are interested. h3. Here Comes Pez Pez is based on Atlast, which has been generously released into the public domain. (In keeping with the spirit, I intend to keep Pez in the public domain as well.) Pez shares many of the same goals as Atlast: * A small, simple, fun codebase. * A library to add scripting to whatever application you have. * A powerful language to do this scripting in. * A highly portable implementation. * Fun for the whole family. There are a couple of differences in the roadmap, though. Pez is actively maintained, and features are being added. I am fleshing it out for more general-purpose coding, so that in addition to keeping Pez useful as a scripting language, Pez will be more useful as a standalone language. I'll even be adding real regular expression support. And the reasons for going with Atlast were that it is tiny (~4k lines), it's clever, it's portable, it's written entirely in C, it's public domain, and it's fun. h3. Weirdness Ahoy! Forth is a weird language; it evolved along different lines than most languages. Although different coding paradigms (some new, some old) are becoming more and more popular all the time. (Have a look at "Factor":http://factorcode.org/ , "Haskell":http://www.haskell.org/ , "Joy":http://www.latrobe.edu.au/philosophy/phimvt/joy.html , "Erlang":http://erlang.org/ , "Scala":http://www.scala-lang.org/ , "Reia":http://reia-lang.org/ , and the numberous other new interesting languages. They're fun!) So the "weirdness isn't so bad":http://www.paulgraham.com/avg.html , and maybe it's actually great. While we're accumulating weirdness, then, I'm pleased to say that Atlast is sort of a weird Forth. It only loosely followed the standard, and its design predates the 1994 standard. Even better, Pez is a weird version of Atlast! Although Forth is great, there are already plenty of standards-compliant flavors laying around. Pez can be thought of as following more modern conventions without breaking the spirit of Forth. Single-line comments start with a backslash in Forth, but start with either "#" or "#!" in Pez, so that you can write a script that starts with "#! /usr/bin/env pez" and expect it to run. The standard Unix system calls and an autotools-based build are being added and refined (respectively) as we speak. h3. Who's Responsible for this Fiasco? So far, mostly me. (Although Mr. Walker implemented it, I'll take responsibility for the "fiasco" part.) The "credits":http://github.com/pete/pez/blob/master/doc/CREDITS are available online or in the repository for the full run-down of contributions. "Matthew King":http://www.automatthew.com/ came up with the name, and has made some contributions already. (Stack-based language? Pez? Right? I'm going to call the package distribution system "Dispenser". Feel free to ignore the cultural reference if you're from somewhere that doesn't have PEZ candy.) Patches are always gratefully accepted. h3. The Plan So, where is Pez going from it's current, humble status? As previously mentioned, Pez is going to be fleshed out for general-purpose coding as a standalone language, with the application-scripting part kept up as well. There is a first pass at an FFI, for calling C libraries from Pez. There are multiple bug fixes and some performance enhancements coming. You can get the (almost) full list from the "todo":http://github.com/pete/pez/blob/master/doc/TODO file. I have some ideas about concurrency that are not quite solid yet, but will hopefully make their way into the language. There will, thanks to the FFI, be a lot of libraries to add with minimal effort needed. I'm starting with "SDL":http://www.libsdl.org/ , because that sounds like the most fun. I suppose we'll eventually also need some grown-up libraries for parsing JSON, dealing with web-apps, and what have you. And I'm planning to try out using Pez as an intermediate language for the Roboto compiler. Pez (and nearly every Forth dialect) has an odd mixture of portability, dynamism, and closeness to the machine, so I think it would be fun to use for a VM, instead of a bytecode compiler. h3. Rupez In keeping with having fun with the language, the above-mentioned Matthew King has also created "rupez":http://github.com/automatthew/rupez so that Pez can be portably called from Ruby. It uses Ruby-FFI, so you can even eval Pez code on top of the JVM in JRuby or from Rubinius, in addition the the normal MRI 1.8 and 1.9 interpreters. h3. That's All I've Got. Feel free to check it out. It's at "github.com/pete/pez":http://github.com/pete/pez . If it doesn't work, let me know. If you want to hack at it, feel free. If you want to take the project, fork it, change the name, turn the comment character back to backslash, integrate it into the Windows kernel, and use it to implement next-gen DRM capabilities to make people un-watch movies after seeing them so that they can't tell their friends about them, then hey, it's public domain, the most free of the free software licenses. Do whatever. Put that in RMS's GNU/Pipe and GSmoke it.

Views, for Serious

Pete Elmore — Thu, 23 Jul 2009 00:00:00 +0000

It seems views are all wrong nowadays. It is time to do views for serious, and then get the party started. I wrote "Hoshi":http://github.com/pete/hoshi a while back. It is sort of like "Markaby":http://markaby.rubyforge.org/ , but there are a few differences, and I'll highlight them so the rest of this article makes sense. One of the main ones is that (with the exception of the one-off block version) there's no instance_eval, and very, very little magic involved at all. Calls to tag methods have no fanciness, and the code really just sort of looks like Ruby. This was the whole idea for Hoshi, incidentally. The view should be a first-class object, with inheritance and instance methods and all of those things that allow you to actually put all of your Ruby knowledge to use. Without instance_eval intermittently confusing the semantics, you get to use blocks and closures and local variables and your context is always the instance of the view. That having been said, Hoshi looks close enough to Markaby (and was largely inspired by Markaby) to muddy things a bit. I've been asked by at least two really smart guys if there's a way to get Hoshi to allow "div.foo!" to generate "<div class='foo'>". The answer is that although it would be nice to have, I don't know of a way to get that to happen without breaking the parts that actually make Hoshi nicer than Markaby. And this is where I actually get to the point. To pick on that CSS class example again, those classes are there to describe the type of thing that the tag represents. That div up there belongs to the foo class, and the accompanying CSS describes how a .foo ought to look, and sometimes how a div.foo ought to look. This separation of the document (semantic HTML) from its presentation logic (the CSS) is nearly univerally considered the Right Thing to do when on the web. Are you spotting an analogue to Hoshi and expressive domain-specific languages yet? If not, don't worry, I'll do my best. If you've done a lot of ERB/HAML/etc., then this basically the opposite approach. Even Markaby (and I love _why, he's a genius, so hopefully *we still cool* in the off chance that he reads this) is really like a templating language in Ruby syntax, and that's the opposite of what you really want. The idea isn't to make tags convenient to write; it's to make sure that you don't write tags very often. You want to build a document by describing it, not by putting a bunch of tags in it. Code works best when a given piece only solves one problem. You want some of your view methods to describe the document and provide the content, and you want some other private methods squirreled away at the bottom to handle all of the tag logic. You want to talk about your document not in terms of HTML tags, but in terms of what it actually is, and build a very DRY DSL for describing the document in some private methods down near the bottom of your class or in a superclass. I know you want it, because I can see it in your eyes. I generate my resume with Hoshi. Any heavy or repetitive tag-lifting got pushed out of the parts where I talk about what I want it to say, and section headers are not done by "h3('Section Name', :class => 'section-header-or-whatever-i-forgot-the-css-class-actually')", but by a call to the section method: "section 'Section Name'". I'm free to change it from an h3 to an h2, or to make the text BOLD, ITALIC, UNDERLINED, AND BLINKING to maximize my professionalism. This DRYing out of code, pulling repetitive things or complex logic or even ugliness into a method somewhere else is common sense, but doesn't seem to occur even to really smart guys. In fact, I think we get trained by templating. Who would ever define a method in an ERB template? Rails /sort of/ has a method for dealing with this, in that technically you can pull logic out of templates and into Helpers, but you still don't have first-class views, and templates are still "HTML with a little Ruby". HTML is static, and even loops and conditionals are excessively weird and ugly in ERB. Even if you add "helper methods", it's an approach that actively discourages all of the common programming practices that are common sense everywhere except templating languages. And that's what Hoshi really is for. Everything you know about programming? You get to use that. Inheritance. Methods. Instance variables. Closures. You love these things, right? I do, too, and that's why, rather than making tags easy to write, Hoshi tries to push tags and other tag logic out of the way. h4. Footnote Actually, all of this is where the name for Hoshi came from, via a somewhat indirect route. I was sick of HTML: "I'm Sick Of Html" -> "ISOH" -> "HOSI" -> "??" -> "Hoshi".

Reading List for Coders

Pete Elmore — Mon, 20 Jul 2009 13:59:51 +0000

This is a collection of articles and code that hold interest to every coder, and all present a fascinating look at different sides of software and computer science, and a couple of historical articles. The sort of piece that leaves your mind buzzing with possibilities. All of these pieces will change the way you think about computers, and are all fascinating besides. They should be of interest whether or not you are familiar with or like any given technology. The first few I selected provided me for an important criterion for inclusion: rather than finishing this list, I wanted to re-read them (and did for most). The order is pseudo-random. Ken Thompson, "Reflections on Trusting Trust" "http://cm.bell-labs.com/who/ken/trust.html":http://cm.bell-labs.com/who/ken/trust.html Ken, one of the infamous Bell Labs trio, along with Dennis Ritchie and Brian Kernighan, describes self-reference in code uses it to demonstrate how a compiler is written in the language it is designed to compile, uses that to demonstrate possibly the world's most clever compiler hack and uses that to demonstrate why software is fundamentally untrustworthy. Richard W. M. Jones, "JonesForth" "http://www.annexia.org/_file/jonesforth.s.txt":http://www.annexia.org/_file/jonesforth.s.txt In the only appropriate use of the literate programming style that I've ever seen, Jones builds a complete Forth compiler before his readers' eyes. It makes for a distressingly addictive read once you are far enough into it, and shows exactly what is so brilliant about Forth, the only language besides most assembly languages to provide at the same time low-level control and dynamism. (In many ways, newer "dynamic" languages such as Ruby, Perl, and Python, pale in comparison to the dynamism inherent in Forth's execution model.) Ed Post, "Real Programmers Don't Use Pascal" and Ed Nather, "The Story of Mel" "http://www.pbm.com/~lindahl/real.programmers.html":http://www.pbm.com/~lindahl/real.programmers.html "http://www.pbm.com/~lindahl/mel.html":http://www.pbm.com/~lindahl/mel.html The first article is a brilliant piece of satire from 1983. Aside from being a hilarious read, you can out-old other coders if you recognize all of the topics mentioned. It is here to break the list up slightly, but mostly because it is both enjoyable and sets the stage for the second article, "The Story of Mel." Mel's tale may be a bit obscure if you do not understand machine code, but is still a great read nonetheless. Paul Graham, "Beating the Averages" "http://www.paulgraham.com/avg.html":http://www.paulgraham.com/avg.html Too much low-level stuff, right? This article is probably the most likely to have been read before seeing this list, so much so that I have to fight the urge to list my criticisms of the article to avoid sounding like a Paul Graham worshipper. But that doesn't change that the article is brilliant, and in case you have not read it, it is an exploration of the reasons for choosing programming langauges with a brief defense of Lisp, through the description of the "Blub Paradox". The Blub Paradox is possibly the most interesting part of the article, that I hope I am summarizing fairly when I say that it is like a coder who, because he has never seen a screw, cannot fathom why he would need a screwdriver. Worse, having never owned a screwdriver, he doesn't know why he would ever buy a screw. Topher Cyll, "If It's Not Nailed Down, Steal It" "http://www.artima.com/rubycs/articles/patterns_sexp_dsls.html":http://www.artima.com/rubycs/articles/patterns_sexp_dsls.html Cyll shows, in what is perhaps inadvertently a different take on the Blub Paradox, the core of the hacker ethos: feature-stealing. Starting with basic Ruby, he jumps through a number of hoops to add pattern-matching, S-expressions, and a small DSL to write an interpreter for the familiar Logo language. It is a fun look at writing an interpreter for a small language, and at de-Blubbing your language of choice. Pete Stevens, "Upside-down-ternet" "http://www.ex-parrot.com/~pete/upside-down-ternet.html":http://www.ex-parrot.com/~pete/upside-down-ternet.html A description of a fun hack for your local network, using Linux's iptables and squid. Stevens' neighbors are jumping on his unencrypted wireless network, so he serves them an upside-down version of the internet. It shows exactly how creative one can get with seemingly mundane system tools. Brian W. Kernighan, "Why Pascal is Not My Favorite Programming Language" "http://www.lysator.liu.se/c/bwk-on-pascal.html":http://www.lysator.liu.se/c/bwk-on-pascal.html Brian Kernighan, another Bell Labs vet, talks about programming language design by contrasting Pascal with Fortran, and his experiences in porting Fortran code to Pascal, and describes the biggest problem, a problem still relevant to more modern languages: "There is no escape." Dennis M. Ritchie, "The Evolution of the Unix Time-sharing System" "http://cm.bell-labs.com/cm/cs/who/dmr/hist.html":http://cm.bell-labs.com/cm/cs/who/dmr/hist.html I promise that this is the last Bell Labs article. It is a history of Unix, and rationale for its design decisions. Unix's design still survives today in nearly every operating system, especially Linux and MacOS X (even Windows has, sometimes grudgingly, gradually imported features from Unix, especially from the C coder's perspective). Especially the section "Pipes", in which DMR talks about modularity and how the pipe operator got its current form in the shell. Tom Duff, "Duff's Device" "http://www.lysator.liu.se/c/duffs-device.html":http://www.lysator.liu.se/c/duffs-device.html Tom Duff describes Duff's Device, which is some sort of abuse of some C feature, probably its syntax. If you have never encountered one, it is an interesting (but short) read on low-level constructs popping up in higher level languages, and an amusing push at the edges of what C can do. Various MIT hackers, "HAKMEM" "http://home.pipeline.com/~hbaker1/hakmem/hakmem.html":http://home.pipeline.com/~hbaker1/hakmem/hakmem.html This is actually so widely available that it is almost redundant to provide a link. It is a collection of small hacks on varied topics, but mostly math and PDP assembly code. Several of the ones that I can understand are absolutely mesmerizing. John Walker, "ATLAST" "http://fourmilab.ch/atlast/atlast.html":http://fourmilab.ch/atlast/atlast.html This is a full manual for the ATLAST language, although the section I mean to discuss is the introduction. Despite describing a problem Walker had in 1990, this article (like many listed) is still incredibly relevant. It discusses the importance of writing applications that are user-scriptable, his experiences with adding AutoLISP to AutoCAD, and the problem that applications rarely can be scripted. When they are, though, it is often as a manifestation of Greenspun's Tenth Law. Walker also certainly has a hacker's sense of humor: "[D]on't be put off by the examples. Just skim over them as if you understood them." (I hate to plug here, but I have forked ATLAST to add more portability, FFI, and a few other new features. See "http://github.com/pete/pez":http://github.com/pete/pez for the Pez project.) Richard P. Gabriel, "Lisp: Good News, Bad News, How to Win Big" "http://www.dreamsongs.com/WIB.html":http://www.dreamsongs.com/WIB.html This is the article that first laid out the worse-is-better approach, discussing mainly what happened to Lisp in the 80s and why Unix became the dominant platform. "Worse is Better" is simply solving the 90% case and leaving the user an escape hatch for the remaining 10%, which is a philosophy that has gained a lot of ground. Gabriel wrote rebuttals to his own argument under a pseudonym, and then rebutted those. The story behind those articles is as interesting as the articles themselves: "http://www.dreamsongs.com/WorseIsBetter.html":http://www.dreamsongs.com/WorseIsBetter.html . That's it, that's the list, and it is by no means complete or perfect, but does represent a collection of articles that stuck out in my mind as having had an impact on my approach to computers and specifically to writing code, and are likely relevant to a large number of coders. They are the articles that I have often excitedly shared with co-workers. I'm somewhat disappointed that textbooks that are purportedly about computing don't borrow more heavily from the philosophy of the actual coders who created the field that they're writing about, which I hope to have represented well in this collection (including a few more contemporary pieces). But mostly, I hope that these are fun to read.

Hoshi 0.1.0 Released...Soon

Pete Elmore — Thu, 06 Nov 2008 00:00:00 +0000

You can check it out at github right now (http://github.com/pete/hoshi), or you can wait for the official release, but Hoshi is here, and it's incredible. It's everything you've ever wanted and more. It's...well, actually it's just a first-class view library.

Hoshi fills a gap in Ruby MVC applications, namely the V part. Templates don't count as first-class views, don't allow you to take advantage of Ruby's fancy object system (Inheritance is back again!) and mixing languages is annoying and makes validation/syntax checking harder. With HAML and ERB, you are mixing Ruby and HTML and in most cases, also CSS and Javascript, not to mention that the templating engine has its own syntactical rules. On top of that, with HAML you don't know if you have valid HTML until you hit the page that loads that file, and with ERB you don't know until you run the file, and even then it might be valid with some values and invalid with others. Ouch.

Hoshi solves this problem in a way similar to the way the very clever and very cool Markaby does: by making HTML tags Ruby methods. The main difference between Hoshi and Markaby is that Hoshi::View sub-classes are view objects. You instantiate them, call methods on them, and eventually toss the output of one of these methods over to a browser (or whatever). Hoshi::View isn't a module, there's no funny instance_eval or parsetree business going on behind the scenes, and method_missing isn't used unless you set the permissive flag in your view. And because it guarantees valid HTML/XHTML/XML if you give it valid Ruby, you'll know if it's wrong when your code loads, and you can make sure it's valid with ruby -c.

And there is one more cool piece of functionality provided with Hoshi: html2hoshi. This is a little program (really, a command-line front-end to lib/html2hoshi.rb) that takes a big, scary, poorly-indented ball of HTML and generates a nice, clean, readable, manageable Ruby file that uses Hoshi to generate equivalent HTML. Want to read some obfuscated or compressed HTML?

	curl http://www.google.com/ | html2hoshi - | less

Or maybe you have a web designer that emails you HTML files, and whatever WYSIWYG HTML editor he/she uses generates awful, unreadable code. Maybe the disigner where you work generates the unreadable code himself/herself*. Either way, your job of cutting up the pieces for use in your web app can be a pain. Well, try this out:

	html2hoshi index.html index.rb

I bet that when you do that, you'll feel great. Now the code is readable, and you move chunks around and cut it into pieces like you would any other Ruby code. Wow.

Anyway, to summarize, Hoshi: The Web Can Be Awesome.

*Web designers reading this: most of you are cool, please don't take this personally, and I'm sure you know the ones I'm talking about. But I don't feel that way about you. You're, like, my BFF. I've always looked up to you and admired your work. The cleanliness of your purely semantic markup, when married to your elegant CSS has often brought tears to my eyes. I'm not talking about your code. I'm talking about the muddled markup manufactured by that guy two cubes down from you. You know who I mean. The one who has worn down the keys he uses to copy and paste, and who always smells oddly like sawdust.

Not that it's a bad smell, just that it's very odd, especially considering that he doesn't do any woodworking. He's got a studio apartment on the third floor of that apartment building just down the street from the office, he can't possibly own a table saw. Where would he put it? But that smell is distinctly sawdust. I mean, I'd ask him about it myself, but honestly, how do you bring it up? And my mind always goes blank when I talk to the guy, you know? All I can think of is sawdust, and it's such a strong scent. I've never smelled actual sawdust that smelled that much like sawdust.

Anyway, web designers, to summarize: We cool?