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

531–540 of 788 posts

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

#531

Post by snapetom »

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

> being bogged down in reinventing a lot of what ORMs offer.

There's a saying - if you hate ORMs and don't use them, eventually you're going to write your own ORM.

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

#532

Post by itishappy »

jagraff wrote: post #222

> Contrarily, library development is about abstractions. Spend time hunting for an algebra This line piqued my interest - what does an algebra mean in this context? Does anyone know of any good resources for further exploration?

Algebraic structure. It's a fancy way of saying that a system follows certain patterns or rules.

As an easy example, you're probably quite familiar with the algebra of addition over integers. It describes rules like associativity and commutativity that describe some general transformations that are guaranteed to always behave predictably. Contrast this with subtraction over integers, which is associative but not commutative. Programs in general are neither associative nor commutative, so sadly no swapping terms or adding parenthesis willy-nilly.

A slightly more advanced example that you're probably still familiar with is mapping over Functors. A functor is just a thing that contains other things, and it includes collections you're familiar with like lists and trees. Well, the action of taking stuff out of a container, modifying it, and returning the results in their original position turns out to be an incredibly common and useful pattern!

https://en.wikipedia.org/wiki/Algebraic_structure

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

#533

Post by sesm »

kflgkans wrote: post #438
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 cou…

React's mental model has always been UI = F(data) and in ideal case any component is a pure function. But, of course, in most real apps there are cases when this mental model breaks: internal state, animations and side effects. The old way to provide escape hatches for those cases was to wrap a function into a class, where original function is 'render' method and the cases above are handled with lifecycle methods. The problem was that one piece of functionality often required updating several lifecycle methods, and for a big component that non-locality made things very hard. Hooks are a different way to express non-purity that keep code more local.

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

#534

Post by YoshiRulz »

pjc50 wrote: post #345
corytheboyd wrote: post #312

Earlier quoted context omitted.

> Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. I started working in Java a few months ago and holy shit does this stick out like a sore thumb. Null checks cascade down from gods domain all the way to hell. But oop we missed one here and caused an outage lol add one more! So much wasted human effort around NPE, and yet, we sit around in a weekly meet…

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.

Kotlin fixes the null handling problem too, and with the added benefit of being able to gradually migrate Java code.

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

#535

Post by kflgkans »

taeric wrote: post #448
kflgkans wrote: post #443

Earlier quoted context omitted.

The most common pattern in languages with explicit error handling, is to simply return the error (possibly with some context added) in every function up to the point where the process was started (e.g. an HTTP endpoint handler, or the CLI's main function) to deal with it. I'm not saying exceptions are good, but I am saying that they do represent the most common error handling pattern.

Right, this is largely the same idea. For things that have to be bubbled up, you wind up in the simplistic "single thread of execution by an operator" pattern. And, in that scenario, exceptions work exactly the same as just returning it all the way up. It is literally just making it easier to unwind the stack. My assertion is that actual error handling in workflows doesn't work in that manner. Automated workflows hav…

Thanks for the additional clarification!

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

#536

Post by kflgkans »

sesm wrote: post #533
kflgkans wrote: post #438

Earlier quoted context omitted.

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

React's mental model has always been UI = F(data) and in ideal case any component is a pure function. But, of course, in most real apps there are cases when this mental model breaks: internal state, animations and side effects. The old way to provide escape hatches for those cases was to wrap a function into a class, where original function is 'render' method and the cases above are handled with lifecycle methods. Th…

Thanks, that makes sense. Interesting perspective on the UI = F(data), I did not know that. I still wish the mechanics were a bit more... intuitive... I guess? Personally, I'm a big fan of The Elm Architecture [1]. I felt that is a very nice way to separate state and logic. But I'm not such a big fan of Elm itself (subjectively).

[1] https://guide.elm-lang.org/architecture/

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

#537

Post by ackfoobar »

bluGill wrote: post #309
pinoy420 wrote: post #261

Earlier quoted context omitted.

How many errors are actually recoverable. I bet most thrown exceptions could be replaced with a printf(“it went wrong here”) for all their utility.

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…

> The real value of exceptions is you can skip 6 levels of functions that have lines like

For some reason some Go programmers think those lines are the best thing since sliced bread.

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

#538

Post by smj-edison »

mr_tristan wrote: post #383

This list does resonate, but I’d make some tweaks to express things slightly better. For example: > Most programming should be done long before a single line of code is written I would say “most engineering should be done before a single line of production code is written”. Formalizing a “draft process” is something I’m really trying to sell to my team. We work in an old codebase - like, it’s now older than most of t…

Sort of tangent, but is there a semi automated way to select which engineer would be best to implement a ticket? Something like "we need to modify this API, let's run git blame and see who has the most familiarity" and some form of scheduler that prioritizes the most experienced engineers on the parts of code that only they know?

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

#540

Post by aranchelk »

tasuki wrote: post #492
aranchelk wrote: post #393

> Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy > Objects are extremely good at what they're good at. Blind devotion to functional is dumb. Blind devotion to anything in engineering is dumb, but if you go full functional on the frontend it’s definitely not “Kafkaesque”

> if you go full functional on the frontend it’s definitely not “Kafkaesque” This has been my experience too. Elm on the frontend is easy and delightful.

Right on! I’m using PureScript with an Elm-like framework.
Post reply on HN