Hacker News Reader

Comment by tiffanyh | Hacker News Reader

For me, the answer is - The code that never existed.

Not to sound cheeky but eliminating code, is a beautiful thing. Less code is easier to maintain, understand, and faster to run. So the less code you can achieve, the better overall the software will be.

View on HN

This brings me to a very nice regular expression. It is the one being recommended in

    RFC3986 "Uniform Resource Identifier (URI): Generic Syntax"
    by  T. Berners-Lee, R. Fielding and L. Masinter

    https://tools.ietf.org/html/rfc3986

to parse an URI. Having seen so many regular expressions, that try to match it all, this regex tries to match as little as possible, while, at the same time, matches any string, because it matches no string. It does not define what to match, but what not to match and making every match optional.

According part from the spec:

    ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
     12            3  4          5       6  7        8 9

    The numbers in the second line above are only to assist readability;
    they indicate the reference points for each subexpression (i.e., each
    paired parenthesis).  We refer to the value matched for subexpression
    <n> as $<n>.  For example, matching the above expression to

      http://www.ics.uci.edu/pub/ietf/uri/#Related

    results in the following subexpression matches:

      $1 = http:
      $2 = http
      $3 = //www.ics.uci.edu
      $4 = www.ics.uci.edu
      $5 = /pub/ietf/uri/
      $6 = <undefined>
      $7 = <undefined>
      $8 = #Related
      $9 = Related

    where <undefined> indicates that the component is not present, as is
    the case for the query component in the above example.  Therefore, we
    can determine the value of the five components as

      scheme    = $2
      authority = $4
      path      = $5
      query     = $7
      fragment  = $9

One of my favorite RFCs for sure, and it's a beautifully simple and useful regex. It's a shame RFCs seem to have fallen out of fashion, the WHATWG URL spec is an unreadable mess of a monster, not least the parsing section: https://url.spec.whatwg.org/#url-parsing

Deleting code is a beautiful feeling. Python's new walrus operator has gotten a lot of hate recently, but a few days ago I was writing a script and realized I could get rid of a few lines (AND have my meaning be clearer) using the walrus operator. So satisfying.

As a fan of Erlang’s pattern matching, the walrus operator feels like an obvious win.

I do, however, resent Python 3 for removing pattern matching on tuples in function heads.

Reminds me of a saying I read from moderngpu library's wiki page, a highly optimized yet highly readable GPU basic primitive library: "Software is an asset, code a liability. On good days I'd add 200 or 300 lines to this repository. On great days I'd subtract 500." source: https://github.com/moderngpu/moderngpu/wiki/Introduction

The original `true` was a 0-byte executable file [0] (well, perhaps 1 byte for the newline character). Sadly, that is not longer the case.

[0] https://unix.stackexchange.com/questions/419697/why-are-true...

> For me, the answer is - The code that never existed.

> Not to sound cheeky but eliminating code, is a beautiful thing. Less code is easier to maintain, understand, and faster to run. So the less code you can achieve, the better overall the software will be.

Unless you think compressed/ minified code is beautiful, there must be additional factors involved other than minimizing LoC.

To me it's removing lines of code without affecting readability (or even improving it). Like when you don't know about a language feature so you implement a hacky version, then find out there's already a very elegant standard way to do it so you get to lance that hideous monstrosity you made off your code

https://github.com/kelseyhightower/nocode/blob/master/README... you're welcome

Reply on news.ycombinator.com