Older blog entries for zhaoway (starting at number 303)

in these days, news from the arena of programming languages only reminds me how people can easily get excited over trivial things.

empirical and theoretical. many and many big volumes of trivialities are produced. and not necessarily easy to be learnt.

life is very short. time spent to learn a new, so called, fundamental innovation in programming languages, could be better spent elsewhere.

learn chemistry. learn economics. there're many whole world unknown to me. watch another japanes anime or tv series. they teach me more than old Alan Kay or old Guy Steele.

lisp or unit testing, i'd better spent more time with my life partners.

don't take me wrong. i like collecting programming languages. to this day, i've collected some of c, of course, and scheme and forth and c++ and java and python. and a little bit of perl and ruby and ocaml and clean and erlang. and even less so with a few more bizarre ones.

i've also collected some programming practices, such as literate programming, and such.

it's a difficult thing to say. it's like you asking me if i support the death penalty. i just can't give a quick answer.

but i do dislike people give easy answers in the face of real difficult questions.

there ARE real questions in the field of programming languages research.

7 Mar 2005 (updated 7 Mar 2005 at 14:54 UTC) »

for a quick and conservative adoption of scons, GenerateConfigH provides excellent example.

in fact, that example could be even simplified a little bit more.

it should be noted that it's still easy to provide the user the usual interface to a source package:

$ ./configure
$ make
$ make install

just dump the m4 and autotools, in favour of python and scons. (i think it should be perfectly ok if one has nothing against make, especially when one's project is small.)

funniest ad of the week:

nobody reading your blog?

rotfl..

i thought AVL was initiatives of three persons. it seems it was two. (i am totally confused about the plural and singular stuff.)

suppose there is a solar system in a galaxy far far away.

suppose there is only one planet in this solar system.

suppose there is a civilization which is like the one on our earth about five hundred years ago.

now think about their Issac Newton.

can you notice something interesting?

now i, too, know that blogging is risky. :D

bonus point:

have you read the paper by nobel prize winner Michael Spence on Job Market Signaling?

a little economics is good for us. ;)

27 Feb 2005 (updated 27 Feb 2005 at 13:43 UTC) »

my finger is faster than my brain.

27 Feb 2005 (updated 27 Feb 2005 at 03:01 UTC) »

Just happened to know R6RS effort is underway for awhile.

chromatic, please don't be too serious about my last post. ;) you can read it as my halfly joking frustration towards unit testing instead. ;)

on the other hand, when you read about people talking about ideas of construction software, you have to:

1. check out what great projrects they have done before. this alone could save you alot of time from taking serious about many false ideas. in my case, i've only a hand of introductory articles. now you see. ;)

2. this point is rather radical. my take is the only next big news is a proof technique for real. nothing else could be big news any more. no silver bullet. we just tends to forget about it so very often. (unless we can prove for real.)

open source answer to unit test: don't.

let me explain. ;)

in a sense, open source is about lowering the development cost, and unit test is more work to do.

one way to lowering deveopment cost, for open source projects, is to let users help testing. then as developers, we should: 1. help users do testing; 2. make every bit of your program testable by users.

the way to help users do testing for us, is to write attractive docs. e.g. write usage docs in ezines. saving the time to write test cases, use the time to write interesting tutorials. write more tutorials.

the way to export every bit of our program so they're testable by users, is to write libs. structure our programs as a bunch of libs plus a small executable. write more docs about the api. see point 1 above.

so. the open source answer to unit testing is: write more libs, write better docs.

that's the open source way to do it. i'm serious. ;)

unit testing is for corporate lusers. ;)

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