Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

151–160 of 788 posts

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

#151
Just personal opinions, I guess, I agree with most, but here are some I disagree with:

- There is no pride in managing or understanding complexity

Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity.

- Java is a great language because it's boring

That is if you write Java the boring way. A lot of Java code (looking at you Spring) is everything but boring, and it is not fun either.

- Most programming should be done long before a single line of code is written

I went the opposite extreme. That is, if you are not writing code, you are not programming. If you are not writing code on your first day your are wasting time. It is a personal opinion, but the idea is that without doing something concrete, i.e. writing code, it is too easy to lose track of the reality, the reality being that in the end, you will have a program that runs on a machine. It doesn't mean you will have to keep that code.

- Formal modeling and analysis is an essential skill set

Maybe that explains our difference with regard to the last point. Given the opportunity, I prefer try stuff rather than formalize. It is not that formal modeling is useless, it is just less essential to me than experimentation. To quote Don Knuth out of context: "Beware of bugs in the above code; I have only proved it correct, not tried it." ;)

- You literally cannot add too many comments to test code (I challenge anyone to try)

time++; // increment time

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

#152
post #77
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…

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.

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

#153
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…

Video game logic: Everyone worse than me is a noob. Everyone better than me has no life.

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

#154
post #151

Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. - Java is a great language because it's boring That is if you write Java the boring way. A lot of Java code (looking at you…

I agree with you, i'm much more on the "try stuff out" scale vs. formal methods. That being said, i've worked with people who are the other way and still very effective. I think this one is more of a trade-off or personality thing than something that's "true" or "false"

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

#155
post #8
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…

It was botched from the start because there's so many opportunities for unchecked exceptions as well. Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. Divide by zero. And so on. You also have a problem similar to "monads and logging": if you want to log from anywhere in your program, your logging function needs to be exception-tight and deal with all th…

Unchecked exceptions are just Java's weird way of what languages call panicking these days. They suck, but as long as you don't throw them yourself and catch them in a logical place (i.e. at request level so your web server doesn't die, at queue level so your data processing management doesn't lock up, etc.) you can usually pretty much ignore them.

The worst part about them is that for some reason even standard library methods will throw them. Like when you try `list.Add(1)` on a list without checking if said list is read-only. The overhead of having to read every single bit of documentation in the standard library just to be ahead of panicking standard methods is infuriating.

That's got nothing to do with the concept of checked/unchecked exceptions, though, that's just Java's mediocre standard library.

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

#156

> Typed languages are essential on teams with mixed experience levels I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.

I'm kind of wondering where the "mixed experience levels" part comes from. What is it about more homogeneously skilled teams that makes them less susceptible to the productivity boost that statically typed languages give in large code bases?

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

#157
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…

> They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. Syntactic sugar it needs is an easy way (like ! prefix) to turn it to a runtime exception. Procrastinating on exceptions is usually the correct thing to do in your typical business application - crash the current business transaction, log the error, return error resp…

The try/catch/rethrow model can easily be substituted by just adding a `throws` to the method. If you truly don't care, just make your method `throws Exception` or even `throws Throwable` and let the automatic bubbling take care of making you handle exceptions at top level.

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

#158
post #56

> ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables…

One job I had, we got handed a code base with at least 4 different reinventions of an ORM in it.

It became clear that each developer who'd worked on the code had written their own helpers to avoid direct SQL. It took a fair bit of persuading leadership, but the first task ended up being doing a huge reactor of everything SQL. Unsurprisingly enough, lots of bugs got squashed that way.

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

#159

Earlier quoted context omitted.

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

While Python has some great linters, I don't know of any in C that can correctly and automatically enforce some coding style. Most of them can only indent correctly, but they can't break up long lines over multiple lines, format array literals, or strings. Few or none knows how to deal with names or preprocessor macros.

clang-format and clang-tidy are both excellent for C and C++ (and protobuf, if your group uses it). Since they are based on the clang front-end, they naturally have full support for both languages and all of their complexity.

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

#160
post #92

Earlier quoted context omitted.

It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...

Starting with raw SQL is fun. But at some point you find out you need some caching here, then there, then you have a bunch of custom disconnected caches having bugs with invalidation. Then you need lazy loading and fetch graphs. Step by step you'll build your own (shitty) ORM. Same thing for people claiming they don't need any frameworks.

> you find out you need some caching here, then there

Forgive my ignorance, but how do ORMs help with adding caching? Or are you implying they obviate or reduce the need for caching?

Post reply on HN