Older blog entries for ksandstr (starting at number 19)

Damn.
Looks like I've got distracted, again. I haven't hacked Reiska for almost a week now, having got caught up in the wonders OCaml. I did get a start writing a FNP client library in OCaml, though, so maybe the time wasn't all wasted. As a side effect I've started yearning for OCaml-ish closures in C... it feels like many of the problems that OCaml makes rather simple when compared to C would be solved quickly and efficiently using closures, tail recursion and all that functional-programming-y stuff. I can imagine how implementing closures (in the language, that is) without garbage collection would require some world-class trickery though...

Further on the plus side, I've grown used to OCaml's strong & static typing -- it's actually kind of neat, having the compiler barf on certain idiotic errors. It's no C for some low-level tasks, but it'll do for stuff I'd previously have used things like Python and Java for.

ebizo: 19.89 and counting.

It turns out that ``more caffeine'' is not a solution to the sleepiness problem. Not in the long run, anyway.

Objective CAML sure is strange. I know I shouldn't be distracting myself with new stuff while involved in a project that could actually become something else than just a cob-webbed module in my local CVS repository, but I can't help it :-)

As a plus, I now understand why so many people cringe in horror at OCAML's type system -- it's pretty much everything I've been looking to get away from in its almost Pascal-ish typing. For example, the separate +-*/ operators for integers and floating-point numbers. Helloooooo? What's the freaking point here? I shouldn't have to rewrite the same function if I want to do the same basic steps for floating-point numbers. Or complex numbers. Or any numeric type that has the required operators.

From my first impression with OCAML, I would say that it is as close to a bondage-and-discipline language as functional programming is going to get. This isn't necessarily a bad thing (I'm sure that Pascal is one of the more used languages, counting the 667 dialects), but I'd be glad if the language picked up some polymorphism at some point... The static typing probably allows for some bitchin' optimizations by the compiler, though.

Like someone (can't remember who) somewhere once said, LISP (probably also other dynamically typed languages) is good for building organic, ever-changing systems while statically typed languages are good for building pyramids, where you'd better have a precise floorplan before you even start building unless you want to tear down half of what you have built merely because you chose the wrong kind of mortar. Not that tearing down and reimplementing (aka refactoring, like the OO-correct like to call it) isn't a good thing some of the time -- I'm just not sure if the language design should enforce it.

Noticed that I've started commenting my code a bit much -- I mean, comments are good, but block comments longer than 15 lines in the middle of a function are likely to be a sign of something. Not that they aren't concise and descriptive of the surrounding code, but I can't help thinking that there might be a better place to shove that kind of borderline inline documentation. Maybe I should start putting documents about "this and that" in the CVS module, or something.

Released version 0.0.2 of Reiska. It won't compile because of some changes I made to Steven Hazel's FNP library that I haven't released yet, but it contains a fair amount of other improvements that might be interesting, if you're interested in this kind of thing.

Ja nyt unta palloon.

Free hint: Don't use idempotent_function(foo) in the second part of a for() construct in C (probably applies to C++ as well) if you intend to change whatever it is that foo points to during the loop. You see, the compiler may perform the idempotent_function() call just once, leaving you eating sand if you, for example, chop the last character off the end of the string on every iteration. Ugh.

Not declaring any functions G_GNUC_CONST that take arguments by reference would probably help limit damage here.

Indeed, D. Knuth was right -- premature optimization is the root of all evil.

I've decided that from this day on, whenever someone asks me a trivial technical question I'll just respond with the question "what would Jesus do?". I've determined that this response will have the appropriate weird-out value, having tested (and honed) the technique on several ex-cow orkers. Somehow I get the feeling though that the effectiveness could be improved by making an effort to look more like a stereotypical satan-worshipping death metal enthusiast, but I'm too lazy to try that out.

Hm? What are you still here for? Move on to the next diary entry, nothing else to see here.

Another morning, another sunrise. This one isn't as pretty as the one on the 30th.

reiska is coming along pretty well, considering that I took a day off the project studying Common LISP (prompted by the slashdot.com article). I'm almost done with the datastore design, but I'll need to run some more tests and implement item ordering according to popularity (weighting) before I can use this with Stephen Hazel's libfreenet.

I released the first (and so far only) version of reiska to the public - it's more of a "I'm gonna do a FNP implementation, so I'm releasing early" tarball than anything else, so as released it won't do anything useful. It generated a small flurry of posts on the freenet-devl mailing list, though, some of them suggesting that I use libfreenet for the node-to-node communication (which may be wise, since the protocol has been changed quite a bit for the 0.4 release - or so I've read) and concentrate on the message passing logic, datastore management and client handling in reiska. This approach looks pretty sensible, now that I have a better understanding of the inner workings of a Freenet node.

I whined some months ago how it is fucking hard to get into the Scheme mindset, and my opinion still holds -- expressing iteration with tail recursion may be OK if you're a hard-core theorist who implements every basic algorithm once without doing anything particularly useful with it, but try writing anything really useful without ever using a "while" macro and I'll give you the award for supreme wankerhood (a dried pea and a nut in a tiny cardboard box, if you're wondering).

Common LISP, on the other hand, is beautiful. CLOS in particular. I'd say that CLOS is the best object system I've ever had the pleasure of messing around with. I've had a couple of problems with the "a name may be both a variable and a function" thing as well as remembering to use funcall, but I guess I'll get used to it.

I just wanted to tell y'all that I'm currently looking at the first really damn beautiful sunrise this year. It's all purple and light red and blueish, sunlight reflecting off a thin layer of high clouds. Beautiful.

(also, NP: Lamb - Gorecki (Global Communication mix2))

Having read the slashdot.com article on the pulled SDMI paper, I'm starting to wonder if it would be possible to reduce the information required to remove the watermarks from a SDMI track into a couple of formulas, or a few lines of C/LISP/Haskell/something? If it were, we could distribute PNGs of them, print them on shirts etc, much like the css-auth thing and strong encryption before that. The paper is pretty long for printing on a shirt, after all.

Heh. Now all we need is CipherSaber, only for SDMI. Oh, and they'd need to start actually releasing stuff for SDMI too, for full effect.