An Interview with Brian Kernighan: Breeding Little Languages(broadcast.oreilly.com)
broadcast.oreilly.com
An Interview with Brian Kernighan: Breeding Little Languages
http://broadcast.oreilly.com/2009/04/an-interview-with-brian-kernig.html
9 comments
Or, leave error-handling code just as bulky as it is, but design languages in which errors need to be handled less frequently.
Do you know any language where it's not bulky?
> Do you know any language where it's not bulky?
Good question. Off the top of my head, I'd say, "no".
OTOH, one can look at relative bulkiness. E.g., I've found that dealing with exceptions in Python is significantly less work than in C++.
Good question. Off the top of my head, I'd say, "no".
OTOH, one can look at relative bulkiness. E.g., I've found that dealing with exceptions in Python is significantly less work than in C++.
I gave up on awk when Perl became available, and after that, Python. However, after reading this interview, I think I should relearn it.
It's very handy when you're working with delimiter-separated data. I've never bothered to learn the more powerful features of awk, because Python is generally better for sufficiently complicated text processing, but for little one-off scripts, awk is a nice thing to know.
Right. Awk is great for the sweet spot of 1-3 line filters, and the subset of the language needed for most of those could fit on half a page. You could do bigger stuff with it, but at that point it's probably better done in another language. There are surprisingly many cases where a few lines of awk is good enough, though.
Perl is logically a superset of awk, but there's so much more in the core language that I kept forgetting parts of it.
Perl is logically a superset of awk, but there's so much more in the core language that I kept forgetting parts of it.
bwk is a great writer. I enjoyed reading "Practice of Programming" and "The AWK Programming Language".
I completely agree (and the list doesn't stop there of course; it's pretty sobering when you look at just how many great books he has co-authored). Every single one of them is a great example of crystal-clear and concise writing.
> Brian: I'm torn on this. Error-handling code tends to be bulky and very uninteresting and uninstructive, so it often gets in the way of learning and understanding the basic language constructs. At the same time, it's important to remind programmers that errors do happen and that their code has to be able to cope with errors.
The lesson we learn from this is that we should design languages so that error-handling code does not have to be "bulky".