Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

551–560 of 788 posts

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

#552

Earlier quoted context omitted.

This is what we did with clang-format on our code base. The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.

*cough*clang-format off*cough*

Ha, yes. I started doing that but then lost the will to continue.

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

#553
post #84
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…

I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, th…

I don't know that we'll ever be able to agree on "global standards" though. Software is too specialized for that.

The only software standard that I'm reasonably familiar with is https://en.wikipedia.org/wiki/IEC_62304 which is specific to Medical Devices. In a 62304-compliant project, we might be able to do something like your example, but it could take a while. OTOH, I'm told that my Aviation counterparts following DO-178 would almost certainly be able to do something comparable.

It is going to be very industry dependent, where "industry" means aviation, or maritime, or railroad, or Healthcare, etc... Just "software" is too general to be meaningful these days.

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

#554
post #214

Earlier quoted context omitted.

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…

More than one writer refuses to use a computer, preferring typewriters. Harlan Ellison learned how to repair typewriters after he could no longer find anyone to fix his. Stephen King wrote Dreamcatcher with a fountain pen. Authors totally obsess over details that seem irrelevant to people outside that craft.

There is a class of people who refuse to see computer programming as an art.

They try to shoehorn it into being an engineering discipline and comparing it to authoring a book (something you can't give timelines on or T-Shirt size) probably horrifies them.

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

#555
post #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 anythi…

sowhatyouresayingisthatyoureequallyhappyeditingjavascriptinitsminifiedartifactformastheoriginalcode?imeanifallthatyoucareaboutisthatyourwordsarecorrectlyinterpretedbythemachinetheresnovalueinmakingsurethatyourcodeisreadableandusablebyanotherhumanbeingamiright?

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

#556
post #371

> Gradual, dependently typed languages are the future What's that? Idris is dependently typed. > Gradual typing is a type system that lies inbetween static typing and in dynamic typing. Some variables and expressions may be given types and the correctness of the typing is checked at compile time and some expressions may be left untyped and eventual type errors are reported at runtime. That sounds miserable. I can't s…

Imagine adding types to a legacy JavaScript codebase. You can turn everything to valid TypeScript by annotating `any` everywhere, then you can gradually add types here and there.

Or imagine writing Rust with `Rc` everywhere and then using the borrowing style on the hot path.

I can see where the author is coming from, but sadly a difficulty is that dependently typed languages often require the programmer to prove type equality during type checking. It's hard to do if the information is not complete.

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

#557

> You literally cannot add too many comments to test code In my opinion, almost every developer I've worked with who advocated for generous amounts of comments has overestimated their (and or others') ability to write good quality comments. Obvious ones like `a = b; // set a to b` while useless are also mostly harmless, but I've been lead astray by outright factually wrong comments, many more times than I can count.…

That’s why your comments should be on things you know to be factual like WHY you made a certain decision. Things like that cannot always be communicated by good variables and functions.

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

#559

Earlier quoted context omitted.

More than one writer refuses to use a computer, preferring typewriters. Harlan Ellison learned how to repair typewriters after he could no longer find anyone to fix his. Stephen King wrote Dreamcatcher with a fountain pen. Authors totally obsess over details that seem irrelevant to people outside that craft.

There is a class of people who refuse to see computer programming as an art. They try to shoehorn it into being an engineering discipline and comparing it to authoring a book (something you can't give timelines on or T-Shirt size) probably horrifies them.

Ah, the joys of overloading. Do you mean "art" as the high-brow stuff we see in galleries and are produced in volumes of dozens per artist-years? Or do you mean "art" as the more common stuff that's produced by artisans are the rate of dozens per week? Because to me it's more the latter -- I'm an artisan, not an artist.

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

#560
post #434
post #277

Earlier quoted context omitted.

5-10 years ago I was just skipping Webpack and Babel, and raw-dogging React.createElement in personal projects in order to be happy and maintain sanity. At work I would just push hard for alternatives like Parcel or Brunch. Now, with Vite I just don't mind the toolchain anymore, it just helps me instead of getting in the way. Similar to Go. All the problems I have now are of my own creation.

dumb question from someone re-entering the FE world: why is Vite necessary? My understanding is it basically strips the type information using Go (IIRC) where your typechecking is then a separate step (without transpilation). So feedback is more rapid. But, with tools like Deno or ts-node, where the type checking is apparently also off the hot path, why does Vite still exist? Is it because it connects file monitoring…

It is also a bundler and minifier and dead code tree-shaker. It combines all your modules into one file (or a few) for production. In development it doesn’t do the bundling part (for now — with Rolldown[0] replacing Rollup[1] in the future, bundling will be fast enough to do the same in dev and prod).

It also serves as an integration point for other kinds of tooling that involves processing or generating code. For example, the latest versions of React Router[2] (which now integrates Remix's features) and Tailwind[3] are designed primarily to be integrated into projects as Vite plugins.

[0]: https://rolldown.rs/

[1]: https://rollupjs.org/

[2]: https://reactrouter.com/home#react-router-as-a-framework

[3]: https://tailwindcss.com/blog/tailwindcss-v4#first-party-vite...

Post reply on HN