l0stman

Well, the wayback machine is your friend. http://web.archive.org/web/20111001124736/http://log.nadim.c...

I was just wondering if you've planned on open-sourcing the code since the very beginning or if the idea came much later. Anyway congrats on launching.

Well, played. For a couple of seconds I was wondering why I had this impression of deja vu then I found this (http://hackerne.ws/item?id=4692794). I burst out laughing.

I had to look up what the `:' operator does and it adds an element to the beginning of the list. So the last line should be

    split (left, right) x = if x<p then (x:left, right), else (left, x:right)

    qsort :: Ord a => [a] -> [a]
    qsort []     = []
    qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater
        where
                lesser = filter (< p) xs
                greater = filter (>= p) xs

I know nothing about Haskell but I don't think this code implements the original quicksort algorithm which sorts the input in-place. Moreover the two-pass of filter over the list and the concatenations cause unnecessary overhead. Thus, even if the sample code is simple and elegant, a real-world implementation would surely be a bit longer than the given example.

Just finished ``On Lisp''. This is an advanced Lisp book and shouldn't be your first one. It assumes some familiarity with the language so you're better of reading ``Practical Common Lisp'' first if you're diving into Lisp for the first time. The book focuses almost exclusively on advanced use of macros and metaprogramming.

Interestingly, I've also read SICP in parallel -- currently reading the last chapter -- and there's some overlap in the topics treated in the two books. I'm also walking through CLRS and TAOCP at the moment, albeit reading the latter with a slower pace compared to the former.

On the non-technical side, I'm reading ``Drawing with the right side of the brain'' by Betty Edwards. I've picked up this book since I've decided to resume drawing one year ago. I highly recommend it if you struggle to draw a realistic rendering of a real life object or a landscape.

Just add the following lines in your .bashrc:

    export GIT_PS1_SHOWDIRTYSTATE=yes
    export GIT_PS1_SHOWUNTRACKEDFILES=yes

Note also that there's a more feature complete version that accomplishes the same tasks in the contrib directory of git (http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/comple...).

It's implemented in bash but I use it with almost no modification with the Korn shell.

Actually I posted this article yesterday http://news.ycombinator.com/item?id=1624402 but I went unnoticed. The author was working on search feature for his Hex editor and tried to outperform GNU grep by using Boyer-Moore. After multiple attempts, he finally discovered the hard way all the tricks used by Mike Heartel to make GNU grep run faster than his implementation.

Thanks for sharing this, it was extremely brave of you to do so. Speaking of one's failures in public requires a high degree of courage. Besides, from reading your other posts on HN, I thought you were what I would generally consider a successful guy. But like you said, there's always a flip side in every situation.

Since this issue has been raised many times on HN, could you show the kind of queries that point back to Mahalo in the results. I use Google daily but it never happened to me.

My gut feeling is that it has something to do with Arc. Some people tends to think it's just a regular Lisp with shorter keywords and that there's nothing really innovative in it. The problem is that pg kept the code private for too long while advocating publicly the power of the language and criticizing Common Lisp.

So when he finally released it, some lispers were disappointed because they've been waiting for something really disruptive. And it backfired as most of the time, the harshest critics comes from your disappointed sympathizers.

That being said, I don't hang that much on IRC so I have no real back-story supporting this.

In SICP, I think they use this approach to simulate digital circuits. http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html...

Just in case you don't want to install Silverlight like me, you could paste the url of the video directly into mplayer. For example, you could play the first lecture with:

  mplayer mms://171.67.219.228/see/ainlpcs224n/cs224n-lecture01.wmv

To be fair, the part of Emacs implemented in Lisp looks nothing like poetry. I wouldn't qualify it as ``utter crap'' but it's a lot messier than I thought. Some of the default packages looks like straight C code translated verbatim to Lisp.

My take is that even if it's easier to screw things up in C, that doesn't mean that if you program in a higher level language, you'd automatically produce elegant code.

This article has been discussed before. The last submission is only 20 days old.

http://news.ycombinator.com/item?id=1191534

http://news.ycombinator.com/item?id=757204

Could you be more specific instead of just saying some vague statements without giving any information? What problems have you encountered on *BSD systems?

You said:

The United States, Canada, Australia, and New Zealand obviously turned out quite well largely modeling British systems of common law, trade, treaty, military organization, and government.

and

The African countries were much better under British Rule than non-British rule.

I'll ignore the fact that you're trying to mix together countries that have been independent for centuries with other ones which only acquired it roughly 50 years ago.

What I don't understand is your circular reasoning. If the rule under the British empire was that great, shouldn't the US and Canada be in a much worse state right now compared to that golden age? This seems to contradict your thesis.

And lastly, you seem to forget that most of the conflicts in Africa are due to the artificial borders imposed by colonialism. Some tribes like the Tutsi are spread across Rwanda, Burundi and Eastern Democratic of the Congo. Bring in the fact that most of these countries were governed by dictators largely supported by the former rulers and you'll see a cleaner picture of the situation.

There's some gross oversimplification in your reasoning. Just to cite a few.

Egypt? Incredibly wealthy under the British, not so much under self-governance.

You seem to forget that Egypt has a history of more than thousands years and was a superpower long before the British empire even existed. And after that, there was Persian, Greek, Roman, Arab and Ottoman occupation. Thus comparing the country's wealth during and just after the British colonialism is reductive. How about trying to do the same comparison throughout these periods and see under which one Egypt was at its peak?

I think you're overly optimistic about what's going on here and overlooks trolling. I don't know if the video was edited to not show the offending ones. But I'm pretty sure if this becomes a popular trend, you'd have to deal with more trolls than you'd like to.

Maybe you're right and there's some hidden potential behind all of this. But the cynic in me just imagines 4chan members drooling at the prospect of ruining a show with shocking images and videos.

Could you share the brilliant startup idea you come up with after seeing this video?

I wonder if this kind of immortality would be that great. Most of my motivations to do things now come from the time limit factor. If I were immortal with unlimited memory, I think I'd just procrastinate and continue to postpone all the tasks I have to accomplish just because I can.

I might be mistaken but I think davidw was referring to earlier attempts to delete the article on Wikipedia, not Hacker News.

Ficciones by Jorge Luis Borges is a must read. Especially ``The South'' at the end of the book.

http://en.wikipedia.org/wiki/Ficciones

There's no email in your profile. You should put it in the ``about'' field, the ``email'' field is not visible to other users.

Could you explain why have you decided to manage your own network. If I remember correctly, that wasn't the case in the early days of Weebly.

The instruction ``call _a'' pushes the address of the next instruction onto the stack.

If all you want is to group commands, you could use {...} instead of (...) so you don't have to spawn a subshell.

You can't expect people to be reasonable when it comes to language flamewar. Personally, I think weak advocacy is worse than no advocacy at all.

So why not create syntax that catches 99% of the cases for which you intend the language to be used and abolish the ability to create further syntax?

Although it's possible to create new syntax in Common Lisp via reader macros -- I don't think lispers recommend to extend the syntax. But when you miss a language feature, instead of fighting against the language, you could implement it. I don't remember exactly who said it in one the SICP video lecture, Harold Abelson or Gerald Sussman, but he said something like

Lisp is not good at solving a particular problem. What Lisp is good at is extending the language to solve a class of problems.

The problem with syntax is that it's difficult to use correctly with macros. It's no wonder that most introduction books to C warns against the pitfalls of using macros. Even the simple ones could bite you if you're not careful. Consider:

  #define DOUBLE(x)	(2*x)	/* should be (2*(x)) */
  #define MAX(a, b)	((a) < (b) ? (b): (a))

Even the last one is not immune against multiple evaluation problems if you try to evaluate MAX(a++, b). In Lisp you could avoid this by using gensym and local bindings. That being said, C macros and Lisp macros are completely different beasts. And I recommend reading ``On Lisp'' for advanced use of Lisp macros.

I just read Coders at Work and here's an excerpt from the interview of L. Peter Deutsch about this quote:

Seibel: I think Larry Wall described it as bowl of oatmeal with fingernail clippings in it.

Deutsch: Well, my description of Perl is something that looks like it came out of the wrong end of a dog. I think Larry Wall has a lot of nerve talking about language design -- Perl is an abomination as a language. But let's not go there. (...)