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

431–440 of 788 posts

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

#431

Post by maleldil »

hkwerf wrote: post #31
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 is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that. For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definite…

> I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.

If you don't already, you should run `cargo fmt --check` in CI and block PR merges until it passes. You can also run it in a pre-commit hook, but you can't be sure everyone will set that up.

Automating such types of decision is great but moot if others have to opt into it.

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

#432

Post by igouy »

9rx wrote: post #272
gorjusborg wrote: post #38

No, objects aren't generally 'good', unless you think keeping multiple state machines in sync is 'good'. OO is not evil, but it also shouldn't be your default solution to everything. Also, who is this person? I immediately distrust someone who calls themselves 'a pretty cool guy'. That's for the rest of us to decide.

> OO is not evil, but it also shouldn't be your default solution to everything. With Smalltalk and Objective-C both being effectively dead at this point, that really only leaves Ruby (and arguably Erlang) as the only languages that are able to express OO. And neither of those languages are terribly popular either. Chances are it won't be your default solution, even if you want it to be.

J ... J ... Java.

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

#433

Post by maccard »

Retric wrote: post #77
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 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…

This is the best argument I've ever heard for editorconfig, commiting a standardised format to the repos, and viewing it in whatever way you want to view it on your own machine

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

#434

Post by dfee »

whstl wrote: post #277
dtquad wrote: post #168

>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very…

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 with a dev server? Because it also somehow works non-js artifacts like CSS and image imports?

Ultimately, I've found the world of Vite + ESNext imports to be a world of frustration and pain. And, I really want to like Deno, and a lot of it is magical, but ultimately, there's just some splitbrain stuff going on with Deno's concept of a monorepo and their inability to commit to their public projects (e.g. Fresh) leaves me concerned it's risky to build on top of.

(ok, that turned into a rant, but there are some questions in there.)

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

#435

Post by bluGill »

hasley wrote: post #389
bluGill wrote: post #309

Earlier quoted context omitted.

I disagree. The real value of exceptions is you can skip 6 levels of functions that have lines like status = DoThing(); if(status != allIsWell) {return status;} C++ embedded for a long time has said don't use exceptions they are slow. However recent thinking has changed - turns out in trivial code exceptions are slow but in more real world code exceptions are faster than all those layers if checks - and better yet yo…

Do you have any references for that? I used to avoid exceptions on small Cortex M0/M3 devices as well.

Khalil Estell has some great work on that. https://www.youtube.com/watch?v=bY2FlayomlE is one link - very low level technical of what is really happening. He has other talks and papers if you search his name.

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

#437

Post by zaphar »

bluGill wrote: post #311
zaphar wrote: post #294

Earlier quoted context omitted.

The counter point here is that at least with Checked Exceptions you know only those 20 functions are part of the code path that can throw that exception. In the runtime exception case you are unaware about that 21'st function elsewhere that now throws it and it's not in the correct handling path anymore. You have no way to assert that the error is always correctly handled in the codebase. You are basically crossing y…

Like I said, the implementation is wrong. Adding an exception to that 21st function, and then that whole call chain as well ends up being a lot of work. Sure you eventually find the place to handle it, but it was a lot of effort in the mean time. It gets worse. Sometimes we can prove that the 21st function because of the way it is calling your function can never trigger that exception, but still it will need code to…

The Rust Result type with accompanying `?` operator and the `Try*` traits are how you implement exceptions correctly. It makes it easy to model the error domain once in your trait implementations and then the `?` does the rest of the work.

You could imagine something similar with Exceptions where there is simple and ergonomic way to rethrow the exception into your own error domain with little to no extra work on the part of the developer.

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

#438

Post by kflgkans »

dtquad wrote: post #168

>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very…

If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me.

Up until roughly 4-5 years ago I was doing small front-end React apps on the side (I'm a backend engineer) and was feeling very productive with class components. They made sense to me, concerns were nicely separated, and I felt I could reason pretty well about what was called when and how state was manipulated.

Then hooks came around, I tried them a few times, but I just felt so lost. Suddenly everything is intermingled in one function and we're using side effects to react to changes and manipulate state. I could no longer understand when which code was executed, and especially following and manipulating state became impossible for me.

The projects I already, I kept with class components. Haven't done any new front-end projects since then.

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

#439

Post by 9rx »

igouy wrote: post #432
9rx wrote: post #272

Earlier quoted context omitted.

> OO is not evil, but it also shouldn't be your default solution to everything. With Smalltalk and Objective-C both being effectively dead at this point, that really only leaves Ruby (and arguably Erlang) as the only languages that are able to express OO. And neither of those languages are terribly popular either. Chances are it won't be your default solution, even if you want it to be.

J ... J ... Java.

Patrick Naughton came from the Smalltalk world, so Java is definitely inspired by Smalltalk, but he didn't bring along the oriented bits. Its object model is a lot closer to C++'s. To have objects does not imply orientation.

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

#440

Post by mands »

corytheboyd wrote: post #424
pjc50 wrote: post #345

Earlier quoted context omitted.

C# half-fixes this with its nullable annotations. I say half-fixes, because the boundary between code that supports them and code that does not is leaky, so you can make a mistake that leaks a null into a non-nullable variable. If you build an entire program with nullability checking on it's pretty great, though.

Java, or at least Lombok, seems to have a @NonNull annotation that does what I want— cause code not to build that fails the check, and forces propagation of the annotation. Reality does indeed feel exactly like what you mentioned with C#, though. The annotation is going to be missing where it’s needed most unless something forces the whole project to use it.

check JSpecify (https://jspecify.dev) - it's the standardised null annotation package for Java. Intellij understands the annotations so you generally get decent null-checking across your codebase.

Even better, apply at the package level via `package-info.java` (unfortunately sub-packages need to be individually marked as well)

  @NullMarked
  package com.foo;

  import org.jspecify.annotations.NullMarked;
Post reply on HN