> I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits.
I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.
As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.
This comment and many others in this thread seem to be missing something. I see a lot of anger here or blame on the author for deliberately choosing to not use types, but I think the author actually does a very admirable job explaining what's going on in their head:
"... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared me ..."
The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget.
> specifying your types is about as low-hanging, basic a step as you can take.
No, absolutely not. Learning an entirely new syntax, static semantics, and entire way of reasoning about code is about as high-hanging as you can get. Sure, once you know how to use static types, applying that knowledge is fairly easy. But it's a big mountain to climb before you get to do that.
This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work.
Now, personally, I think it is worth learning that. And, certainly, once you learn it, you get to amortize that benefit through the rest of your career. But there's a lot of people standing at the base of the mountain, realizing only how far they have to climb with no idea of the view they'll have once they're up there. Those people deserve sympathy, understanding, and encouragement to climb. Not criticism and mockery like I see all over this thread.
I did one of my internships at a financial services company. Their web applications were responsible for performing transformations on massive JSON datasets, with a huge variety of financial data. This is precisely the kind of project that would benefit most from typing.
I was relieved to find out that they were smart enough to use TS, yet horrified when I looked at the code base and found that the entire codebase was littered with the "any" keyword, making typing damn near useless.
We had so many bugs reports that essentially boiled down to "this data is being transformed in a way it shouldn't be". Almost invariably these bugs were due to the developer thinking that some variable represented one thing, when it really represented something else, and they thus performed an incorrect transformation on it. Typing would've eliminated this entire class of bugs.
Figuring out what any variable represented often involved traversing the huge codebase to find out where the variable originated. On some occasions, I even had to talk to the back-end developers to figure out what the heck was going on. Typing is self-documenting, and would've completely eliminated the need to go on a scavenger hunt to figure out what a variable meant.
Anyways I got sick of this rather quickly, and made sure to add types to any new code that I wrote. I was the only developer on the 20 person team that bothered to do so.
As an intern, I didn't understand why these developers refused to use types. I just assumed that with their years of experience, they must've had a good reason. Now looking back at it, it's clear that they didn't understand types, didn't want to learn how to use types, and thus just chose to completely ignore typing.
As you said, this is utterly horrifying (especially for a financial services company dealing with real money).
JS the language isn't great but it's JS the culture that is the real problem.
There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore.
If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's become so pervasive that isn't really a tenable position anymore.
> As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take.
How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point?
> If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.
"Over-engineering" means drawing blueprints when the job is to change a bulb. It does not mean that blueprints are useless. It's about the job and the tools picked to do it. I can conceive of many jobs that fit the scope of a dynamic language and where bringing the big typed cannons could be seen as over-engineering.
I've worked with a lot of people in the Python world who just wanted to move tickets across the kanban board as fast as possible, and they'd do a quick check of the happy path and call it a ticket. They'd be praised for their output and we (rightly, I think) didn't try to trace bugs back to a developer. They would do all sorts of dynamic-typing hacks to get the immediate task at hand done with little regard for the mess that was made, and they strongly disliked static types because they made those error prone, unmaintainable hacks really difficult to express.
Let me pull that out into a block quote:
> [types] made those error prone, unmaintainable hacks really difficult to express
This is, in my mind, the most valuable feature of static types, and one that at least some dynamic typing enthusiasts can't easily get their heads around. Types are like rails that guide you to code which is maintainable. Another very valuable feature is that they serve as documentation that would otherwise never be written or quickly fall out of date in a dynamically typed language. Lastly in importance is that the compiler/type-checker precludes certain errors.
I worked on one of those code bases. The team thought fixing endpoints where the ORM was being used incorrectly and generating N+1 queries was "premature optimization."
I think one of the sources of this kind of attitude is experience with type systems that are clumsy or slow to use. This goes equally for languages without type declarations and those with.
Personally, the two things I informally look for are:
* Does the language allow instant-to-a-human static analysis so I can see warnings when I'm passing the wrong type to a call?
* Will this language allow me to leave sections (almost always something I get off the wire) with minimal / no type information in order to come back to it later?
Typing is hugely powerful for avoiding problems. I've done a lot of work in Python, which I think has missed huge opportunities to introduce a more robust type-checking system. My current favorite is Elixir / Erlang, which I think uses pattern matching and static analysis to balance strong typing v.s. weak typing wins. It's interesting to compare Elixir to Elm. Elm has a much stronger type system, which means I almost never pass the wrong thing, but it also makes dealing with unstructured data much more frustrating.
Interesting characterizing engineering as honestly, horrifying, low-hanging and regarding one approach to typing as translatable to all practices and the underlying assumption it conveys a guarantee of reliability. I don't find any of those things to be true (in isolation or together). Of course I only know so much so there's that.
That's true to a point but it depends on perspective. On a big team with a mix of experience levels, you are going to want to put up as many barriers to mistakes as possible and it doesn't matter how much it slows anyone down because it can't be more than dealing with the problems will be.
But less people, smaller projects, higher experience levels, and better testing are all factors that shift the balance between effort and expected return. Before TypeScript came around I wrote multiple 5-10k loc apps alone in JS and the number of bugs that TypeScript would have caught in those was pretty minimal. Working on a team of 5 on apps twice that big, I see errors that TS could catch in almost every single file.
If a majority of software developers had your attitude towards static types all dynamic typed languages (maybe except for JS) would have died out by now.
> If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.
Does that mean no thought and design went into all the huge protects like Instagram, Netflix and Whatsapp (that use dynamically typed languages)? Design and engineering is much more then just adding types. Clean design patterns, good code, tests and docs are pretty important too. In fact they are much more important then just static types.
Oh come on, this is a discussion probably older than both of us put together. And we probably both know that the discussion devolves into where/what kind of tests are written. I'm on your side in the static type system debate, but you must realize that the responsible part of the other side delegates the responsibility to exhaustive testing.
Typing offers guarantees. You can guarantee that your function will receive the right inputs, and produce the right outputs. Even soft typing enforced by an IDE is beneficial in that sense.
I have refactored a large, central chunk of JavaScript code back at HERE. I found and fixed several bugs related to typing as I went along.
A lot of code passed server responses or a subset of them as-is, so I had to read API documentation to understand the inputs of some deep parts of the frontend code. This is why I favour explicitly encapsulating server responses in a data class.
In addition to typing, I favour microtypes and enums. Those go further to prevent unexpected application states. Assert statements are a last barrier against unmet expectations that could break things.
If you want to build reliable software, you must be strict about the inputs you accept. Don't let sloppy inputs propagate.
As a c developer, I've always found the lack of typing to be one of the things I dislike about python.
If you're calling a function in C, a lot of the time just knowing the type and argument name is enough to call functions without resorting to documentation
In python, you have the argument name and then... what do you want? A number? Are floats or integers alright? Is it a string? And object? An enum? Are there any bounds on the input data that a data type would've instantly told me? Fine, I'll go read the documentation
Adding types gives you so much more information in so few characters
Much of web development doesn't need extreme levels of attention to safety. A good fraction of web development is such that errors are quickly caught in manual testing and at worst just make some button look weird for the short span of time before the problem is noticed and fixed. Also, time spent using generic safety tools is time that could instead be spent reworking and better understanding the specific code to make it safer. There is a lot of cultism in the industry about testing and type safety. I have seen people demand almost 100% test coverage for code that displayed some extremely simple UX which, if it broke, would be completely obviously broken the first time you tried actually interacting with it. I have seen TypeScript used for short code that basically just displays simple UX and is made up largely of calls to third party libraries anyway. I think there is no generic appropriate level of attention to safety. It depends on the context. If you're working on code that controls a spacecraft or a medical device, it makes sense to spend an enormous amount of thought and work on safety. For much of web development, that just doesn't make sense, but organizations seem to often fall into a trap of mandating bondage-and-discipline features for stuff that doesn't need it - why, I don't know. Maybe because there's an impression that "everyone else is doing it". I guess also, some people just enjoy it.
But I don't enjoy it. I like writing JavaScript. I think I can often do it elegantly and that the perceived elegance at least somewhat corresponds to objective quality. TypeScript makes my code uglier, to my taste at least, and makes development less fun for me. This impacts not just my feelings, but also my productivity. TypeScript had better provide me with something great to make up for this. I rarely make the kind of errors that TypeScript is capable of catching or feel like I need the help with readability and code discovery that it provides. But other people, I recognize, do benefit from it sometimes and in any case, other people pay me to use TypeScript.
It's probably worth taking a step back and interrogating why the actual "Why was I Anti-TypeScript?" a little bit more and use it as an opportunity for broader self development.
The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".
For me, I can handle the lack of static typing when I'm doing small scripts, like if it's going to be 100 lines or so of Python (my go-to language if I need to test some math out in a sandbox or do some file manipulation on my system). I might actually be a little faster in writing those scripts because of the lack of typing.
Once it starts getting any bigger than that, though, static typing really catches and points out a lot of problems before I even launch the program, that I'd otherwise be spending time debugging and looking for anyway, most likely.
I also think static typing has the benefit of enforced self-documentation a bit, so other developers know just by checking the type what sort of data they should expect to see in there, and not trying to give it garbage to begin with. Granted good variable naming and proper documentation would alleviate that, but that's never been fully consistent at any organization I've ever worked for.
And considering I mostly work with relational SQL databases, there's no escaping typing on the database end for that, so I might as well have models that map to the typing of what's in the database so I don't have to keep checking the database tables to make sure I'm giving it good data.
Naming is incredibly hard, though. And refactoring is hard.
It's a pain in the neck when something starts out as bla_list or whatever and you discover that after half a decade of changes bla_list isn't actually a list anymore, it's a dictionary, and that it doesn't only hold Bla these days, it can also contain Foo or Bar. This type of stuff is immediately obvious with modern static typing.
I guess static first is a chore because at that point you have no idea what invariant or structure is required for the task. After prototyping you know where to tighten the bolts.
The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After your project gets to a certain size, and it need not be large, you start making smaller changes and moving code around -- having some guard rails there is a huge productivity boost. Being able to read code and know that it does what it says because you know the types also improves your productivity.
The critique of typed languages being slow to write was somewhat true in the past. However, more modern typed languages (e.g. Swift or Typescript) do a lot of inference and have some flexibility built in. Because of that I think you get many of the same benefits of loose typing while maintaining type safety. One worry I had with starting Typescript was a fear it was going to make engineers over-engineer things, which is a behavior that Java seems to promote -- that turned out to not be true. You can go off the deep-end on generics, but in practice I haven't seen this.
Also with Typescript, you're not so far from Javascript where it's an entirely new language. So if you love Javascript, you don't lose anything.
Don't want to oversimplify since the article has some useful insights, but overall it reads like a typical transition from thinking static typing is a burden to realizing type safety can be incredibly useful.
I distinctly remember that in college I believed the history of programming languages is purely evolutionary in the sense that newer languages are objectively better than older ones. As in - people wrote assembly until C came along and gave them if clauses and for loops and then came Java where you didn't need to manually manage memory anymore and could use classes and then with Python you didn't even need to specify types anymore!
I.e. the newest language with the most everything is the best!
Nowadays it feels like I'm replaying that in reverse - doing less and less OOP, loving statically typed languages, wanting to learn some Rust etc.
I think a large part of the support for Typescript comes from being able to create good tools for the language.
But, I still have an aversion to front-end development itself, because it just feels too _involved_. You have to set up so much, and it has become a lot more difficult since you need to install webpack, postcss, and many other plugins just to do a hello world app.
It's still bearable if you have to do all of that, and you _understand_ what is going on, but most of the time, especially when it comes to front-end, I do things "because that's how it's done".
My problem with TypeScript is the lack of runtime benefits. Yes, you get some benefits of static checks during compile time, but at the cost of huge additional effort. This effort maybe makes sense for a large project with many team members pushing code, but for small hobby projects I think this just makes quick iteration far more difficult. To me this defeats the whole purpose of using a dynamic garbage-collected language to begin with.
If TypeScript was a first-class language, you could do all sorts of great runtime optimizations (perhaps a v8 fork will do this eventually?). In this case I would absolutely jump all over it, even for small hobby projects.
As it is, going from JS -> TS, one might as well just skip the extra translation step and just start writing everything in Go or Rust, especially for back-end nodejs/deno projects. In these languages the runtime benefits makes the abstractions worth the effort.
After being an early adopter of TypeScript, I decided to skip TypeScript in my next projects for a few years because I thought it was not worth the hassle. I remember spending a lot of time in DefinitelyTyped to create and fix type definitions, and when Babel and ES6 were popular I used that instead.
I recently changed my mind and started to migrate a large JavaScript codebase to TypeScript, in strict mode. I consider my team to be composed of only good developers but still, I found so many bugs. I still spend time on DefinitelyTyped definitions, but if you do more than prototyping or work on a project also developed with other people for more than a few weeks, TypeScript is for sure worth it in my opinion.
Typescript is more popular now because projects are migrating more and more business logic layer to front end. Thus the need for type safety and static analysis.
I’m agnostic about Typescript. Bare JavaScript is very efficient and optimized language, well suited for smaller projects.
However, when project scope balloons up, then Typescript becomes more useful. It’s way of enforcing descriptive comments a code, than trying to be a type safe language.
Still not a typescript fan here. It feels like a half-baked language because of the insistence of not having a runtime (even though some information makes it through to the underlying js...so this objection of theirs isn't total). In a usual typed language, you could extract the type of an intersection type using pattern matching. But you can't do that in typescript. Instead you get to pick the most relevant ugly hack for your situation.
Typescript feels like every one of its features has some catch, and it's very irritating.
The issue that broke the camel's back for me was when I saw "cstomerName is not defined" in production. I just could not accept that it is OK to live with tools that let that happen.
It takes a lot of mental and emotional capital in the creative process to produce something that is truly wonderful. Microsoft is systemically incapable of approaching creative perfection. Very few are.
While I'm fan of statically typing, there is something with Typescript I don't like, but don't know exactly what it is. In my day-to-day it's mostly Kotlin and Elm, which also are both statically typed, which I don't mind and mostly don't even notice.
But with Typescript it is as if I'm always fighting the compilator, trying to make it happy with whatever code I wrote. Maybe it's just the JS ecosystem being too lax that makes having types for everything difficult? Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.
I had this too - when I first started I fought typescript quite a bit. I struggled through this because I kept finding more and more code on github that was TS, kept seeing more articles that were TS, kept seeing big improvements from MS on TS, etc. So I kept learning the best practices and trying to understand why I shouldn't use "any[]" or "{key: string?}" and so on - trying to get past the parts where I wanted to be lazy. Eventually on one of my projects I had to reorganize my model structure, where some classes held other classes and so on. I had to both move one and rename one. This was early on, but since I did a reasonable job with typescript, I was able to just run `tsc -p .` over and over and it found all of the places I missed, which were far more than I would have guessed. It only took maybe 20 minutes to do that massive refactor. From that day forward, I really enjoy working in typescript. I think it's different from (some) other strongly/statically typed languages because it allows you be be a little more expressive in what you're defining. Perhaps expressive is the wrong word, but I find that it's quite flexible in this area, and I really enjoy that because if I take the time to flesh things out it can really help me find or prevent bugs.
Basically in the same boat, although I still use TS as it's become kind of defacto in JS land, I'm not sure that I dislike it so much as am not sure it's always worth it. Maybe I tend to approach it too much like Swift or Kotlin and get annoyed when a dependency is missing typings or the compiler is so easily tricked/lax about a lot of the actual type-saftey.
Maybe putting Typescript it into the bucket of a "better linter" is the mindset to have.
TS has a bit of Java feel to me. Forces me to follow all kinds of hard compiler requirements that take some time to implement, like generics, but then there's still all of these edge cases like null-pointers that make it feel like you're still building a house of cards.
Kotlin and Elm are more functional, don't know about Elm but Kotlin has non-null pointers as a base feature of it's language, not some later bolted on tie-wrapped solution.
> Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.
I’m curious - how do Elm and Kotlin solve these problems in a way that balances the often competing goals of “add types to reduce errors” vs “have a high productivity environment where it’s quick and easy for engineers to write new code”?
Currently maintaining a very large codebase in TS, and never going back to vanilla.
The initial migration found hundreds of bugs, typos, imperfections. And now every refacto, bugfix, new features... can be trusted.
More than that, when you use JS in the back and the front, your types can follow from the database, to the api, to react... even to your integration tests or your public SDK.
Add one more column in your DB and suddenly 1000 errors pops, but those are good errors, you just have to follow them until nothing scream and you have done a perfect migration.
It can feels negative at first but it is actually very pleasant and reassuring, like having an angel watching over your code.
Are there big companies still doing untyped JS at scale out there?
I'm not a frontend person and I always disliked dynamic type systems. But I vaguely remember the skepticism when Angular moved to TS. To me it made a lot of sense that most projects at Google, MS and the like would hugely benefit from a language that is kind of a C# on the JS runtime. And in 2021 I see TS pretty much everywhere, but maybe I'm missing something?
In my team people object to TS due to a few things: additional complexity, additional build step, build time increase, copy-pasting code around (to console, code snippets etc.) does not work anymore (but last time we talked it was soon after coffeescript -> esmodules migration and I guess everyone was tired of coffeescript which might have affected the mood).
There's no unanimous consensus that TS is all gold; some people who are fine with types don't like certain TS implementation details and in fact some devs start saying out loud that sometimes it's very difficult to fight TS with certain constructs.
Something that's gaining popularity and what I'm trying lately is using JS + jsdoc annotations more thoroughly, which gives the niceties of TS (when using vscode) without the downsides and heavy compilation step:
I like the post, but the author's original perspectives are something I was always perplexed by. There was a period in late 2000s and early 2010s where dynamic languages were all the range (Ruby, Python, CoffeScript) and static typic was seen as archaic and slow by an entire segment of development community and I never understood it.
>I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits.
I mean ... that is a perspective. EJB 2.0 was over-engineered for many use-cases. SOAP is an over-engineered standard for many use-cases. Static typing is not. Maybe for small scripts, static typing doesn't provide that much value (although even then I don't really buy it - why wouldn't you want to know what you're working with at any given time), but for sizable (web) applications that need to be maintained for years, it's critical.
>also it felt slow to work on, as I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem.
Another interesting perspective. Every single one of those compilation errors was a runtime error waiting to bite you in the butt. If you think solving compilation errors is slow, debugging and solving runtime errors is way slower. I'm glad the author learned the value of compile-time checks.
>The other reason was Advanced TypeScript concepts like Generics felt very hard to understand initially and I started feeling that I am in the Java world where every piece of code is strongly typed and overwhelming.
This right here is the big problem in a nutshell. There is nothing wrong with ignorance - we all start there. But it's one thing to be 'overwhelmed' by something when starting out, and another to being ANTI that something BECAUSE you don't understand it. The author admits he was overwhelmed by TypeScript and that caused him to be ANTI-Typescript. That is something you see in places. And that the author justified his Anti-Typescript perspective by having an ignorant view of Java to boot. The author talks about 'Java world', but does he have any experience with Java development at all?
"First I didn't like it because it takes longer to learn, then I discovered the obvious features that are the reason TypeScript was invented in the first place."
Came from a statically typed background when I landed with JavaScript and - absolutely loved - the fact that it wasn't. I've been using TypeScript for the better part of four years for my day job, but I'll still use plain old JavaScript when the situation allows for it. TypeScript has become a religion, and I've seen folks screaming in Github issues because a 14 line package didn't export types.
TypeScript has its place and it's nice points. It's got downsides too. Just as using plain JavaScript does. Stop bemoaning people who don't use TypeScript. Stop lauding people who choose it as the default "because types." Right tool for the right job, and all that.
Here's a project idea I'd really like to see: A version of Chromium, targeted at web developers, that is is modified to accept TypeScript syntax as a variant of JavaScript.
This hypothetical browser wouldn't perform type-checking, just be able to parse TS syntax and convert it to plain JS, in the same way tools like Babel do.
This would let you use TypeScript without the need for any transformation pipeline in dev. You could then separately run TypeScript in a console to get async checking. Then only when you build for production do you run everything through a compiler/bundler to get a plain JS bundle that will work in everyone's browsers.
type State = { id: "initial" } | { id: "running", speed: number }
const f = (s: State) => {
switch (s.id) {
case "initial": // s.id available
break;
case "running": // s.id and s.speed available
break;
}
}
The problem with Typescript shows up when people with background in Java or C# starts taking oo design patterns into js-land where they don't really belong (patterns like dependency injection, factories, singletons etc.).
Although I like the actual language of TypeScript more than JavaScript, it still doesn't feel useful enough to justify its usage. Computers' native language is Assembly but we rarely use it and prefer to code in C/Python/whatever because this is so much easier (+ portable). Browsers' native language is JavaScript and it isn't much harder nor less powerful than TypeScript, nor does it provide a seriously different perspective (like Clojure/Elm/Reason do) so why not just use JavaScript (you have to understand it anyway)?
The value of TypeScript is a function of the codebase size, size of team, and length of time for maintaining this codebase.
If you're an individual, putting together dinky little web sites that you don't need to maintain for years - the value of TypeScript over JavaScript isn't as pronounced.
If you have a web application that counts hundreds of thousands of lines of code, maintained by team of developers over many years - JavaScript does not cut it ... at all.
>> satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits
I tend to rail quite hard against the “type everything” world view but I’ve always been crystal clear on the benefits of types at boundaries between components. They can be a succinct way to codify the invariants and contract between components in a software architecture - with a nice quick feedback loop when you appreciate it most (when you’re exploring an unfamiliar API). They can also be a total train wreck for productivity when abused.
Where they fall down for me and always become a productivity penalty is working inside those component boundaries. Tests are a better answer then. I care that the actual behaviour is sound, if i say concat(list1, list2); something like Java’s type system guarantees of only “hey you put two lists in, you get some list back which might or might not be a concatenation of the two you provided” aren’t sufficient, you might as well not type it at all. Tests are necessary.
In typescript you could actually type concat in a meaningful way but i digress.
I think tests are also a better tool for handling people boundaries, that is developers separated by time (i.e. myself in 1 year) or separated by space, (i.e. between groups of developers in different orgs). The fundamental difference is the explanation, a test explains how something should behave, an intention. A type is a terse expression of how a person interpreted the problem domain and is not guaranteed to be an appropriate or useful model, it’s just a rule.
There’s a possible exception to all of this for me - dependant types. I’m still learning and undecided on the value.
All said and done, I’m happy that things like mypy and typescript exist, but I’m not convinced they are a cost effective way to maintain reliable software if over-used or used in rubbish ways. Used appropriately, they’re great. Used all the time, no thanks.
Yep, I'm a firm believer in using TS pragmatically. Type the obvious code (React component props, API responses, function arguments), and start by aiming for an "80% sweet spot" of type coverage. Don't get into arguments with the compiler, and avoid writing really complex types unless you've got a key spot in your code where adding that type now makes it a lot easier to infer types in other places:
[+] [-] mdoms|5 years ago|reply
I honestly find this attitude horrifying. I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.
As far as "engineering" goes, specifying your types is about as low-hanging, basic a step as you can take. If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.
[+] [-] munificent|5 years ago|reply
"... concepts like Generics felt very hard to understand ... every piece of code is strongly typed and overwhelming. Even simple code like below scared me ..."
The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget.
> specifying your types is about as low-hanging, basic a step as you can take.
No, absolutely not. Learning an entirely new syntax, static semantics, and entire way of reasoning about code is about as high-hanging as you can get. Sure, once you know how to use static types, applying that knowledge is fairly easy. But it's a big mountain to climb before you get to do that.
This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work.
Now, personally, I think it is worth learning that. And, certainly, once you learn it, you get to amortize that benefit through the rest of your career. But there's a lot of people standing at the base of the mountain, realizing only how far they have to climb with no idea of the view they'll have once they're up there. Those people deserve sympathy, understanding, and encouragement to climb. Not criticism and mockery like I see all over this thread.
[+] [-] spideymans|5 years ago|reply
I was relieved to find out that they were smart enough to use TS, yet horrified when I looked at the code base and found that the entire codebase was littered with the "any" keyword, making typing damn near useless.
We had so many bugs reports that essentially boiled down to "this data is being transformed in a way it shouldn't be". Almost invariably these bugs were due to the developer thinking that some variable represented one thing, when it really represented something else, and they thus performed an incorrect transformation on it. Typing would've eliminated this entire class of bugs.
Figuring out what any variable represented often involved traversing the huge codebase to find out where the variable originated. On some occasions, I even had to talk to the back-end developers to figure out what the heck was going on. Typing is self-documenting, and would've completely eliminated the need to go on a scavenger hunt to figure out what a variable meant.
Anyways I got sick of this rather quickly, and made sure to add types to any new code that I wrote. I was the only developer on the 20 person team that bothered to do so.
As an intern, I didn't understand why these developers refused to use types. I just assumed that with their years of experience, they must've had a good reason. Now looking back at it, it's clear that they didn't understand types, didn't want to learn how to use types, and thus just chose to completely ignore typing.
As you said, this is utterly horrifying (especially for a financial services company dealing with real money).
[+] [-] jpgvm|5 years ago|reply
There is a subset of JS codebases that are good, well engineered and written by people that understand the languages faults and limitations but the list is incredibly small and even smaller still now Joyent isn't really around anymore.
If there was one ecosystem I wish I never needed to touch again it would be JS but unfortunately it's become so pervasive that isn't really a tenable position anymore.
[+] [-] mekoka|5 years ago|reply
How do you come to such a conclusion when there have been many languages whose success was specifically tied to the fact that they were dynamically typed? Doesn't that indicate a pain point?
> If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.
"Over-engineering" means drawing blueprints when the job is to change a bulb. It does not mean that blueprints are useless. It's about the job and the tools picked to do it. I can conceive of many jobs that fit the scope of a dynamic language and where bringing the big typed cannons could be seen as over-engineering.
[+] [-] throwaway894345|5 years ago|reply
Let me pull that out into a block quote:
> [types] made those error prone, unmaintainable hacks really difficult to express
This is, in my mind, the most valuable feature of static types, and one that at least some dynamic typing enthusiasts can't easily get their heads around. Types are like rails that guide you to code which is maintainable. Another very valuable feature is that they serve as documentation that would otherwise never be written or quickly fall out of date in a dynamically typed language. Lastly in importance is that the compiler/type-checker precludes certain errors.
[+] [-] fallingknife|5 years ago|reply
[+] [-] aeturnum|5 years ago|reply
Personally, the two things I informally look for are:
* Does the language allow instant-to-a-human static analysis so I can see warnings when I'm passing the wrong type to a call?
* Will this language allow me to leave sections (almost always something I get off the wire) with minimal / no type information in order to come back to it later?
Typing is hugely powerful for avoiding problems. I've done a lot of work in Python, which I think has missed huge opportunities to introduce a more robust type-checking system. My current favorite is Elixir / Erlang, which I think uses pattern matching and static analysis to balance strong typing v.s. weak typing wins. It's interesting to compare Elixir to Elm. Elm has a much stronger type system, which means I almost never pass the wrong thing, but it also makes dealing with unstructured data much more frustrating.
[+] [-] jimmont|5 years ago|reply
[+] [-] svachalek|5 years ago|reply
But less people, smaller projects, higher experience levels, and better testing are all factors that shift the balance between effort and expected return. Before TypeScript came around I wrote multiple 5-10k loc apps alone in JS and the number of bugs that TypeScript would have caught in those was pretty minimal. Working on a team of 5 on apps twice that big, I see errors that TS could catch in almost every single file.
[+] [-] nromiun|5 years ago|reply
> If this is "over-engineering" then I think that says a lot about how much thought, design and engineering goes into some of these code bases.
Does that mean no thought and design went into all the huge protects like Instagram, Netflix and Whatsapp (that use dynamically typed languages)? Design and engineering is much more then just adding types. Clean design patterns, good code, tests and docs are pretty important too. In fact they are much more important then just static types.
[+] [-] eyelidlessness|5 years ago|reply
[+] [-] nicbou|5 years ago|reply
I have refactored a large, central chunk of JavaScript code back at HERE. I found and fixed several bugs related to typing as I went along.
A lot of code passed server responses or a subset of them as-is, so I had to read API documentation to understand the inputs of some deep parts of the frontend code. This is why I favour explicitly encapsulating server responses in a data class.
In addition to typing, I favour microtypes and enums. Those go further to prevent unexpected application states. Assert statements are a last barrier against unmet expectations that could break things.
If you want to build reliable software, you must be strict about the inputs you accept. Don't let sloppy inputs propagate.
[+] [-] andrew_|5 years ago|reply
[+] [-] ChrisRR|5 years ago|reply
If you're calling a function in C, a lot of the time just knowing the type and argument name is enough to call functions without resorting to documentation
In python, you have the argument name and then... what do you want? A number? Are floats or integers alright? Is it a string? And object? An enum? Are there any bounds on the input data that a data type would've instantly told me? Fine, I'll go read the documentation
Adding types gives you so much more information in so few characters
[+] [-] coldtea|5 years ago|reply
In fact, several geniuses in Computer Science have historically been of the same opinion (pro dynamic typing).
[+] [-] axguscbklp|5 years ago|reply
But I don't enjoy it. I like writing JavaScript. I think I can often do it elegantly and that the perceived elegance at least somewhat corresponds to objective quality. TypeScript makes my code uglier, to my taste at least, and makes development less fun for me. This impacts not just my feelings, but also my productivity. TypeScript had better provide me with something great to make up for this. I rarely make the kind of errors that TypeScript is capable of catching or feel like I need the help with readability and code discovery that it provides. But other people, I recognize, do benefit from it sometimes and in any case, other people pay me to use TypeScript.
[+] [-] pbreit|5 years ago|reply
[+] [-] madeofpalk|5 years ago|reply
The author didn't use and understand something, and rather than trying to they instead just defaulted to rejection. It's midly disapointing seeing this in people who label themselves as "Senior".
[+] [-] cableshaft|5 years ago|reply
Once it starts getting any bigger than that, though, static typing really catches and points out a lot of problems before I even launch the program, that I'd otherwise be spending time debugging and looking for anyway, most likely.
I also think static typing has the benefit of enforced self-documentation a bit, so other developers know just by checking the type what sort of data they should expect to see in there, and not trying to give it garbage to begin with. Granted good variable naming and proper documentation would alleviate that, but that's never been fully consistent at any organization I've ever worked for.
And considering I mostly work with relational SQL databases, there's no escaping typing on the database end for that, so I might as well have models that map to the typing of what's in the database so I don't have to keep checking the database tables to make sure I'm giving it good data.
[+] [-] oblio|5 years ago|reply
It's a pain in the neck when something starts out as bla_list or whatever and you discover that after half a decade of changes bla_list isn't actually a list anymore, it's a dictionary, and that it doesn't only hold Bla these days, it can also contain Foo or Bar. This type of stuff is immediately obvious with modern static typing.
[+] [-] agumonkey|5 years ago|reply
[+] [-] danielrhodes|5 years ago|reply
The critique of typed languages being slow to write was somewhat true in the past. However, more modern typed languages (e.g. Swift or Typescript) do a lot of inference and have some flexibility built in. Because of that I think you get many of the same benefits of loose typing while maintaining type safety. One worry I had with starting Typescript was a fear it was going to make engineers over-engineer things, which is a behavior that Java seems to promote -- that turned out to not be true. You can go off the deep-end on generics, but in practice I haven't seen this.
Also with Typescript, you're not so far from Javascript where it's an entirely new language. So if you love Javascript, you don't lose anything.
[+] [-] MatekCopatek|5 years ago|reply
I distinctly remember that in college I believed the history of programming languages is purely evolutionary in the sense that newer languages are objectively better than older ones. As in - people wrote assembly until C came along and gave them if clauses and for loops and then came Java where you didn't need to manually manage memory anymore and could use classes and then with Python you didn't even need to specify types anymore!
I.e. the newest language with the most everything is the best!
Nowadays it feels like I'm replaying that in reverse - doing less and less OOP, loving statically typed languages, wanting to learn some Rust etc.
[+] [-] gamesbrainiac|5 years ago|reply
But, I still have an aversion to front-end development itself, because it just feels too _involved_. You have to set up so much, and it has become a lot more difficult since you need to install webpack, postcss, and many other plugins just to do a hello world app.
It's still bearable if you have to do all of that, and you _understand_ what is going on, but most of the time, especially when it comes to front-end, I do things "because that's how it's done".
This makes me feel very insecure about my code.
[+] [-] BluSyn|5 years ago|reply
If TypeScript was a first-class language, you could do all sorts of great runtime optimizations (perhaps a v8 fork will do this eventually?). In this case I would absolutely jump all over it, even for small hobby projects.
As it is, going from JS -> TS, one might as well just skip the extra translation step and just start writing everything in Go or Rust, especially for back-end nodejs/deno projects. In these languages the runtime benefits makes the abstractions worth the effort.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] speedgoose|5 years ago|reply
I recently changed my mind and started to migrate a large JavaScript codebase to TypeScript, in strict mode. I consider my team to be composed of only good developers but still, I found so many bugs. I still spend time on DefinitelyTyped definitions, but if you do more than prototyping or work on a project also developed with other people for more than a few weeks, TypeScript is for sure worth it in my opinion.
[+] [-] wwww4all|5 years ago|reply
I’m agnostic about Typescript. Bare JavaScript is very efficient and optimized language, well suited for smaller projects.
However, when project scope balloons up, then Typescript becomes more useful. It’s way of enforcing descriptive comments a code, than trying to be a type safe language.
[+] [-] Blackthorn|5 years ago|reply
Typescript feels like every one of its features has some catch, and it's very irritating.
[+] [-] foobarian|5 years ago|reply
[+] [-] boredpandas777|5 years ago|reply
[+] [-] matsemann|5 years ago|reply
But with Typescript it is as if I'm always fighting the compilator, trying to make it happy with whatever code I wrote. Maybe it's just the JS ecosystem being too lax that makes having types for everything difficult? Like you have a react hook and some components that you can compose, and the typedefs just become unwieldy and impossible to get right. Often they end up not even catching what should be compilation errors.
[+] [-] fimbulvetr|5 years ago|reply
[+] [-] jamil7|5 years ago|reply
Maybe putting Typescript it into the bucket of a "better linter" is the mindset to have.
[+] [-] dep_b|5 years ago|reply
Kotlin and Elm are more functional, don't know about Elm but Kotlin has non-null pointers as a base feature of it's language, not some later bolted on tie-wrapped solution.
[+] [-] exhaze|5 years ago|reply
I’m curious - how do Elm and Kotlin solve these problems in a way that balances the often competing goals of “add types to reduce errors” vs “have a high productivity environment where it’s quick and easy for engineers to write new code”?
[+] [-] h1fra|5 years ago|reply
More than that, when you use JS in the back and the front, your types can follow from the database, to the api, to react... even to your integration tests or your public SDK.
Add one more column in your DB and suddenly 1000 errors pops, but those are good errors, you just have to follow them until nothing scream and you have done a perfect migration. It can feels negative at first but it is actually very pleasant and reassuring, like having an angel watching over your code.
[+] [-] hocuspocus|5 years ago|reply
I'm not a frontend person and I always disliked dynamic type systems. But I vaguely remember the skepticism when Angular moved to TS. To me it made a lot of sense that most projects at Google, MS and the like would hugely benefit from a language that is kind of a C# on the JS runtime. And in 2021 I see TS pretty much everywhere, but maybe I'm missing something?
[+] [-] jakub_g|5 years ago|reply
There's no unanimous consensus that TS is all gold; some people who are fine with types don't like certain TS implementation details and in fact some devs start saying out loud that sometimes it's very difficult to fight TS with certain constructs.
Something that's gaining popularity and what I'm trying lately is using JS + jsdoc annotations more thoroughly, which gives the niceties of TS (when using vscode) without the downsides and heavy compilation step:
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
[+] [-] macspoofing|5 years ago|reply
>I always felt that adding types to the functions/variables and satisfying the TypeScript compiler is an over-engineering and not providing any meaningful benefits.
I mean ... that is a perspective. EJB 2.0 was over-engineered for many use-cases. SOAP is an over-engineered standard for many use-cases. Static typing is not. Maybe for small scripts, static typing doesn't provide that much value (although even then I don't really buy it - why wouldn't you want to know what you're working with at any given time), but for sizable (web) applications that need to be maintained for years, it's critical.
>also it felt slow to work on, as I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem.
Another interesting perspective. Every single one of those compilation errors was a runtime error waiting to bite you in the butt. If you think solving compilation errors is slow, debugging and solving runtime errors is way slower. I'm glad the author learned the value of compile-time checks.
>The other reason was Advanced TypeScript concepts like Generics felt very hard to understand initially and I started feeling that I am in the Java world where every piece of code is strongly typed and overwhelming.
This right here is the big problem in a nutshell. There is nothing wrong with ignorance - we all start there. But it's one thing to be 'overwhelmed' by something when starting out, and another to being ANTI that something BECAUSE you don't understand it. The author admits he was overwhelmed by TypeScript and that caused him to be ANTI-Typescript. That is something you see in places. And that the author justified his Anti-Typescript perspective by having an ignorant view of Java to boot. The author talks about 'Java world', but does he have any experience with Java development at all?
[+] [-] MFogleman|5 years ago|reply
"I always used to get some compilation errors which were hard to understand initially, and I scratched my head trying to figure out the problem. "
Which is like saying, "I got rid of my carbon monoxide detector because it kept beeping at me"
[+] [-] nothis|5 years ago|reply
[+] [-] andrew_|5 years ago|reply
TypeScript has its place and it's nice points. It's got downsides too. Just as using plain JavaScript does. Stop bemoaning people who don't use TypeScript. Stop lauding people who choose it as the default "because types." Right tool for the right job, and all that.
[+] [-] stupidcar|5 years ago|reply
This hypothetical browser wouldn't perform type-checking, just be able to parse TS syntax and convert it to plain JS, in the same way tools like Babel do.
This would let you use TypeScript without the need for any transformation pipeline in dev. You could then separately run TypeScript in a console to get async checking. Then only when you build for production do you run everything through a compiler/bundler to get a plain JS bundle that will work in everyone's browsers.
[+] [-] throwaway4good|5 years ago|reply
[+] [-] qwerty456127|5 years ago|reply
[+] [-] macspoofing|5 years ago|reply
If you're an individual, putting together dinky little web sites that you don't need to maintain for years - the value of TypeScript over JavaScript isn't as pronounced.
If you have a web application that counts hundreds of thousands of lines of code, maintained by team of developers over many years - JavaScript does not cut it ... at all.
[+] [-] CraigJPerry|5 years ago|reply
I tend to rail quite hard against the “type everything” world view but I’ve always been crystal clear on the benefits of types at boundaries between components. They can be a succinct way to codify the invariants and contract between components in a software architecture - with a nice quick feedback loop when you appreciate it most (when you’re exploring an unfamiliar API). They can also be a total train wreck for productivity when abused.
Where they fall down for me and always become a productivity penalty is working inside those component boundaries. Tests are a better answer then. I care that the actual behaviour is sound, if i say concat(list1, list2); something like Java’s type system guarantees of only “hey you put two lists in, you get some list back which might or might not be a concatenation of the two you provided” aren’t sufficient, you might as well not type it at all. Tests are necessary.
In typescript you could actually type concat in a meaningful way but i digress.
I think tests are also a better tool for handling people boundaries, that is developers separated by time (i.e. myself in 1 year) or separated by space, (i.e. between groups of developers in different orgs). The fundamental difference is the explanation, a test explains how something should behave, an intention. A type is a terse expression of how a person interpreted the problem domain and is not guaranteed to be an appropriate or useful model, it’s just a rule.
There’s a possible exception to all of this for me - dependant types. I’m still learning and undecided on the value.
All said and done, I’m happy that things like mypy and typescript exist, but I’m not convinced they are a cost effective way to maintain reliable software if over-used or used in rubbish ways. Used appropriately, they’re great. Used all the time, no thanks.
[+] [-] acemarke|5 years ago|reply
https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...