2 ms·
Let's turn the knobs on the scenario and see how it appears: >>> >>> with the advent of the first programming languages you no longer had to think in terms of
by ithkuil 6y ago
Let's turn the knobs on the scenario and see how it appears:
>>> >>> with the advent of the first programming languages you no longer had to think in terms of registers, loading operands from memory, storing the results back, spilling registers to the stack.
>>> You _are_ handling registers and memory spills, but just one step removed through the use of C.
The analogy may not be perfect, but I think it makes obvious some of the things also mentioned in sibling comments: it's all about habit, maturity and thus trust.
If you trust your tools are working correctly, if you know how to deal with their well known quirks, you'll just rebase on top a layer and hopefully boost your productivity and tackle more complex problems more easily.
Maturity is important because if today you're more likely to blame yourself than the compiler when your stuff doesn't works, it's just because you're lucky to work with mature and popular toolchains. (And I'm not only talking about the past when compilers where new and unproven, it still happens today on some niche embedded toolchains).
So, yes, it's indeed rational to be wary of new unproven abstraction layers as they could bring more pain than help.
It's hard to judge when that line is crossed though.
I personally like to know how stuff works under the hood anyways. I find it useful in practice and it gives me confidence in using the higher layers, when they make sense, or stay with the lower level layers, when they make sense.
Occasionally I still write some assembly. But most of the time, for most of the stuff, it just makes more sense to use a higher level programming language.
I see k8s in a similar way. We have operating systems, programming languages, etc; all sorts of abstractions that help us separate concerns and have specialists dealing with the nitty gritty details of some stuff, so that everybody else can be specialized in something else (just like in real life)
- lifeisstillgood 6y agoBut i think this is apples and oranges - C maps pointers and memory allocation in a very direct robust manner, even Python allows you to dis back to see the stack. But this hard-line-to-underlying reality is unlikely to exist looking at how this months k8s will configure last years AWS route53. It just works 80% of the time is a disaster, 98% of the time might be bearable. is it above 99%?
- ithkuil 6y agoIndeed, my point was that it's a quantitative question not a qualitative one. When compilers created buggy code every other day, when memory allocators were unreliable because memory fragmentation would make it likely for new allocations to fail in the lifetime of a normal program execution, etc, it would be, as you said "a disaster if it works <95%" of the times. Did k8s reach 99%? The jury is still out. Probably not yet, but in principle I don't see anything wrong pursuing that path just because it's "another layer". We use abstraction layers all the time; they allowed progress (Yes often we went too far)