Live data from Hacker News

Ask HN: What is the most beautiful piece of code you've ever read?

news.ycombinator.com

331–340 of 394 posts

Re: Ask HN: What is the most beautiful piece of code you've ever read?

#333

Earlier quoted context omitted.

What is a maze? One could argue that if the user perceives a maze, then it produces a maze.

> One could argue that if the user perceives a X, then it produces a X. This can be stretched to turn anything into anything else. For example, why can't this comment be a maze? In that case 10 REM; 20 END is my even shorter, more elegant maze program because I see a maze in it. Some constraints that are typically implied when people say "computer generated mazes": - They are solvable (have a start and end) - OR they…

> This can be stretched to turn anything into anything else. For example, why can't this comment be a maze?

Name one person who perceives your comment as a maze.

It must be perceived as a maze by people for it to apply.

As it stands, I’m not sure if people perceive your comment as a maze.

Maybe theoretically there’s a nonzero number of people who perceive the comment as a maze. But unless your audience is those few people, there wouldn’t be much utility in it. In the OP’s example this maze perception is not only highly widespread but it’s also leveraged for a particular intended effect.

Re: Ask HN: What is the most beautiful piece of code you've ever read?

#334
post #240

Earlier quoted context omitted.

Everything is an illusion. \s and /s are just liquid crystal pixels on the screen, filtering some light. However it's easier to say that if something has a name and you can identify it, then it's probably that thing. I see a maze it means it's a maze :)

> I see a maze it means it's a maze :) I'd suggest to not go bar-hopping in Thailand with that mindset...

Nice to see a bit of casual transphobia on hackernews.

Re: Ask HN: What is the most beautiful piece of code you've ever read?

#335
post #23

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

ohh wow, I remember being fascinated with Pascal program that makes snow fall. Basically, it was white dots on a blue background in an infinite loop. :)

Somewhere I have a copy of a BASIC program I typed into my TRS-80 Color Computer as a kid, from an issue of K-Power magazine.

I don't recall if it was one of the full issues, or one of the "insert issues" found within Family Computing of the era.

It was a special kind of "snow fall" generator; IIRC, there were only a couple of versions, one for the Apple IIe and the other for the PCjr - I likely used the PCjr version for the conversion since the BASIC language was nearly identical between the PCjr and my CoCo 2.

What was special was that it managed to seemingly move hundreds of pixels relatively rapidly on the screen; now, this might not seem like such a feat, but it really was considering we're talking about a computer system running an interpreted BASIC program, with a max speed below 1 MHz in standard mode (0.89 MHz - there was a so-called "speedup poke" that "doubled" the speed - POKE 65495,0 if anyone cares).

I don't recall what trick it used - or if it really used anything special at all - but I do remember being impressed by that bit of code.

Re: Ask HN: What is the most beautiful piece of code you've ever read?

#336
post #147
post #75

Earlier quoted context omitted.

Wow! This is really cool. I just entered it quickly in a C64 emulator and it ran, creating a maze. Not sure, whether it would be a solvable one, but it is interesting to note, that the paths are really connected!

> the paths are really connected! What do you mean by that?

The paths make sense. I.e. you got uninterrupted lines, surrounded by walls, so it is a real maze and not just a lookalike or partial maze. Oh, and it's a-maze-ing! :-)

Re: Ask HN: What is the most beautiful piece of code you've ever read?

#337

Bash fork bomb (do not run, this will crash your system if it's not configured properly): :(){ :|:& };:

I like the Windows one, too. It looks a lot simpler as well. %0|%0

I don't know Windows scripting, but that looks like something you'd have to put in a file and call for it to work, instead of just running that on the command line. You can do the same thing on Unix systems. Writing

  $0|$0
on a file and running it should also work as a fork bomb.

Re: Ask HN: What is the most beautiful piece of code you've ever read?

#338
post #82
post #24

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…

> It silently transforms an O(1) space algorithm into an O(n) space one, and adds an enormous constant time overhead.

It doesn't silently transform O(1) to O(n), the code is explicitly O(n^2) space worst-case. The only 'silent' transformation that could happen here is an optimization to improve performance. Also, I don't know where you got the 'enormous constant time overhead' part.

> Algorithms that are optimal under the mutable data assumption are different than algorithms that are optimal under the constant data assumption.

A normal programmer wouldn't be defining writing their own sort functions. A normal Haskell programmer would understand mutability in Haskell.

> Performant programming in Haskell requires a much more intimate understanding of the underlying architecture than performant programming in, for instance, C++.

It really depends on what you're writing and how much performance you actually need. Implementing a moderate-complexity parallel data processing algorithm in Haskell may result in a slightly slower but much simpler implementation than C++. An implementation of the same complexity in C++ may be slower than Haskell. Writing performant, parallel, safe code for a moderately complex algorithm in C++ is far from easy.

Re: Ask HN: What is the most beautiful piece of code you've ever read?

#339
post #7

John Carmack's Fast Inverse Square Root: https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv... . The first time I really and truly felt that people approach problems differently from how I, by default, go about them.

The most beautiful piece of code you've ever read contains a magic number with the comments "evil floating point bit level hacking" and "what the fuck?"... you're a madman.
Post reply on HN