I find this topic particularly interesting. I've often said to others that software, in itself, is a general abstraction of one or more complex tasks. The whole point of software is to hide complexity and make possible, in a hopefully simpler manner, doing things that would otherwise be very difficult or impossible. Despite what users may experience, the complexity remains but becomes hidden.
Isolating complexity is the essence of successful abstractions
61–70 of 87 posts
Re: Isolating complexity is the essence of successful abstractions
#62Python showed what relaxed types could do. And we could go a long way as it turns out without types. But there are use cases for types, and even python admitted such when they added type annotations. However, when I was a kid a would put a firecracker next to an object. I didn't bother running the scenario through a compiler to see if the object was of type Explodable() and had an explode() method that would be calle…
Python showed that you can be wrong about your types and still build a successful product.
Re: Isolating complexity is the essence of successful abstractions
#63Isolating complexity, I would say, is a consequence of using good abstractions... not necessarily the essence of abstraction however. The essence of abstractions are in semantics. I define a type and an algebra of relations on that type which gives me theorems I can use. That is the essence. The consequence is that I can now think in terms of the theorems and definitions I've established rather than all of the details at the lower-level.
However, sometimes it's a bit over-rated when all that's needed is some information hiding and indirection, which is what this article appears to be discussing. These tools are the ones that are "leaky" in the sense that the complexity they attempt to hide often escapes the confines of their interface. It tends to give "abstraction" a bad reputation among programmers who have to deal with such systems.
Essential complexity does have to live somewhere. Best to be upfront about it.
Re: Isolating complexity is the essence of successful abstractions
#64> The question is first of all whether we have written them down anywhere The only hard thing in software: papers please (easily accessible documentation)
The hard part about documentation is that it requires you to have a component that can be comprehensibly and sufficiently documented. So much of the software written is seen as provisional, that even its authors think “well, we’ll document the v1”, not realizing that their prototype is just that.
Re: Isolating complexity is the essence of successful abstractions
#65The author's assertion is true - complexity has to live somewhere. The nuance, though, is that all places complexity can live are not created equal. Let's take the example of memory management: by pushing that complexity into the type system, Rust forces the programmer to deal with it and design around it. At the expense of some performance, we could instead push this complexity into a runtime garbage collection syst…
(I'm not responding directly to parent post, more adding my two cents in agreement)
'Necessary complexity' needs to live somewhere. There is often a core of complexity that is intrinsic to the problem being solved. This cannot be removed, only moved/converted/etc..
That doesn't mean everything needs to be complex, and that you need to 'collect' it somewhere. There is such a thing as unnecessary complexity, and code that has a lot of it is 'bad code'. Don't fall for the trap of thinking that you can't improve code by identifying and eliminating unnecessary complexity.
Re: Isolating complexity is the essence of successful abstractions
#66Python showed what relaxed types could do. And we could go a long way as it turns out without types. But there are use cases for types, and even python admitted such when they added type annotations. However, when I was a kid a would put a firecracker next to an object. I didn't bother running the scenario through a compiler to see if the object was of type Explodable() and had an explode() method that would be calle…
Python showed that you can be wrong about your types and still build a successful product.
Unless your product is a Boeing 737 MAX.
Re: Isolating complexity is the essence of successful abstractions
#67Earlier quoted context omitted.
It's not about hiding the complexity in the type system, that is, the complexity of the type system. At least for Rust, it's about that (yes, complex) type system isolating the even worse complexity of tracking lifetimes and aliasing and such, for all possible control flow paths, in your head. It's harder to summarize what Typescript is isolating, except that JavaScript function signatures are the flipping wild west…
Sometimes the original js function isn't safe at all. So does the typescript definition. For example, `Object.assign` overrides all property with same name. Sometimes you use it to construct a new object, so it is a safe usage. But what about using it to override the buildin object's property? It is definitely going to explode the whole program. However there isn't really a mechanism for typescript to differ the usag…
Yeah, TS is kinda rough that way. It's not my favorite. Harder job, rougher results, understandable to be honest.
Re: Isolating complexity is the essence of successful abstractions
#68The author's assertion is true - complexity has to live somewhere. The nuance, though, is that all places complexity can live are not created equal. Let's take the example of memory management: by pushing that complexity into the type system, Rust forces the programmer to deal with it and design around it. At the expense of some performance, we could instead push this complexity into a runtime garbage collection syst…
The other tradeoff comes with ease of debugging. Compile-time vs runtime errors. Dredging through microservice logs vs stack traces from the monolith.
Re: Isolating complexity is the essence of successful abstractions
#69The author's assertion is true - complexity has to live somewhere. The nuance, though, is that all places complexity can live are not created equal. Let's take the example of memory management: by pushing that complexity into the type system, Rust forces the programmer to deal with it and design around it. At the expense of some performance, we could instead push this complexity into a runtime garbage collection syst…
I'd add the additional nuance that cognitive load is highly dependent on the brain of the subject. One person's cognitive load is another person's effortless routine--it largely depends on how often the person works with those concepts and how quickly they can switch into the "mode". Where one person sees a wall of indecipherable matrix variables in Python, another person sees that it's obviously just a Cholesky decomposition as part of a Monte Carlo simulation.
So where to push the complexity should be dependent on who will be interacting with it and what they consider "cognitive load".
As an additional example:
> Rendering your web application entirely on the frontend in React, or entirely on the backend with templates, where all the logic lives in one place, is much easier than doing server-sided rendering then hydrating on the frontend.
For an expert front-end React developer, rendering entirely in the backend with Jinja templates would be higher cognitive load than the other options, even if it is technically simpler.
Re: Isolating complexity is the essence of successful abstractions
#70[deleted]