Types are a basic tool of software design (2018)
tedinski.com
tedinski.com
After a while, I found myself adding back types in a decent number of places to "anchor" the type inference, indicating that a certain type/signature is fixed and a change should be carefully considered.
I still don't know how folks deal with these kinds of changes in weakly typed languages without always allowing bugs to pour into their code over time. But I do love the "move fast" and low boiler-plate aspects of "typeless" coding.
All strong types do is make it explicit at compile time (and with static analysis), instead of leaving it to be discovered in tests or at runtime.
This is why I'll use Python for small one-off scripts but anything that will be in regular use I prefer to do in Java. Even though I have many more years of experience with Python.
- Don’t have big projects.
- Have lots of unit tests to cover some of what a C# or Java compiler would have caught through static analysis.
- Don’t even consider doing certain kinds of refactoring (which would be trivial on a strongly typed language) because they have no way of knowing what will break.
Of course it’s not impossible to have a good JavaScript code base, it’s just much harder to have a very large one where it’s still economically feasible to make significant changes to it without having to resort to a rewrite or needing to write tests which would be covered by the compiler in a strongly typed language.
Too bad you don't know me so you're left to ad-hominem attacks on my expertise.
>without having to resort to a rewrite.
Glad you get to move the goalposts anywhere you want to justify any comment you make. You haven't worked on every codebase that ever existed, even though it sounds like you think you have.
In many cases, yes, it is worth a rewrite instead of trying to shoehorn something that exists, only because it exists but is the wrong solution for the new requirements. We're not going to get into the weeds of every kind of refactor in every kind of codebase here on HN, so instead you can move the goalposts and I'll just stop replying here. We can agree to disagree and call it a day.
I also haven't seen every codebase in existence, but I have seen enough "it's only going to take a year" rewrites that absolutely should have been refactorings and so I remain rather skeptical of the claim that rewrites make sense in "many cases".
If dynamically typed languages only worked well in absolutely pristine codebases that never saw any hacks or poorly thought out solutions, I'm not sure they'd be actually useful in most real-life settings. Of course, people refactor all the time in dynamically typed languages as well.
Strong and weak are sort of coherent as a spectrum, but they aren't a typology, and they do not in any sense or in any case reduce to static vs. dynamic types. Conflating them is not useful: I can make a good case that Julia's type system is stronger than C's, but Julia is dynamically typed and C is statically typed.
There's no reason to keep doing this. It's a malapropism, we could just.. not say that. Especially in a thread which is specifically about types.
Given the fantastic iteration speed that the Web platform had (and still does to some extent) I didn't really miss a compiler for catching errors. The main improvement is that IDEs find it easier to support big refactoring.
I also worked on a mid sized scala codebase a little later on. Scala is probably better now than it was then, but despite (perhaps because of?) the cleverer type system, everything was so slow that it actually took longer for many bugs to be highlighted by the compiler than they would have been found by hitting f5 in a browser window with a good js codebase. That was when I realised that as a developer I care a lot about when an error is highlighted in wall clock time and not at all about which compiler phase it was discovered in.
I found working with type inference being its own skill. If you know how to place type annotations well, the ripple effect only affects one or two callsites and then the type inference just continues to infer what you meant in the subsequent code. Though we may be approaching the structuring of the code differently so YMMV. But I haven't had issues even with complicated member constraints which replicate dependent typing.
F# is derived from OCaml, and they both support interface files–in the case of F#, with the .fsi extension–which is designed to solve exactly this problem. After settling on the surface area of your module, you nail it down by writing an interface file with the exact types you want to enforce. The compiler then uses this to check the usage of the module by its consumers, and provides much more accurate type errors.
It works really well.
Looks like so much useful documentation for understanding the code, assistance for refactoring, and static checking (which are like always running, fast and exhaustive unit tests for free) for a modest amount of type annotations that each person on the team would need to recreate in their heads anyway. Static type checking is so useful for catching runtime errors to do with optional values and index/key not found error too, that always create a load of edge cases.
Editing JavaScript with no types is scary, especially when you didn't write it. You're mostly guessing what the types must be and hoping your running code exercises enough edge cases to catch any problems. "You should write more tests" as an alternative rings hollow for me because (for the things they will check for you) types are more concise, exhaustively check all values, are ran continuously, are fast, aid with automatic refactoring, document the code in the same file its in, and will locate exact snippets that are causing errors. More often than not, test mostly check happy paths, aren't even close to as exhaustive, and nobody is writing tests that check every combination of function parameters being null vs non-null, string vs number etc. (which would be a huge amount of noise in your test suite that would slow down refactoring too). Types are a compliment to tests as well, not an alternative.
I can't relate to arguments about types getting in the way (as long as you avoid trying to get too clever like with complex generics and TypeScript conditional types). Usually when this happens, it's because it's hard to reason the runtime edge cases in your own head and there's probably a simpler way to write it. I'd love a good non-niche example to the contrary. Worst case in TypeScript, you can use `any` as an escape hatch anyway so as long as you can add types to most of your program it's not a strong reason against for me.
I’m not joking. I prefer the after.
Edit: thanks. Yes, commas, not comments.
Some of the codebases had tests, a good chunk of which could (and were) eliminated simply by using TSC as part of the build process. I think allowing the compiler and tooling like prettier to make choices for you leaves more space for you to think about the problem, not the myriad of problems _around_ it.
I've worked on dynamically typed code-bases in the past, and also on code-bases without formatters like prettier... and I'm not going back there.
So many odd bugs can be avoided simply by taking a little bit of time and declaring some types. It doesn't have to be a super fancy type-system (I actually prefer if it isn't), but I really want to know whether something is expected to be a string or a number, or what properties an object can be expected to have, or what values a literal can accept, and so on. It's just so frustratingly time-consuming to figure out in hindsight. And all for some person's odd perception of simplicity.
Same for formatters - all the squabbling over some personal preferences on how code should be formatted. Hell no. Let's install some opinionated formatter and let it do its job, I want to tackle more interesting problems than yet another narrow-minded discussion about necessity of semicolons, placement of whitespace or line-length.
I'm at a point where I straight-up refuse to work with people who prefer to work that way; or at least require them to be a few departments away from me. They can be programming gods; if they can't be arsed to type their code so I can immediately grok it, they can program elsewhere.
I sometimes write TypeScript for 2 hours straight without actually running the code or any unit test, and it would just work -- the return value is exactly what you want. I don't think I can do that for JavaScript for more than 15 minutes even though they are the "same language".
This one: https://github.com/hotwired/turbo/pull/971/files#r1317386731
> function buildFormData(formElement: HTMLFormElement, submitter?: HTMLElement): FormData {
> It might be useful to know that submitter is optional argument here.
> How would one express that? The variable now needs to be renamed?
And two lines later:
> const name = submitter?.getAttribute("name")
It's already easy to see that submitter is optional.
Why force yourself to read inside function implementations like this for every function you might use when fool-proof automated assistance is right there? What if the function was tens of lines long? What if the optional value only appeared inside a chain of 5 nested functions? How would you easily fix/update your code if the value isn't optional now but got changed to be optional in the future?
Manual effort like this is error-prone, not scalable, and a huge distraction. Why would avoiding type annotations be worth this?
Here's where whether or not it's defined can be traced to: https://github.com/hotwired/turbo/blob/41c074ff113a8882aadbc...
Maybe the types should have been written differently, to indicate that it's the type of the submitter property in a FormEvent. That's another cost of using TypeScript, is trying to get the types right. TMTOWTDI.
Why does that matter? Error-prone approaches create buggy code and we don't want buggy code, whether it's a library or something else. Libraries can be huge and complex, and arguably should have more robust edge case checking than regular code.
Let’s say you have some code :
const foo = {
x: 1,
y: 2,
};
const foo = {
x: 1,
y: 2,
z: 3,
};
- y: 2
+ y: 2,
+ z: 3
+ z: 3,
This is why it irritates me when people forget the trailing comma. It’s not a problem in the moment. But I know it will be a small but avoidable cognitive burden on the next PR (wait, why did "y" changed ? Oh, right, it didn’t).
All that, just to not have to add a trailing comma ?
Certainly the idea has been suggested many times. I think people end up formatting both before/after and doing a diff on formatted before against formatted after. I've done that.
Everyone likes the simplicity that comes with removing guardrails, but when easily preventable problems happen that's glanced over as an unavoidable fact of life.
easily preventable is doing a lot of work here. This is assuming the types are already written and never need to be maintained. How often does the type checker catch a problem with the code vs the type definitions themselves?
All the time? I've worked on code bases with multiple people without types, and whenever there's a place that can produce e.g. "string or undefined" like when a key might not be found in a collection, it produces edge cases everywhere that don't get noticed outside of the happy path, including after the code has been merged. You're forced to simulate in your head all the code paths, and remember which values might be optional which is error-prone, isn't scalable and eats up brain cycles.
Even typos like `object.detail.name` vs `object.details.name` cause runtime errors, or calling a function with the wrong number of arguments or in the wrong order, some of the most trivial bugs you can think of.
I don't understand how someone can dislike writing type annotations so much that they're happy having their time wasted like this when automated assistance is right there. To me, it's like not wanting to use a spellchecker when writing an article, or opting out of syntax checking code before it's ran.
I get that problems with type definitions can be frustrating but it's better than runtime errors (having to write more tests isn't better either), and often flags actual bugs, potential future bugs ("what if this was undefined sometimes?"), or overly dynamic code that's hard to reason about (e.g. conditionally adding/removing fields from objects, or having a field that changes type between string/array/undefined vs using an array of strings instead). I'd love a counter example here - often the examples I see has overly dynamic code because the coder hasn't had a strong incentive to avoid such code before. As in, I write type checker friendly code so I can benefit from type checking.
90% of type annotation stuff I work with is mundane and simple (e.g. strings, numbers, arrays, something optional, object with basic fields) and is well worth the minimal effort. The more complex stuff isn't needed often, usually optional, and gives you protection from tricky bugs too.
In Clojure, a dynamically typed language, referencing a var that is not declared, or calling a function with the wrong number of arguments will result in a compilation error. You don't need static typing or type annotations for this.
> I don't understand how someone can dislike writing type annotations so much that they're happy having their time wasted like this when automated assistance is right there. To me, it's like not wanting to use a spellchecker when writing an article, or opting out of syntax checking code before it's ran.
It's not about liking or disliking, it's about "wasting time." Spell checking and syntax checking are free, annotating everything with types and maintaining them is not.
Can it catch problems like e.g. if you try to access a `y` field on some input object but only field `x` is defined? And if you want to define a function that takes a callback that must accept two arguments? What about ways to force you to check a variable with type `string | undefined` is defined before you do something with it? At some point it must breakdown because more complex checks can't be inferred?
> it's about "wasting time." ... annotating everything with types and maintaining them is not.
See this example. I'd argue the type annotations are minimal, but you gain a lot of safety, documentation and refactoring help from them: https://github.com/hotwired/turbo/pull/971/files
Having runtime errors is the point - that's real dynamic typing for you. If not for the possibility of runtime errors, you'd have to do more to have the code run. A lot of junior devs who prefer static typing don't get it. Senior devs who prefer static typing at least understand that some have a different preference. Of course you don't want a lot of runtime errors to make it to production, but in development, yes.
There are those who think that the IDE should provide feedback at every keystroke. Most IDEs have this opinion built into them. But I don't like it very much. It's gotten to the point where there isn't an IDE I really like. I miss Atom.
Huh, I'm absolutely in the pro-static-types camp, but I never use spellcheck which I personally find distracting and unhelpful. I wouldn't consider those two be similar issues at all.
Reflecting on your comments on the Transcendental Syntax threads, you should really look into linear logic, or at least System F (https://en.wikipedia.org/wiki/System_F).
It isn't. It's the most basic value proposition of TypeScript.
> This is assuming the types are already written and never need to be maintained.
No, it doesn't.
You need to write software so that you get an application that does what you wish it to do. Does this surprise you? This is not something that was invented by TypeScript.
When a software developer wants to prevent bugs when adding features, what they do is add preconditions and post-conditions to enforce invariants, and they handle code paths specific to both the happy path and failure modes. What static typing does is ensure these checks can be done at compile time, and that failure modes can be prevented by ensuring data types that do not meet conditions cannot be passed to functions.
TypeScript allows developers to check preconditions and post-conditions by defining types and adding type assertions that verifies whether an object is of a certain type, and then assert at compile-time if they meet preconditions and post-conditions. If they specify a type that has specific characteristics, the typescript compiler helps them by automatically checking preconditions and post-conditions, and prevent code paths that are proven to be failure-prone.
This is the very basic of software development. This can only be interpreted as "maintenance" or "extra work" by someone who thinks it's ok if the program crashes and malfunctions if preventable failure modes are not prevented. This is not a trait of a programming language. This is a trait of your and the level of quality at which you do your job.
> I am excited to see how this code base changes without Typescript. The "types" or what things are will have to be communicated in some way. This may lead to very readable code.
This is funny to me. "If we don't have the compiler checking types the developers will perfectly compensate with documentation, an improvement." Maybe remove the unit tests as well, then the developers will write accurate code.
Who wouldn't want to spend some weeks or hard labor so their computers can work for a few less seconds? Let's keep what's really important in mind!
Other effective features of Ada's type system:
- type ranges (https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...)
- generalized type contracts using subtype predicates (https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...)
- attributes (https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...)
There is a quote I saw somewhere, forget where, but it was basically: define your data structure and the algorithms will reveal themselves.
That is aligned with the basic premise of Domain-Driven design: define a model of the problem domain, and everything else just falls in place.
I wonder why these articles reinvent the wheel with functional programming hand-waving when DDD has been screaming this for years.
These are two different levels of abstraction. If you're still enraptured by the fundamental mechanisms of computation (i.e. functional programming) you're not going to see the value in trying to figure out the best way to build via composing mechanisms of computation, whether it's functional, imperative, procedural, logic-based, lisp-based, object-oriented, message-passing, whatever. There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails.
I don't see why this is surprising; people re-discover old lessons daily, and petty details will always be conflated with broader themes and patterns—it's just how the human brain works. The discussion is what keeps us thinking about those old lessons. This is just a person's blog, not a journal trying to represent an industry.
I think your comment fits the "not even wrong" category. It goes beyond nonsense.
There is no DDD framework because the very idea of a DDD framework makes absolutely no sense at all. DDD is an approach to software design, not something you build and reuse.
DDD is then used to specify what types to define to put together a model of the domain. Again, there is absolutely no point to have a framework to define these.
Lastly, DDD defines interfaces for domain services, and imposed absolutely no restrictions on how to define those. This has nothing to do with frameworks.
Development speed is also irrelevant and unrealistic.
Not even wrong.
""Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.""
(Though from your description I suspect that's also not the one?)
> Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious. That was in 1975. Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language: Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.
You still have to reason about the types no matter what. But writing it down empowers you to offload a lot of mental load to the computer, asking it to check your work, give you feedback as you go. It also communicates intent to other humans who read it.
One reason I like TypeScript is that there remains a, "just trust me" escape hatch when I'm testing/hacking something and don't want to "show my work" by writing out some complex type. (Funny how "show your work" is something math teachers have to fight many students to do. This feels like the same thing). But that complex type always existed. You're just saying "trust me on this." Writing it down doesn't conjure the type into existence.
Rust also clicked for me when I understood that it's really just more of the same thing: memory management, lifetimes, etc. exist no matter what. But it offers a way to show your work, formalizing intent, so that the checker/compiler can worry about the boring problems for you.
In this sense, the issue is really about making decisions on just how much "trust me on this" is appropriate.
Space, Time, Minds. Those exist. Probably :)
Other classes can count as implementors of protocols without needing to subclass them, and static type hints will notify you if you make a function which accepts a protocol as an argument and pass something which doesn’t implement it
It is quite difficult to work on large Ruby or Python projects; interfaces are not determined, and figuring out what's happening is painful.
Still, so many devs love it, and they wanna keep working with Ruby and Python in this way.
I kind of feel that experienced devs move on, and give up projects without types.
Sometimes I wonder if this type of article is just a rehash of object-oriented programming articles from the 90s where the keyword "class" is search-replace'd by "type".
I saw this much earlier in the day and dismissed it. I just now read more of it. I was first off-put by the title, but then it goes on to say:
> [...] design is about everything that’s leftover after we remove all the function bodies. It worth taking a moment to think about what that looks like. Here are some of my own immediate thoughts: 1. Everything that’s left is just types. [...]
Which reaffirms my suspicion that "Types!" are this writer's hammer for all of programming's nails, or possibly a click-bait writing device. There's probably a better article in here trying to get out as the end notes mention. [Maybe read them first.]
But I couldn't even agree with the first one:
> I meant for the main point of today’s essay to be universal: hence my emphasis that types are central to design even in dynamically typed languages. [...]
I can't say I've ever considered types/signatures when sketching out a design. That comes much later in prototyping and actual implementation--I suppose if I used Haskell that might be different.
What do you think about when it comes to design?
“Much later” is probably an exaggeration. You get to types “soon after” the initial design.
When tasked with wearing on multiple hats (architect, programmer, user), I agree with your point. From a programmer's point of view, however, (abstract) types are IMHO indeed a much more useful tool as they cover many of the other concerns (policies, performance, etc.), too.
There are basically no untyped programming languages for a reason, types are a fundamental concretization.
In fact, I would argue there is no such thing as untyped programming, there's just different degrees to which the programmer is the enforcer of correctness.
Design often includes algorithms, which don't devolve merely to types. So this statement only makes tangential sense if all you're ever building is CRUD applications.
1) despite having tests, almost every day there's some bug in production because code expects data X but it receives data Y - this class of bugs is entirely non-existent in strict/static languages
2) to have some degree of control, they added a linter which infers and validates types, but it doesn't catch everything (see #1) and this step takes like 5 minutes - defeating the whole idea of "dynamic languages don't need compilation so you're faster with them", because modern static compiled languages can compile incrementally in a few seconds and you already have 100% type information without waiting for 5 minutes each time
3) refactoring code is very hard, because without proper typing, it's hard to find all instances of usage of data X or property X without manually researching tons of code (data flow); in languages with proper typing, IDE can find it all immediately, but ours fails to catch a lot of stuff
So in the end, in my experience:
1) lack of types allows for quicker debugging/hotfixing if you don't care about data/logic validity (because you don't run tests or linters anyway)
2) you waste more time and suffer more in the rest of the situations
So we started adding type hints all over the place, and banned arbitrary arrays with "magic" keys in public APIs.
I sincerely don't understand people who push against using types, it's like they never worked on large projects in teams, or never maintained a project for more than a few months. Or maybe they have some secret sauce I'm not aware of?
What I think this post is reaching for is not types, and it’s beyond even abstract data structures. It's really templates, which is a general concept that gets used in every design scenario. Numbers are templates, integers are templates, bits are templates. We can describe how the idea works to each other and partly to the computer but it’s up to the programmer to animate them.
Once you understand the concept you see it everywhere. Super Mario is full of templates: you jump on an enemy’s head, or sometimes it doesn’t work but gives you a clue to do something else. Templates are nodes of understanding.
Anyone familiar with the initial versions of C / C++? Both languages have offerd the ability to define your function signatures in header files for as long as I have known them, so if you wished to separate from the actual function body you should have been able to do that.
But then Haskell can hardly have been the first mainstream? But maybe someone with more ancient knowledge could share some insights - thx.
Isn't it the other way around? Types derived from analysing the problem domain? That's the basic premise of a bunch of software design techniques.
I don't get it, what's the difference between this and C's function declaration?
addIfEven: Int -> Int -> Maybe Int
even without knowledge of the implementation lets us know our caller has 'entered into a contract' where addIfEven will reduce two integers depending on some conditions. This contract then becomes two-wayed: If I modify the implementation of the function there's a good chance I'll be forced to modify the signature, thereby letting me know statically that I've broken the contract with the callsite.
I'd recommend checking out https://lexi-lambda.github.io/blog/2020/08/13/types-as-axiom... for a far better write-up than this comment on why type-driven development is like unlocking a cheat-code for development.
Meaning, model the whole thing in math, then you know whether the implementation matches the design.
Functions can be seen as basic tools of software design only if you completely leave out IO and asynchronous nature of the communication.
That’s why Haskell is so beautiful and understandable when you work with pure data, and suddenly becomes so cumbersome and cryptic when you need to work with IO and async communication. Because functions ARE NOT basic tools of software design.
Actors that asynchronously pass each other messages are.