[HN Gopher] The hardest program I've ever written (2015)
___________________________________________________________________
The hardest program I've ever written (2015)
Author : jacobedawson
Score : 35 points
Date : 2025-10-29 05:14 UTC (3 days ago)
(HTM) web link (journal.stuffwithstuff.com)
(TXT) w3m dump (journal.stuffwithstuff.com)
| sema4hacker wrote:
| > That handful of code took me almost a year to write.
|
| Formatting can be tough. See Knuth's extensive bug list for TEX
| from 1987 at https://yurichev.com/mirrors/knuth1989.pdf to see
| the kind of tarpit one can get trapped in.
| cjfd wrote:
| One can talk about about the technical side of writing a code
| formatter, but what about the ethical side? Automatically
| formatted code looks kind of okay but never great. Uniformity for
| the sake of uniformity. It is not a very humanistic.
| chaps wrote:
| This might just be the most HN comment I've ever read.
| noir_lord wrote:
| It's certainly an interesting take.
| 7thpower wrote:
| There seem to be a lot of posts that attempt to cast
| seemingly mundane things through an "ethical" lens and I
| often wonder what the authors of them must be like in real
| life.
| o11c wrote:
| There are 3 major problems with automated code formatters:
|
| * Handling of _multiple_ newlines to break sections, or none to
| group related functions (e.g. a getter with a setter).
| Sometimes it 's even best to _move_ functions around for better
| grouping.
|
| * They don't factor out an expression into a separate variable.
|
| * They destroy `git blame`. This one is avoided if the tooling
| has always enforced formatting.
| layer8 wrote:
| Regarding the second one, a formatter shouldn't be changing
| the AST. At most inserting parentheses/braces/semicolons for
| clarity, which doesn't change the AST structurally (or,
| depending on one's definition of "AST", doesn't change it at
| all).
| dragonwriter wrote:
| > * They don't factor out an expression into a separate
| variable.
|
| That's...not formatting, and there's probably no good
| deterministic rule for when to do that, anyhow.
| mjsir911 wrote:
| yeah, I've come to terms that I mostly do programming-as-an-art
| and that includes how my code is structured, and I'm on exactly
| the same page.
|
| In pragmatic business environments it's not worth the fuss but
| I never feel great about anything I make in those kinds of
| environments anyways, and I always appreciate being able to
| shine when there's no enforced code formatting.
| bartekpacia wrote:
| weirdest take on code formatting I've ever read
|
| imho uniformity of what the code looks like > some single
| person's opinion
|
| it's so satisfying to me when I just run "gofmt" and know the
| thing is formatted well.
| ncruces wrote:
| _Gofmt 's style is no one's favorite, yet gofmt is everyone's
| favorite._
| andrewflnr wrote:
| "Ethics" is overdramatizing it. The goal of a code formatter is
| not greatness, but adequacy, in a context where the code is a
| means to an end. They're particularly used in contexts where
| you may be sharing the project with people who don't care about
| formatting at all. Forcing me to work in or clean up the messes
| of my lazy co-workers is also, I would suggest, not very
| humanistic.
|
| Feel free to not use one in your art projects.
| wiseowise wrote:
| Humanistic is bikeshedding for weeks over new lines and "I feel
| like this is more readable".
| nkrisc wrote:
| What is the ethical dilemma presented?
| jibal wrote:
| You surely forgot the "/s".
|
| The uniformity is not merely for the sake of uniformity.
| b4ckup wrote:
| I once wrote a formatter for powerquery that's still in use
| today. It's a much simpler language and I took a simpler
| approach. It was a really fun problem to solve.
| PaulKeeble wrote:
| About the worst job on any enterprise software project is the PDF
| output, they always end up doing it for emails or something else
| and its a never ending list of bugs. Text formatting is a never
| ending list of problems since its so got a lot of vague inputs
| and a relatively strict output. Far too many little details go
| wrong.
| mmaunder wrote:
| Is solving formatting made easier with the use of LLMs?
| jibal wrote:
| No.
| mmaunder wrote:
| A downvote and curt response. Seems I've touched a nerve.
| Which makes sense, since what I'm asking is if this high
| effort craftsmanship is potentially being, or has been
| replaced by LLM's. It seems both a shame and disrespectful if
| that has occurred. Perhaps it is better to live in denial.
___________________________________________________________________
(page generated 2025-11-01 23:00 UTC)