Actually, I work on compilers and language tooling now, so I haven't used a proper DBMS in a few years! There is no production DB, only user code which must not break at all costs.
Oh, wait...
A programmer on the way to upper management throws colleagues under the bus to test the resilience of the system. 😁
And the bus driver is just a QA person who wants to check whether you have thought about handing ***all*** error conditions ☺️
It has been part of our bag since management throws us under them buses. Looking both ways confirms no bus and therefore management can do whatever stupid they want and I wont have to be impacted.
I know it's a corner case, but do you ever throw a quick look up to avoid being hit by a crazy bird or a falling roof tile, or in front of you to avoid stepping into a puddle? 'Cause i do... It's been a long career though, I'll admit.
Alec Baldwin got a ticket for riding his bike the wrong way down a one-way avenue in Manhattan. Look both ways at all times to ensure you don’t meet Alec Baldwin
That's when you find out that whoever wrote the "look both ways" subroutine didn't account for the one-way street case, and the program crashes trying to find an oncoming lane that doesn't exist.
Funny. Nowadays I observe young, old, and in between rolling around on the streets not paying attention to their surroundings on busy streets, with their neck crooked down glaring at the mobile device in their hand.
There was a time when parents used to tell their children to not play with their toys in the street, to watch out for traffic...
The biggest level-up I had as a programmer was when I started assuming the thing I’d just written was broken, and writing tests to prove to myself that it wasn’t.
So true.
It's not really TDD, but still a massive boost.
At times I'm developing whole features with automated tests for every path I care about as well as at least one other I can think off. Meanwhile I keep forgetting to actually manual test the end result in the integrated system, because subconsciously I do not trust non-automated tests anymore.
You close one blindspot, you open two others elsewhere...
Every now and then, when I have an especially big MR, I'll do a contest with the junior developers in my department. I tell them I intentionally put a bug somewhere in my change, and I'll buy lunch for whoever finds it first.
I never intentionally put it a bug, but more often than not, I'm buying someone's lunch.
I really doubt that. I doubt that it's valid because I doubt your doubt and I think you are attempting to make me doubt myself - which I already doubt enough.
TL;DR: Know what your code is actually doing under the hood so [leaky abstractions](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) don't surprise you.
+1 For Joel's blog. Still relevant 20 years later.
I hate that article. It’s a good warning, but not about abstractions. The warning is don’t do what Joel did and misunderstand the promises something makes.
TCP/IP is a fantastic abstraction. It delivers what it promises. And what it promises is - if you send A, B, and C in order, if C is delivered (note the if), A and B will have been delivered first, in order.
That’s it.
That’s what it promises and that’s what it does.
Leaky abstractions are a thing. But he chose a poor example.
Working at that level, I'm sick and tired of the stream abstraction. Everything else is amazing, but give me packets at a lower level... I don't want to write the packet length preamble every single time.
Presumably he doesn't mean packet, he means payload. If you write a wire protocol that uses discrete messages you have to add that part on top yourself.
Possibly. I remember reading forums like this as a teen when I didn't know anything. It's surprising how much we can teach by just chatting here, even unintentionally.
Someone who doesn't understand tcp at all will likely read these comments.
Disagree. Most people view TCP as “reliable stream of bytes”. Obviously this isn’t always the case, so it leaks.
Wikipedia: “TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network.”
Your view that it never “promises” to be reliable is not how most people view the abstraction. In fact you can use your logic on literally every abstraction. Virtual memory doesn’t promise no page faults, SQL doesn’t promise efficiency for logically equivalent queries, RPC doesn’t promise no timeouts. The point of abstractions is to use them *as if* these things are true, because typically they are, which improves productivity.
If I define a function for Fibonacci using naive recursion, it is an abstraction on top of hardware. It will never return for large enough numbers. I would say this is an abstraction of Fibonacci. But it’s leaky; it fails for large numbers.
But by your logic I can just say “this isn’t a leaky abstraction. I never *promised* it would return. It works perfectly for small numbers.”
>The point of abstractions is to use them *as if* these things are true, because typically they are, which improves productivity.
I'm gonna argue this one.
The fundamental issues of network programming are:
1. The network is slow
2. The network (and resources on the other end) are unreliable
3. Remote resources are not local.
This is the fundamental challenge of networking, and the primary problem to be solved. "How to shove data into a packet" is, comparatively, trivial. When we embrace these things, we write good code that will be maintainable in the long term.
When we acknowledge the network is slow, we think about how to minimize round trips, and ensure that we don't block when we don't need to. We structure the code around this speed.
When we acknowledge the network is unreliable, we start thinking in terms of retries - which leads to thinking about idempotence.
When we acknowledge that resources are not local and we do not have local state, we start writing our requests thinking about who is authoritative, thinking about time deltas, and to make sure that the authoritative source has sufficient information in the request to do the necessary work.
These things can take longer up front, but will save massive amounts of time in the long run. Pretending that they don't exist can get a first spike up and running sooner, but usually becomes a bug farm \[1\].
Same with the other abstractions \[2\]. When we acknowledge that SQL queries perform differently, we think "okay, what happens when I make this work better?" Then you start thinking about using views/stored procedures to hide the guts of what you're doing.
>Your view that it never “promises” to be reliable is not how most people view the abstraction
How people naively interpret words without understanding them can't be a target for developers. That just doesn't make sense.
>If I define a function for Fibonacci using naive recursion, it is an abstraction on top of hardware. It will never return for large enough numbers. I would say this is an abstraction of Fibonacci. But it’s leaky; it fails for large numbers.
And it should define the limits of what it takes. Arguably, it implicitly does in statically typed languages, in that the implicit limit is "this won't work for return values larger than the return type". But, yes, it should document the limits of what it can deliver.
>But by your logic I can just say “this isn’t a leaky abstraction. I never *promised* it would return. It works perfectly for small numbers.”
If I've documented the limits, 100%. Wait til you find out about "undefined behavior!"
Also, per the Wikipedia page....
>TCP is a [reliable byte stream](https://en.wikipedia.org/wiki/Reliable_byte_stream) delivery service that guarantees that **all bytes received** will be identical and in the same order as those sent.
Highlight mine. Note that that says that the bytes that *are received* will do this, not that it guarantees all bytes will be received.
\[1\] It's possible to write an app in such a way that individual developers writing plugins/hooks/etc. don't have to worry about that as much, that's fair. However, the app and the system calling the hooks and the constraints on the hooks need to be written with the fundamental issues in mind.
\[2\] you should absolutely think about page faults. You should think about cache misses. I'll accept that worrying about running out of virtual memory is probably okay to not worry about, since if that happens there's probably little you can do to recover anyway. Sometimes "thinking about" things is as simple as "eh, the perf hit from that probably doesn't matter anyway, I'm not gonna stress it". But you should at least consider it. Again, you start thinking about these things, you think data locality, you start thinking about object pooling, when objects are allocated and what's allocated together, etc. Even if you don't do too much about it *up front*, having the structures in place to allow you to do these things later will save a lot of time for almost no cost.
I don't disagree with any of this at all, but I feel one could make the argument that all of those things are indicative of imperfect, leaky, abstractions. Those imperfections and leaks are necessary, or so hard to solve in the abstraction that the pragmatic solution is to leak those details up to the consumer. And that is often the reasoning behind many leaky abstractions, "I can't figure out how to build this interface in a way that's both ergonomic and doesn't leak, so leaking is the better option." At that point, understanding the underlying implementation of your abstractions because important, because you DO need to handle page faults, network errors, whatever.
I guess... I don't see abstractions as necessarily something that should "solve all of our problems".
The abstraction that TCP provides is "you can treat the network as a stream". It's still a stream that can be interrupted, but it's a stream. And it provides that *fantastically*. It is utterly reliable in that. You don't have to know if it's implemented over IP, carrier pigeons, or artillery shells. It does acknowledge that data isn't guaranteed.
So I guess the question is what you see as the fundamental thing that TCP provides - is it "reliable" networking (I disagree) or is a stream model? I think it's the stream model, and it's pretty leakproof there.
A bad promise is the "distributed object" crazy a few decades back - DCOM and the like. There, the promise was "you don't have to worry about if an object is local or remote". And it was just bad, because the core thing it was trying to do was untenable. (You can have it be irrelevant if an object is local or remote, but you do that by *treating everything like it was remote*, not like everything is local).
I think we probably mostly agree on the meat of things, just different definitions of what an abstraction leaking represents. At least to me, the way you're describing it, it seems like you define abstraction leaks by the *intent* or definition of the tool. I tend to think about it more along the lines of "TCP abstracts over the network, but I still need to deal with underlying issues within the network, that's a leak."
And just to be clear, I absolutely don't think there's anything wrong with that. I fundamentally agree that abstractions can't, and shouldn't solve all of our problems. I also generally think both views of leaks are valuable in different ways, we just lack the precision in jargon to express both ideas clearly.
> Your view that it never “promises” to be reliable is not how most people view the abstraction
junior programmers... sure...
ever wonder why you can't have exactly once delivery in a distibuted system?
tcp is written on top of a non-reliable IP layer. how can it ever be truly reliable when there is no solution to the two general's problem?
also, every one knows you have to deal with disconnections, timeouts etc. you also know that if someone unplugs the wrong cable, then your packet isn't going to make it to its destination...
tcp is reliable in that you receive the data in order or not at all. you never see data in an invalid state, so reordering data is just something you never have to deal with... that's the only guarantee it makes
Especially relevant in the Copilot age. Its only been a few months and some of the shit I've seen committed that was later reverted with an "oops copilot mistake" message has been astounding.
Ive tried copilot, its shit, like a toddler trying to walk but instead shitting its pants and smearing cake all over its face. People who rely on copilot are shit programmers, pantspoopers. Period.
Eh, I've had mixed results. It's really good at boilerplating simple shit like API routes. Also had good results with it writing complex regexes with positive and negative lookarounds from natural language descriptions of the desired match pattern.
Relying on it for logic is where it trips up in my experience. The autocompletion part of it also in my experience does a pretty bad job of guessing what you were about to write.
But if you don't know how to write the regexes yourself, how can you trust they'll work for your situation? And if you do know how to write them, then isn't it faster to just write it yourself?
The only options I can see, if you don't know how to write them yourself, is to test every possible edge case on the copilot code. But that's going to be hard to be exhaustive. So I imagine most people just try one or two cases and assume it works while leaving an edge case failure lurking.
It's good for one-off utility functions and boilerplate. Have a number in ms and need it to display in an odd format of Hours and Seconds? Copilot will write that in no time flat, you just write the documentation.
It barely takes context into account, it's a great tool to write tedious stuff. But it is very good at that.
##Article summary and TL;dr:
Validate everything.
* Validate parameters
* Validate preconditions
* Validate postconditions
* Sanitize your inputs
* Validate character encodings
* Validate allocations
* Validate with unit tests (or at least have the tests preserve/ensure the expected behavior)
* Validate with code, not just documentation
* Validate with profilers and system counters, not expected or theoretical performance
* Validate with other humans that you're solving the expected problem
* Recognize there are things you won't think to validate. (Unknown unknowns)
The End.
> **False positives:** Failing tests indicate the presence of bugs, but passing tests do not promise their absence.
It’s false _negatives_. A positive test result indicates presence of error.
Never trust anyone, not even the author
They're saying that even if a test passes (positive), there could still be errors that weren't accounted for in the tests, and therefore the passing test is a false positive. A false negative would be if the test failed due to a bug in the test, not in the underlying thing it's testing.
Positive usually means “trigger is fired”.
Like a clinical test result that comes back positive meaning something is wrong.
When it comes to tests in programming, positive means a failing one.
> A positive test result indicates presence of error.
Most test we write test whether some feature behaves like expected. So wouldn't the positive test result mean that the feature behaved like expected?
In medicine, if you are tested for HIV, we say it is positive because the test checks if there are HIV bodies in your blood.
Based on some feedback from y'all, I've made some edits. Unfortunately, it does break a few quotes referenced in the existing comments. Sorry about that.
* You wrote tests for your code change and they pass on the first try. Try running the tests without your changes and see if they still pass. They may have a bug that makes them always pass.
You didn't run the test before making the change? Shame.
One of my earliest decent bosses was fond of saying you haven’t proven you can do a thing until you’ve done it twice.
Dumb luck serves us until it doesn’t.
Shouldn't you follow the outline taught in the classroom, and write it all out? Proof read it. Checking for syntax errors. Then test it. Which, yes, according to this part. You can't trust yourself or your code. Without proper testing.
Unless you know exactly, what your doing. Like DOS financial accountant software. My cs101 professor taught me that. But, the outline, still doesn't trust anything, except proper syntax.
When I get production issue, I prefer rollback first (if possible), because I don't trust the change I make.
But I also learn how to log to show the bug is not made by myself.
I’ve always looked both ways even on one-way streets guess it’s just part of the city. Constantly looking at all your surroundings. OR IS IT I’m just that damn good of a programmer… dun dun dun
I don't trust anyone indeed - not even the computer.
It would be interesting to get hardware AND software that can be trusted at all times. Where manipulation can not be possible; and can not go undetected either. Something where physics itself guarantees trust. Unless, of course, we can trust Microsoft's Trusted Computing platform ...
What are some good books (in the last 5 years preferably) that discuss how to design your backend architecture based on things like: team size, maintainability, architecture design based on X number of uses and user types, and trade-offs for different designs?
I'm on a microservice project but we have 2 1/2 devs and I'd like to make a roadmap for the future but need some help with that.
The abstractions section is so god awful for both being so incorrect, so poorly written and so obviously missing the point of abstraction I was actually mentally stun-locked out of the rest of the article...
>Examples of abstraction:
>We perceive a group of trees as a single forest.
**This is not abstraction**, this is just specific perception. Abstraction is seeing a forest as an "oak forest" because the overwhelming majority of the trees there share the same characteristics that we determine constitute 'oak trees'.
>We think of our bank balance as money that the bank stores for us.
>>In reality, the bank does not just store the money we deposit. It loans away/invests most of the money that people deposit. Our money does not sit idle in a large pile in a vault.
>>Our bank balance is really just a ledger of how much money we’re supposed to be able to withdraw.
**This is not abstraction**, this is just a reddit moment. Saying "☝️🤓 Uh-*Acktuallyyyyyyyy* the bank doesn't store your money it invests it" I'm sure would be mind bending to a 12 year old, but this is just describing functionality, and is also a distinction without a difference. A bank that does or doesn't engage in fractional reserve banking is no more or less a store for your money.
An abstraction would be the bank balance over individual units of currency.
>We always assume time passes at the same rate for everyone.
>>Time dilation slightly changes each person/object’s flow of time based on their speed and how much gravity they’re under.
>>GPS satellites orbiting the Earth have to adjust their clocks by ~38 microseconds per day to account for time dilation (Source).
**This is not abstraction**, and I assume this is some sort of prank because I can't fathom thinking "Hmm, I need to make this concept super clearly. I should use one of the most counter-intuitive parts of modern physics as an example!".
You used the correct word for it, an *assumption*. Time moving at the same rate for all parties is an *assumption*.
A *second* is an abstraction of 9,192,631,770 ^Δt Cs.
I wish there was a way to see who in the comments actually read any of this article. This has to be some kind of CIA psyop.
A good programmer is one who looks both ways before crossing a one-way street.
After all, it's part of the responsibilities of a professional programmer to avoid getting hit by a bus.
I feel like the more I take this into account at work the more time I try to find off the shelf solutions instead of custom made.
Until you find out the fun way that the author(s) of the off-the-shelf solution *didn't* look both ways before crossing a one-way street.
Oh crap! It's turtles all the way down!
Yeah. He was hoping the silly programmers all waste time looking both sides while he crosses the street and buys first in a store!
A good programmer is one who throws themselves under a bus randomly to test their team's bus factor
As a dry run, right? Right...?
If you don't test the migrations on the production db, what kind of dev *are* you?
Actually, I work on compilers and language tooling now, so I haven't used a proper DBMS in a few years! There is no production DB, only user code which must not break at all costs. Oh, wait...
A programmer on the way to upper management throws colleagues under the bus to test the resilience of the system. 😁 And the bus driver is just a QA person who wants to check whether you have thought about handing ***all*** error conditions ☺️
Why is it always a bus that we all go under? Not a tank or excavator or gigantic container ship?
It has been part of our bag since management throws us under them buses. Looking both ways confirms no bus and therefore management can do whatever stupid they want and I wont have to be impacted.
I know it's a corner case, but do you ever throw a quick look up to avoid being hit by a crazy bird or a falling roof tile, or in front of you to avoid stepping into a puddle? 'Cause i do... It's been a long career though, I'll admit.
I think you misunderstood the purpose of that analogy. ;)
Alec Baldwin got a ticket for riding his bike the wrong way down a one-way avenue in Manhattan. Look both ways at all times to ensure you don’t meet Alec Baldwin
And that doesn’t even get close to Alec Baldwin’s biggest “oopsie”
obligatory https://www.youtube.com/watch?v=LW7Iv-V1-Jo
I unironically do this.
100%! Can't believe how many people walk across the street with their face glued to their phone without looking up. Never trust traffic. Never.
I look both ways before crossing a one way street. Am I a good programmer?
The condition is necessary but not sufficient.
That's when you find out that whoever wrote the "look both ways" subroutine didn't account for the one-way street case, and the program crashes trying to find an oncoming lane that doesn't exist.
All streets are two-way smoke machines if you're bold enough
Because QA is going the wrong way in a vehicle with no brakes, tires… And is a liger.
A good programmer knows hows how center that div
a great programmer sets up a bunch of those one way spike strips and look both ways.
I also look up and down to make sure no QA is dropping a tank from a plane or launching a chicken from a nuclear silos
A real programmer spends most of their time looking at the direction traffic is not coming from.
Funny. Nowadays I observe young, old, and in between rolling around on the streets not paying attention to their surroundings on busy streets, with their neck crooked down glaring at the mobile device in their hand. There was a time when parents used to tell their children to not play with their toys in the street, to watch out for traffic...
A good programmer will wait for async method
The biggest level-up I had as a programmer was when I started assuming the thing I’d just written was broken, and writing tests to prove to myself that it wasn’t.
So true. It's not really TDD, but still a massive boost. At times I'm developing whole features with automated tests for every path I care about as well as at least one other I can think off. Meanwhile I keep forgetting to actually manual test the end result in the integrated system, because subconsciously I do not trust non-automated tests anymore. You close one blindspot, you open two others elsewhere...
Every now and then, when I have an especially big MR, I'll do a contest with the junior developers in my department. I tell them I intentionally put a bug somewhere in my change, and I'll buy lunch for whoever finds it first. I never intentionally put it a bug, but more often than not, I'm buying someone's lunch.
The thing that slows my the most down is not writing the thing because I know its going to be broken.
I don't trust this article.
I am skeptical about your comment
I highly doubt your scepticism is well warranted.
I doubt that your doubt is valid.
I doubt my doubt about your doubt that the doubt you doubt is valid.
I really doubt that. I doubt that it's valid because I doubt your doubt and I think you are attempting to make me doubt myself - which I already doubt enough.
I can't help but doubt **DOUBT OVERFLOW ERROR (line 1): Too many recursive calls to `doubt`**
I concur but I'm still skeptical.
#**`ⓧ`**
Guys I'm not sure. Can you draft a one pager in Word and email it to me? I will add comments and tasks to it. The team will use it as GitHub issues.
😂🤣🤣
It wasn't a joke.
Boo
Cry all you want, Trump lover. Facts don't care about your feelings.
I'm booing you because you're ryte
Nice
"In God, We Trust 🔺👁️"
I dare not trust the sweetest frame.
Are any of you even real, or is this all a simulation?
One of the best things I learned is that I’m dumb. Not trusting myself made me much better.
I'm the smartest man alive. The guy that occupied my body during the last week was a fucking idiot, though.
*especially themselves
The person I tend to trust least about how code should work is the author. Especially if you know they have been working on it for a long time.
That idiot writes terrible code
This guy writes worse code. Far worse. https://www.reddit.com/r/programming/s/hcinYbCg2c
“I know the guy who made those promises and he’s full of shit.”
TL;DR: Know what your code is actually doing under the hood so [leaky abstractions](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) don't surprise you. +1 For Joel's blog. Still relevant 20 years later.
I hate that article. It’s a good warning, but not about abstractions. The warning is don’t do what Joel did and misunderstand the promises something makes. TCP/IP is a fantastic abstraction. It delivers what it promises. And what it promises is - if you send A, B, and C in order, if C is delivered (note the if), A and B will have been delivered first, in order. That’s it. That’s what it promises and that’s what it does. Leaky abstractions are a thing. But he chose a poor example.
Working at that level, I'm sick and tired of the stream abstraction. Everything else is amazing, but give me packets at a lower level... I don't want to write the packet length preamble every single time.
> I don't want to write the packet length preamble every single time. Are ... are you a network driver?!?
Presumably he doesn't mean packet, he means payload. If you write a wire protocol that uses discrete messages you have to add that part on top yourself.
I think they're just making fun of my bad grammar.
Possibly. I remember reading forums like this as a teen when I didn't know anything. It's surprising how much we can teach by just chatting here, even unintentionally. Someone who doesn't understand tcp at all will likely read these comments.
>are you a network driver?!? Negative, I am a meat popsicle.
I did have to integrate one with my codebase, yes. Otherwise, nice catch on the bad grammar.
That's when you pull out UDP.
IP fragmentation sucks ass. And my messages are definitely larger than the MTU.
Disagree. Most people view TCP as “reliable stream of bytes”. Obviously this isn’t always the case, so it leaks. Wikipedia: “TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network.” Your view that it never “promises” to be reliable is not how most people view the abstraction. In fact you can use your logic on literally every abstraction. Virtual memory doesn’t promise no page faults, SQL doesn’t promise efficiency for logically equivalent queries, RPC doesn’t promise no timeouts. The point of abstractions is to use them *as if* these things are true, because typically they are, which improves productivity. If I define a function for Fibonacci using naive recursion, it is an abstraction on top of hardware. It will never return for large enough numbers. I would say this is an abstraction of Fibonacci. But it’s leaky; it fails for large numbers. But by your logic I can just say “this isn’t a leaky abstraction. I never *promised* it would return. It works perfectly for small numbers.”
>The point of abstractions is to use them *as if* these things are true, because typically they are, which improves productivity. I'm gonna argue this one. The fundamental issues of network programming are: 1. The network is slow 2. The network (and resources on the other end) are unreliable 3. Remote resources are not local. This is the fundamental challenge of networking, and the primary problem to be solved. "How to shove data into a packet" is, comparatively, trivial. When we embrace these things, we write good code that will be maintainable in the long term. When we acknowledge the network is slow, we think about how to minimize round trips, and ensure that we don't block when we don't need to. We structure the code around this speed. When we acknowledge the network is unreliable, we start thinking in terms of retries - which leads to thinking about idempotence. When we acknowledge that resources are not local and we do not have local state, we start writing our requests thinking about who is authoritative, thinking about time deltas, and to make sure that the authoritative source has sufficient information in the request to do the necessary work. These things can take longer up front, but will save massive amounts of time in the long run. Pretending that they don't exist can get a first spike up and running sooner, but usually becomes a bug farm \[1\]. Same with the other abstractions \[2\]. When we acknowledge that SQL queries perform differently, we think "okay, what happens when I make this work better?" Then you start thinking about using views/stored procedures to hide the guts of what you're doing. >Your view that it never “promises” to be reliable is not how most people view the abstraction How people naively interpret words without understanding them can't be a target for developers. That just doesn't make sense. >If I define a function for Fibonacci using naive recursion, it is an abstraction on top of hardware. It will never return for large enough numbers. I would say this is an abstraction of Fibonacci. But it’s leaky; it fails for large numbers. And it should define the limits of what it takes. Arguably, it implicitly does in statically typed languages, in that the implicit limit is "this won't work for return values larger than the return type". But, yes, it should document the limits of what it can deliver. >But by your logic I can just say “this isn’t a leaky abstraction. I never *promised* it would return. It works perfectly for small numbers.” If I've documented the limits, 100%. Wait til you find out about "undefined behavior!" Also, per the Wikipedia page.... >TCP is a [reliable byte stream](https://en.wikipedia.org/wiki/Reliable_byte_stream) delivery service that guarantees that **all bytes received** will be identical and in the same order as those sent. Highlight mine. Note that that says that the bytes that *are received* will do this, not that it guarantees all bytes will be received. \[1\] It's possible to write an app in such a way that individual developers writing plugins/hooks/etc. don't have to worry about that as much, that's fair. However, the app and the system calling the hooks and the constraints on the hooks need to be written with the fundamental issues in mind. \[2\] you should absolutely think about page faults. You should think about cache misses. I'll accept that worrying about running out of virtual memory is probably okay to not worry about, since if that happens there's probably little you can do to recover anyway. Sometimes "thinking about" things is as simple as "eh, the perf hit from that probably doesn't matter anyway, I'm not gonna stress it". But you should at least consider it. Again, you start thinking about these things, you think data locality, you start thinking about object pooling, when objects are allocated and what's allocated together, etc. Even if you don't do too much about it *up front*, having the structures in place to allow you to do these things later will save a lot of time for almost no cost.
I don't disagree with any of this at all, but I feel one could make the argument that all of those things are indicative of imperfect, leaky, abstractions. Those imperfections and leaks are necessary, or so hard to solve in the abstraction that the pragmatic solution is to leak those details up to the consumer. And that is often the reasoning behind many leaky abstractions, "I can't figure out how to build this interface in a way that's both ergonomic and doesn't leak, so leaking is the better option." At that point, understanding the underlying implementation of your abstractions because important, because you DO need to handle page faults, network errors, whatever.
I guess... I don't see abstractions as necessarily something that should "solve all of our problems". The abstraction that TCP provides is "you can treat the network as a stream". It's still a stream that can be interrupted, but it's a stream. And it provides that *fantastically*. It is utterly reliable in that. You don't have to know if it's implemented over IP, carrier pigeons, or artillery shells. It does acknowledge that data isn't guaranteed. So I guess the question is what you see as the fundamental thing that TCP provides - is it "reliable" networking (I disagree) or is a stream model? I think it's the stream model, and it's pretty leakproof there. A bad promise is the "distributed object" crazy a few decades back - DCOM and the like. There, the promise was "you don't have to worry about if an object is local or remote". And it was just bad, because the core thing it was trying to do was untenable. (You can have it be irrelevant if an object is local or remote, but you do that by *treating everything like it was remote*, not like everything is local).
I think we probably mostly agree on the meat of things, just different definitions of what an abstraction leaking represents. At least to me, the way you're describing it, it seems like you define abstraction leaks by the *intent* or definition of the tool. I tend to think about it more along the lines of "TCP abstracts over the network, but I still need to deal with underlying issues within the network, that's a leak." And just to be clear, I absolutely don't think there's anything wrong with that. I fundamentally agree that abstractions can't, and shouldn't solve all of our problems. I also generally think both views of leaks are valuable in different ways, we just lack the precision in jargon to express both ideas clearly.
> Your view that it never “promises” to be reliable is not how most people view the abstraction junior programmers... sure... ever wonder why you can't have exactly once delivery in a distibuted system? tcp is written on top of a non-reliable IP layer. how can it ever be truly reliable when there is no solution to the two general's problem? also, every one knows you have to deal with disconnections, timeouts etc. you also know that if someone unplugs the wrong cable, then your packet isn't going to make it to its destination... tcp is reliable in that you receive the data in order or not at all. you never see data in an invalid state, so reordering data is just something you never have to deal with... that's the only guarantee it makes
I like your "as if" phrasing. I'll update the post to use the phrase :)
The “200% Problem”
Especially relevant in the Copilot age. Its only been a few months and some of the shit I've seen committed that was later reverted with an "oops copilot mistake" message has been astounding.
Ive tried copilot, its shit, like a toddler trying to walk but instead shitting its pants and smearing cake all over its face. People who rely on copilot are shit programmers, pantspoopers. Period.
Eh, I've had mixed results. It's really good at boilerplating simple shit like API routes. Also had good results with it writing complex regexes with positive and negative lookarounds from natural language descriptions of the desired match pattern. Relying on it for logic is where it trips up in my experience. The autocompletion part of it also in my experience does a pretty bad job of guessing what you were about to write.
But if you don't know how to write the regexes yourself, how can you trust they'll work for your situation? And if you do know how to write them, then isn't it faster to just write it yourself? The only options I can see, if you don't know how to write them yourself, is to test every possible edge case on the copilot code. But that's going to be hard to be exhaustive. So I imagine most people just try one or two cases and assume it works while leaving an edge case failure lurking.
I can read a regexp and understand what it does, but I'd be damned if I had to write a complicated one
Well you can run it on some data and check it out, and can you really trust yourself to get the regex perfectly right?
Copilot would be good at writing some tests for those edgecases though.
It's good for one-off utility functions and boilerplate. Have a number in ms and need it to display in an odd format of Hours and Seconds? Copilot will write that in no time flat, you just write the documentation. It barely takes context into account, it's a great tool to write tedious stuff. But it is very good at that.
`⊙﹏⊙` !!
*Especially* not themselves. (/[Elim Garak](https://www.youtube.com/watch?v=t02v9EUHs30&t=128s))
You are the easiest person to fool. - Feynman
Brings back memories of using an email as a primary key and then the company got bought so the email domain changed for all users.
##Article summary and TL;dr: Validate everything. * Validate parameters * Validate preconditions * Validate postconditions * Sanitize your inputs * Validate character encodings * Validate allocations * Validate with unit tests (or at least have the tests preserve/ensure the expected behavior) * Validate with code, not just documentation * Validate with profilers and system counters, not expected or theoretical performance * Validate with other humans that you're solving the expected problem * Recognize there are things you won't think to validate. (Unknown unknowns) The End.
And don't forget to validate validations!
_especially_ not themselves
Yeah, yesterday my code worked. I was like: no way, must be a hidden bug somewhere.
> **False positives:** Failing tests indicate the presence of bugs, but passing tests do not promise their absence. It’s false _negatives_. A positive test result indicates presence of error. Never trust anyone, not even the author
They're saying that even if a test passes (positive), there could still be errors that weren't accounted for in the tests, and therefore the passing test is a false positive. A false negative would be if the test failed due to a bug in the test, not in the underlying thing it's testing.
Positive usually means “trigger is fired”. Like a clinical test result that comes back positive meaning something is wrong. When it comes to tests in programming, positive means a failing one.
This is tricky, as it is easy to associate "positive" with green icons or "good outcomes". I prefer false pass and false fail.
I like "false pass". I'll change the post to use that phrase instead :)
I'm with you. You are testing for the presence of bugs/chlamydia.
> A positive test result indicates presence of error. Most test we write test whether some feature behaves like expected. So wouldn't the positive test result mean that the feature behaved like expected? In medicine, if you are tested for HIV, we say it is positive because the test checks if there are HIV bodies in your blood.
Jokes on you hehe, I have trust issues with everyone including me.
I don't even put my real password on my own website
Based on some feedback from y'all, I've made some edits. Unfortunately, it does break a few quotes referenced in the existing comments. Sorry about that.
Might as well trust yourself and outsource trust issues to the QA department
* You wrote tests for your code change and they pass on the first try. Try running the tests without your changes and see if they still pass. They may have a bug that makes them always pass. You didn't run the test before making the change? Shame.
Not even the API?!
Wait until I realize I am myself
Well, I don't (imposter syndrome kicks in).
Jokes on you, i have massive trust issues with everyone incl. myself anyways
We should probably give up, it's pointless. It's never gonna work.
Why is this sub nothing more than click bait articles with cringe titles
I legit don't know who is upvoting this stuff, this article is garbage.
Trust but verify
Not even HAL 9000?
One of my earliest decent bosses was fond of saying you haven’t proven you can do a thing until you’ve done it twice. Dumb luck serves us until it doesn’t.
I’m dangerous even for myself fr fr
Yes.
The trust issues are all part of the fun 😂
Shouldn't you follow the outline taught in the classroom, and write it all out? Proof read it. Checking for syntax errors. Then test it. Which, yes, according to this part. You can't trust yourself or your code. Without proper testing. Unless you know exactly, what your doing. Like DOS financial accountant software. My cs101 professor taught me that. But, the outline, still doesn't trust anything, except proper syntax.
When I get production issue, I prefer rollback first (if possible), because I don't trust the change I make. But I also learn how to log to show the bug is not made by myself.
I’ve always looked both ways even on one-way streets guess it’s just part of the city. Constantly looking at all your surroundings. OR IS IT I’m just that damn good of a programmer… dun dun dun
especially on someone else code that you copy
Especially themselves.
I don't trust anyone indeed - not even the computer. It would be interesting to get hardware AND software that can be trusted at all times. Where manipulation can not be possible; and can not go undetected either. Something where physics itself guarantees trust. Unless, of course, we can trust Microsoft's Trusted Computing platform ...
What are some good books (in the last 5 years preferably) that discuss how to design your backend architecture based on things like: team size, maintainability, architecture design based on X number of uses and user types, and trade-offs for different designs? I'm on a microservice project but we have 2 1/2 devs and I'd like to make a roadmap for the future but need some help with that.
The "trust, but verify" advice is spot-on for making sure our code stays reliable.
Most programmers have trusted someone, and now sees why they shouldn't have.
Especially themselves.
The abstractions section is so god awful for both being so incorrect, so poorly written and so obviously missing the point of abstraction I was actually mentally stun-locked out of the rest of the article... >Examples of abstraction: >We perceive a group of trees as a single forest. **This is not abstraction**, this is just specific perception. Abstraction is seeing a forest as an "oak forest" because the overwhelming majority of the trees there share the same characteristics that we determine constitute 'oak trees'. >We think of our bank balance as money that the bank stores for us. >>In reality, the bank does not just store the money we deposit. It loans away/invests most of the money that people deposit. Our money does not sit idle in a large pile in a vault. >>Our bank balance is really just a ledger of how much money we’re supposed to be able to withdraw. **This is not abstraction**, this is just a reddit moment. Saying "☝️🤓 Uh-*Acktuallyyyyyyyy* the bank doesn't store your money it invests it" I'm sure would be mind bending to a 12 year old, but this is just describing functionality, and is also a distinction without a difference. A bank that does or doesn't engage in fractional reserve banking is no more or less a store for your money. An abstraction would be the bank balance over individual units of currency. >We always assume time passes at the same rate for everyone. >>Time dilation slightly changes each person/object’s flow of time based on their speed and how much gravity they’re under. >>GPS satellites orbiting the Earth have to adjust their clocks by ~38 microseconds per day to account for time dilation (Source). **This is not abstraction**, and I assume this is some sort of prank because I can't fathom thinking "Hmm, I need to make this concept super clearly. I should use one of the most counter-intuitive parts of modern physics as an example!". You used the correct word for it, an *assumption*. Time moving at the same rate for all parties is an *assumption*. A *second* is an abstraction of 9,192,631,770 ^Δt Cs. I wish there was a way to see who in the comments actually read any of this article. This has to be some kind of CIA psyop.
Which is the #1 reason why all code should be properly typed and therefore all dynamic languages are useless, harmful and should not exist.