31–40 of 87 posts
> Complexity has to live somewhere. If you are lucky, it lives in well-defined places. This whole section makes me think of construction which has similar abstraction and hidden complexity problems. It strikes me that they solve it by having design be entirely separate from implementation. Which is usually the corner where all our luck as software developers inevitably runs out. Our methods are still rather "cowboy."…
I think "types" is the solution of two completely different problems: 1. how to specify memory layout for faster execution 2. how to give hint when I press . in IDEs if you use typing outside these two scopes you'd probably find many troubles.
Types imbue pure data with meaning. That's pretty much it, and the other uses of types flow from that. Whether you use that meaning to produce IDE hints (say, via Python type annotations, though I am aware Python typing isn't only that), or you feed it to a compiler that promises that it will ruthlessly statically enforce the invariants you set via the types, or anything else, is up to you, your goal and the language…
For isn't, the return type STM () doesn't give you anything back, but it declares that the method is suitable for transactions (i.e. will change state, but can be rolled back automatically)
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…
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.
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.
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 bugs" themselves havent really delivered anything useful.
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…
> Complexity has to live somewhere. If you are lucky, it lives in well-defined places. This whole section makes me think of construction which has similar abstraction and hidden complexity problems. It strikes me that they solve it by having design be entirely separate from implementation. Which is usually the corner where all our luck as software developers inevitably runs out. Our methods are still rather "cowboy."…
It’s crazy to see what we’re capable of building now vs even 15 years ago.
Earlier quoted context omitted.
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…
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.
Throwing away the test means throwing away that user story and the value that comes with it.
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.
Earlier quoted context omitted.
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…
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.
Maybe you meant to invoke .bar(), but at least we know thanks to type checks that the target exists.