~devyn

DevHost1 rebooting for a kernel upgrade

DevHost1 maintenance

DevHost1 will be down briefly for maintenance. It should be up within an hour.

Update: DevHost1 is back up. There was a freak issue with every process spawn causing a SIGILL, but I don’t know whether it will happen again. I’ll restart on next kernel update just to be sure.

Progress is slow on TPFS, but it hasn’t stopped. Things are a bit easier now that it’s an ΩF:∅ project, though, I guess.

I suppose I should keep this more up to date.

JavaScript, why?

I don’t understand why people like JavaScript. It’s like liking PHP. They’re gross languages that have horrible inherent limitations and are certainly not as easy to use (while still allowing complexity) as they should be.

JavaScript doesn’t even have an integer primitive. I don’t understand how one could possibly think that double-precision floating points are enough. They’re slow.

JavaScript converts hashmap (object) keys to strings. This makes them useless (and slow) as general purpose maps.

What’s up with the syntax? It’s like someone took C syntax and made it evil. Since 4. is a valid literal in C (and so it is in JavaScript too), you can’t do 4.toString(). Instead, you have to do 4..toString() or (4).toString() (though the former is preferred). But 4. isn’t even necessary, because 4 == 4. — all numbers are floats, unlike C, where 4. is a double and 4 is an integer.

Now, I don’t mind that JavaScript is similar to C in a few ways. That’s good. I also don’t mind the object model. It could be done better (see Lua), but as it is right now is definitely useable. I don’t mind Node.js, which seems to be quite popular — it’s great that people have an interest in evented/asynchronous programming. It’s an interesting area. Node isn’t the end-all solution though. It’s definitely far from perfect.

However, I’m not really a huge fan of dynamic typing. It’s easy, sure, but it’s also easy to miss bugs. I’m not a fan of C/++’s static typing either (though it was somewhat necessary at the time). Instead, a strong type inference system would be good, like Scala, Haskell, and many other languages (especially functional languages).

This would change JavaScript too much though. The object model, as it is, is not very compatible with a strong type inference system.

I think we need a replacement for JavaScript on the web. Better yet, how about some kind of bytecode JIT with a standard calling convention? A JavaScript compiler could then target this JIT. This would allow a large variety of languages to be used on the ‘net.

Anyway, there’s my rambling for the day.

TPFS 0.1 coming soon

As soon as I’m not swamped with homework, I promise.

The docs are (sometimes) available at h.devyn.tk/docs/tpfs. This will give you a good indication of my progress.

So far block allocation is what I’m working on. The algorithm I’m using at the moment is really ugly and sometimes slow, so I’m trying to improve it.

dot.tk keeps taking down my domain

And it’s really annoying. I don’t have my home webserver up all the time — it’s not dedicated. Apparently they expect it to be up every time their robot crawls it, or they immediately remove it. I guess I can’t complain — it’s free, after all.

Anyway, devyn.tk is now my tumblr, and h.devyn.tk is my home server.

If you’re wondering why I went with a ‘.tk’ domain, which have been used for… many malicious purposes, it’s because I rather like the sound of ‘devyn.tk’. That’s it.

The practicality of the ‘fix’ combinator

In Control.Monad.Fix and Data.Function, there is a combinator function called fix. Its type is (a -> a) -> a. It is defined as:

fix f = let x = f x in x

but it could also be defined (maybe more clearly) as:

fix f = f (fix f)

It creates an infinite chain of the function, and it’s sometimes used to rewrite a recursive function. For example:

ones = 1:ones

is equivalent to:

ones = fix (1 :)

Because Haskell is lazy, and (:) doesn’t require evaluation of the right-side to evaluate the left-side, this works and will print in GHCi as [1,1..] would.

Another example is the factorial function:

fact = fix (\fact n -> case n of 0 -> 1; _ | n >= 1 -> n * fact (n - 1))

Thanks to Derek Elkins for the above example

Although understanding how the fix combinator works is a powerful realization (like much of Haskell, really) — it feels like points-free for the sake of points-free to me, when used in actual code. Points-free functions can often make how the functions work clearer, however, there are many cases in which a standard, pattern-matched function would be clearer. The factorial above is easily expressed as:

fact 0 = 1
fact n | n >= 1 = n * fact (n-1)

Although the version using the fixed-point combinator is arguably more beautiful functionally, I opine that the latter version looks better.

There are several more “real-world” applications of fix on the Enumerator and iteratee page of the Haskell wiki. However, I think that even in this case where the fixed-point combinator applies quite nicely, it is still much cleaner and more practical to use simple, tail-call recursive functions.