Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

61–70 of 788 posts

Re: Software development topics I've changed my mind on

#61
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style

Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it.

Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.

Re: Software development topics I've changed my mind on

#62
post #52
post #39

Earlier quoted context omitted.

Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy an…

I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code. 80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't real…

Functional code is more chained and need more space often. Descriptive names are better; tends to be longer. Buy ultrawide.

80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable.

200 is great.

Re: Software development topics I've changed my mind on

#63
post #52
post #39

Earlier quoted context omitted.

Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy an…

I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code. 80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't real…

Reading vertically is much faster than reading horizontally, so I think 80 is a good soft limit. In some contexts it's hard to not go over it sometimes, e.g. in Java where it's not uncommon with very long type and method names.

Re: Software development topics I've changed my mind on

#64
post #2

> Java is a great language because it's boring [...] Types are assertions we make about the world This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. In brief for non-Java folks: Checked Excepti…

Checked exceptions as an idea are great (Nim’s usage of something similar is excellent) but yeah Javas particular implementation was annoying and easy to avoid, so most did.

Re: Software development topics I've changed my mind on

#66

It felt good to read someone who thinks like me, honestly. Also the observation of "The trouble with functional programming is functional programmers" is absolutely correct . This needs to be said more. Way more. P.S.: You can ask why, and I can answer honestly, without hostility.

I think trying to fit everything into the same lens is usually the real problem. Functional programming is a great methodology for a lot of things, but there are many ways to design things. Chances are really good that something elegantly written in prolog won't be as elegant in scheme or java, and vice versa.

Re: Software development topics I've changed my mind on

#67
post #6

> Gradual, dependently typed languages are the future I really interested why the author thinks this. I've seen the general sentiment wrt "the future" go from C to C++ to Java to Ruby to JS (also server-side) and Python. My own sentiment went from Ruby to Haskell to, well, Kotlin I guess... I looked into Idris (dependently typed), but did not think it would fit the Overton window[1], to be a reasonable expectation fo…

Dependent typing is mainly just that feature of Typescript that `x: number | null` becomes just `x: number` inside an `if (x != null) { ... }` statement. If you dig deeper into the type theory, it gets really interesting and complicated because types themselves can start to include any arbitrary code. And that's where Idris comes in! But after doing a whole project on Idris in college, I agree it is way outside the o…

Narrowing, as TypeScript calls it, isn't dependant typing - it's basically just a form of pattern-matching over a sum type.

Re: Software development topics I've changed my mind on

#68
post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space.

I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.

Re: Software development topics I've changed my mind on

#70

It felt good to read someone who thinks like me, honestly. Also the observation of "The trouble with functional programming is functional programmers" is absolutely correct . This needs to be said more. Way more. P.S.: You can ask why, and I can answer honestly, without hostility.

I think trying to fit everything into the same lens is usually the real problem. Functional programming is a great methodology for a lot of things, but there are many ways to design things. Chances are really good that something elegantly written in prolog won't be as elegant in scheme or java, and vice versa.

Yes, this is one of the bigger (if not the biggest) problems. I don't think that imperative programming is the only or the best way, either.

The different approaches can and do transform some really ugly things in one paradigm to something really neat and joyful things in another.

But reaching that level of maturity or flexibility is rather hard as far as I can see, and it's honestly sad.

Post reply on HN