Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

151–160 of 269 posts

Re: Choose Boring Technology (2015)

#151

Post by Pannoniae »

t-writescode wrote: post #122
Pannoniae wrote: post #109

Earlier quoted context omitted.

I admit I have a hard time following this logic. If an agent has a baseline intelligence, you can... instead of using boring technology, just DIY/NIH the simplest custom solution which fulfills your requirements. And you'll usually do a better job than a general-purpose software library. Even if in the other approach, the LLM knows the stack better, you're just going to push the complexity into your client code, so i…

That’s definitely not true, and I’ll give two incredibly common examples: 1: arraylist. A library will probably do better than you. It’s already written and common. 2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.

1. This isn't true whatsoever. You can easily do better than std::vector (trivial relocation support, non-inlined grow), better than C# List (ref T accessor, batch add API, maybe even an add-uninitialised API or in-place constructing specific things), better than a Python list (this one is obvious), etc.

2. This is a better point but depending on your workload, I don't think this is unheard of. Or at the very least, if your workload is simple, you can grab one off the top of the benchmarks, point AI at it to customise it a bit then you're good. But to be fair this one's a bigger structural investment so I do see your point. For smaller utilities the tradeoff is pretty clear.

Re: Choose Boring Technology (2015)

#152

Post by jagenabler2 »

insanitybit wrote: post #147
i_like_robots wrote: post #66

Earlier quoted context omitted.

Poor choices whether influenced by this article or engineers chasing CV points are no different. Boring technology is a tool or communication device like any other. I hope in your situation you were able to influence the engineers utilising it poorly to reconsider.

The point is exactly that - bad decisions happen when your reasoning is based on silly terms like "boring" or "hyped" or whatever. The solution is to discuss the merits of each solution as it pertains to the problem space, which "boring" does not help with (and obfuscates).

While it shouldn't be the absolute guide for every technical decision, it helps to have abstractions to capture the intuition and years of experience that goes into choosing a solution. It can make the discussions smoother.

When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.

There are scenarios where all that criteria is met but it's still a bad fit. Boring Not boring becomes a trade-off scale. There are understood costs that come with choosing a tech that's not boring and I don't have to explain why.

If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.

Re: Choose Boring Technology (2015)

#154

Post by nimih »

krapht wrote: post #52
PyWoody wrote: post #12

Earlier quoted context omitted.

Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0] [0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...

His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.

Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).

Re: Choose Boring Technology (2015)

#155

Post by t-writescode »

inigyou wrote: post #139
t-writescode wrote: post #122

Earlier quoted context omitted.

That’s definitely not true, and I’ll give two incredibly common examples: 1: arraylist. A library will probably do better than you. It’s already written and common. 2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.

How many times has the stable and established X surprised you with some unexpected behavior? Once upon a time I wanted a URL /like/this/with%2Fslashes/ where a path parameter could, in rare cases, contain an encoded slash. Legit according to every RFC I checked. Works fine in browsers. But I couldn't get the web server to not convert it to a / before hitting my code. And woe betide thee who wants to make nginx return…

How many times have existing APIs made by experts in their fields had bugs.

How many of those are you willing to let your own services and your customers’ data be hit by whole classes of bugs that battle-hardened APIs have already fixed?

You sure you can get an LLM to handle every single one of them on first pass? Would you stake your company reputation and the PII of all your customers on it?

Re: Choose Boring Technology (2015)

#156

Post by nine_k »

krapht wrote: post #52
PyWoody wrote: post #12

Earlier quoted context omitted.

Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0] [0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...

His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.

Replace curl with wget, get robots.txt support. Write timed-out URLs into a file for the next identical run.

The idea stays: you can jerry-rig a web crawler from pedestrian, readily available parts, and quickly test the idea for which you wanted to crawl the Web.

The point is that bash, xargs, wget, make, etc are well-understood, well-maintained tools. They are not even necessarily simple, but they likely contain very few unknown unknowns.

Re: Choose Boring Technology (2015)

#157

Post by t-writescode »

Pannoniae wrote: post #151
t-writescode wrote: post #122

Earlier quoted context omitted.

That’s definitely not true, and I’ll give two incredibly common examples: 1: arraylist. A library will probably do better than you. It’s already written and common. 2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.

1. This isn't true whatsoever. You can easily do better than std::vector (trivial relocation support, non-inlined grow), better than C# List (ref T accessor, batch add API, maybe even an add-uninitialised API or in-place constructing specific things), better than a Python list (this one is obvious), etc. 2. This is a better point but depending on your workload, I don't think this is unheard of. Or at the very least,…

Is it obvious? Those existing APIs have known performance characteristics and deep integration into several other libraries. The moment you custom-roll your own root library, you break integration with all existing other libraries that depend on the defaults. To add, your LLM has to think about your new custom version rather than looking at the billions of lines of examples using the one it already knows works from decades of historical data.

If you really, really need some ultra-micro-optimization, you’re obviously not the target of this; but unless you’re doing HFT or the most inner loop of a game engine, the standard library and all its deep integration and battle-testedness is worth the 1% perf hit.

Re: Choose Boring Technology (2015)

#158

Post by Animats »

jaggederest wrote: post #134
jason_oster wrote: post #123

Earlier quoted context omitted.

Compare to what happened to Python. That will cheer you up!

Hey, at least python is now extremely consistent: it's an unpleasant tarpit regardless of whether it's human or AI generated. Ruby, too, rip my native programming language. I remember in the pre-AI era I was doing a quick sample contract employment with a company that had >200 columns in their user table and was manually enumerating them in every query , multiple times. They were using SELECT $1,$2,...$184,$185 from…

That's a different tarpit. That's the problem with object-relation mapping, which is trying to deal with the mismatch between structs in languages and rows in SQL. There are a huge number of such schemes, and they range from somewhat annoying to awful. They're bad across a broad range of programming languages.

This is an area where LLMs might actually help. Or make things worse. We'll have to see.

Re: Choose Boring Technology (2015)

#159

Post by t-writescode »

clueless wrote: post #88
t-writescode wrote: post #81

Earlier quoted context omitted.

It’s not about conservative vs progressive but about “safe, battle-tested, stable” vs “could be amazing future-tech”; and the idea of having a small number of innovative technologies, in particular where they matter, is about allowing yourself to spend all those thought-tokens on areas that matter. You don’t want to be innovating your logging tech or your database if the old will work because you might spend 90% of y…

I might be missing something but conceptually, “safe, battle-tested, stable” vs “could be amazing future-tech” IS about conservative vs progressive... am I missing something?

Good point, I suppose conservative is the right word there. Its broader meaning has been a bit louder lately, so I didn’t think of it the right way there.

Re: Choose Boring Technology (2015)

#160

Post by mikestorrent »

lkirkwood wrote: post #140
sgarland wrote: post #137

Earlier quoted context omitted.

I think calling anything in the JavaScript ecosystem “mature” is a bit of a stretch. This is the same community that brought us left-pad.

10 years ago though

And here we are, almost all the complaints from a decade ago still have relevance
Post reply on HN