Problems with TypeScript - <AUTHOR> https://blog.logrocket.com/is-typescript-worth-it/ <comment><USER2> IMO, Yes (usually).

Let me elaborate.

If you are starting a new project, yes use typescript over JS. And configure it with all strict options.

This doesn't magically give you well architected and well-tested code, it still takes a good engineer to do that. But what it does allow is for the engineer to refactor the code to support new functionality with more speed and confidence, rather than shoehorning it in in fear of breaking something or it taking too long. Furthermore, as people join your team, it will be a lot easier for them to figure out where some piece of data is coming from and how the code flows from one spot to the next.

If you have a massive JS project and you want to convert it to typescript. The answer _might_ be no. Oftentimes when people port a JS project to TS, they end up using non strict typescript, and you get the syntactic overhead of writing TS, without really any benefit because nearly everything is any typed. If your only concern is a better codebase, and it doesn't matter how long it takes, then sure it is worth it, but we all know that is never our only concern. It still might be worth it, but I can almost guarantee you from experience, you will still end up with TypeErrors in your console at some point, because people will have just any typed things.

Also if you're writing a tiny node script in a single file, to do some simple operation, then no it is probably not worth setting up a command to compile it and a tsconfig to configure it. Unless it is doing multiple things, and/or someone else in the future will have to use it, then it is probably still worth it.

<comment><USER2> Oh one other potential drawback.

Typescripts inferred types, can do some crazy things, and can be very powerful. This to me is really fun, but has definitely caused me when I first started using it to get lost in having fun doing crazy things, to ensure my strings were exactly some set of values depending on what some other value was, when a simple unit test and a simple "string" type, would've been a lot quicker and less confusing.

<comment><USER3> If the strings are static you can define a type that's a union of string literals, create a tuple containing them all, and then a type guard function that simply checks the argument against the array. If the strings are dynamic then you're better off looking at a library like newtype-ts, but it's not very ergonomic compared to the likes of Haskell/PureScript so use sparingly.

<comment><USER4> Why not just use an Enum? It will only accept the values of that enum.

[https://www.typescriptlang.org/docs/handbook/enums.html#enum...](https://www.typescriptlang.org/docs/handbook/enums.html#enums)

[https://www.typescriptlang.org/play/index.html?useDefineForC...](https://www.typescriptlang.org/play/index.html?useDefineForClassFields=true&preserveConstEnums=true#code/KYOwrgtgBAsgngZQC4CcCWIDmBnKBvAWACgpSoAxAeUqgF4oAiAIwEMUGAaYsqAIQEEASnUYAzAPbjO3MlUoDh9BhPGt2xAL7FiosCADGSNOJBQTAGzgBRcBH4pMACgBuLcwC5YiVBhwBKfBlSfRNscXNgADpzcScGJAALNFwAdzRzczMQSygkFgBrYCyi8VFchKLCuFxRFHFoeGR0LGwGPwBuIKgQkDCI6NiXNzpaekafFsiFDs1tIgtrW3s4xOSoNIyoJiKWU2AUOvYZ+ezFyGXHceacKaEAgHpHqAAVJNw1kHEkKF2ofcOgA)

<comment><USER5> Just my personal preference but using these string union types means that you don't have to import the enum. Plus it's less verbose and translates back to JS better than an enum does.

Really just a matter of preference though.

</comment></comment></comment></comment></comment><comment><USER6> TypeScript feels worth it until you use something like Elm, then you realize just how lacking and TypeScript's type system truly is.

I have grown rather weary of type systems that don't require you to be exhaustive and, for my money, types like `Omit` and `Pick` are nasty hacks that just let you pretend like you aren't doing dynamic types, something TypeScript does a lot. The TypeScript pattern of `someFunc<typeof someInput>` is just dynamic types with extra steps. Using `any` wouldn't really lose you much of anything, the "type" is just "whatever this input is". That's not a real type, that's a dolled-up dynamic type. But hey, it typechecks!

TypeScript's major weakness is that it doesn't want to break away from Javascript. That strict dedication to being a superset means the type system explodes into ten thousand builtin types the come, seemingly at times, from nowhere, simply to control for the wildness of Javascript. It feels like a joke sometimes, and like I need to have encyclopedic knowledge of all these highly-specialized types that are included in the language and are often being used in the background.

This leads to nearly impenetrable error messages regarding types, especially if you have a stack trace involving more than one object/record type (whatever you want to call it), it will expand all of them and just, no. It's unreadable. It can be read, but it cannot simply be _grokked._

TypeScript just doesn't impress me. I get far better results from other languages for a whole lot less work. TypeScript claims to want a balance between correctness and productivity but the language gives me neither of those things. My typical experience is that I wrote almost the same amount of actual code, but now also with types. Elm lets me write _far less total code._ Less code means less bugs and more productivity, and better types and better correctness is what gives you those things.

<comment><USER7> A big problem is that elm has questionable stability as a project. It's mainly one person, and not a lot of mainstream usage. The biggest projects mentioning elm are ones related to the main programmer.

Typescript on the other hand has had massive growth and has been adopted by a large amount of libraries. Now, web ts/js libraries usually suck but it still speaks to the overall health of the language in a community. Even then, typescript still only has a very small percentage of usage.

Elm is basically a rounding error on some of the surveys I've seen.

Long term support, tooling, etc are often much more important for languages past a threshold. Typescript as a language may not be super exciting. Typescript as a technology is wonderful.

<comment><USER8> I was an early enthusiast of Elm.

Sadly, Elm was never able to build a true core development team outside of Evan. Or at lest it didn't do it fast enough.

Evan is a smart programmer but not a strategic organizer or a communicator.

As a result, one of the most exciting and promising approaches to front end development was relegated to a nice-toy project status.

If you want to take the risk of building something using Elm's approach, you'll do it with Reason. Maybe not 100% as nice as Elm, but you'll feel confident you're not risking your code base and company on the whims of one person.

I still think Elm is a nice educational language for getting people (and kids) into FP.

</comment></comment></comment><comment><USER9> Guaranteed almost 100% type soundness!!! Non TypeScript user will hate this.

Config it to maximum strictness!

Add in runtime type checks Parse, don't validate [https://lexi- lambda.github.io/blog/2019/11/05/parse-don-t-va...](https://lexi- lambda.github.io/blog/2019/11/05/parse-don-t-validate/)

Bring type to business logic, e.g.

RegisteredUser { userId: number, email: string }

AnonymousUser { userId: number, email: null }

User = RegisteredUser | AnonymousUser

Handle errors ala Rust,

Return errors/errortype rather than throws

Utilize structure to determine result, e.g.

Failure { error: Error, value: null }

Success<T> { error: null, value: T }

It is worth it. My experience with TypeScript is a whole lot different.

Conspiracy theory inducing facts:

\- LogRocket's main use is monitoring bugs in browser application

\- Airbnb is LogRocket's customer

<comment><USER10> I'm interested in the way you describe handling errors here. Do you have any real world examples you can point me to? Thanks

<comment><USER9> I would have gladly shown it to you, but almost all my code is proprietary

Here's a small example:

```

function fetchCurrentWeather(){ return fetch(...) .catch(() => ({ error: new NetworkError(), value: null}) .then(res => res.json()) .then(maybeWeather => Weather.is(maybeWeather) ? { value: maybeWeather, error: null} : { error: new DecodeError(), value: null}) .catch(() => ({ error: new DecodeError(), value: null})) }

// And then you use it somewhere in you react app

async initialFetch(){ try { if (this.state.isLoading) return; this.setState({ isLoading: true, weather: null, error: null }); this.setState({ weather: await fetchCurrentWeather().then(reault => { if (result.error) throw result.error; return result.value; }) }); } catch (error) { this.setState({ error }) } finally { this.setState({ isLoading: false }); } }

render(){ return ( <div> {this.state.isLoading && ...} {this.state.weather && ...} {this.state.error && ...} </div> ) }

```

<comment><USER11> Why is this better than throwing errors or using Promise.resolve()?

I know it is inefficient because creating a new error with a stack trace each time is bad for performance. However, you can also throw errors which do not extend Error to avoid this. Destructuring the output and explicitly checking for errors every time seems to be quite the hassle.

<comment><USER12> Because the error/success is encoded in the type, you are forced to handle the error case. If you aren't also wrapping throwable functions in `try/catch` then you have a lot of unhandled error cases.

If you know that something truly isn't going to error then you can just force cast it as `foo as Success<T>`. That will still blow up at runtime if its not a `Success`.

Alternatively, you could introduce a monadic chaining that is able to pipe `Result<T>` objects through many functions then handle at the end.

</comment></comment></comment></comment></comment><comment><USER13> Mentioned as an afterthought at the end: IDE support for typescript, the best part about using the language.

Not mentioned: type annotations serve as a form of documentation that gets statically verified. The verification strategy has some cracks, and there's a (fairly small) chance that the documentation will end up misleading. But API documentation for javascript projects generally sucks, and typescript helps to fill a lot of the common gaps.

<comment><USER14> i'm tired of devs that claim that TS and GraphQL are "self-documenting" and don't need to write any documentation. it doesn't fill in the common gaps, it's just an excuse to not have to think about or talk to users.

<comment><USER15> I'm the author and the claims that Graphql and typescript replace documentation is madness

<comment><USER16> ...good thing that there's pretty much no one making them, then.

There's plenty of people saying that it effectively augments documentation, and provides a form of it that's quite useful.

</comment></comment></comment></comment><comment><USER17> While TypeScript isn't perfect, it surely is a major step forward compared to plain JS! Newer features like conditional types and mapped types open up new possibilities. My colleague actually recently gave a fantastic talk about these advanced features at the TS Berlin Meetup, highly recommended watch if you want to see what it's like pushing the boundaries of TypeScript: [https://www.youtube.com/watch?v=PJjeHzvi_VQ](https://www.youtube.com/watch?v=PJjeHzvi_VQ)

<comment><USER18> Still compiles Down to js where you lose all type checking.

Have you ever looked at a compiled js file? Things like spreading objects I to each other

{...a,...b}

End up being a nest object assign which is actually slower than spreading.

<comment><USER19> Checks don't need to be in the JS, they just need to be there at compile time. No differently than a binary generated by Haskell; and you have source maps to replace debugging symbols too.

And as mentioned by another user, you can choose your compile target to a specific version of JS which does support object spreading.

<comment><USER20> Actually, Haskell compilation produces more type information available at runtime than Typescript's compiler does. For example, algebraic data types turn into tagged unions at runtime on Haskell, allowing pattern matching to operate on them.

Whereas on Typescript the compilation process erases all this information, making it impossible to evaluate many such expressions.

There are multiple 3rd party solutions to this, such as: [https://github.com/pelotom/runtypes](https://github.com/pelotom/runtypes)

<comment><USER19> > algebraic data types turn into tagged unions at runtime on Haskell

How does that work? I know next to nothing about the GHC, but in Haskell I would assume some tag is associated with each constructor (probably an integer) for the ADT and that the actual pattern matching gets compiled down to simple comparisons to either that integer or the right function for the more complex cases (pattern matching strings and other values).

TypeScript essentially does that, except that the tags are not going to be optimized by the compiler (they will remain strings if the dev uses them), and the "pattern matching" is just regular conditional checks (if, ternary or switch) with even the exhaustiveness check being done as a manual hack introduced by the dev and checked at compile-time (the else or default case assigning the value to the never type).

As for runtime values, Haskell also needs to validate types when deserializing, although that will be done by the deserialization libraries such as Aeson instead of deserializing and _then_ optionally validating like in TS.

<comment><USER20> Yes, you're right, it should be an integer comparison check ultimately.

> TypeScript essentially does that, except that the tags are not going to be > optimized by the compiler

What do you mean by this? Typescript erases type information during compilation. So you would not be able to emulate pattern matching against types on TS. Or you could if you manually added some common tag to every single data type like interface.

Or are you talking about just compile-time type checking on TS?

<comment><USER19> > Or you could if you manually added some common tag to every single data type > like interface.

This is how you emulate them, I took it for granted and neglected to explicitly mention this is a moderately popular convention in TypeScript (those are the tags I referred to). fp-ts for example uses it all over the place.

With this the end result is essentially the same with compile-time type-safety for everything, and compiled down to an untyped binary or an untyped JS blob.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> The type of problem that TypeScript solves is not the type of problem that I have.

In my 15 years of engineering, exceedingly rare is the case where the underlying cause is due to using wrong types. I could count the number of times types has been problem on one hand. Instead, almost all issues are due to logic errors and missing or poorly understood business requirements.

For me, the time spent resolving TypeScript specific issues (missing type definitions, lack of support in third party libraries, general finickiness etc.) does not make it a worthwhile investment. I also did Scala for several years professionally, and while it instils rigor, I feel much the same that the price you pay isn't remotely worth the benefit you get. Conversely, I think one of the best investments you can possible make into tooling is to reduce the edit-compile-view cycle time, and you should aim for seconds at the most if not instantaneous updates. That speed of iteration will pay dividends.

<comment><USER22> It's a charmed life where one hasn't had to spend countless hours helping other people track down "undefined is not a function" errors :|

<comment><USER23> I did that a lot at my last job and found that the debugging was pretty quick. There's always some race condition from some asynchronous function somebody called without waiting for the callback. Does TS help with that?

<comment><USER24> if something can be returned as undefined instead of a function, then yes, you are forced to either write code to handle the undefined value, or modify your logic so the returned value can only be a function :)

</comment></comment></comment></comment><comment> why-oh-why Instead of focusing on what TS does not, focus on what it does.

TypeScript is not sound; JavaScript isn't either. The first one will catch some type errors, the second will catch none.

Syntax highlighting, linting, testing, and now type checking: every step can make you more confident about the code you ship, before it even hits the browser.

You can forgo using any help and probably you'll code faster, but, again, you lose confidence.

<comment><USER25> Tests are the only thing that give me confidence about any code I write, Javascript or otherwise.

<comment><USER26> And compilers are effectively a rudimentary form of test. They are not sufficient, nor necessary but they do validate some basic assumptions about the code.

<comment><USER27> If for no other reason, I would like Typescript for flagging when you typo some property - e.g. foo.FooID vs foo.FooId.

I've lost a stupid amount of time in regular JS because of things like this that make me want to pick up the computer and throw it out the window.

<comment><USER9> Decent editor does that now. I'm using atom on daily basis and it's helping me with that. VScode and intellij does the same

<comment><USER28> Doesn't the functionality for that in most editors leverage typescript typings, so that it's not really independent of typescript?

<comment><USER9> Ah I misread the parent comment. I thought it was more like "I wish typescript has this anti-typo functionality"

You're right that it's not independent from TS.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> Doesn't typescript enable things like renaming an identifier and all it's usages, without doing it as a global text replace, or worrying that you might have renamed something you shoudldn't? Or is the type checking so "leaky" in a typical project that that kind of luxury (That would be done every day by Java or C# developers etc) isn't really available anyway?

Unless it's a massive overhead to use typescript, autocomplete, renaming etc seems like they would make it worth it on their own.

<comment><USER30> I use what you describe on a regular basis in typescript without issues indeed.

</comment></comment><comment><USER31> There has been some research done on how programmers interpret gradual typing systems, and it turns out that it breaks many expectations and ends up being confusing.

Explainer video: [https://www.youtube.com/watch?v=iRf9l3Bz7nA](https://www.youtube.com/watch?v=iRf9l3Bz7nA)

Original paper: [https://cs.brown.edu/~sk/Publications/Papers/Published/tgpk-...](https://cs.brown.edu/~sk/Publications/Papers/Published/tgpk- beh-grad-types-user-study/paper.pdf)

<comment><USER32> Note that the paper is concerned with run-time type checking and glosses over the fact that most/all of those code samples in the survey would be rejected at compile time by a static type checker (or at least by TypeScript).

Their conclusion that "erasure" is disliked and unexpected is effectively saying the underlying dynamic language's behavior is disliked and unexpected.

Of course it's possible to deliberately or accidentally coerce TypeScript into violating its type constraints and behaving in JavaScript's disliked and unexpected ways, but the survey questions would have to be substantially different, and likely the responses as well.

</comment></comment><comment><USER33> The soundness of the type system is not a valid criticism given that it's aiming at improving a language that had almost no type system at all. If you need more from your types then perhaps TS or JS is not the right choice here.

</comment><comment><USER4> My take away from this: If you don't have the discipline on your team to enforce good structural standards for your code, TypeScript may not help as much as you think.

In my very much opinionated opinion, all the issues highlighted in this article, are avoidable with:

1\. Don't use the `any` type (I'm actually pretty shocked this article doesn't talk about using `unknown` instead of `any`. I have found `unknown` can be used where `any` tends to be used, most of the time, if not all the time, and it comes with the benefits of things like assertion control & tsc's type interference (it acts almost as a marker, in some ways, basically, for the type that gets fed through. It also forces you to think about validating the input)

2\. Enforcement of strict options for the compiler

A non-goal to me is using TypeScript to avoid writing tests. This should never be someone's idea in adopting any typed language. I think this is a smell of a bigger problem. Types or no types, it does not influence why or how many tests I write, as testing is about validating your programs ability to handle its inputs & the correctness of its outputs (your testing algorithms, at the end of the day), so I do not see how this factors testing at all. Types also do not negate the fact you need to do validation (beyond perhaps, trivial validation of arguments at the call site, if your codebase is actually following good structural patterns)

Is TypeScript perfect? No.

Should you use it? I think you should probably make that decision after a careful reading of the documentation & discussing it with your team.

Do I personally think this article has a strong case against TypeScript? No, as its (to me) very trivial to avoid any of these problems.

You know what would likely be more effective with most code bases I've seen though? Good documentation & comments, with explanations of what things do if it isn't obvious enough to pick up in a second or less glance. Preferably following the JSDoc standard.

<comment><USER34> > Don't use the `any` type

The problem here is two-fold:

1\. Culture and existing code. Popular libraries use any when they should be using unknown or just not de-serializing stuff and making you explicity parse it yourself. The reason why these are popular is because culture and because of #2.

2\. Creating type guards is a pain, especially if you're trying to go from unknown to something with a complex structure. If types were something you could reflect on in run time, like most other interpreted languages, this would be a lot easier.

<comment><USER4> To address culture, someone has to start doing it better, no reason it can't be those who know there is a better way, so I treat that as a red herring myself. You could always make a strongly typed wrapper around a library, for instance.

Creating type guards might be a pain, sure. I think assertion functions will go a long way in this regard

[https://www.typescriptlang.org/docs/handbook/release- notes/t...](https://www.typescriptlang.org/docs/handbook/release- notes/typescript-3-7.html#assertion-functions)

I also think that its an overestimated pain. If you are using interfaces to type your objects (commonly, this seems to be the pain point) then I don't think its terribly difficult to construct type guards around that.

There is also the reflect-metadata polyfill (that I think TC39 is eventually going to make a standard) for run time type information. Using decorators could be valuable combined with `emitDecoratorMetadata` option

[https://rbuckton.github.io/reflect- metadata/](https://rbuckton.github.io/reflect-metadata/)

</comment></comment></comment><comment><USER35> the title completely doesnt match the content, this is pure clickbait and logrocket is so shameless about it. i grit my teeth and click but am completely unsurprised at yet another low quality list of arguments that have been rehashed over and over.

here's a less well known, more rigorous study: [http://earlbarr.com/publications/typestudy.pdf](http://earlbarr.com/publications/typestudy.pdf) \- To Type or Not to Type: Quantifying Detectable Bugs in JavaScript

<comment><USER14> they mention a time tax of 262 seconds median for TS annotations for their set of 400 bugs. almost 4.5 minutes. so idk, there seems to be some math missing in this paper about the actual trade offs. so maybe you get a 15% improvement in "detectable" bugs found, at a 13.3% time cost (60 minutes /4.5 minutes) per hour of work. worth it...? are your devs expensive? more expensive than QA.

<comment><USER36> Types are easier to read, reason about and maintain than tests, particularly if it's QA writing the tests instead of engineers.

</comment></comment></comment><comment><USER37> Thing is you can now have many of the benefits of TS without using it in your own code. Most popular libraries come with type definitions now and an editor like VS Code will take advantage of this and give you the same autocompletions TS would.

TS introduces some friction for setting things up, it slows you down in initial development, increases LoC, etc. I do like the type documentation in function signatures, the autocompletion and the refactor support, but I think the project needs to be of a certain size for the cost/benefit trade off favors TS, typically a project that goes on for 6+ months and with 2 team members or more. Anything smaller than that and I wouldn't choose it myself.

</comment><comment><USER38> > ...there is an argument that states that the adoption of TypeScript would > not have been as high if a sound type system is 100% guaranteed. This is > disproved as the dart language is finally gaining popularity as Flutter is > now widely used.

In my experience TypeScript's unsoundness is a feature, not a bug. You cannot compare it to languages that were designed from the ground up to be sound. JavaScript was fundamentally not designed to be used in a 100% sound way, and trying to do so introduces an _enormous_ developer burden in terms of idioms and language features that you can't use, and syntactic hoops you have to jump through. You find yourself constantly fighting against the language.

I know this because at my company we started with Flow, which is (very proudly) sound. It was impossible to be productive. For a small example, every reference to document.body had to have a null-check, even though we could guarantee by where we placed our <script> tags that the body would never ever be undefined. The experience was rife with situations like this, which created tons of cruft and made code harder to read.

"any" is nearly always bad. But the other escape hatches, like casting, have proven essential to building a reasonable codebase that doesn't try to ignore the reality of JavaScript.

> Runtime type checking would be beneficial when dealing with JSON payloads > returned from API calls, for example.

This I agree with, but I don't think it belongs in the core TypeScript project. We used Flow Runtime with Flow ([https://gajus.github.io/flow- runtime/](https://gajus.github.io/flow-runtime/)) which creates runtime assertions automatically based on your static types, on a file-by-file basis. It was wonderful, and is the only thing I miss about Flow, although it was a third-party project and there's no reason something similar couldn't be made for TypeScript. I would be giddy to hear that someone was building one.

</comment><comment><USER39> These kind of articles seem to be commonplace and I frankly do not think they provide any productive value. "any" is supposed to be the escape hatch as TypeScript is designed to be incremental. Anyone with a semblance of understanding knows that TypeScript transpiles into regular JavaScript, you don't run TypeScript code in the browser.

<comment><USER9> Friendly tips: you can replace any with unknown. Other friendly tips: runtime type checks are available [https://github.com/gcanti/io- ts](https://github.com/gcanti/io-ts) [https://github.com/pelotom/runtypes](https://github.com/pelotom/runtypes)

<comment><USER40> Can you please provide more detail when it's best to use runtime type checks? For webapps with strict TS config, I'm failing to see the advantage. Runtime errors can occur when crossing boundaries from server API to UI but when you discover the exceptions, you go fix your contract.

<comment><USER9> 1st it's easier to identify which contract is inaccurate, or even whether the contract is inaccurate or not in the first place

2nd it's more convenient for both the end-user and the developers that errors are handled this way

</comment></comment></comment></comment><comment> lets-surf This example from the article looks like an argument for immutability to me.

        interface A {
            x: number;
        }

        let a: A = {x: 3}
        let b: {x: number | string} = a;
        b.x = "unsound";
        let x: number = a.x; // unsound

        a.x.toFixed(0); // WTF is it?

<comment><USER41> Kind of, you can't have your cake and eat it too.

When it comes to typing systems you have to pick 2: Depth, Mutability, Soundness

</comment></comment><comment><USER42> Whenever that thing about Airbnb comes up I feel compelled to remind that it was a study of _eight_ bugs, three of which ts would've prevented.

<comment><USER35> 8 bugs? are you sure? did you watch the talk? [https://www.youtube.com/watch?v=P-J9Eg7hJwE](https://www.youtube.com/watch?v=P-J9Eg7hJwE)

</comment></comment><comment><USER43> "Is Typescript worth it?"

No, but not because the tired diatribe on typing, but because JavaScript nowadays is mostly good enough... As long as we remember what its goal is and we don't use it for anything more than its intended purpose.

That aside, everything in that post re soundness vs unsoundness was what I used to know (and was taught in college) as "strong" and "weak" typing, is the redefinition recent? Was I taught incorrectly? That aside, C is weakly typed (and there are long, long discussions on it) but I'll say that, if it's good enough for C, then being for or against it becomes pretty much subjective (obligatory IMO, my saying that at all is _also_ subjective).

After all, it's a flamewar that's been going on for decades. Typescript certainly isn't going to solve it.

<comment> archon-99 The definitions are:

Static: Statically checked by a compiler.

Dynamic: Not Statically checked by a compiler

Strong: Types enforced by the runtime

Weak: Types not enforced by the runtime

Of these,

JavaScript: Dynamic, Weak

TypeScript: Static, Weak

C#: Static, Strong

As to if you think TypeScript is worth it, of course its worth it. Whether or not you're writing JavaScript or TypeScript, you're still thinking in types, function signatures and data structures. TypeScript allows you to encode that information so you don't need to hold it in your head (or have other programmers figure it from usage, as would be the case for JavaScript). But that aside, TypeScript's tooling alone makes it worth it.

As for this flame war, i strongly suspect that most type system advocates have mostly likely used BOTH dynamic and static languages (C#, Java programmers have had to deal with JavaScript for decades), while I expect the majority of dynamic advocates (say Python, PHP, JavaScript) have primarily stuck with dynamic.

Those with the wider perspective have the better insight imo.

<comment><USER43> I am aware of those definitions. It was "sound" and "unsound" what threw me off.

> Whether or not you're writing JavaScript or TypeScript, you're still > thinking in types, function signatures and data structures. TypeScript > allows you to encode that information so you don't need to hold it in your > head

Static vs dynamic, a flamewar that's _over sixty years old_ to which I am _not_ going to contribute.

> But that aside, TypeScript's tooling alone makes it worth it.

JavaScript has pretty good tooling too.

> As for this flame war, i strongly suspect that most type system advocates > have mostly likely used BOTH dynamic and static languages (C#, Java > programmers have had to deal with JavaScript for decades), while I expect > the majority of dynamic advocates (say Python, PHP, JavaScript) have > primarily stuck with dynamic.

Should we ask LISP developers? How about its derivates like Clojure or Scheme? There are many of them here in HN (in fact, I've dabbled on Clojure a little bit myself), though that would probably lead to a different flamewar entirely (functional vs oo).

In any case, I don't follow what point you were trying to make writing this suspicion, it was clear that you were going to get counterexamples and you didn't provide sources that at least gave support to having such a suspicion. I would appreciate if you elaborated what was your implication.

By the by, I worked in java during 2013 and 2014, and I've been working with Go exclusively for nearly a year now. I still don't really care about what type system any given language I've worked on has, there's good and garbage code everywhere. Though, since all this can _only_ be opinion until someone conclusively demonstrates a given type system's superiority, I still prefer writing python code.

> Those with the wider perspective have the better insight imo.

Maybe we should ask Guido van Rossum's perspective.

<comment> archon-99 > JavaScript has pretty good tooling too.

I believe most of the best in class tooling for JavaScript borrows on leveraging TypeScript compiler for inference. And its still below the bar offered by TypeScript.

> Should we ask LISP developers? How about its derivates like Clojure or > Scheme? There are many of them here in HN (in fact, I've dabbled on Clojure > a little bit myself), though that would probably lead to a different > flamewar entirely (functional vs oo).

OOP is not at odds with FP. They are different things entirely and can be leveraged in equal measure within a codebase. Consider C# and LINQ (with LINQ derived from lazy expressions in Haskell). As for LISP, TypeScript services as a good test case for layering dynamic languages with type systems, so why not TypeLISP?

Anyway, the point im trying to make is, irrespective of if the programmer is working with a type system or not, the programmer is still reasoning about software with types. The dynamic language programmer is still thinking about function signatures (arguments, return types), they are still thinking about 'the properties of some object' and they still think about generic abstractions (as in .map()). I don't understand why JavaScript programmers are adverse to encoding that information in a type system when it solidifies and communicates their intent. (both to other programmers as well as the compiler)

JavaScript on its own requires the programmer to infer the original developers rationale from usage, and assertions of 'correctness' can only truly be inferred by running a software (by test or otherwise). Obviously, both TS and JS need tests, but in the TS case, you've removed a whole class of issues around types and call signatures, where as in JS, one might be compelled to test both 'types' and 'logic'. A type system can at least narrow huge classes of problems, allowing a programmer to focus on testing logic, not the inadequacies of their (or others) brains to hold mountains of implied type information in their heads.

If you want one practical example..... refactoring. While JavaScript is dynamic, just change the name of a function, or move functionality elsewhere...what assertions can JavaScript or its tooling provide that all dependent code is appropriately updated as a result of that refactor?

Honestly, choosing to leverage of a type system, imo, is an open admission of the complexities of software, and the fallibilities of the human brain. Rejecting the benefits of a type system to me demonstrate a dangerous over- estimation of one own abilities, or a lack of personal introspection with respect to reasoning. While this debate seems to continue, I don't think my views on it ever will.

<comment><USER44> > As for LISP, TypeScript services as a good test case for layering dynamic > languages with type systems, so why not TypeLISP?

Lisp users think that a 'dynamical' and a 'dynamically typed' language are two different things. Lisp is both. Being 'dynamically typed' supports or simplifies a lot of dynamical features.

There are a bunch of languages which implement a subset of Lisp features and which were adding type systems. Historically much of typed FP was developed out of Lisp tradition.

Common Lisp for example has CLOS definitions like:

        (defclass person (living-thing)
          ((name :type string)))

So the definition makes clear that are a class/type which inherits from the class/type living-thing. It also defines that contents of the slot name are of type string.

A CLOS method then is:

        (defmethod say ((from person) (to person) (m message))
          ...)

Which means that an object of class person sends to another object of class person an object of class message.

Multi-methods in CLOS allow us to define and dispatch on the class of several arguments.

Common Lisp then also has type declarations:

        (defun collide (a b)
          (declare (type moving-object a b))
          ...
          )

This allows programs to document types, compilers to use types for optimization purposes and some compilers to do type checking.

What Common Lisp lacks is a more extensive/expressive type system which would be competitive with what Haskell/or similar would offer.

</comment></comment></comment></comment></comment><comment><USER45> I've found TypeScript and React with VSCode to be incredibly productive for web development. If you're on the fence, give it a shot.

TypeScript is a superset of JavaScript, so it brings a lot of baggage along with it, but if you're writing frontend code it's a real pleasure to work with compared to JS.

</comment><comment><USER46> Why do these sorts of articles always give vague definitions of Soundness and act like it exists on a spectrum?

Soundness = Progress & Preservation.

From Pierce's Types And Programming Languages:

"Progress: A well typed term is not stuck (either it is a value or it can take a step according to the evaluation rules).

Preservation: If a well typed term takes a step of evaluation, then the resulting term is well typed."

There are not degrees to Soundness and it is a well defined term.

<comment><USER47> You've shown that _one can give a black-and-white definition of soundness and have it be useful_.

That doesn't mean that there's no way to give useful meaning to "more sound" or "less sound".

Consider the following family of languages:

L has a sound type system.

LD (D for "dynamic") is L _plus_ the ability to escape from it, in specially marked "unsafe" sections of code, into a dynamically typed system. (So evaluation can produce runtime errors, but they can be handled safely.)

LC (C for "crash") is L _plus_ the ability to escape in "unsafe" sections into a system like Ld's except that now type errors aren't checked for and caught at runtime, they just produce memory-stomping and buffer overflows and the like.

D is just LD's "unsafe" language.

C is just LD's "unsafe" language. (Any resemblance to actual real-world languages named C, living or dead, is purely coincidental.)

The only one of these languages that is sound is L, of course. But there is some quality closely related to soundness by which there's an obvious partial ordering where L > LD > D, L > LC > C, LD > LC, and D > C, and if someone describes this situation by saying that LD is "sounder" than C then I don't see any reason why we should stop them.

Similarly: a federal state is either a "perfect union" or not, for any reasonable definition of "perfect", but it's reasonable for the US constitution to aim at a "more perfect union". A thing is either "unique" or not, but despite the cries of pedants it's reasonable to describe a limited- edition Ferrari of which only two were ever made as "almost unique" and as "more unique" than a standard-issue Ford Fiesta. A given region of space is either "vacuum" or not, but most of the things we describe as "vacuum" actually contain some very rarefied gas and it's common to use terms like "high vacuum" to quantify how vacuum-like a "vacuum" is.

</comment></comment><comment><USER48> There is quite a lot missing in TypeScript types (e.g. integer or uint types would help a lot in typical tasks such as accessing an array or iterating a loop; even if they are stored as floats, I want to make sure someone won't take 2.5 element of a list to get undefined).

Still, for me, TS is a day and night difference with JavaScript. While it does not solve everything, at least I know what is code about. E.g. when I see `volume` in plain JS the first question I ask myself is: is it a number, plain object, instance of a class, a simple boolean, or what?

It is not only about tests. It is also about readability.

</comment><comment> crooked-v Typescript from the ground up is absolutely worth it, starting with how it gives you full IDE inference for all those "big blob of options" objects that a lot of JS methods use.

<comment><USER49> Any IDE could do that for JavaScript; it has nothing to do with TypeScript.

<comment><USER50> How could this be done for JavaScript without any mechanism for signifying the _type_ of object that is expected?

<comment><USER51> If you're using a third party dependency that has type definitions tsserver / VSCode will pick it up regardless of whether you're writing js or ts.

<comment><USER22> I don't believe many understand how much tsserver is doing behind the scenes in Vscode for JS code bases.. Of course any IDE can do that, because they can use tsserver via the language server protocol haha.

<comment><USER51> Yeah I use it with CoC in nvim and find it works as well as VSCode.

</comment></comment></comment></comment></comment></comment><comment><USER52> Ignoring the tech side for a minute, my major problem with TypeScript is that TS proponents assume that the static vs. dynamic debate has been settled. That the future is static typing, and that people have to be crazy for wanting to do dynamic typing in a dynamically typed language.

A great many developers have found themselves having to write JavaScript because that's where they got pigeonholed. Then, because they'd rather be doing Haskell, Java, or whatever, they bring that crap to JS and enforce it on developers that possibly liked doing regular JS.

Type inference is older than I am. Yet you would think this is some new technology. When in reality, we could have had it on Ruby. On Python. On Perl. And on Lisp. Decades ago. It's not new and it's not special. But it certainly has a lot of undeserved hype at the moment.

There is no conclusive proof static typing reduces bugs. This is some weird myth that keeps circulating. The trend pendulum will continue swinging though. TS won't be immune.

<comment><USER53> I don't see how you can claim that TS believes the static vs dynamic debate is settled when TS already includes, and continues to add features that enable and make it easier to dynamically type stuff (for example, unknown is a fairly recent addition).

In reality, the reason TS has been so successful, and likely will continue to be so successful (until they screw up the execution, or forget what made the language so successful) is thst TS is an entirely pragmatic language. It uses theory not to decide its roadmap, but rather, uses actual problems and needs faced by JS developers to decide the roadmap, and then uses type theory and other CS concepts to solve those problems.

For example, the reason TS uses Types is not because a group in MS decided that static typing is better than dynamic typing, and what JS really needs is a layer of types above it (that was coffeescript...). Typescript was created because MS wanted to make better IDEs and tooling for JS (specifically, they wanted to bring Intellisense which is a huge VS selling and marketing point, to JS) and they realised they couldn't do that without adding type information to JS.

Hence, a practical need drove the decision to create TS.

<comment><USER23> IDEs aren't that necessary if you have strong command line skills. The only ide feature I really miss is autocomplete because it's a pain to remember method names

<comment><USER54> My IDE is Vim/i3/bash.

So the IDE stuff isn't extremely advantageous for me.

But that's the reason Typescript was created.

A convenient side effect of that for me is that I can manually use the same clues an IDE used to understand the code base I'm working on easier, faster and with more confidence than I would be able to in a vanilla JS project.

</comment></comment></comment></comment><comment><USER55> Typescript users: LOVE IT!

Non-typescript users: ANOTHER layer? /sigh/

Cynical, yes, but that's because I haven't had a smooth onramping experience the times I thought about switching. Would love a recommendation.

<comment><USER56> Using TS since ~2017.

Moving an existing codebase to it is a giant pain, otherwise it's not bad.

It fits you into better practices, but don't treat it as types are always true. When debugging issues I'll commonly assume Typescript's types do not exist or how it would act if they are wrong. This is notably true of consuming API responses with mixed data types.

Generally, what I really like about typescript is that you normally blend it with linting, minifying, and strong IDE integrations. These things, when combined, really help code readability and adherence to TS conventions and eventually save you from massive bugs that might not have been caught prior. Obviously, at the end of the day, how you use it really defines how helpful it is.

All that said, I haven't ever really had major issues with the tools around TS.

</comment></comment><comment><USER57> > the adoption of TypeScript would not have been as high if a sound type > system is 100% guaranteed. This is disproved as the dart language is finally > gaining popularity as Flutter is now widely used. Soundness is a goal of the > dart language which is discussed here.

Look, I wish TS type system was sound too, but that's not a "proof", it's just a data point. TS doesn't have the same goals as Dart, there are lots of variables which aren't the same, so you can't just take Dart's approach and say "look I proved it". There are lots of popular languages with unsound type systems; Java for example.

I don't know how you could have a criticism of TS without mentioning the lack of sum types. Yes, you can fake it by having an object with the same field name differentiated by a string constant, it's still not as nice as having first class support for sum types.

</comment><comment><USER58> Another Typescript fan here. The title didn't match the post content but I agree with everything he wrote concerning type "soundness". From my POV it's a downside of typescript but it makes sense since it's just a superset of JavaScript

<comment><USER59> Yep, it ain't perfect but it is so much better than not having it. Anyone being concerned about TS adding overhead please take a look at how generics in Java work - both struggle with erasure of type information at compile time. Java may be sound but doing anything non trivial with generic types gets complex quickly. Compared to Java generics doing TS advanced types is almost a joy.

</comment></comment><comment><USER60> Eric Elliot does a great analysis on this:

[https://medium.com/javascript-scene/the-typescript- tax-132ff...](https://medium.com/javascript-scene/the-typescript- tax-132ff4cb175b)

<comment><USER7> side note: but what the hell is hashicorp configuration language (HCL)?

It's apparently the second fastest growing language based on whatever metric the chart is using and I've never heard of it.

<comment><USER61> It's used with Terraform, amongst other things. So you might not have heard of it if you're not doing devops/infrastructure work.

</comment></comment></comment><comment><USER62> I might get downvoted, but I believe that using "strict" mode is not worth it precisely for the reasons this article talks about. You get at least 90% of the benefit of Typescript (IDE support, typos, refactoring, etc) without --noImplicitAny and other flags that induce a lot of boilerplate and wasted time. After all, how confident can anyone be that DefinitelyTyped types are correct? I use types when I find them useful. I also enjoy being able to not use types when I don't need them, which is why I choose to use Javascript.

</comment><comment><USER63> I'd say it's definitely worth it.

I wrote a blog post recently about my experiences learning and using TypeScript as both an app dev and a library maintainer for Redux:

[https://blog.isquaredsoftware.com/2019/11/blogged-answers- le...](https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and- using-typescript/)

As part of that, I listed some of the tradeoffs and takeaways. In particular, I strongly recommend a "pragmatic 80%" approach to tackling TS.

</comment><comment> dynamite-ready I won't lie. I read the title, and thought "At last, objectivity". It's like CoffeeScript all over again.

Except this time, this particular assault on ECMAScript is much better funded.

Don't get me wrong, I think there's a place for strong typing in web based UIs. But for one, WASM is a better idea for the choices and flexibility it offers, and more importantly to me, I think the bigger challenges in UI programming are not solved by strict typing.

</comment><comment><USER64> Most npm modules are written in JavaScript and when it comes to types they are handwritten (if they exist at all). The very nature of this makes TS unsound, as you have to count on the types being written correctly. I've encountered incorrect types many times. Even worse, when the types ship inside the module and are incorrect, it's difficult to correct them. I prefer JS modules to have a separate @types module.

</comment><comment><USER65> If you're writing JS, then adding TS will give you a lot more reassurance when writing new code or refactoring old one. Even if it's not perfect, I don't see a reason why you'd choose JS over TS today other than maybe you don't want to go through the first month of getting used to. Once you're out of that, you'll end up with code that's much easier to reason about and also debug, in my humble opinion.

</comment><comment><USER66> I've done some programming with typescript. IMHO the reason for around 50% of the javascript world now using it is that it provides substantial improvements over javascript that are real. Personally, I insist on typescript on any node.js or frontend javascript codebase these days.

Yes, it's not perfect. And, yes the inherent problems of javascript still leak through in many places. But with a little configuration, you can make the static code analyzer and compiler help you avoid most of that.

IMHO the amount of verbosity it adds is negligible. I actually measured a slight decrease in LOC when I was converting code. You add some type annotations (which IMHO also help human code readers) but then you also get access to syntactic sugar to offset that. It's a fair compromise considering that most tools trying to help the developer have more to go on and basically work much better. Ballpark your number of LOC is not going to grow when switching to typescript.

But IMHO it's just a gateway drug for developers to find their way to more capable languages. Personally, I'm interested in the direction that Jetbrains is taking with Kotlin-js, which with the next version will have some nice tooling around it to leverage typescript type definitions for integrating npms and hides most of the build tool madness behind gradle. The kotlin compiler has a much more sound/strict typesystem than typescript and also the language has quite a few language features that the typescript developers have not gotten around to supporting yet (they've been making progress catching up with recent releases though). They are also addressing size of the minified code. With the recent improvements, hello world is now a lot more reasonable than it used to be (<80kb instead of ~1MB). It eliminated unused code more effectively.

If you feel brave, you can get started with this on a modern react project right away. Most of the dependencies you'd use for that should just work fine with kotlin-js. But realistically it's probably going to take another few years to stabilize. IMHO Kotlin is interesting because it is already widely used by frontend developers on Android and has a lively ecosystem of frameworks that might also make sense in a browser. Also co-routines are nicer than async await in typescript.

And of course WASM is opening up this space further to just about any language. So for people finding themselves a taste for more/better typing, there will be plenty of alternatives for typescript.

</comment><comment><USER67> In general it seems hard to be in-between dynamic typing and static typing (compiling). As the article implies, one typically has to do more testing if dynamicness can allow "bad data" in.

The trade-off for dynamicness is more productivity and (potentially) easier- to-read code because less code is needed on average to express an idea since type-related code isn't needed as often. But if TypeScript is not type-safe enough to reduce the need for fine-grained testing, then you get the worse of both worlds: the verbosity of types and the busy-work of micro-testing.

That being said, I wish JavaScript would add a feature to allow _optional_ parameter checking such as:

function foo(a:intReq, b:datetime, c:datetimeReq, d) {...}

Here, the "Req" ("required") suffix means the field can't be null or white- space. Parameter "d" has no type indicator. It's still "soft" type checking, but would catch a lot of problems earlier.

</comment><comment><USER68> It's interesting that someone who is primarily using JavaScript in the backend is criticizing TypeScript's type system. There is a simple reason why TypeScript's type system is how it is... TypeScript is additive which works well in practice.

</comment><comment><USER69> LogRocket deserve some praise for doing the company blog right. Good, self hosted content (no Medium) and well written pieces on technology from a practical everyday perspective. I am not a customer, by the way.

</comment><comment><USER70> I don't think pointing out deliberate design decisions is a valid criticism. It's like criticising a chair for not being a beachball.

Folks seeking a Haskell-like type system in javascript certainly have options.

</comment><comment><USER71> This article is wrong from many aspects. There are things that many developers can't get with Typescript and it's flexibility...just always keep in mind what makes Typescript so special compared to any other languages. You can't achieve both flexibility and typed solid programming in the same place, you must sacrifice the things you just mentioned and few others. Typescript was supposed to be flexible and developer friendly, it's not a hardcore language and never will be.

</comment><comment><USER72> A bunch of the issues here are due to the author actually casting instead of letting inference do its job.

       // unsound, val.toFixed(0) compiles
       let val: number = ("string" as string | number)

vs.

       // sound, val.toFixed(0) does not compile
       let val =  ("string" as string | number) // sound

In general, it's unnecessary (and as demonstrated, potentially harmful) to annotate assignments like these.

<comment><USER73> Their example without `: number` still exhibits the exact same behaviour.

The `: number` isn't a cast either, it's declaring the type of the variable.

You can't help but explicitly name the type of a variable in many cases. What if they were passing val to a function as an argument? You can't have 'function foo(x)', you have to have 'function foo(x: number)' and name the type.

So yes, their example is contrived, but no, what you said is not sound. It has the same problem as the one the author mentions. The typescript compiler intentionally does not catch their issue.

If I'm misunderstanding what you're trying to demonstrate, please make a typescript playground of it.

</comment></comment><comment><USER74> The author's example is a trivial corner case that can be easily avoided.

It is nowhere close to important enough to fuel the question of 'Is TypeScript Worth It?'

</comment><comment><USER23> I think I'm alone in this, but JavaScript is a neat language that is incredibly powerful and expressive (minus a few warts). Most of the problems that arise from it seem to come from undisciplined work habits and a lack of code review. As long as your team is smart enough to not call all your function arguments "args" or "data" or "params", the asynchronous flows are really nice. IMO at least

</comment><comment><USER75> It's worth it because it catches a lot of low-hanging bugs at a small cost, and it's well maintained and has great tools support. Plus you can even use it like a simple linter if you want to continue writing vanilla Javascript (it catches less, but still catches a lot).

</comment><comment><USER76> I don't know how these people are using TS, but I've been part of a major project for over a year and we've had zero runtime issues, using all kinds of libraries in both nodejs and the browser. But for our standards, that object assignment in the example is a big no-no, TS or no TS.

</comment><comment> dynamite-ready I've got a tangential question, and I think it's worth asking here.

With the precision ML requires, why aren't data scientists rushing from Python, to a language with a stronger type system?

<comment><USER77> Most machine learning doesn't work the first time and required rapid iteration outside of your production system in my experience. Then, when you finally get a model, you can put those weights into your stable production system that has all the automated testing and is written in a typed language.

</comment></comment><comment><USER78> I had this question since I tried rewriting some big-todo app in TS.

Do people try to write a core in simple (sound) types and then have an outer shell of IO/frail typechecks around ?

</comment><comment><USER79> Change my mind but if you are using VScode you're getting 90% of the benefits without having to take the cost of writing types.

</comment><comment><USER80> Worth it at component level. Hassle at application level.

I use TS to write components and JS to write the app using those components.

</comment><comment><USER22> Interesting.. The biggest drawback I've experienced with TypeScript has been the complaining.

</comment><comment><USER81> The main problem with TypeScript is that at the end of the day -- you're still using JS.

Which outside of its natural realm of application (i.e. the browser) is a highly questionable value proposition.

"A bandaid over a machine-gun wound" is what we might call it.

</comment><comment><USER14> nope - the loss in velocity is not worth using it unless you're a massive team. TS is for Java programmers who are mad at Javascript for existing and don't know how it works well enough to grok overloading etc. plus you get a lot of the benefits of TS in an IDE like VSCode without actually having to use types at all. if you're a javascript native, typescript is constricting and eliminates one of the best parts of javascript - no types!!

<comment><USER82> [https://www.tutorialsteacher.com/typescript/function- overloa...](https://www.tutorialsteacher.com/typescript/function-overloading)

TS/JS don't allow for overloading the way that other languages do - it does not allow you to differentiate between functions via number of parameters, only types of parameters. If you try to differentiate based on number of parameters, it will simply use whichever definition of that function name it finds first.

<comment> 52-6F-62 That's not [entirely] my experience. Here's a quick example:

Declaration file style:

\---

        // add.d.ts
        export declare function add(a: number, b: number): number;
        export declare function add(a: number, b: number, c: number): number;
        export declare function add(a: number, b: number, c: number, d: number): number;

\---

        // add.js
        function add() {
         switch (arguments.length) {
          case 2:
           return arguments[0] + arguments[1];
          case 3:
           return arguments[0] + arguments[1] + arguments[2];
          case 4:
           return arguments[0] + arguments[1] + arguments[2] + arguments[3];
          default:
           throw new Error("Too few or too many arguments. Number of arguments: " + arguments.length);
         }
        }
        module.exports = { add };

\---

        // adding.ts
        import { add } from "./add";

        console.log("4 + 4 =", add(4,4));
        console.log("4 + 4 + 4 =", add(4,4,4));
        console.log("4 + 4 + 4 + 4 =", add(4,4,4,4));

\---

(Gist: [https://gist.github.com/Robert- Fairley/98a2da3f0361e524f4e05...](https://gist.github.com/Robert- Fairley/98a2da3f0361e524f4e056d947a6172a))

It will default to the first function name, but it definitely allows for overloading the number of parameters.

It's not perfect as you do still have to implement the function as it would need to be implemented for JS

</comment></comment></comment><comment><USER83> In type systems there's a tension between expressiveness, soundness, and comprehensibility. A sound type system must exclude _all_ programs that have runtime issues, and, holding that constant, try its best to maximize expressiveness and comprehensibility of the programs that can be written.

But what about programs that can run fine but are excluded by the type system? They are _censored_. This is what's less visible until you actually try to build something substantial, pushing the boundaries of expression, performance, or scale. Then you'll find that a sound type system can become more and more of a straight-jacket. One that forces you to write code in ways that are limited by what its type designers could envision expressing (or could prove that was safe to express).

The trouble is that it's hard to know when you might reach the point where the type system begins to limit you. It might never happen, as you frolick happily within the walled garden. Or it might happen when you write your first line of code. In a large system that must deal with external requirements, it's something that in my experience becomes inevitable. That's not even touching upon comprehensibility, which becomes an increasing challenge for purely sound type systems as they attempt to increase expressiveness.

The biggest innovation of TypeScript is JavaScript. That is, TypeScript started with a huge established corpus of JavaScript that showed what developers wanted to express and how they wanted to express it. And, crucially, how popular various kinds of expression actually were in the developer community. This forced TypeScript to take practical expressiveness of millions of lines of JS seriously, that ordinarily would have been censored by type system design before the first line of code was written.

That's why it's entirely unfair to harp on TypeScript's unsoundness, without also exploring the corresponding gain in expressiveness and comprehensibility relative to other type systems.

BTW, this line of reasoning is the reason so many "sound" type systems also have their equivalent of "any": Rust has unsafe[1]. C# has unsafe[2]. Flow has any[3]. And all practical languages have strings, which are kind of a lowest common denominator when it comes to dealing with a type system that simply can't express what you need.

[1]: [https://doc.rust-lang.org/book/ch19-01-unsafe- rust.html](https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html) [2]: [https://docs.microsoft.com/en-us/dotnet/csharp/language- refe...](https://docs.microsoft.com/en-us/dotnet/csharp/language- reference/keywords/unsafe) [3]: [https://flow.org/en/docs/types/any/](https://flow.org/en/docs/types/any/)

</comment><comment><USER84> yes

<comment><USER85> Was working an application written in JS

Converted it to TS. In the process of fixing up types, it found bugs for us. Value demonstrated

</comment></comment><comment><USER86> I stopped reading after the first sentence.

</comment><comment><USER87> I don't like TypeScript at all. I used to write c# and javascript all day. Every time I had to write javascript, it was much more enjoyable than writing the c#. I would often have to create classes purely because the language required them. All of these classes all over the place with no methods in them at all. A whole bunch of typing all over the place that I could tell I was never even mentally parsing, but still having to type and see on the screen.

Then I started working on my own and decided to use Node a lot in the situations where I would have to use c# at my previous job. There were no more bugs, no problems with refactoring, and it was much more enjoyable than writing c#.

Now this TypeScript is infecting javascript, and all the jobs and so on require "typescript" instead of javascript. It puts all the things I didn't like about c# back into javascript. People will make all kinds of ridiculous claims that it is irresponsible not to use TypeScript, and that it improves productivity and so on. None of these claims are true and don't get to the real reason that TypeScript exists.

Most well-structured programs aren't one giant function that is hard to refactor. They are usually a series of isolated, small functions. There is even a trend towards "microservices" and function as a service and so on. These are things that reduce the claimed reasons for TypeScript, rather than increase it. Many times I see the reason for using TypeScript being "it is good for large teams". Yet still, I see it used in teams of 3 people all the time.

The real reason TypeScript is used is because there are a very large number of programmers now, which means the quality of the average programmers is much lower than it has ever been. Many people who program often just copy and paste code from stack overflow. Many of these people were the same people who looked in fear at JavaScript, and couldn't even understand it because it wasn't the one language that they knew. TypeScript gives these people more safety, feedback, and familiarity to be able to do their job.

That is fine, but lets not pretend it is anything else.</comment>


Does Things.app Have Over-the-Air Sync? - <AUTHOR> http://mitchj.info/blog/2010/10/does-things-app-have-over-the-air-sync/ <comment><USER2> It's actually a really good point. Things is so desperately in need of cloud-y syncing, I can't even begin to describe it. Apparently they're working on it. Still, embarrassing. All the others are getting it right.

Well, maybe there's a feature in store that makes up for it...

</comment><comment><USER3> This is really a post? Come on man!</comment>


New Look for GMail blog - <AUTHOR> http://gmailblog.blogspot.com/

<comment><USER2> I would really like at least _some_ part of the Internet to remain a collection of documents, and not a framework-based application.

</comment><comment><USER3> I tried all the layouts and can't get my head around them.. except for the 'sidebar' view, they all feel like Flash websites from 2005

</comment><comment><USER4> Some of these designs look very nice. Some others made my brain hurt as I couldn't figure out how the data was structured. They may not work for the gmail blog, but they may be perfect for certain "tumblresque" blogs.</comment>


Show HN: Framework for faster distributed data transfer - <AUTHOR> https://github.com/mgronhol/pouring-rain

<comment><USER2> Change test-client.py to end:

      print client.fetch(1000)
      print client.fetch(1)

And when you run it, you get the same thing twice (whatever file was specified as the first argument to test-server.py on the commandline). On the other hand, change it to end

      print client.fetch(1)
      print client.fetch(1000)

and you get "Hello World!" twice.

At one point the server process also gave me this:

      Server(s) started. Press enter to stop.
      Exception in thread Thread-1:
      Traceback (most recent call last):
        File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 552, in __bootstrap_inner
          self.run()
        File "/Users/wolfson/src/others/pouring-rain/LT/Server.py", line 84, in run
          self.streams[ entry[1] ].discard( entry[0] )
      NameError: global name 'entry' is not defined

<comment><AUTHOR> Thanks, just noticed a small initialization issue there, fixibg that soon :)

</comment></comment><comment><USER3> You said Luby, so prepare to be vaporized.

On the technical side, theoretically this should only be a few percent faster than BitTorrent but requires significant complexity.

<comment><USER4> why vaporized?

also, why faster? does bittorrent duplicate some traffic?

<comment><USER3> BitTorrent has overhead from control traffic (have messages etc.) that can theoretically be eliminated using rateless coding. The extra decoding makes it a wash IMO.

<comment><USER5> FWIW, when building the second version of the core tech from which BT was of forked we did license the tornado codecs from digital fountain to try to get a better reliability rate and it ended up being worse than a wash; setting aside the additional complexity it adds to the system it completely screws with internal block verification based on hashes. The blocks are also not structured compared to other FEC codecs (e.g. Rizzo) so you lose any hope of streaming. Long sorry short, unless you are trying to get around nasty packet loss there are better encoding schemes for this sort of data distribution task.

</comment></comment></comment></comment><comment><USER4> this is all new to me and i'm struggling to find a friendly, simple introduction to the field. does anyone have a good link to, say, an introductory article on fountain codes? i'm starting to get a feel for the idea from reading various wikipedia pages, paper abstracts, powerpoints, etc, but a good "layman's" article would be great...

[update] huh. just after posting i started searching for "fountain codes" and found this - [http://blog.notdot.net/2012/01/Damn-Cool-Algorithms- Fountain...](http://blog.notdot.net/2012/01/Damn-Cool-Algorithms-Fountain- Codes) (previously had been searching for luby, raptor, etc).

</comment><comment><USER6> I fail to see how is this _exponentially_ faster. "Transfer time T(K) = 1.25/K where K = number of servers" seems pretty linear to me...

<comment><AUTHOR> Linearity: function's derivative is constant w.r.t. the parameter discussed. dT(K)/dK = -1.25/K^2 and this most certainly is not constant.

<comment><USER6> To clarify, the original title said that this was a method for _exponentially faster_ data transfer. That said, you got me in that it is not linear. As you have shown, that function is quadratically decreasing (which is _worse_ than linear). The title has been corrected since then, so I kind of got my point through.</comment></comment></comment>


Letters to Uncle Steve: 12 Punchy Steve Jobs Email Replies - <AUTHOR> http://www.ismashphone.com/2010/11/emails-to-uncle-steve-12-steve-jobs-email-replies.html <comment><USER2> I love it. It communicates that he is 'one of us', that 'he cares' about his consumers, that he values our opinions. Even if he only answers with 'no'. He is very busy, he doesn't have time to write long answers. Does that mean he's better off not answering? No, people love him for dropping short emails. Well, is that intentional, some sort of marketing strategy? That's probably part of it, but not more - otherwise more CEOs would do it.

Great stuff.</comment>


Nursing home residents positive for coronavirus, but show no symptoms - <AUTHOR> https://www.bostonglobe.com/2020/04/03/metro/51-residents-positive-coronavirus-wilmington-nursing-home-despite-having-no-symptoms/ <comment><USER2> Is it possible yet, to identify whether someone has already had the virus and is immune?

My gut feeling tells me, that half of the other 47 of the total 98 residents may also have already had the virus.</comment>


The Great UHD Codec Debate: Google's VP9 vs. HEVC/H.265 - <AUTHOR> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=103577

<comment><USER2> I guess that explains my recent question of why the MPEG side of things stopped publishing comparisons to VP9 after it actually got released and instead continues to point to studies they did from random git commits, 6 months before the first (and even then explicitly called out as beta) release of the encoder.

Be interesting to see the results from this comparison, as they seem to generally be a respected third party in this field:

[http://compression.ru/video/codec_comparison/call_for_codecs...](http://compression.ru/video/codec_comparison/call_for_codecs_15.html)</comment>


Instagram hides false content behind warnings, except for politicians - <AUTHOR> https://techcrunch.com/2019/12/16/instagram-fact-checking/ <comment><USER2> Pardon my ignorance here but are they not overthinking this a bit? For political or other high profile accounts,when inaccurate facts are stated:

\- List the facts at dispute and let them know you were nkt able to independently verify the claims and require a response including at least two independent sources backing their statement.

\- Of course they'll reply with bogus (independent ) sources but the point is this allows a warning like "<platform name> found incorrect statements made on thid AD. The advertiser had responded stating their reasons and sources backing their claims. Click <here> to view the contested facts, why we found them inaccurate and the advertisers response."

It's not a generic warning saying the ad is a lie. The advertisers can only complain so much about impartiality since at the end of the day not only was their ad allowed but the users are left deciding who is correct, the platform or the advertiser? If they are a legitimate opposing political party they can also use their special account to contest facts made by their opposition and a similar warning can be shown on the opposition's ad stating how an opposing party contested specific statements and what the platform's fact finders think and why. And of course charge them extra for having special accounts.</comment>


EA removes Battlefront 2 refund option as gamers mass-cancel pre-orders - <AUTHOR> https://thenextweb.com/gaming/2017/11/14/ea-battlefront-2-refund-remove/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheNextWeb+%28The+Next+Web+All+Stories%29 <comment><USER2> Can mods update the title to the one of the site: "EA removes Battlefront 2 refund option as gamers cancel pre-orders en masse [Update: False alarm]" \- Looks like this is actually not a problem.

> Update: As pointed out by PCGamesN, it appears the refund button is disabled > for all pre-orders on EA's Origin store – not just for Star Wars: > Battlefront 2.

> While EA does indeed offer refunds for up to seven days after a pre-ordered > game launches, the refund button only appears once the game is out. This > means that anybody who wants to cancel their pre-order will have to go > through the customer support chat by default.

> Or alternatively, wait for the refund button to show up once Battlefront 2 > launches officially on November 17.

<comment><USER3> I disagree. Disabling all refunds is an obvious obfuscation for disabling BF2 refunds.

<comment><USER4> The update is that refunds aren't disabled, the system has always worked in this particular way for pre-orders less than 7 days before launch, and nothing has changed. When the game launches, the refund function is available for 24 hours from first start up.

</comment></comment></comment><comment><USER5> With respect, I think a lot of people are missing the bigger issue here. Slowly, steadily, and imperfectly, mass culture is starting to demand authenticity from the companies that sell them products. The most downvoted comment on reddit, with something like 650k downvotes, is EA's predictably soulless PR response to the pricing complaints (which is now copy-pasted into every thread about p2win and overpriced microtransactions).

This is part of a cultural shift. EA appears to be on the wrong side of it, and the traditional "community engagement" tactics they deployed backfired horrendously. Twenty years ago, you could adequately manage a mass consumer community with ads and some targeted engagement. As people's resistance to transparent inauthenticity grows (and it has been growing steadily for at least fifty years), it is becoming increasingly difficult to manage people one doesn't actually care about. Mass credulity is decreasing (slowly, steadily, imperfectly).

As with all cultural shifts, there are contradictions and complexities. Yes, some kids in the "downvote brigade" will buy the game anyway, and there will be whales who spend too much money on the game. The problem for EA is that they won't be as numerous, and as time and culture march on they will eventually all but vanish.

I don't think anyone in advertising or PR thinks their job is getting easier. And honestly, it should be difficult to sell people stupid baubles for large amounts of money. I think the rise of mass media exposed some holes in our collective cultural defenses that we've been patching up over two or three generations. This kind of backlash will become increasingly more frequent as large entertainment companies attempt and fail to adapt to the changing times. At the end of the day, some middle-aged cadre of smart, possibly even savvy and well-meaning PR people will try to adapt EA's (or whomever's) community engagement tactics, and they will find a new and creative (even laudable) ways to fail.

<comment><USER6> I might be too pessimistic, but I'm inclined to believe that PR/marketing will figure out how to be 'authentic' or otherwise solve this problem well enough. There's lots of smart people who get paid to do so, and I think that trumps any disjointed mob behavior.

In fact, it's quite possible EA is not at all surprised by this backlash and was simply 'optimizing'. This time they went a bit too far perhaps, so next time they'll be a bit nicer until all this is forgotten.

I mean, we're talking about EA here. I don't recall a time where they weren't hated by most of Reddit, and I don't get the impression it's been much of a problem for them.

</comment></comment><comment><USER7> And yet folks will keep falling for the CGI trailers and marketing hype EA churns out for every game. The only solution is to wholesale stop supporting ANY game EA produces.

<comment><USER8> And a single whale can make up for literally hundreds of lost sales through micro-transactions.

<comment><USER9> Exactly! Microtransactions are there to grab the big spenders. Mobile "games" follow this pattern to the extreme. For example some guy spent $1M playing a mobile game ([0] and HN discussion [1]). Honestly I don't understand why game companies are left to exploit gullible people (adults and/or kinds) into what is essentially gambling.

[0] [https://arstechnica.com/tech-policy/2016/12/california- man-s...](https://arstechnica.com/tech-policy/2016/12/california-man- spent-1-million-playing-game-of-war/)

[1] [https://news.ycombinator.com/item?id=13165780](https://news.ycombinator.com/item?id=13165780)

<comment><USER10> >into what is essentially gambling

I think at this point it's important to differentiate: Loot-Crate systems with resellable content (CS:Go etc) are gambling. Loot-Crate systems without resellable content function by the same mechanism but are different legally.

On the other hand pay-to-win or pay-to-skip are very different from gambling and work by completely different mechanisms. Being ahead of everyone else allows whales to either feel superior or to help fellow players, making the whales feel useful and depended upon. All of these feelings can be hard to get in the offline world, so instead whales pay to get them online.

I'm not condoning predatory microtransaction systems at all, but I think it's important to differentiate them instead of treating them all as if they were gambling

<comment><USER8> I think it's also important to note that this is not a scenario which was imagined when those rules were put into place and that gacha systems exploit the same psychological responses in order to get you to spend more.

</comment></comment></comment></comment></comment><comment><USER11> The article only tells half the story.

"EA eventually announced it will lower the character unlocking difficulty by 75 percent. But it seems this didn't curb the outrage."

From what I was reading last night they also reduced the currency rewarded by playing the main campaign. Thus making the cost reduction negligible. Looks like it was just a misdirection tactic by EA.

<comment><USER12> Also worth noting, reducing the cost by 75% still means that darth vader costs roughly $65 or 10 hours of your time. That's one character. There are at least 6 others to purchase.

<comment><USER13> Wait, 10 hours of gameplay to unlock Vader? That's actually not too bad. I was under the impression that it was 10x that. Not that I'm going to buy this game, but 10hrs is easily attainable in 1 weekend. Especially if the game is fun.

<comment><USER12> A character that previous games let you play from the get-go and for free.

</comment></comment></comment></comment><comment><USER14> Is it possible this is all free marketing for EA and was planned? (or at least controlled after?) This customer base has no self control or long term opinions. Hell, i bet half the people downvoting on Reddit will still buy the game + creates before Christmas.

The wider causal gaming community probably don't know or care.

<comment><USER15> There is no way a marketing department would approve that plan. I guarantee everyone over there is in full on damage control (how they're doing on that remains to be seen).

</comment></comment><comment><USER16> I used to have a video game addiction. I once sat on my knees for 8 hours playing Mega Man 2 (I could barely unfold my legs afterwards). When I got Diablo in 1996, I stayed up for 40 hours playing it, to the point where I started clicking on hallucinatory demons on the screen.

I am so happy I stopped playing video games before in-app purchases became a trend. Destroyed productivity was bad, but the stories about people flushing tens or even hundreds of thousands of dollars down the drain terrify me. That could have been me.

</comment><comment><USER17> The comment itself doesn't seem all that terrible though. Perhaps a little tone deaf but not at all offensive.

<comment><USER18> It snowballed a bit, but overall it reflects the disregard gamers feel from EA: they try to make a $60+ game that also has microtransactions (Games-as-a- Service) and everything that is buyable by microtransactions has to be impossible/extra tedious to achieve in regular play to bait the whales(their actual target demographic) into wasting a ton of money (while the average gamer is just plankton/social bait to EA). And then they try to bullshit their way out of it with this argument.

<comment><USER19> People don't want to pay for DLC, season pass, expansions basically nothing? How do you pay for upcoming content then? For the current price the game has a vast content.

<comment><USER20> Maybe you've heard of Dota 2 or Overwatch, two massively profitable and popular games with no interactive content behind transactions. EA could have easily just made different cosmetic skins for the USS Enterprise (or whatever) with a hierarchy of rarities, stuck them in crates, and let the money roll in.

<comment><USER21> > Maybe you've heard of Dota 2 or Overwatch, two massively profitable and > popular games with no interactive content behind transactions.

I agree with what you're saying, but there's a small amendment to that: with Overwatch, you _can_ buy loot boxes for extra character skins or sprays. But the impact on the game is minimal[0]. Loot boxes start at $1 each (with volume discounts available), but you also get one for free every time you level up, which happens every 5 games or so[1], in addition to a loot box for every three arcade-mode games you win (up to three boxes per week).

In my mind, this is the right way to do it: the content is good enough to be engaging and worth paying a small amount of money for if you _really_ want a certain skin, but you can also decide never to pay one cent after you initially buy the game and still feel like you're getting the full experience.

[0] There are a couple of cases where certain emotes can make it easy to hide in an unexpected location, affecting gameplay, but they're rare enough that the videos get shared widely, and once they're no longer secret, they don't impact the competitive meta-game measurably. In other words, it's self- correcting: there's no _systematic_ way that buying loot boxes to get all the skins/emotes/sprays/etc. allows you to consistently improve your competitive advantage over other players.

[1] Depends on whether or not you win, how well you personally play in each round, whether you're in a group, etc.</comment></comment></comment></comment></comment>


I created a typeless note taking app - <AUTHOR> http://remembber.com <comment><AUTHOR> Librarian is a novel way to look at note taking. This is an MVP and I'm happy to receive some feedback on it. (windows and mac)</comment>


Ask HN: When is the best time to talk to investors? - <AUTHOR>

We are ready to launch our latest startup and we would like feedback from the VC and angels community.
When should we start talking to possible investors. Before we launch, to get initial feedback? After we launch, when we test the acceptance of our product? Six months later, when we are profitable or not?
What is the best strategy to approach them? Just send them an introductory email about our product?
Feedback highly appreciated. <comment><USER2> You should build a relationship with potential investors over time, starting from when you have a prototype. Don't wait until you actually need to raise a round.

Investors like to see traction in your product, and if you lack it, they'll continually label you as "early."

Avoid cold calls unless you have no other way in. Get introductions through your network.

</comment><comment><USER3> Start informally meeting investors without pitching them. Go to conferences and events and try to build relationships.

If you live in the US there should be meetups and/or conferences within driving distance.

Take the time to start building those relationships as soon as possible.

</comment><comment><USER4> If possible, launch first, then start looking for investors. It'll be much easier to get noticed by investors when you have actual users.

<comment><AUTHOR> I agree. But sometimes it is better to get feedback before you launch so you can correct the course early. Most of the time they want to see profits.

So I guess it is a matter of getting advice early and funding later.

</comment></comment><comment><AUTHOR> Another question, should we contact a bunch of them using pitching services like angel.co or is it better to contact them one by one, making it more personal.

Instinct tells you a more personalized approach is better, but pitching services look like a good alternative, if not, why angels subscribe to them?

<comment><USER5> Of course best with a personal introduction, but many start-ups don't have one.

Pitching services are good to cast a wide net but just keep in mind that there are tons of start-ups that are blasted out on those channels so it's a bit harder.

Definitely try to get meetings just to talk and discuss early rather than asking for money. If you get them interested and engaged in more of an advice perspective, they tend to be more interested later down the line.</comment></comment>


Forget silicon – SQL on DNA is the next frontier for databases - <AUTHOR> https://www.zdnet.com/article/forget-silicon-sql-on-dna-is-the-next-frontier-for-databases/ <comment><USER2> Encoding what is essentially able to produce random proteins by backing up data to it.

What could possibly go wrong?

</comment><comment><USER3> "Simply put, at this pace, there soon won't be enough data storage and compute material to go by. Which is why people have been looking into alternative storage media for data for a while now."

If this is true, then why is cloud storage so cheap? What's wrong with just building bigger data centers? Does anybody know what the technical benefit of this technology would be?

In any event, there's something amazing about humans using the same data storage that living organisms use.

</comment><comment><USER4> [https://brandonsanderson.com/books/legion/legion-skin- deep/](https://brandonsanderson.com/books/legion/legion-skin-deep/) Legion: Skin Deep is a modern-day thriller/mystery with some science fiction undertones. In this story, Stephen is taken on a case to find a corpse with important information encoded in its DNA.

</comment><comment><USER5> Make a great movie plot.. data base written.. creating new killer bacteria that wipes out humanity..

<comment><USER6> Alternatively, a dystopian future where big media companies mine human DNA for copyright infringements and courts will order said people to purchase licensing rights to exist. With the alternative being slavery, suicide, or having the offending portions of DNA removed.

The act could be called the DNCA.

<comment><USER7> Or because of patent infringements... some biotech corporation might have these</comment></comment></comment>


Why I, a founder of PLOS, am forsaking open access - <AUTHOR> http://www.michaeleisen.org/blog/?p=1580

<comment><USER2> I fully agree. Open Access journals are evil. Very nice analysis, has anyone been able to quantify the impact of the increased popularity of OA journals on the financial crisis?

Also we should take into account the energy saved by all the scientists not being able to download paywalled full pdfs, mother earth says thank you.

</comment><comment><USER3> I thought we were going to keep the April Fools pranks of HN.

</comment><comment><USER4> "Sure PubMed Central – the free database of papers produced with funding from the National Institutes of Health – gets over 1,000,000 hits a day. But do you really believe numbers from the government? After all, these are the same people who are saying that 7,000,000 people have signed up for Obamacare."

Yes, I do believe they are reasonably accurate, the post is filled with these spurious arguments.

tldr; do not read. waste of time

<comment><USER5> It's an april fools joke, laced with massive amounts of obvious sarcasm.

<comment><USER6> My favorite:

"But we never hear about the people who've been hurt – like all the students at places like Harvard and Stanford who no longer have better access to the scientific literature than hoi poloi at lesser institutions."</comment></comment></comment>


Link's Awakening disassembly progress report – week 5 - <AUTHOR> https://kemenaran.winosx.com/posts/links-awakening-disassembly-progress-report-week-5/ <comment><USER2> That you can apparently see where designers changed their mind when building a room, because items have sometimes been "painted over" with other items, is absolutely amazing. That is some kind of computer/game archeology that you have to be very lucky to be able to do.

I do wonder however if that's certain... in the example where bushes have been overlaid with flower titles, are we certain this does not change some property of the tiles in meaningful ways? In the same room, you can also see how the cave entry is painted over with the statue, and in this case that cave entrance is something that gets revealed later in the game.

In any case, a great series. This is exactly the type of content I come to HN for.

<comment><USER3> The flowers can also be cut as if they're bushes, making it a reasonably hypothesis that the bushes serve to make the tile "cuttable", and the flowers then just change the look.

I too enjoy the traces of development decisions that must have been made decades ago. As an example, when making a toy Gameboy emulator, I discovered Tetris writes to a memory address that is normally used for bank switching, yet the game has no memory bank controller. Given that it just barely fits in 32K, with 60 bytes or so to spare, I presume they were using such a controller during development and then maybe spent some time cramming it into 32K to spare the cost of the part.

<comment><USER4> Way back in the day, I was working on a project to extract your score from a bunch of old ROMs across various platforms. Developers picked some insane ways of storing even something as simple as a score. The very worst I recall was some old game about, I think, catching falling pots or something. Instead of just storing a 4 digit number, they stored the score as 4 pointers to the location where that digit was stored in memory. They'd increase your score by adding a multiple of the images' size to that location, and they handled overflow manually. I assume the idea here was screen rendering performance, but it didn't seem like it could possibly be worth it.

<comment><USER5> Having written a fair share of deeply embedded assembly.. if you're used to writing this close to the metal on a small system, that may have actually have been the most straight-foward way. Since ultimately the score must be rendered to the screen, and that might be its only purpose, there was probably little point in holding a "raw" intermediate value. Adding a constant and a few instructions for rollover don't sound too bad in the grand scheme of things.

<comment><USER6> figuring out tricks like that looks so fun. my "embedded" experience has been hard real time but usually on things with decent amounts of rom and ram. so tricks like that weren't needed.

</comment></comment></comment></comment></comment><comment><USER7> The rooms' data compression remind me of the Pokémon sprites during battles in Pokémon Gen I/II (Red/Blue(/green) and G/S/Y). As I remember it, the in-battle sprites (which are fairly large) are "compressed" using a custom algorithm. IIRC, it does RLE, and has some facilities for doing dithering, which was used in a lot of the sprites to give the impression of more color depth than there actually was. And they were only 4-bit (white, black, and two colors) in G/S/Y!

<comment><USER8> That brings back memories! I actually reverse-engineered that exact sprite compression (at least the G/S variant) back in 2001, when I was involved in the early ROM hacking community [1]. I stared at disassembled Z80 machine code for many, many hours to figure out and document the various quirks. I wrote a decompression program in (terrible, self-taught) QBasic, the only programming environment I had access to / knowledge of back then.

[1] [https://www.romhacking.net/utilities/59/](https://www.romhacking.net/utilities/59/)

<comment><AUTHOR> Oh, nice!

The compression algorithm is said to have been written by Satoru Iwata himself, giving a hand to the overloaded GameFreak team when the development of Pokémon G/S was hitting size limits pretty badly [1].

There is a readable version of the decompression routines in the Pokémon G/S disassembly repo [2]. As the code was originally written in assembly, it is not decompiled–only re-documented.

Which means the code we read is the actual code Iwata wrote it 20 years ago.

I really like seeing the traces of actual human beings in a disassembly. Noticing different coding styles; seeing where routines were written, then patched over later… We read code, but we see people.

[1] [https://retrocomputing.stackexchange.com/questions/11476/how...](https://retrocomputing.stackexchange.com/questions/11476/how- did-satoru-iwata-compress-pokemon-gs-to-fit-two-regions-on-a-single-cartridg)

[2] [https://github.com/pret/pokered/blob/10289bf/home/pic.asm](https://github.com/pret/pokered/blob/10289bf/home/pic.asm)

</comment></comment></comment><comment><USER9> That map image reminds me how big this game was by Game Boy standards. Impressive!

</comment><comment><USER10> wow. Great way to understand how the games were created back then with the low storage space. It would be great if this game can be remade to play on the browser. I remember playing this from my older brother's console but never got through it because at the time, it was well before my time and the graphics just didn't work for me. Older now, and I feel like I can appreciate this game now and overlook the old graphics... I know emulators exists, but never understood how to set it up.

<comment><USER11> > it was well before my time and the graphics just didn't work for me. Older > now, and I feel like I can appreciate this game now and overlook the old > graphics

As mentioned on the featured article, Zelda: Link's Awakening is being released on the Nintendo Switch in a few months. You may be interested to see the graphics and art style: [https://www.youtube.com/watch?v=_U- _XfDGgDw](https://www.youtube.com/watch?v=_U-_XfDGgDw)</comment></comment>