Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Isolating complexity is the essence of successful abstractions

v5.chriskrycho.com

Post reply on HN
Print view View original

41–50 of 87 posts

Re: Isolating complexity is the essence of successful abstractions

#41

Post by youerbt »

hitchstory wrote: post #38
youerbt wrote: post #36

Earlier quoted context omitted.

I'm a Haskell bro and I love testing. You misunderstand me, though. All I say is that maybe _some_ of those tests deliver value by just making sure that code even runs, which is otherwise covered by types.

When I do TDD (virtually every time i write a line of code) each test scenario isnt just a way to verify that the code is working, it's also a specification - often for a previously unconsidered edge case. Throwing away the test means throwing away that user story and the value that comes with it.

I believe you (other than tests being specifications, they are examples at best). But that doesn't change the fact that TDD looks more adopted in untyped languages, and that deserves an explanation.

Mine is that a lot of potential errors (typos, type mismatches) don't need to be exercised by running code in typed language.

Yours is... well, you don't really address it.

Re: Isolating complexity is the essence of successful abstractions

#42

Post by yakshaving_jgt »

hitchstory wrote: post #35
youerbt wrote: post #34

Earlier quoted context omitted.

> That also explains why TDD is more popular in say Ruby or Python vs. Java. I'd say that TDD being more popular in untyped languages speaks against TDD, as it hints that maybe some of its benefits are covered already by a type system.

Id say if you think tests and types are doing the same thing in the same way you are badly abusing at least one of them. One attacks the problem of bugs from the bottom up and the other from the top down. They both have diminishing returns on investment the closer they get to overlapping on covering the same types of bug. The haskell bros who think tests dont do anything useful because "a good type system covers all…

> The haskell bros who think tests dont do anything useful because "a good type system covers all bugs" themselves havent really delivered anything useful.

Please don't do this. It's not constructive.

Re: Isolating complexity is the essence of successful abstractions

#43

Post by yakshaving_jgt »

dartos wrote: post #16
knome wrote: post #12

Earlier quoted context omitted.

I didn't get the general idea that the author thought they hid the complexity, but rather that they exposed and codified it. They gave the complexity that would previously live in your head somewhere it could be expressed. And once expressed, it can be iterated on.

Encoding complexity in your type system forces you to deal with that complexity throughout your codebase. It doesn’t give complexity a specific place to live.

If you parse a value into a guaranteed non-null value at the system boundary, then you have eliminated the need to check for that nullability throughout the rest of your codebase.

Did you mean to write the literal polar opposite of what you wrote?

Re: Isolating complexity is the essence of successful abstractions

#46

Post by freehorse »

I do not think of complexity as one thing. Abstractions are about both hiding and exposing complexity at the same time. Different levels of abstractions can expose or isolate different part of complexity. Exposing parts of it in a way that they become amenable to your tools is as important as isolating other parts somewhere in the background. Essentially, this has to do with how well a given abstraction choice maps into the structure of the problem-space and the relationships there. The choice of which parts of complexity you isolate and which you expose is important. You probably do not want to deal with everything at once, but also usually you cannot avoid dealing with something.

The way I primarily see (and often like) type systems wrt complexity is as choosing which parts of complexity are important and exposing them (and rest being still there to deal with). There is a cognitive aspect to abstractions and complexity, irrespective even of IDEs, debuggers, compilers etc. I personally want my abstractions to make at least some sense in my head or a piece of paper in the way I think about the problem before even I start writing code. If the abstractions do not help me actually cognise about (some part of) the problem, they probably solve other problems, not mine.

Re: Isolating complexity is the essence of successful abstractions

#47

Post by talles »

This is such a simplistic view on the matter.

The author talks about complexity like it's always an intrinsic thing out there (essential) and the job of the abstraction is to deal with it. It misses the point that a great deal of the complexity on our plates are created by abstractions themselves (accidental). Not only that, sometimes great abstractions are precisely the ones that decide to not isolate some complexity and allow the user to be a 'power user'.

Re: Isolating complexity is the essence of successful abstractions

#49

Post by bluGill »

youerbt wrote: post #34
chuzz wrote: post #32

That's why Typescript/Python optional typing hit the best balance for me. Coding in duck-typed language is generally fine when your test suite is as fast and frequent as a type checker. That also explains why TDD is more popular in say Ruby or Python vs. Java. Speaking of Java, the problem with types is when you try to reify every single problem you encounter in your codebase. By the way, python has structured types…

> That also explains why TDD is more popular in say Ruby or Python vs. Java. I'd say that TDD being more popular in untyped languages speaks against TDD, as it hints that maybe some of its benefits are covered already by a type system.

You did clarify latter a bit, but this cannot stand unchallenged. TDD and tests solve different problems from types and so are valuable for that. Tests assert that no matter what you change this one fact remains true. Types assert that you are using the right things in your code.

I don't think it is lack of types at fault for untyped languages liking TDD (though I miss types a lot). I think it is there is no way to find out if functions exist until runtime (most allow self modifying code of some form so a static analysis can't verify without solving the halting problem). Though once you know a function exists the next step of verifying the function (or an overload in some languages) exists does need types.

Re: Isolating complexity is the essence of successful abstractions

#50

Post by titzer »

talles wrote: post #47

This is such a simplistic view on the matter. The author talks about complexity like it's always an intrinsic thing out there (essential) and the job of the abstraction is to deal with it. It misses the point that a great deal of the complexity on our plates are created by abstractions themselves (accidental). Not only that, sometimes great abstractions are precisely the ones that decide to not isolate some complexit…

> sometimes great abstractions are precisely the ones that decide to not isolate some complexity and allow the user to be a 'power user'.

I agree with this. Sometimes abstractions are the wrong ones. In a layered system, where each layer completely hides the layer below, sometimes abstraction inversion (https://en.wikipedia.org/wiki/Abstraction_inversion) occurs where the right mechanism is at the bottom layer but intermediate layers hide it and make it inaccessible, leading to a crappy re-implementation that is slower and usually less capable.

Post reply on HN