Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

501–510 of 788 posts

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

#501

> ORMs are the devil in all languages and all implementations. Just write the damn SQL What are the main issues people run into with ORMs? I've used Django ORM for years and written some relatively large applications using it without much problems. Complex queries and aggregations can result in quite hairy code though.

I can give an example for Prisma.

It joins in code, not in SQL. We realized this way too late because we assumed an ORM is optimally structuring code. It wasn't.

This, along with the fact that SQL is already a definitive language, made us realize that ORM's are stupid and utterly useless. I'm talking about the ones that try to pretend they're code, and not a query.

There are multiple ways you can design an ORM though, and one way is to let the user fully manage how they want the query to run, so you're pretty much structuring a query already. Why not go the extra mile and make an SQL query?

I get that ORM's are fine when you don't want to deal with writing queries (e.g. school projects) but for real world apps just take the extra minute...

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

#502

> Never go full monad in Java. what? why?

From a use-case perspective, Haskell monads let you restrict where various effects happen. Some code can be allowed to do local mutation, other code can do shared-mutation suitable for (ACID-like) transactions. In Java you can do anything, everywhere (except throw checked exceptions from lambdas for some reason) so the monadic wrappers would give you about as much guarantee as a comment, and be less clear.

From a representational perspective, you need a generic of a generic to represent and that doesn't really work. Or if you go for interfaces not type variables, you could have a Monad but you don't know which one you have (List? Future? Parser? Either?). It's like representing the above as literal 'Object's, you'd be constantly casting.

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

#503

Earlier quoted context omitted.

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.

As SRE who dealt with more caching errors then I care to. Alot of caching comes down to YAGNI. To his point: It's very hard to beat decades of RDBMS research and improvements Your RDBMS internal caching will likely get you extremely far and speed difference of Redis vs RDBMS call is very unlikely to matter in your standard CRUD App.

> Redis vs RDBMS call is very unlikely to matter in your standard CRUD App

To any juniors reading: cache the response payload (or parts of it), not the results of database queries.

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

#504
post #484
post #468

Earlier quoted context omitted.

Unless the library upgrade is also fixing a 9.9 CVE.

That same scenario (an emergency version-change to a direct dependency) could also remove a function that your code calls! Yet that does not mean mean compiler-checks are bad, or that the solution is to make a system that lets you yeet it into production anyway. Look, I get it: Sometimes a Checked Exception defined in a niche spot "infects" higher-level code which adds it to their signatures, because nobody takes the…

> That same scenario (an emergency version-change to a direct dependency) could also remove a function that your code calls!

absolutely, but the catch is it doesn't affect me transitively. the immediate caller must deal with the issue somehow. with exceptions, it is expected to not handle the ones you have no business handling, so you should change your signature. this propagates upwards and there is no layer of abstraction that can handle this problem without breaking the world. the only somewhat sane way is wrapping the new exception is something that you already handle - if that makes logical sense, which it very well might not.

> NicheCalculationResult class is trickling upwards

yes, and yes people do freak out, not sure why you think they aren't :)

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

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

Formatting is also important for cohesion. A code base that is formatted is easier to browse.

And I couldn't care less about where you put the {}. I love autoformatters.

Linting is a little more. It's both style and genuine issues, like don't == instead of === in JavaScript.

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

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

I've pretty much been stuck on java since 1995, I started right around 1.0. There have been some stints of Python or we have some glue code in C/C++ or whatever but we're talking 95% java.

Some of these things are mildly annoying when you think about them in theoretical terms.

But all the professional teams I've been on a (a lot) have successfully dealt with exceptions without issue. The teams settled on an exception and error handling process early in the design phase and it rarely has caused a major issue.

Yet it seems out on the internet in any place where programming languages are discussed it is an insurmountable problem that has caused all projects in Java to fail and the language died an early and unpopular death. It seems if it caused anyone huge problems it was not Java's issue but that team's issue.

There are/were other much bigger issues over the years. Memory leaks have been issues. Spring was hard for many people to deal with back around 2005 or so. The first iterations were quite bad with XML. XML in general caused a lot of issues. J2EE caused a lot of issues just because it was so badly designed early on. (Some of this was because it was birthed out of CORBA, which was itself pretty horrible.) Plenty of issues were caused by using Collections with mixed objects in them early on before Generics were introduced. Visual J++ caused havoc. Different models of web application caused a lot of havoc before we got to Javascript UIs in the browser driven by Web API back ends. JPA was a big mistake IMO. But exceptions were never really a huge problem anywhere.

So many have blamed a problem on Java when it was actually a problem with a library, component, or framework written in Java that became way more popular than it should have been. And along the way there were a lot of "developer influencer celebrities" who were listened too far far more than they should have been. Many of these guys (I can't remember one ever being a woman) sold everyone on ultra complex designs and ways of doing things and the community almost always bought in to a ridiculous degree.

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

#507
post #272

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.

> and arguably Erlang

Curious about your case for this. I don't know a lot about Erlang other than "it's what Elixir is based on" or whatever technical jargon is more accurate. I thought it was functional.

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

#508
post #389

Earlier quoted context omitted.

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.

Nice, thank you!

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

#509
post #239

Earlier quoted context omitted.

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.

This is disastrously easy to implement with just a few filters on git (clean & smudge).

I highly recommend it though, especially if you worked for a long time at one company and are used to a specific way of writing code. Or if you like tabs instead of spaces...

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

#510
post #295
post #288

Functional programming does not prevent you from using objects Stop listening to functional programming bros. Watch someone like Zoran Horvat. While I can't cosign all of his opinions, he tries to bridge the functional/OOP gap for OOP programmers. OOP programmers urgently need to distance themselves from this binary narrative. Everyone should understand functional programming and how they can utilize functional appro…

> Functional programming does not prevent you from using objects It's a bit like how doing single-entry bookkeeping doesn't stop you from doing double-entry bookkeeping.

That's probably the most incorrect analogy. If I have objects, I can change their state in the middle of any bookkeeping.

There should be a different name for functional programming with mutable objects.

Post reply on HN