81–90 of 394 posts
The SQLite source tree and DRH code in general are truly piece of art. Almost every line of code is carefully commented. Despite the complexity of the project, you'll learn a lot of practical concepts including expression tree generation, bytecode execution, how to test your code and so forth.
The one that blew my mind when I was in college was a simplified version of quicksort in Haskell. It's just so elegant and clean. quicksort :: Ord a => [a] -> [a] quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter ( = p) xs Now surely someone may come along and point out how this isn't a true quicksort[0] because it doesn't partition the elements in place, but…
This implementation of quicksort is actually a great example of why functional programming sucks. It silently transforms an O(1) space algorithm into an O(n) space one, and adds an enormous constant time overhead.
Algorithms that are optimal under the mutable data assumption are different than algorithms that are optimal under the constant data assumption. So a normal programmer might sort via quicksort in Haskell because it's the optimal sort in imperative languages even though naive Haskell quicksort is objectively worse in every way than naive Haskell mergesort.
Performant programming in Haskell requires a much more intimate understanding of the underlying architecture than performant programming in, for instance, C++. And that's a very low bar.
I'd have to think long and hard for the most beautiful code I've ever read, but I think the classic K&R "strcpy" comes pretty close: void strcpy(char *s, char *t) { while (*s++ = *t++); } It's short, elegant, and quite readable to the trained eye–a bit sharp too, but if you use it right it's quite functional.
Then t would never be able to overflow s (nor even eat its null terminator)
TeX
Exploit codes are often the most beautiful code I read, they are usually small and take some dazzling brilliance to push the computer and make it do what it wasn't. I can remember the first code that showed how to exploit IFS, race conditions via symlink, the classic "smashing the stack", RTM's worm. Beauty of a code to me has nothing to do with the formatting, comments, documentations, but everything to do with the…
I had absolutely no idea until now that RTM co-founded y-combinator. I remember him from mentioned in Bruce Sterling's The Hacker Crackdown and Clifford Stoll's The Cookoo's Egg as well as an occasional Phrack article.
Earlier quoted context omitted.
Cool one liner! Here's some other languages: Python: 2 * sum([x for x in range(1, 13)]) Haskell: 2 * sum [1..12]
What’s quite elegant about Ruby (in and of itself, not in comparison to your examples) is how consistently it is implemented using its own simple set of core features, with very little magic or syntactic sugar. reduce , Enumerable , what the & operator is doing etc. What’s so challenging about Ruby is how the language can be abused by library vendors to make all kinds of surprising magic and homegrown syntactic sugar…
Honestly, I don't think this has much to do with Ruby. This a consequence of using reduce or any other higher-order functions, which come from functional programming, and are now available in almost all modern multi-paradigm programming languages (including Python and Haskell).
I you like this kind of constructs, you should definitely learn a functional programming language, you'll love it.
Someone once posted a C program here on HN, where each line, even the comments, seemed to "line up" in 6- or 8- character blocks with a space in between. It made the whole program look sort of like a table. I felt it was sort of like poetry. I unfortunately no longer have a link to it, and once looked very hard but couldn't find it. I would be extremely appreciative of someone else saw it and had a link. If I recall…
For me it's a BASIC one-liner which generates mazes 10 PRINT CHR$ (205.5 + RND (1)); : GOTO 10 I found this specific one via slashdot[1], but something similar, which I've never managed to find/replicate, was used to generate mazes on the Atari 800 XL at my school when I was a kid. [1] https://developers.slashdot.org/story/12/12/01/1847244/how-d...
This is the art of illusion.
The one that blew my mind when I was in college was a simplified version of quicksort in Haskell. It's just so elegant and clean. quicksort :: Ord a => [a] -> [a] quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter ( = p) xs Now surely someone may come along and point out how this isn't a true quicksort[0] because it doesn't partition the elements in place, but…
Quick sort comes with a steep penalty. Worst case is O(n^(2)). The reason quicksort is good is because it's in place. Once you throw away the in place aspect of quick sort, it's straight up bad. This implementation of quicksort is actually a great example of why functional programming sucks. It silently transforms an O(1) space algorithm into an O(n) space one, and adds an enormous constant time overhead. Algorithms…
Please tell me what imperative quicksort algorithm has O(1) space. All versions I've seen and could recall use recursion; although each recursive call uses O(1) space, in the worst case of bad pivot element selection each recursive call would only really sort one element resulting in a worst-case O(n) space. Use of randomization would result in a high probability of choosing a good pivot element, but even then you can expect approximately O(log n) space.
Also would like to see why you think the Haskell version has enormous constant time overhead. Where do you think this overhead comes from? If you are comparing to an equivalent program in C++ then sure allocations and stuff, but compared with the typical Haskell list-processing programs I don't see any significantly larger overhead.