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

Software development topics I've changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

231–240 of 788 posts

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

#231

Post by skeeter2020 »

skydhash wrote: post #94
hliyan wrote: post #68

Earlier quoted context omitted.

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 anythi…

The value of software is both what it does now (behavior), and what you can get it to do later (structure). What you described as design and the compiled artiface is the behavior. The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it…

experience gives you some possible ideas for how it will be used in the future, but after a long time I'm coming to the position you're fooling yourself if you think you can predict where with any accuracy. It's still valuable and important to try, just not as critical to be right as I used to think. Example: I've completely flip-flopped from interface simplicity to implementation simplicity.

I agree that a house is a bad analogy, for your reasons and because you can "live" in software that as a building would not be fit for human habitation.

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

#233

Post by bluGill »

VyseofArcadia wrote: post #206
Kichererbsen wrote: post #179

Earlier quoted context omitted.

Most programming is actually figuring out what already exists and what (and more importantly: why) the requirements are. This is best done long before a single line of code is written. I think the author is taking a wider view of "programming" than the actual writing of code as the end product. Some of the most important work I've done is spend the time to argue that something doesn't need to be done at all.

> what (and more importantly: why) the requirements are Maybe in a startup? My experience as an IC in larger, more established companies is the requirements are dictated to you. Someone else has already thought carefully about the customer ask, your job is just to implement, maybe push back a little if the requirements they came up with are particularly unreasonable.

If you dig deep you discover they have figured out some requirements in detail, but there is a lot missing. Is this new feature that last one in that line, or will there be more options in the future? Is this new feature really going to be used - many times we have put large effort into features only to discover no customer used them (as evidenced by the critical bug that made the feature unusable outside of the test lab that nobody complained about until 4 years had passed). These things drive how you engineer the thing in the first place.

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

#234

Post by lucasoshiro »

cies wrote: 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…

> to C++ to Java to Ruby to JS (also server-side) and Python

I feel that languages are going back to static typing. Newer languages such as Go, Rust, Kotlin, Swift, Dart, Nim etc are all statically typed (I can't remember a language from the last decade that is dynamically typed).

Even some dynamically typed languages are moving towards a more static typed system: for JS we have TS, and for Python we have type hints

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

#235

Post by catlifeonmars »

ghc wrote: post #214
latexr wrote: 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…

To reduce your argument to its essence, you're saying typesetting is part of the craft of writing. I've yet to meet an author who believes this (other than enjoying editing their own work as output from a typewriter), and I think the same broadly applies to code. It's not that everyone thinks these things are unimportant, it's that caring deeply about doing them a particular way is orthogonal to the craft. It's somet…

I think there are accessibility aspects to formatting. Specifically to different formatting.

Not sure the typesetting analogy is the best, but typesetting absolutely matters for readability. Authors don’t need to care about it because typesetting is easy to change (before printing) and because publishers spend time caring about it —- all before it ends up in the hands of readers.

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

#236

Post by bluGill »

gmm1990 wrote: post #150
ZaoLahma wrote: post #82

> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions th…

I assume there are people who are able to have those eureka moments before writing any code. I definitely write a lot of code before figuring out the final design but always think I should be designing more.

Always plan to throw one away. You will, so best to plan for it. (paraphrasing Fred Brooks)

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

#237

Post by lmm »

AnimalMuppet wrote: post #220
lmm wrote: post #181

Earlier quoted context omitted.

Because you can't capture the evaluation of a function as a value, or write the type of it. E.g. try to write a generic function that takes a list and a callback, and applies the callback to every element of the list. Now what happens if your callback throws a checked exception? It doesn't work and there's no way to make it work, you just have to write another overload of your function and copy/paste your code. Now w…

Make the signature of your generic callback "throws Throwable". It's generic; it should never care about the specific types that the callback can throw. (Except that then you have to decide what your generic function is going to do if the callback throws an exception...)

> Make the signature of your generic callback "throws Throwable". It's generic; it should never care about the specific types that the callback can throw.

> (Except that then you have to decide what your generic function is going to do if the callback throws an exception...)

Exactly. Presumably you don't want to handle them and want to throw them up to the caller. But now your function has to be "throws Throwable" rather than throwing the specific exception types that the callback throws.

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

#238

Post by davidw »

ZaoLahma wrote: post #82

> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions th…

Yeah, the other stuff seems sensible or at least "Ok, I can see that", but I definitely disagree with this one.

You should spend time thinking about stuff beforehand, sure, but getting your hands dirty is also going to reveal things.

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

#239

Post by noahjk »

desdenova wrote: post #152
Retric wrote: post #77

Earlier quoted context omitted.

> the formatting and conventions of the blueprint Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information. I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenat…

Fortunately nowadays formatting issues can be delegated to autoformatting in any popular language. Some people still argue over autoformatter parameters, but then people will always find a bike shed to argue about.

Maybe a new paradigm for code formatting could be local-only. Your editor automatically formats files the way you like to see them, and then de-formats back to match the codebase when pushing, making your changes match the codebase style.

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

#240

Post by psychoslave »

hliyan wrote: post #68
latexr wrote: 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 anythi…

>I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization.

Maybe not at the same level, but code organization is also a design.

I don’t care that much about the exact linter rules applies (but I do prefer blue, hmm, nooo). But getting rid of merge conflicts that come from lake of common linter rules, this is a great pipeline process improvement, and this is some kind of code contribution pipeline design.

Post reply on HN