A former colleague of mine had a good way to describe it: technical debt is like financial debt, too much will kill you but if you don’t have any you will be outgunned by those that do.
The trick is how to manage tech debt properly, and the widespread scrum fake-agile in use provides no means for ever tackling tech debt once taken on. This is one reason for the explosion in SRE teams.
Mocks and stubs get used all over the place because nobody understands what it means to write code that’s easily testable. They’re great when used correctly (e.g., remote services or inherently stateful APIs like time). But they almost never are.
You end up with tests that ensure one and only one thing: the code is written the way it’s currently written.
Tests should do two things: find unexpected out-of-spec behavior, and prevent regressions during the course of editing and refactoring. These overly-mocked tests by definition can’t do the first one and they actively inhibit the second. They have negative value insofar as they constantly trigger failure while making completely benign edits.
Handcrafted artisinal stuff is a luxury because that's the only niche that makes economic sense for it now, given mass production and other recent developments (too lazy to list, sorry).
Consider how you can't really get by in most of America without a car because we designed our cities to require them. It would be a mistake to conclude that, because life is harder in a car-optimized society without a car, society must be better off optimizing for cars.
Btw, it goes without saying that if you wanted to have a general-purpose relational language then you should use Prolog, not Datalog. After all, if you use Prolog there's nothing stopping you from sticking to Datalog when you want, and only using the full power of Turing-completeness when you must.
Seriously. Learn Prolog. It's a powerful language and you'll never worry about the Object-Relational Impedance-Mismatch ever again in your life. The only reason not to learn it is that you will forever be sad that you can't use it in your day job. Or you'll find one where you can, like I did.
There's essential decoupling and accidental decoupling; decoupling you want, and decoupling which mostly just obscures your business logic.
Resilience in the face of failure, where multiple systems are communicating, or there's a lot of long-running work which you want to continue as seamlessly as possible, is the biggest essential decoupling. You externalize transitions in the state machine (edges in the state graph) of the logic as serialized messages, so you can blow away services and bring them back and the global state machine can continue.
Scaling from a single consumer to multiple consumers, from multiple CPUs to multiple machines, is mostly essential decoupling. Making decisions about how to parallelize subgraphs of your state machine, removing scaling bottlenecks, is an orthogonal problem to the correctness of the state machine on its own, and representing it as a state machine with messages in queues for edges helps with that orthogonality. You can scale things up without external persistent queues but you'll end up with queues somewhere, even if it's just worker queues for threads.
Accidental decoupling is where you have a complex state machine encapsulating a business procedure with multiple steps, and it's coordinated as messages between and actions in multiple services. The business logic might say something like: take order from user; send email notification; complete billing steps; remove stock from inventory system; schedule delivery; dispatch stock; etc.
All this logic needs to complete, in sequence, but without higher order workflow systems which encode the state machine, a series of messages and producers and consumers is like so much assembly code hiding the logic. It's easy to end up with the equivalent of COMEFROM code in a message system.
I think one difference is that session types capture which state a process/co-routine is in after receiving a sequence of messages whereas this system does not, it captures how one can respond to each state in isolation (e.g. I don't think you can statically capture that once a door is closed and locked you can only receive the locked state from it and respond by unlocking it).
The only meaningful thing in this discussion is about people who want to make money easy, but can’t, because of the rules they don’t like.
Well, suck it up.
You don’t get to make a cheap shity factory that pours its waste into the local river either.
Rules exist for a reason.
You want the life style but also all the good things and also no rules. You can’t have all the cake and eat it too.
/shrug
If China builds amazing AI tech (and they will) then the rest of the world will just use it. Some of it will be open source. It won’t be a big deal.
This “we must out compete China by being as shit and horrible as they are” meme is stupid.
If you want to live in China, go live in China. I assure you you will not find it to be the law less free hold of “anything goes” that you somehow imagine.
Yes, it would seem preferable to reuse the same energy storage over and over again, as opposed to digging it out of the ground at huge expense, shipping it across the world, and then spreading it out into the environment as a cloud of toxic particles after one use.
The T.Rex, just like all the other dinosaurs of that last era when the Chuxhulub asteroid impact, wasn't very smart: it obviously was too short-sighted to bother developing a decent space program to deal with asteroid impacts.
Millions of years later, the dominant species of this planet is just as short-sighted and stupid, if not more so, since we know about the T.Rex's demise by asteroid impact.
Reminds me of a previous job where IT wouldn't let me install netcat, because "it hadn't been updated since like forever", my response: "because it's fucking done", I was eventually permitted to install it..
I think a lot of people want what you mentioned. But I also think that even if stack support is implemented, they will "keep it simple" and pass the responsibility of extracting the location/details of your code from the stack trace to, you. That will give rise to everyone writing there own variety of utility/common stack parsing methods and then libraries will spring-up that provide such conveniences and it'll go on to become its own thing.
I feel like that is Go's underlying theme: "we don't provide last-mile-connectivity; how else will the ecosystem grow?!"
One of the worst "ossifications" of non-standards is the notion that colour is three channels of 0..255, one each for red, green, and blue. Combined with the incorrect assumption that the scale is linear[1], and you have a perfect combination for a Dunning-Kruger effect: A bunch of programmers[2] who think they've figured out "graphics", but haven't even begun to understand how any of it works. Not any of: light, display technology, colour standards, or even the human eye.
A short list of falsehoods programmers believe about vision:
- sRGB is the only graphics standard.
- Monitors are actually sRGB and follow that standard.
- Colour intensities are on a linear scale.
- White is 0x00FFFFFF or 255,255,255
- 50% Grey is half of the above: 127,127,127.
- Blending colours is just a matter of linear interpolation.
- Red, green, and blue have a single consistent definition.
- 8 bits is enough for each colour channel.
- Okay, 10 bits is enough.
- 12 bits is enough, surely.
- 0 means black.
- Okay, 16 means black on televisions.
- Fine, black can have different levels in different standards, but it's always clear which level is black.
- At least the white level is consistently defined.
I'd just like to interject for a moment. What you're referring to as Mastodon, is in fact, ActivityPub/Mastodon, or as I've recently taken to calling it, ActivityPub plus Mastodon.
One thing I know of is the CoPilot language/library/thingy from NASA (no relation to Githubs copilot), which can takes in code in a Haskell DSL and outputs code that is guaranteed to run in constant memory and uses an equal number of cycles each loop. See it here: https://copilot-language.github.io/
I don’t worry about it. Which language you’re using ends up way down the list of Things That Matter in terms of building something useful.
I’d think way, way harder about what database I used than which programming language. Most of them are just different stylings of C when you really get down to it. (Ok fine, not Rust.)
Reminds me of a colleague who used to input "president@whitehouse.gov" into all of such mandatory fields (early 2000's). When I asked why, his response was: "If anyone is able to do something about all that spam, it's probably him". :D
One advice: for any of these topics take a tutorial directed at language X and implement the solution in language Y. This will prevent you from mindlessly copying the code and will force you to understand what you are doing.
An electric guitarist usually has a pedalboard that they use to make different guitar tones. Let's approach this like an electrical engineer might.
Time is a straight arrow: call it t.
The guitarist plays, and their guitar pickup records a signal. At any time t, measure the value of this signal's waveform: call it x.
That signal can go into a pedal that maps each value to create an output signal. Call it f(x, t).
The pedal is a linear system when it satisfies f(x1 + x2, t) = f(x1, t) + f(x2, t). In English, you can blend two guitar signals going into a single linear pedal, and it will sound the same as if you used a separate pedal for each guitar.
The pedal is a time-invariant system when it satisfies f(x, t1) = f(x, t2). In English, a time-invariant pedal does not warble over time.
The magic happens when a system is both linear and time-invariant. These systems are so special, we call them "LTI" for short. Feed an LTI system a single, really loud, POP! Something like a clap, or a gunshot. Record the sound of this gunshot, and call it "impulse_response.wav". This file characterizes EVERYTHING about the system. If you know how the system responds to an impulse, you will know how the system responds to any other sound. All you have to do is convolve the sound with the impulse response, i.e. use the contents of impulse_response.wav as a set of weights and pass the sound through it.
The echoes you hear when you speak in a large room is a real-world example of an LTI system. People will go to a cathedral, an open field, or a large tunnel, set up a microphone, and fire a blank pistol. They can go home, convolve the sound of their guitar or voice or whatever with the impulse response, and it will sound exactly like they're in that space! There are whole communities of people making and sharing impulse responses out there, and I just think it's the coolest thing ever.
For any guitarists reading this, I'll bring this back to the pedalboard. Another cool thing about LTI systems is that when you chain multiple of them together, the order does not matter. Reverb, delay, EQ, and wah are all LTI effects. If you've ever wondered why pedal ordering sometimes matters and sometimes doesn't, this is why.
The trick is how to manage tech debt properly, and the widespread scrum fake-agile in use provides no means for ever tackling tech debt once taken on. This is one reason for the explosion in SRE teams.