drob518

33 ms·

841.
by drob518 1y ago
Sure, that’s faster. But do you really care? How big is your data? How many distinct things are you counting? What are their data types? All that matters. It’s easy to write a simple for-loop and say “It’s faster.” Most of the time, it does
842.
by drob518 1y ago
> Also, experiencing immutability benefits in a mutable-first language can feel like 'meh'. I felt that way in the latest versions of Scheme, even. It’s bolted on. In contrast, in Clojure, it’s extremely fundamental and baked i
843.
by drob518 1y ago
The only benefit to mutability is efficiency. If you make immutability cheap, you almost never need mutability. When you do, it’s easy enough to expose mechanisms that bypass immutability. For instance in Clojure, all values are immutable b
844.
by drob518 1y ago
It’s interesting to watch other languages discover the benefits of immutability. Once you’ve worked in an environment where it’s the norm, it’s difficult to move back. I’d note that Clojure delivered default immutability in 2009 and it’s on
845.
by drob518 1y ago
Impressive. Just reacting to the headline since the article is inaccessible.
846.
by drob518 1y ago
Dominos falling into dominos falling into dominos…
847.
by drob518 1y ago
IMO, centralization is inevitable because the fundamental forces drive things in that direction. Clouds are useful for a variety of reasons (technical, time to market, economic), so developers want to use them. But clouds are expensive to b
848.
by drob518 1y ago
A quibble… The 180k is just for the states that responded, if I understand correctly. They suspect that the rate of fraud could be much higher in other states. How much high? I have no idea. I don’t think anyone does. I think they want to r
849.
by drob518 1y ago
Silos are the root of all evil.
850.
by drob518 1y ago
And in fact can intersect.
851.
by drob518 1y ago
Okay, sure, but neither of those things are specific to COBOL. You can write C programs that allocate all memory statically and chase down every core dump over time and have a very reliable C program. Or better yet use Lisp or even Java wit
852.
by drob518 1y ago
From the article: > This enduring reliance exists not out of nostalgia, but necessity: COBOL’s reliability, stability, and the prohibitive cost and risk of replacing decades of deeply integrated logic make it one of the most mission-crit
853.
by drob518 1y ago
Right, Insignia. That was it. But it was a product that HP resold in some fashion.
854.
by drob518 1y ago
Yes, but wasn’t most of that because its performance was low? If you had dialed back the performance of an equivalent Pentium (model whatever was current at that time), would it have been in the same power ballpark?
855.
by drob518 1y ago
Stickers all the way down.
856.
by drob518 1y ago
Actual LOL for that comment. Thank you.
857.
by drob518 1y ago
Well, they ended up being mobile-oriented, but even that didn’t work. They were definitely not server-oriented and they really couldn’t compete at desktop. Honestly, while the tech was interesting, it wasn’t really solving a problem that an
858.
by drob518 1y ago
In the early 1990s, HP had a product called “SoftPC” that was used to emulate x86 on PA-RISC. IIRC, however, this was an OEM product written externally. My recollection of how it worked was similar to what is described in the Dynamo paper.
859.
by drob518 1y ago
Yea, I’ve felt the new 15Cs and they just aren’t the same. Shame. I might have to give SwissMicros a try.
860.
by drob518 1y ago
I still miss my 15C.
861.
by drob518 1y ago
I, for one, appreciate the classic sensibilities.
862.
by drob518 1y ago
Set up time is needed before every clock edge to ensure reliable state transitions by traditional flip flops. It’s not a one time thing. When you’re operating at low voltages it’s more likely that random system noise will violate the stable
863.
by drob518 1y ago
Right. Launch it, get customers, see what needs to be scaled up, buy a new server, and only then, carve out that problematic piece and scale it as a separate service. But by then you have the data to justify it and you have sidestepped a lo
864.
by drob518 1y ago
It’s easier swapping an engineer into a module associated with a well-architected monolith than swapping them into a microservice. Given a monolith uses function calls that are fast and don’t fail when the network cable is unplugged or DNS
865.
by drob518 1y ago
Yep, exactly.
866.
by drob518 1y ago
Without knowing what the cause of those scaling problems were (CPU, memory, IOPS, etc.), I’ll have to take your word for it. But having worked at several startups, I can say that it’s a common disease that engineers start to optimize for th
867.
by drob518 1y ago
There are a lot of people who shouldn’t be doing software engineering.
868.
by drob518 1y ago
I often see technologies adopted simply because they are the “latest and greatest” and “I want to stay relevant for my next job interview,” rather than sound technical reasoning. Unfortunately, these decisions are made by humans and those h
869.
by drob518 1y ago
IMO, 99.999% of apps should just use monoliths with basic 1+1 redundancy. Unless you’re working at a FANG and require just insane scale, you really don’t need microservices or even lots of modularity. Just keep it simple. If you need more r
870.
by drob518 1y ago
At this point, however, there are probably more browsers for gopher than there are servers for gopher. /sarc

More ›