Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 394 posts

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

#92

Post by cool-RR »

why_only_15 wrote: post #53
Shoop wrote: post #45

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]

You don't need the list comprehension for python - just 2 * sum(range(1, 13))

And drop the 1, too

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

#93

Post by brokencode »

nwallin wrote: post #82
switz wrote: 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…

I don’t see how this is a great example of how functional programming sucks. It is easy in any programming language to build a slow sorting algorithm. The fact that you need to use different algorithms with immutable data is irrelevant. You need to use different algorithms for pretty much any type of data structure.

Functional programming makes a different set of tradeoffs than imperative programming. You have to work harder to get peak performance, but in many cases it is actually quite performant. Just look at how fast Elm is for web applications, and how that approach allows for a time-traveling debugger and virtually no crashes.

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

#94

Post by [deleted] »

_bxg1 wrote: post #64
throwaway_n wrote: post #61

Earlier quoted context omitted.

This is O(n^2) though

All of JS's list processing functions are pretty inefficient, since at the bare minimum each one creates and copies to a new array (as opposed to, say, Rust iterators). You use them when elegance is more important than performance; N^2 is fine when N is eight.

[deleted]

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

#95

Post by mceachen »

Hnrobert42 wrote: post #88

Along these lines, does anyone else have the experience of reading some code and thinking “Damn this is good. So clear, so well formatted,” only to realize moments later with a bit of embarrassment that it is your own code?

Or, worse, "who was the idiot that wrote this?"

... git blame ...

oh. me.

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

#97

Post by 11235813213455 »

# Permutations of a list:

- haskell:

  perms [] = [[]]
  perms xs = [ x:ps | x
- js: (using https://github.com/tc39/proposal-slice-notation for conciseness)

  const perms = xs => xs.length === 0
    ? [[]]
    : xs.flatMap((xi, i) => perms([...xs[0:i], ...xs[i+1:]).map(xsi => [xi, ...xsi])
# Cartesian product of 2 or n lists

- haskell:

  cart2 xs ys = [(x,y) | x  [[a]];
  cartn [] = [[]]
  cartn(xs:xss) = [x:ys | x
- js:

  const cart2 = (xs, ys) => xs.flatMap(x => ys.map(y => [x,y]));

  const cartn = (...args) => args.reduce((yss, xs) => yss.flatMap(ys => xs.map(x => [...ys, x])), [[]]);
  // or recursive
  const cartn = (xs, ...xss) => xss.length === 0
    ? xs
    : xs.flatMap(x => cartn(...xss).map(y => [x,y]))
Post reply on HN