6 ms·

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 objec

by pestaa 14y ago

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.

dons 14y ago
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.
- _delirium 14y ago
  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.
mjhoy 14y ago
It's only ~1500 lines, with comments. find Hbro -iname '*.hs' | xargs cat | wc -l
- aoe 14y ago
  A little off-topic, why didn't you just do "xargs wc -l"?
  - mjhoy 14y ago
    Ah! Didn't realize wc provided a total. I had used the "cat | wc" bit for scripts to just grab the number. Thank you.
  - babarock 14y ago
    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 http://unix.stackexchange.com/a/41745/4098
  - ori_b 14y ago
    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.
- tedunangst 14y ago
  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.
dan00 14y ago
"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.
AndrewO 14y ago
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.
- dons 14y ago
  xmonad was written in Haskell because it needed to be small, fast, but safer than C.
tree_of_item 14y ago
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?".
bct 14y ago
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.)

by pestaa 14y ago

dons 14y ago

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.

_delirium 14y ago
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.

mjhoy 14y ago

It's only ~1500 lines, with comments. find Hbro -iname '*.hs' | xargs cat | wc -l

aoe 14y ago
A little off-topic, why didn't you just do "xargs wc -l"?
- mjhoy 14y ago
  Ah! Didn't realize wc provided a total. I had used the "cat | wc" bit for scripts to just grab the number. Thank you.
- babarock 14y ago
  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 http://unix.stackexchange.com/a/41745/4098
- ori_b 14y ago
  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.
tedunangst 14y ago
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.

dan00 14y ago

"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.

AndrewO 14y ago

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.

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

tree_of_item 14y ago

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?".

bct 14y ago

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.)