Hacker News Reader

Comment by pestaa | Hacker News Reader

I honestly love projects like this one, but is the implementation language really worth fragmenting this niche? Uzbl is in Python and I can't think of any objective reason why Haskell would be better for a browser.

View on HN

"I honestly love projects like this one, but is the implementation language really worth fragmenting this niche?"

If you honestly love these kind of projects, than I can't understand why you're asking this question?

It just has to be worth for the guy doing it. Every other view point considering the usefullness of it or how profitable it would be, is just killing all the fun and in a way taking away all the meaning.

"Uzbl is in Python and I can't think of any objective reason why Haskell would be better for a browser."

It's like asking, if there's an objective reason to write an applikation in Haskell instead of Python.

There are some benefits using a compiled, optimized and modern statically typed language for desktop software that runs on the user's machine -- it's less work to get a smaller memory footprint, reduced liklihood of runtime errors, faster start times.

For "big" software I agree in principle, but for both of these browsers, the vast majority of computation happens in the embedded WebKit rendering engine, which is written in C++. The browser built around it is more UI bindings and an API to interact with other Unix software, and for that, afaict, Python isn't really slowing uzbl down.

I feel like something similar could have been said about Xmonad. Yet, through its configuration and extension mechanisms, it's become a gateway for a lot of people wanting to learn Haskell. This niche isn't likely to fragment as long as it's made up people obsessively scratching their own itches.

xmonad was written in Haskell because it needed to be small, fast, but safer than C.

On the other hand, projects like this come in handy when someone inevitably brings up the tired old line of "are there any _real_ projects written in Haskell?".

It's only ~1500 lines, with comments.

  find Hbro -iname '*.hs' | xargs cat | wc -l

A little off-topic, why didn't you just do "xargs wc -l"?

Because of this:

     Any arguments specified on the command line are given
     to utility upon each invocation, followed by some
     number of the arguments read from the standard input
     of xargs.  The utility is repeatedly executed
     until standard input is exhausted.

In other words, if the argument list is too long, xargs will chunk the input and call the program repeatedly. This means that on very large projects, 'wc -l' will be called several times on subsets of the files, and you will get an incorrect total listed at the bottom.

putting a 'cat' in between fixes that. 'cat a b; cat c d' is equivalent to 'cat a b c d', so the chunking doesn't matter. And wc -l can just read from stdin without worrying about how many files there are.

Continuing on this off-topic, this construct is not optimal and can possibly break if one of the filenames has some funky characters (spaces, line breaks, carriage returns, unprintable characters, ...). This happens (unfortunately) more often than you think, and it's a very good idea to learn how to used these commands defensively.

Basically you have two choices, depending on the Unix you're using:

- find ... -print0 | xargs -0 wc -l

- find ... -exec wc -l {} +

The second one is defined by POSIX and, as far as I know, works on every Unix except for OpenBSD (who only implemented this feature starting version 5.1 in 2012).

The first one is non-POSIX so several Unices do not implement -print0.

To the best of my knowledge, GNU find should work fine with both.

More info: http://unix.stackexchange.com/a/41745/4098

Ah! Didn't realize wc provided a total. I had used the "cat | wc" bit for scripts to just grab the number. Thank you.

Come back when they replace WebKit with something written in Haskell. I could write a "browser" in about 50 lines of C if I wanted.

Uzbl isn't really written in one language. uzbl-core (the Webkit wrapper) is written in C, the event-processing framework and tabbed-browsing wrapper are written in Python, and much of the functionality is handled by external scripts written in sh and javascript.

The difference has nothing to do with the language; hbro is taking a very different approach to configuration and integration. (e.g. uzbl does IPC using FIFOs and sockets; hbro is using ZeroMQ. uzbl is extensible with external scripts; hbro seems to be extensible using Haskell.)

(I'm the maintainer of uzbl. k0ral used to be involved with uzbl, and I'm sure hbro has learned from uzbl's mistakes.)

Reply on news.ycombinator.com