The TypeScript Tax - <AUTHOR> https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b <comment><USER2> _But if you're in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact?_

I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial.

Initially you can just run javascript through the typescript compiler and let type inference find some bugs. You can start adding types in places where you want autocomplete to work better. You can ratchet up the strictness if you start to find bugs that stricter type checking would have caught. If you've read any typescript discussions on HN you already know this.

On the flip side, obvious once you think about it, the option is always there to ratchet _down_ strictness if for your codebase the requirements turn out to be too heavy, i.e. slowing feature development down more than the bug reduction warrants. But you don't have to think deeply about it in advance. Just write your code, and every so often take a step back and look at how well things are working. Then adjust based on actual benefits and costs, not some premature estimate of them.

<comment><USER3> I don't know where this misconception started, but you can't just run javascript through a typescript compiler. There is a huge amount of valid javascript that is not valid typescript. Try something like `const testVar = {}; testVar.asdf = "asdf";`. Node web frameworks, for example, are based entirely off this ability to monkey-patch the request object.

<comment><USER4> I think grandparent was referring to the fact that you can tell the compiler to ignore type errors if you so choose. The TypeScript compiler is perfectly happy to compile the code in your example, if you disable strict type checking and treat type errors as warnings. On top of that, there are simple annotations you can add that let you silence warnings as they come up, e.g. `const testVar: any = {}; testVar.asdf = "asdf";`. This is not too far off from a linter with comments to disable linting when you don't want it. So yes, technically, you can just run JavaScript through a TypeScript compiler.

<comment><USER3> Sure... I guess you're saying that you can use the typescript compiler just fine as long as you turn off literally the only reason for it?

Have you been on a team that adequately managed a list of thousands of warnings, always finding and fixing just the ones that are "important"?

<comment><USER4> Yes. As a matter of fact, I'm currently working on a large JS codebase that is a decade old. We switched over all the code to TypeScript in one go, and we are gradually fixing the type errors over time. VSCode does an excellent job of showing you type annotations and type errors inline, so the typing is very useful even if you have thousands of errors elsewhere in the project and never even run the type checker globally.

In fact, out of the dozen or so TS codebases I've worked on, I've rarely seen one completely free of type errors. And yet no team has ever doubted the value of the type system. It's a very pragmatic approach which works very well for many teams in my experience.

<comment><USER3> I just finished something similar: [http://caines.ca/blog/2018/12/11/a-javascript-to- typescript-...](http://caines.ca/blog/2018/12/11/a-javascript-to-typescript- conversion-case-study/)

We opted to keep it strict (no implicit `any`) through the entire transition but only apply it to ts files, so we are indeed completely free of type errors now. We only have 50 cases of (explicit) `any` in 85K+ LOC and they're in type def files.

Let me be the first person you've met to doubt the value of the type system. I do like the in-editor support, but you pay for it with about 25% more code.

I'm certainly not advocating undoing it, but I personally wouldn't do it again (though the team has mixed opinions).

Just curious: What's your test coverage like?

<comment><USER5> So how many errors were uncovered, and how serious could they have been?

<comment><USER3> It's in the blog post, but more were created by the transition than removed. There were less than 10 issues found and none were anything that users were concerned about.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Let me save a few minutes of your time. The author of the article believes that static typing is mostly a waste of time. Consequently, in his point-based model, he assigned that particular feature of the language +0.1 points. "Typing overhead", on the other hand, got -3 points. And then, after adding all the points, he unsurprisingly concluded that the overall score is negative.

If you agree with the premise that static typing is a waste of time, you'll probably agree with the rest, but then you're likely not using TS in the first place. If you don't agree, the article is just wrong.

<comment><USER7> > Consequently, in his point-based model, he assigned that particular feature > of the language +0.1 points.

That's because his stupid chart is comparing a bunch of different things to TS instead of just comparing it to JS. In that case he's putting it up against TDD + code reviews, for reasons that I entirely do not understand. His numbers are so wildly incommensurate that they don't even make sense for any sort of informal water-cooler analysis.

[EDIT] if... if I'm reading his reasoning for that 0.1 score correctly, he'd still give it a -3.9 ROI if it caught _100-friggin-percent_ of bugs that would otherwise reach production, unaided by any other tools or practices. WTF.

[EDIT EDIT] for reference, that means he rates the overhead of noting one's types at 3x as bad as the benefit of magically catching 100% of bugs would be good. This is what I mean by these individual values being ZOMGWTF incommensurate.

<comment><USER8> The reasons you don't understand are clearly explained in the article (you can't skip them because 80% of bugs are not detectable by TypeScript), and if TypeScript actually could catch 100% of bugs, I'd rate it a perfect 10 on that point and the ROI would be game over. TypeScript would win because you could skip the other quality controls and save a ton of time.

I wish.

<comment><USER7> No, I read it. It's nonsense and your numbers are bad beyond any excuse of napkin-math. They're plain ol' down-home gibberish.

[edit] let me demonstrate: the most basic problem is that your numbers in various categories do not measure up to one another in any way that makes sense. -3 for writing typings, +0.1 for catching 10-20% of bugs that would reach production. Either you're having way more trouble writing types than you should or you have so few bugs that catching 10-20% of them isn't very valuable. Plus, read the thread. You just ignore all kinds of benefits of TypeScript (mostly benefits of having any, even half-assed, static type system on top of JS, period). If you like something else, propose it and compare TS to that. You're saying it's 1/10 better than vanilla JS with TDD + code review but 30x worse _in terms of that benefit_ than JS when it comes to time spent adding types. 30. Times. That's just one example, the whole chart's a wreck in a similar fashion. Plus I bet if you ask on this thread folks will be happy to suggest + entries you simply omitted. See the ones suggesting (correctly) that static types make both TDD and code review, which you like, a hell of a lot faster.

In the worst case if some little thing you want to do won't work well in TS or is too expensive to type properly, write that piece in JS. Yes, that's terrible. [pause; significant look; raised eyebrows]. But it's not worse than JS. Obviously. And you can do that in TS. It's part of what makes it such an incredibly easy sell.

<comment><USER8> First of all, you're wildly over-stating the difference. The scale based on percent of time spent or saved. It's impossible on this scale to even say that TypeScript is three times worse than no types, let alone thirty times.

As for the bug reducing benefit, yes it's up to 20% if you do nothing but TypeScript. As explained in the article, 80% of bugs can't be addressed by static types at all, so you can't skip the other measures safely. The zero point includes the other measures, which easily cover 90%+ reductions, combined.

Since other measures catch type errors, too, we apply the TypeScript reduction after discounting the other errors caught. Even with the maximum benefit of the doubt, assuming TypeScript catches 20% of the remainder, it's still a small percent of a small percent. You get exponentially diminishing returns with each bug prevention measure you apply, and TypeScript can't catch the lion's share of bugs, so it's the only one that makes sense to leave out as a quality control measure.

</comment></comment></comment></comment></comment><comment><USER9> I don't think the author adequately addresses the positives of development velocity with Typescript. I find I'm able to read and write code much more quickly with Typescript than without, especially once I am beyond 50-100 loc. I doubt I _ship_ fewer bugs to production, but I certainly catch and fix my own mistakes much more quickly _as I go_, and am able to make more ambitious changes much faster when I have types on hand. Most importantly, I'm able to pick up and work effectively with other people's code without having to dip into their implementation or documentation as frequently. I honestly can't imagine doing javascript for a living any longer without access to it.

<comment><USER10> Yup. He didn't address the biggest winner for me -- the ease of refactoring code you wrote 6+ months ago without breaking everything.

<comment><USER11> I'm on a large codebase that transitioned from Javascript to Flow a few years ago (which is very similar to TypeScript, though nowadays I'd recommend TypeScript over it). Before we started using Flow, big refactors were extremely painful. It was practically guaranteed that we'd have to spend a week manually double-checking things, and then spend at least a few days finding and fixing bugs after deploying the refactor to users. Therefore we avoided refactoring at all costs. With Flow, we suddenly can refactor something, find the loose ends with Flow immediately, be sure about it, and be done with it. The difference between now and then is night and day. We can get things done so much faster now. The article author's experience is completely alien to me.

<comment><USER8> I have all those benefits already. The zero point includes inference, lint, design review, spec review, code review, and TDD -- and you can't leave those out safely because 80% of bugs are not type errors.

<comment><USER10> With TypeScript I can make a change and immediately get a list of every single line I need to update. None of those replace that very key functionality.

> and you can't leave those out safely

Who's advocating for the replacement of code review, specs, and tests with TypeScript? TypeScript makes these things better, it doesn't replace them.

<comment><USER12> You can make the life of others more easy by always naming the same thing the same, eg always naming foo.bar foo.bar and you wouldn't need to annotate them, and everyone will know what it is. But if changing something means you also need to modify code at a lot of other places you have a architecture/pattern issue. Such a change should always be a semver major.

</comment></comment></comment></comment></comment></comment><comment><USER13> I generally wasn't impressed by his work, but learning that Eric Elliot changed his citations to suit his false claims for his article on TDD [1] has made me lose any form of respect for him

[1] [https://twitter.com/Hillelogram/status/1084991487702691840](https://twitter.com/Hillelogram/status/1084991487702691840)

<comment><USER14> I cannot describe how infuriating it is to see hacks like this get publicity. Thank you for sharing that link.

</comment></comment><comment><USER15> I freaking LOVE Typescript.

I shipped an app about 90 days ago based on Typescript.

[https://getpolarized.io/](https://getpolarized.io/)

It's basically a document manager which supports annotations, comments and keeping your documents in the cloud.

Typescript was a MASSIVE win. If you're on a simple code base doing a refactor is easy. Anything significant and it's a nightmare.

If you change an object method JS won't complain.

With Typescript and IntelliJ or VS Code it's just a simple refactoring and your code just works.

I would have probably given up on the project had it not been for TS.

</comment><comment><USER16> > Type safety doesn't seem to make a big difference. TypeScript proponents > frequently talk about the benefits of type safety, but there is little > evidence that type safety makes a big difference in production bug density. > This is important because code review and TDD make a very big difference > (40% — 80% for TDD alone)...

> TypeScript is only capable of addressing a theoretical maximum of 15% of > "public bugs", where public means that the bugs survived past the > implementation phase and got committed to the public repository, according > to Zheng Gao and Earl T. Barr from University College London, and Christian > Bird from Microsoft Research.

The devil's in the details for studies like this and people ignore this to make it look like their opinion is backed up by science when it isn't. Measuring what percent help type safety gives in general is an impossibly vague concept while also very difficult to test, especially when making comparisons between numbers.

From the second study for example right in the abstract:

> Evaluating static type systems against public bugs, which have survived > testing and review, is conservative: it understates their effectiveness at > detecting bugs during private development, not to mention their other > benefits such as facilitating code search/completion and serving as > documentation. Despite this uneven playing field, our central finding is > that both static type systems find an important percentage of public bugs: > both Flow 0.30 and TypeScript 2.0 successfully detect 15%!

15% is a _minimum_ from that study then and it isn't counting bugs that were caught from manual testing or otherwise before making a commit, or how much time was saved.

Quoting the study in this way is incredibly misleading in my opinion.

<comment><USER8> The trouble is most projects are NOT employing the other reviews properly. The study made no effort to determine the quality of the test and review process, and instead assumed that they had been done by virtue of the bugs being merged to the master branch.

The study then finds that about 80% of the bugs they found were not simply ts- undetectable, but not type errors at all. Instead, they're things like the wrong URLs being used (sting errors), wrong branching logic, wrong predicate logic, etc.

That means the maximum effect must be less than 20%, but the authors couldn't detect 20% even knowing exactly what the bug and fix was, down to the line numbers and exact code used to fix the bug.

Even being extremely generous and assuming they could fix 20% of remaining bugs, it's too far down the ladder of exponentially diminishing returns to make much difference at that stage.

<comment><USER16> > The study made no effort to determine the quality of the test and review > process

Assuming you wrote the article, why did you cite that study then?

> That means the maximum effect must be less than 20%

But what effect are you trying to argue? Maximum of what? I feel this is so vague it's not useful.

In my opinion (I'm not going to try to back this up with a study that doesn't measure exactly this), types make an enormous difference while you're in the middle of development before you commit anything: they're capturing cases where you forget a variable could be undefined, when you mix up items and lists, when you want to aggressively refactor, when you forget to pass required parameters etc. Type annotations are rarely required and for the few minutes I take to write them I easily make that time back even in the short term. Only looking at the bugs that get committed (which is super hard to measure) is missing out on a big aspect of the benefits.

You also need to consider that code reviews and writing TDD tests are time consuming to do as well.

<comment><USER8> I get the same real-time error detection and refactoring help from type inference, lint, and TDD. Lint and inference gives me real-time editor feedback, TDD runs automatically on file save.

I do consider TDD and code reviews are costly but you can't skip them with TypeScript because at least 80% of bugs are not detectable with TypeScript.

<comment><USER16> > because at least 80% of bugs are not detectable with TypeScript.

I give up. You're repeatedly using this figure in this thread in a misleading way to make it sound like what you're saying is more legitimate that just an opinion.

The abstract of the study you cite explicitly mentions this is a conservative estimate of effectiveness and ignores bugs detected in private:

> Evaluating static type systems against public bugs, which have survived > testing and review, is conservative: it understates their effectiveness at > detecting bugs during private development, not to mention their other > benefits such as facilitating code search/completion and serving as > documentation. Despite this uneven playing field, our central finding is > that both static type systems find an important percentage of public bugs: > both Flow 0.30 and TypeScript 2.0 successfully detect 15%!

<comment><USER8> The number they consider conservative is that TypeScript can address up to 15% of public bugs. That's a different number than the proportion of public bugs found ts-undetectable because they're not type errors at all.

<comment><USER16> There are so many important details about what this figure means and how accurate it is.

Would it make a difference if TypeScript was used before the code was committed? How does the subject domain of the project impact this figure? How do other testing and review approaches impact this number? Are public bugs of certain kinds more likely to be reported for certain projects?

It's highly misleading to quote this figure in such a simplistic manner without caveats.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Articles like this will certainly bring out the pro-Typescript people, so this got me thinking. I'd like to hear from people who tried Typescript and found they didn't like it for any number of reasons.

Note I'm not pro or anti myself, I've only just begun playing with it, but would like to hear from all kinds of people.

<comment><USER18> Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something. Imagine you give a painter a brush that doesn't allow to be used freely, that's what TS does to a good JS developer.

But TS is at this moment really eating JS jobs, and that kinda hurts. I just don't understand the proponents, besides the job opportunity, give me one single reason to write in TS? If you want to go for a strictly typed language TS is definitely the worse choice. TS simply doesn't fit in the JS ecosystem. Look at (a part of) the dependency part of this package.json, from the beginning of a large project. Don't you agree something is going very wrong in the JS world?

        "ts-jest": "^23.1.3",
        "ts-loader": "^4.5.0",
        "ts-node": "^7.0.1",
        "tsconfig-paths-webpack-plugin": "^3.2.0",
        "tslint": "^5.11.0",
        "tslint-config-prettier": "^1.14.0",
        "tslint-react": "^3.6.0",
        "typescript": "^3.0.1",
        "typings-for-css-modules-loader": "^1.7.0",
        "@sentry/browser": "^4.0.0-beta.12",
        "@sentry/node": "4.0.0-beta.12",
        "@sentry/types": "^4.0.0-beta.12",
        "@types/autoprefixer": "^6.7.3",
        "@types/classnames": "^2.2.6",
        "@types/clean-webpack-plugin": "^0.1.2",
        "@types/compression": "0.0.36",
        "@types/cookie-parser": "^1.4.1",
        "@types/cors": "^2.8.4",
        "@types/cucumber": "^4.0.4",
        "@types/enzyme": "^3.1.13",
        "@types/enzyme-adapter-react-16": "^1.0.3",
        "@types/enzyme-to-json": "^1.5.2",
        "@types/express": "^4.16.0",
        "@types/helmet": "0.0.38",
        "@types/html-webpack-plugin": "^3.2.0",
        "@types/jest": "^23.3.1",
        "@types/js-cookie": "^2.1.0",
        "@types/memwatch-next": "^0.3.1",
        "@types/node": "^10.5.7",
        "@types/node-sass": "^3.10.32",
        "@types/optimize-css-assets-webpack-plugin": "^1.3.3",
        "@types/react": "^16.4.11",
        "@types/react-dom": "^16.0.7",
        "@types/react-helmet": "^5.0.7",
        "@types/react-intl": "^2.3.10",
        "@types/react-loadable": "^5.4.1",
        "@types/react-redux": "^6.0.6",
        "@types/react-router-dom": "^4.3.0",
        "@types/redux-mock-store": "^1.0.0",
        "@types/serve-favicon": "^2.2.30",
        "@types/webdriverio": "^4.10.3",
        "@types/webpack-merge": "^4.1.3",
        "@types/webpack-node-externals": "^1.6.3",
        "webpack": "4.19.0",
        "webpack-assets-manifest": "^3.0.2",
        "webpack-cli": "3.1.0",
        "webpack-dev-middleware": "^3.1.3",
        "webpack-dev-server": "^3.1.5",
        "webpack-hot-middleware": "^2.22.3",
        "webpack-merge": "^4.1.4",
        "webpack-node-externals": "^1.7.2",
        "stylelint": "^9.5.0",
        "stylelint-config-prettier": "^4.0.0",
        "stylelint-config-recess-order": "^2.0.0",
        "stylelint-config-recommended-scss": "^3.2.0",
        "stylelint-scss": "^3.3.0",

<comment><USER10> > But I'm pretty sure if you can code Javascript well Typescript only stands > in your way when you want to create something.

You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to write some code TypeScript is a godsend.

<comment><USER12> There's more to maintainability then just adding types. Maintainability is a process not a language.

<comment><USER10> Yes, and TypeScript is an incredibly powerful tool to make that process easier.

<comment><USER12> It's like using a bandage to prevent an injury. Yes it's good to have, but it doesn't prevent anyone from writing unmanageable code. Contrary it can make it even easier to write unmaintainable code.

<comment><USER10> You can say that about literally any technology. Nobody's claiming TypeScript will fix all your problems and discover all the secrets of the universe: it's just a useful tool that well outweighs the overhead it adds.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> > Type correctness does not guarantee program correctness.

Yeah, obviously. Think about it -- when you write the code you still think about the "types", you're just not writing them down.

Typescript's virtues are completely related to developer productivity. Documenting your code with types, better autocompletion, catching silly mistakes before needing to run it in a browser, getting new people up to speed, etc.

<comment><USER19> Actually, one of the benefits of strong typing (without side effects) is that the correct implementation is sometimes the only one that compiles.

For example, if you know that a function takes a generic list and returns an integer, then the list's length is pretty much the only non-trivial computation it can perform.

<comment><USER8> I've seen this happen for a handful of functions, but implementation correctness proofs for general applications are far beyond the expressive capabilities of TypeScript.

</comment></comment></comment><comment><USER2> One problem with the math for the ROI calculation is that catching a bug with a test is counted the same as catching a bug while you're typing the buggy code. Type checking lets you catch bugs sooner, thus more cheaply.

Another problem is that it focuses on bugs that make it out to production. Maybe for some projects production bugs are so costly that pre-production bugs are relatively negligible, but for most projects you can't treat pre- production bugs as 0 cost.

<comment><USER8> Some good reasons for that:

1\. I get type feedback in my browser with inference. 2\. I get near real-time feedback from TDD on file save. 3\. I get real-time lint feedback, too.

The net result is I get several multiples better bug coverage than TypeScript alone can provide at about the same speed -- while writing idiomatic JS.

<comment><USER10> > TypeScript alone can provide at about the same speed

If writing your unit tests contributes less overhead than writing TypeScript types you're doing something horribly wrong.

<comment><USER8> It's not less overhead, but you can't skip TDD with TypeScript because at least 80% of bugs are not detectable by TypeScript.

</comment></comment></comment></comment><comment> maze-le Before I tried Typescript I thought it was just another JS-precompiler... been there done that. I tried Coffeescript, the Closure Compiler, even LispyScript. In the end it wasn't really that much different to plain old JS, just with some syntactic sugar.

But when I actually had to use it in a project, I instantly fell in love with it. Not only does it force me to think about the proper scope and type of a function or variable, it also helps refactoring and reading undocumented code.

Yes, sometimes it can be frustrating (meh: no typings for a legacy project, build-toolchains have to handle another layer of abstraction, etc.). But this really is peanuts compared to the hoops we had go through before.

TS has been the best thing that has happened to JS-development in the last decade.

<comment><USER20> I would say that there's no Typescript tax. Rather, there's a Javascript tax for Typescript. As in, the shortcomings of Typescript only come from Javascript. Typescript is transpiled to Javascript, so types are not enforced on execution, and that's the only real limitation of Typescript.

<comment><USER21> Usage of the word "tax" is interesting, too. I'm happy to pay tax if I reap tangible benefits from it / if the "money" is put to good use. I'd say that's the case with typescript.

</comment></comment></comment><comment><USER22> He asks the question "But should you use it for your large scale app development project?"

I thought that was literally the reason TypeScript came to be. Microsoft were having lots trouble wrangling Bing web app and internal MS devs wanted a tool to help catch the bugs!

I would say, if you are embarking on a large scale app, you most definitely want to include TypeScript from the start. It will pay dividends in the end.

<comment><USER23> It pays dividends long before the end.

My usual "time to 'oh thank you typescript'" is roughly 2 days from the beginning of the project.

</comment></comment><comment><USER24> Typescript is the best thing happened in my developer life. I can clearly say that Ive observed 99% undefined type errors reduction in js runtime comparing to vanilla js.

</comment><comment><USER25> For any JS that is over 100 lines, I will use Typescript without thinking.

This is 20% for bugs, and 80% for sanity in long term maintenance. Refactoring is so much better / safer when you have a compilation process and at a minimum, types.

I just wish I could use Typescript without npm.

<comment><USER18> If you write 20% more bugs in pure JS you definitely should re-evaluate your skill. I'd never hire someone saying that to me.

<comment><USER26> You should probably re-read the comment, because that is not what he's saying ;)

</comment></comment></comment><comment><USER7> > Missing Features — HOFs, Composition

Uh... I'm pretty sure I've used both in TypeScript projects.

<comment><USER27> This was the most infuriating part. He either doesn't understand what a hof is, is actively lying, or just hasn't even used typescript long enough to understand this is incorrect.

<comment><USER8> Please show me the proper typing of the map transducer in TypeScript. I'm willing to learn.

<comment><USER10> It would seem that someone's done it already: [https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/transducers- js/index.d.ts#L70)

</comment></comment></comment></comment><comment><USER28> A thoughtful article this is. Heck, I like Typescript. I've used it in extensive experimentation and would gladly use it in production if a client or employer insisted on it.

Would I use Typescript for my own production use? Likely not. My perception is that it is yet another layer of complexity added to front-end development that, ultimately, does not need to be there.

</comment><comment><USER29> One thing I really like about Typescript in strict mode is enforcement of handling null and undefined properly. Handling the stuff that usually isn't null is quite error prone as it typically works fine with well-formed data and only breaks once it encounters the real world with unexpected data.

Another very useful part is that refactoring becomes much easier, as you can simply follow the errors when you break an interface other parts of your code are relying on.

Typescript forces me to be more disciplined when coding, and that is clearly a good thing in my opinion. There are probably cases where you don't want that, e.g. rapid prototyping, but otherwise it's very useful.

</comment><comment><USER30> > _" But should you use it for your large scale app development project?"_

This seems to imply that for whatever reason, TS may not be suitable in larger projects, but both Vue.js and Visual Studio Code are full TypeScript projects.

</comment><comment><USER31> I hope I've got this right, but if the author is comparing typescript to a modern tooling environment, while there are technical differences, I may not trust those maintainers more than Microsoft at language design and support.

I don't think you can write off the cost of learning all of those different tools in the non-Typescript environment. Typescript at least centralizes everything and I trust Microsoft to do good language development because of C#'s legacy _alone_.

<comment><USER8> Those tools have a negligable learning curve because once you set them up, you can simply forget about them and write JavaScript code.

</comment></comment><comment><USER32> Put aside the scoring and conclusion parts, the author has a couple interesting observations that resonate with me:

> ... but conscientious developers will be interested in doing things right. > They'll spend hours Googling for examples, trying to learn how to type > things that TypeScript simply can't type properly.

> ... if you only need to hire one or two developers, using TypeScript may > make your opening more attractive to almost half the candidate pool.

On the other hand, it seems that the author worked on a few medium-size projects and then moved on:

> All projects for which impact was judged were >50k LOC with several > collaborators working over several months.

So I wonder if he was able to evaluate the impacts from a longer term perspective, which shall include refactoring experience, iteration speed, developer morale, etc.

</comment><comment><USER33> I think the author gets the detectable 15% wrong way around. TS detecting 15% on average due to annotations means we're finding _at least_ those. Then we have the possibility of detecting all the bugs caught by potential better design. With the example of stringerror for an invalid url, you have two options: it was an accident (broke a url while processing) or misunderstanding (put a non-url text in the string). The second case may be still caught at a higher level by having better containers, better enum, lower chance of using ad-hoc bare object, interfaces which prevent you confusing types of string you're operating on, etc.

Going beyond just adding annotations is not what the references study attempted to do.

</comment><comment><USER34> When WebAssembly will be feature-complete and without the need to call JS for every DOM or API access - developers would be able to just use the proper programming languages, like Rust, OCaml, Haskell, etc, instead of relying on buggy JS universe.

</comment><comment><USER35> For those worried about compile time for large projects, tools like [https://github.com/alangpierce/sucrase](https://github.com/alangpierce/sucrase) can go a long way for the transpilation (remove types), while you can use the TypeScript compiler in parallel only for the type analysis.

That said, Sucrase has a number of issues still. Nothing that can't be resolved, but enough to prevent me from using it in a few projects.

</comment><comment><USER36> My experience with TS is totally on the backend.

The biggest issue with typescript, and the reason I'll probably never reach for it for another large project despite having used it for a 50k line+ project, is that it's still, at its core, javascript. We've experienced a tremendous amount of pain because of this.

\- We've needed libraries which don't provide typescript typings. Like a good little typescript user, we have strict mode enabled, which means we have to build our own typings when we encounter this. We've had library maintainers reject our typings we provide back to the community. We've had library maintainers say they have no desire to provide any support to typescript users because "its a fad" and "ts is just js, you don't need types, live with it" (not joking, not exaggerating).

\- All of the good high-level JS frameworks and architectural libraries are built for, well, JS. So, you want to adapt them for TS, but the JS idioms are _so core_ to their design that you throw away any benefit TS gives you. Express is a good example; you might have middleware which parses a bearer token and attaches it to the request. When the request hits the next middleware or request handler, its just a normal request. There's no way to assert at compile time that "this middleware came before, the request is now a new type with this extra field". Express, Apollo, the list goes on.

\- Further, the community around creating Typescript-native libraries is exceedingly small and, as far as I can tell, dying. I'm talking libraries that are made for typescript and make use of the true end-to-end compile-time verification typescript gives you. TypeStack is probably the leading organization (on GitHub) which builds (amazing!) projects like this, and their velocity is slowing down. TypeDI hasn't seen an update in nine months. Vesper was an incredible web framework that hasn't been touched in a while. There's nothing available for MongoDB if you use that. Basically, you're stuck with JS native projects 90% of the time, and about 10% of those don't have typings available.

\- We've had NPM libraries redefine the Error global. This isn't caught at compile-time, obviously, and totally borked the error responses our API sends.

\- It's a constant uphill battle with the `as` keyword. I wish there was a way to easily ban it globally. You can essentially assert Anything As Anything, and if its not caught in review you'll end up with incredibly hard to trace behavior because "the compiler says this field should be there, why am I getting undefined"... well, its because sixteen layers down someone asserted a type without verifying its accuracy at runtime, and in 5% of situations its incorrect, and it missed review.

\- It's a constant uphill battle with lodash. We have developers on some teams that swear by it, and will scatter `_.get`s all over the codebase, then be startled when things break in unexpected ways. Typescript added the `!` operator, which is basically just an escape hatch, and it took us a long time to get everyone educated that this is, without a doubt, the dumbest thing Microsoft has added to the language because it doesn't actually do anything at runtime, it just suppresses a potentially useful compiler error.

In summary, don't pick Typescript for the backend. It's an obvious improvement over JS, but you'll still be left wishing you hadn't.

But I also don't know what the better option is for a high-velocity organization. Go and Rust are too unproductive. Ruby and Python aren't performant and aren't strongly typed. JVM languages are a pain. Elixir shows a lot of promise but the lack of typing concerns me.

<comment><USER11> > We've had library maintainers reject our typings we provide back to the > community. We've had library maintainers say they have no desire to provide > any support to typescript users because "its a fad" and "ts is just js, you > don't need types, live with it" (not joking, not exaggerating).

Why did you submit the types directly to them rather than to DefinitelyTyped? It's great when libraries maintain their own typings, but TypeScript handles the case where they don't really well.

>Express is a good example; you might have middleware which parses a bearer token and attaches it to the request. When the request hits the next middleware or request handler, its just a normal request. There's no way to assert at compile time that "this middleware came before, the request is now a new type with this extra field". Express, Apollo, the list goes on.

Yeah, this can be a pain. In situations like this, I've defined types like `type RequestWithAuthField = Request & {auth: AuthField};` and then in handlers that I knew came after the auth middleware, I'd immediately cast the request parameter to that type. It is an escape hatch and I'd prefer to not have to do that though.

>Further, the community around creating Typescript-native libraries is exceedingly small and, as far as I can tell, dying.

Besides that they're sure to avoid TypeScript-unfriendly APIs (unlike Express), I don't think there's much difference between a library with good type definitions and a TypeScript-native library. (Maybe the library could have bugs that it being authored in TypeScript would have avoided.)

I don't fully disagree with your points. There's a lot awkward about TS on the backend, but at the same time there's not much quite like it.

<comment><USER7> > Yeah, this can be a pain. In situations like this, I've defined types like > `type RequestWithAuthField = Request & {auth: AuthField};` and then in > handlers that I knew came after the auth middleware, I'd immediately cast > the request parameter to that type. It is an escape hatch and I'd prefer to > not have to do that though.

I find this less than ideal, of course, but _still not worse_ than writing the same in plain JS, since at least this way the next person to come along (or you, a few months later) has clear guidance re: wtf is going on with those weird extra fields on the Request object. It's less effort—for reader and writer—and is more maintainable than expressing the same information as effectively in docs and comments.

</comment></comment></comment><comment><USER37> Could have been titled "static typing vs. dynamic typing" but I guess TypeScript is more clickbaity.

</comment><comment><USER38> This is a good analysis in the "JS or TS" domain, but it's of course seldom the only option to consider. TS competes with languages that compile to JS, so Elm, ClojureScript, Scala.js, Kotlin, etc.

</comment><comment><USER12> All bugs are type errors they say, but how did they pass the type checker ? ;)

</comment><comment><USER39> Type system is like a seat beat, its not going to save your from a head on collision with 18 wheeler. But it will mitigate you pain and suffering in small to medium accidents.

</comment><comment><USER40> Yesterday, there was news that Facebook was porting Yarn from Flow to TypeScript for ease of new contributors. That ease is a shared goal of one of my projects, and yesterday I tried porting it as well.

I discovered that in contrast to Flow, TypeScript has _horrible_ errors. Often I ran into errors that would not give much more information than "error" \-- no line information, no _file_ information, nothing. One of the causes of such opaque errors was empty Flow-style typecasts, so they were pervasive throughout a large project.

In contrast, Flow has beautiful error messages.

<comment><USER10> Huh? It sounds like a problem with your toolchain, not TypeScript. You should get all of that whenever there's a type error.

<comment><USER40> I don't think it was a toolchain issue, because I did receive line and file information for certain classes of errors. Presentation of that information doesn't appear to be pervasive.

</comment></comment></comment><comment><USER41> Here's Eric Elliot, doing his Eric Elliot thing. Pages and pages of beautifully worded, perfectly structured arguments about absolutely nothing. And this month he's a Distributed Systems Expert. More power to this guy for building a brand for himself, but what a load of nonsense.

<comment><USER42> > Pages and pages of beautifully worded, perfectly structured arguments about > absolutely nothing.

I don't know Eric Elliot, but this sentence captures my perception of most "influencers" perfectly.</comment></comment>


In NYC, almost 9 in 10 Covid-19 patients on ventilators don't make it - <AUTHOR> https://www.bloomberg.com/news/articles/2020-04-22/almost-9-in-10-covid-19-patients-on-ventilators-died-in-study <comment><USER2> There was an article in the NY Times a few days ago from a respiratory doctor who explained that the nature of the physical mechanisms in covid-19 pneumonia mean that the patients' oxygen saturation will go way down before they start feeling short of breath, which accounts for the folks showing up at the ER with ridiculously low saturation. He noted that the celebrities who have recovered from covid-19 generally have really close, constant monitoring of their oxygen levels so problems are detected and treated way before ventilators are needed.

[1] [https://www.nytimes.com/2020/04/20/opinion/coronavirus- testi...](https://www.nytimes.com/2020/04/20/opinion/coronavirus-testing- pneumonia.html)

<comment><USER3> What do they do to treat that, short of a ventilator? Oxygen?

<comment><USER4> Yep, oxygen through nasal cannulas or some sort of oxygen injected into a CPAP / BiPAP system.

<comment><AUTHOR> Shouldn't this be dealt with at home, then?

<comment><USER3> I don't know, but I suspect that those on oxygen may be sick enough that they should be carefully monitored, and have intervention available if they need it.

</comment></comment></comment></comment></comment><comment><USER5> Ideally you have a highly functional public health system, testing and tracing, implement quarantine, reasonable isolation measures and border controls and don't need need these heroic medical interventions.

By the time you have hundreds or thousands of people on ventilators I think it is clear you have done something wrong.

Looking at the results in countries that were pro-active dealing with this pandemic and it is hard to see how it got so out of control in many other countries you would naively expect to have equivalent or better preparedness.

We are not out of this yet and perhaps even countries that have just about eliminated this virus will get overconfident and fall to later waves but at the moment it looks like there are some clear winners and losers.

<comment><USER6> Please enumerate the clear winners and losers, and provide your criteria.

AFAICT, there are a few countries that have better morbidity rates at this stage of the game, but there's a lot of time left. Sweden is playing an uncommon angle, some say they are being smart, some say otherwise. etc.

I think every country is doing what they can, we probably won't be able to tell who has 'won' and who has 'lost' even in a long time. Different concentrations of people per square KM will be a huge variable, for instance.

<comment><USER4> Germany has done very well (in a traditional manner). Ireland as well. I agree with you that we still have a ways to go -- but every day we last means one more day gained worth of knowledge, trials, etc.

</comment></comment></comment><comment><USER7> There was an early study out of China that said the same thing. I remember when it came out it and governments were worried about ventilators I thought well does the number of ventilators really matter? If it almost inevitable they're going to die anyways, it is just an example of US medicine heroically prolonging the end when often is isn't worth it.

<comment><USER8> I think from a medical perspective, it's between using a ventilator to give them a 10% chance of survival or letting them just die. No doctor can ethically just not even try to save a life.

<comment><USER9> Do we have any evidence that it is actually giving them that 10% chance, or are the people that survive on the ventilators just the same ones that would have survived without it?

<comment><USER10> Is there any possible way we could test for that? I suppose we could look at retrospectives of those who weren't given treatment during triage, but I imagine they probably are given less of the peripheral support as well once the decision has been made.

</comment></comment></comment></comment><comment><USER11> I saw this linked from another comment on HN, but Dr Kyle-Sidell, an ICU doc in NYC, is trying to figure out why COVID-19 patients aren't responding to typical treatment protocols on Twitter[0] and YouTube[1]. His current theory is that pulmonary edema at the capillary-alveolar interface could be causing diffusion issues, which a ventilator would not directly address.

[0] - [https://mobile.twitter.com/cameronks](https://mobile.twitter.com/cameronks)

[1] - [https://www.youtube.com/watch?v=NmRlvX3VrAQ](https://www.youtube.com/watch?v=NmRlvX3VrAQ)

<comment><USER12> I've heard it speculated that the thing to do may be to not put people on ventilators, but give them blood transfusions.

Where I heard this:

[https://science.slashdot.org/comments.pl?sid=16122794&cid=59...](https://science.slashdot.org/comments.pl?sid=16122794&cid=59921250)

[https://www.statnews.com/2020/04/08/doctors-say- ventilators-...](https://www.statnews.com/2020/04/08/doctors-say-ventilators- overused-for-covid-19/)

</comment></comment><comment><USER13> HANG ON! This only considers patients already discharged or died at the end of the study some ~300 patients. But there are still ~1000 patients who were on mechanical ventilation that are still in the hospital (so aren't included in the denominator). We don't know their outcomes yet and so this is a best a sensationalist headline. Patients with this disease are on mechanical ventilation for much longer than most patients, so early reports like this don't reflect true eventual outcomes. Maybe it will be similar, but maybe it will be more like 40%, which is the usual mortality rate in ARDS.

<comment><USER14> Additionally given the expectation of ventilator shortages these hospitals have likely been preferentially providing ventilators to the sickest patients. Mortality in other areas where shortages don't exist will likely be lower.

<comment><USER15> I thought there weren't shortages? I mean, the expectation was that there might be, but given the social distancing efforts, NYC didn't end up facing shortages, meaning there would be no need to not give some people ventilators?

<comment><USER16> > but given the social distancing efforts, NYC didn't end up facing shortages

Another reason (warning, just from reading the news here and elsewhere) might be that it seems ventilators aren't as useful with Covid-19 as expected, and possibly actively harmful in a number of cases (again, this is just my rehash of what I have read).

From what I read doctors now try to use just proning and extra oxygen for as long as possible even if ventilators are available.

People actually working in healthcare or who have first hand knowledge should feel welcome to update this.

</comment></comment></comment></comment><comment><USER17> Do we have any "iron lung" negative displacement ventilators still in service or did every single one get phased out? I've heard those are easier on the lungs in concept and I'm wondering if some got dug out of basements to fight covid-19 and their success rates

<comment><USER18> As of 2018, there were only 3 in service in the US: [https://people.com/health/polio-survivor-last-3-people- use-i...](https://people.com/health/polio-survivor-last-3-people-use-iron- lung/)

There were quite a few interviews done in recent years with people who still rely on them; one recurring difficulty they talk about is that both expertise and availability of parts became scarce over time, so it becomes harder and harder to keep the machines running.

</comment></comment><comment><USER19> > "We are only reporting observations in this report," said Karina Davidson, > senior vice president for research at Northwell Health. "So we can't say if > mechanical ventilation had been withheld from these patients there would > have been a different survival rate."

<comment><USER20> I think this is an important point.

I've seen others on HN claim this means ventilators are killing people.

It's possible there are alternative protocols that can be used prior to ventilator use. It's also possible these alternative protocols could have increased the survival rate. But that's still different to ventilators killing the patient.

</comment></comment><comment><USER21> This doesn't mean that all of the 1 in 10 would have died without ventilators.

Elon Musk was getting torn apart for sending CPAP (or APAP/BiPAP/BPAP) machines but if in doubt I'd rather go on one of those than a ventilator.

</comment><comment><USER22> Ventilator makes rusting of the avioli even faster. That's what some medical whitepapers are saying.

</comment><comment><USER23> Another detracting factor in the ventilator value calculus is the number of doctors and nurses infected while treating intubated patients. It is very difficult to contain the contamination when removing tubes as the patient always coughs. I'm not sure ventilators save net lives.

</comment><comment><USER24> We are flattening the curve for this.

Oxygen can be done at home. And would reduce infections too.

</comment><comment><USER25> An article I read somewhere was suggesting that doctors should have tried using traditional antibiotics to treat patients instead of intubating them. This of course is strictly anecdotal.

<comment><USER26> Using traditional antibiotics against a virus is not particularly likely to help. Traditional antivirals are in a number of studies currently.

By my non-expert estimate, remdesivir seems to be the most likely candidate. It's not approved for use in the US yet, but is well on the path: [https://www.drugs.com/history/remdesivir.html](https://www.drugs.com/history/remdesivir.html)

</comment></comment><comment><USER27> the ventilator hysteria is just of the examples of the irrational fear and irrational hope that people seem to get caught up in.

The next such fallacy is that of testing and contact tracing. As if that were a solution to anything at all ... That too will go the way of ventillator hope.

I hate to be the bearer of bad news but it will do absolutely nothing. It is not feasible at the scale that people are proposing it and it cannot possibly work without even more disruption than we already have. All it will do is push the disease into the winter when it will be more lethal.

The only rational solution is finding improvements in therapeutics. We cannot keep people from getting infected, but we should be able to keep people from dying of the diseases. And that is a far closer and more achievable goal than any other.

The virus already exhibits several characteristics that show that many people can easily handle it. Finding out what that is, and enhancing the same defenses in those that are at risk will be a quicker and more effective solution than all other factors combined: masks and lockdown, contact tracing etc. these "solutions" may buy some time right now, but at the same time massively slow down our progress studying the disease.

<comment><USER28> > The next such fallacy is that of testing and contact tracing.

Except that other countries have documented success with this. Are you an epidemiologist?

<comment><USER27> Kids don't get infected - is that due to contact tracing?

Epidemiologists are just as confused here as anyone else. They have never seen anything like this disease, there is no data, there is no evidence to anything claimed here. You can't compare to any epidemics before.

The best evidence is the absurd statements by epidemiologists at CDC yesterday:

1\. It is extremely important to maintain social distancing to save lives!

2\. The next wave in the winter might be much worse due to the current social distancing that will be pushing many of the vulnerable into the winter months where the risks of coinfections are higher.

Uhh? What? Do you see the absurdity in these statements? They make no sense, as if they had no idea what to do.

<comment><USER28> > Epidemiologists are just as confused here as anyone else. They have never > seen anything like this disease, there is no data, there is no evidence to > anything claimed here.

Of course they have! There are a lot of coronaviruses. And we already have experience with SARS and MERS. Obviously this isn't exactly the same but suggesting that epidemiologists don't know any more than the rest of us commenting in Hacker News is absolutely absurd.

We don't all get to be experts on this just because we've decided that we're clever. Or maybe we should all be burning down 5G masts as well, after all, _who knows_?

<comment><USER27> what you are doing is a classic fallacy, you take an absurd example and equate my opinion to that. What's 5G got to do with it?

Neither SARS or MERS are even remotely similar to COVID-19. The mechanisms are different, the spread is different etc.

I have also never stated an epidemiologists knows as much as an average hacker news reader.

What I said they are just as confused and unable to decide what is right or wrong and what the right course of action is. That is a completely different statement.

I note how you never addressed the obviously contradictory statements by the CDC.

<comment><USER28> > Neither SARS or MERS are even remotely similar to COVID-19.

Again, you have absolutely zero authority to make that statement, unless you forgot to mention that you are an infectious disease specialist. Same with "children can't be infected", in your reply you're making statements about what "you would" do but do you have any data showing that children are being tested at the same rate as adults?

We could spend forever in a back and forth over things like CDC statements (which aren't contradictory, but whatever) but it would just be dancing around the central point: you don't know. You aren't qualified to speak about it authoritatively. If an epidemiologist tried to weigh in on and online debate about the merits of Rust vs Go I'd say the same thing, but luckily for us they don't.

Having an opinion on things is just fine, but this thread (I'm not singling you out here) is full of authoritative statements with no scientific basis.

> you take an absurd example and equate my opinion to that. What's 5G got to > do with it?

The only reason it's absurd is because you and I both know enough about 5G to know that the idea of it spreading COVID-19 is silly. How can you be confident that the assumptions you're making aren't equally absurd to an epidemiologist?

<comment><USER27> I am summarizing what science states.

I have read numerous scientific papers on both SARS, MERS and COVID-19. It is pretty clear that the diseases are not similar at all. (SARS - MERS yes, SARS - COVID no). Are seriously claiming that scientist consider the diseases similar? They don't.

On the CDC statements I don't get what your point is. These are statements by the CDC to the population.

In the first they want people to tighten the lockdown. In the second they predict that tighter regulations will lead to more deaths in the winter.

There is no interpretation there, this is what they announced to the public. The two statements together make no sense. Notably you say "I could spend forever on back and forth" but you don't offer anything - and perhaps the CDC statements should not be like that. The statements are so because as I said along, the CDC are also confused and unsure what to right course of action is.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> I wonder what effect it will have on future of the countries.

As majority of the people who are dying have cormobities or they are old that means now government will not have to spend money on pension or healthcare and this will lessen the tax burden!?

Less population = more housing

Younger population leftover after virus = higher economic output!?

<comment><USER30> Your comment comes across as repulsive because it seems you believe the following:

1) People with conditions like diabetes are a burden, and having fewer of them will save us money.

2) The housing crisis is caused by overpopulation, not by perverse incentives or inequality of opportunity.

3) Younger people create more economic output.

4) You are excited about all of this -- specifically, about all of these people dying.

Sick people are not weak sheep in a herd. You have no idea what their net output or effect on society is. Many of the dead are talented doctors or nurses who had asthma or asymptomatic heart issues.

If you're excited about hundreds of thousands of people dying, keep it to yourself. Many of the rest of us will lose loved ones before this is over.

<comment><USER31> Thanks for saying this. Since 3 others are criticizing you for the same reasons I'll just reply directly to you.

You can take smt88's reply as language criticism or moral criticism. The use of !? in two out of four paragraphs in econcon's post certainly implies excitement, and choosing only to focus on the "positive silver linings" certainly sends a particular message.

I'm sure there's a way to talk sensibly about this very cynical speculation of what might happen to society in a pandemic like this, but econcon's way of phrasing it is _not_ the way. If the language of a post sends a certain message about the underlying morals of the post, I see no reason not to start criticizing that.

<comment><USER32> _The use of !? in two out of four paragraphs in econcon 's post certainly implies excitement_

You claim insight into another's mind based on colloquial use of punctuation marks!? "Forensic grammarian here, let me take a look...yup, it is clear that they are excited for people to die." Seriously lame. To support my point, I'll point out that I most usually use "!?" as a WTF indicator, or other expression of surprise or disgust. To my recollection, not once have I used it to indicate positive excitement. 'cuz there ain't no style guide on using "!?".

But, man, someone really, really wants to get butt-hurt over that comment, all other indicators be damned.</comment></comment></comment></comment>


Irish battery breakthrough could help save the planet - <AUTHOR> https://www.irishtimes.com/business/innovation/irish-battery-breakthrough-could-help-save-the-planet-1.3930722 <comment><USER2> Seems like there's an incredible battery breakthrough every few months and yet batteries still get 3-5% better every year.

<comment><USER3> I agree with the sentiment. I'll believe it when I see it.

Does anyone know the current status of producing carbon nanotubes at scale? I hear things all the time about new graphene breakthroughs but since there's not yet a reliable way of producing it at volume, consumers haven't started benefiting yet

</comment></comment><comment><USER4> There is no shortage of energy storage technologies. The bigger challenge is commercialization rather than R&D.

</comment><comment><USER5> Light on the scientific details... Anything anywhere else or a working testable prototype?</comment>


Sexual harassment is pervasive in US physics programmes - <AUTHOR> https://www.nature.com/articles/d41586-019-01303-6 <comment><USER2> I don't deny that this is an issue in any college setting where lots of hormone-driven young men are crammed together around a smaller number of women, but something about the way the question in the article is posed makes me suspicious of the intensity or widespread nature of the claim:

> Of the 455 people who responded, 338 reported experiencing some form of > sexual harassment, including gender harassment — such as being ignored > because of their sex or gender, or being told inappropriate jokes — unwanted > sexual attention or a combination thereof during the previous two years.

How inappropriate were the jokes? How much of it was harassment versus social unawareness? How does the survey distinguish between idle chatter that goes south and aggressive men with bad intentions that corner women in the stairwells of physics buildings?

Again, I don't deny the issue, but short articles like these that are lacking in detail about their claims, then link to another article from the same site, which links to a $55 copy of the study [1] seem like insufficient data points beyond everyone's gut feel that "sexism and harassment are a problem in male- dominated fields"

[1] [https://www.nap.edu/catalog/24994/sexual-harassment-of- women...](https://www.nap.edu/catalog/24994/sexual-harassment-of-women- climate-culture-and-consequences-in-academic)

</comment><comment><USER3> I had a friend get physically harassed and eventually get forced to exit the program when she demanded action. Anecdotal, sure, but I would guess it is more common than people realize or want to admit.

</comment><comment><USER4> "such as being ignored because of their sex"

this doesn't quite fit into most people's definition of sexual harassment

<comment><USER5> It also implies mind reading. How do they know that for sure? They don't.</comment></comment>


PHP As A Templating Language - <AUTHOR> http://phphater.com/post/33348901672/php-as-a-templating-language

<comment><USER2> After working with django, going back to simple PHP based templates is pretty sucky. Twig for PHP is pretty similar to django templates: <http://twig.sensiolabs.org/>

<comment><USER3> What's the point of comparing a framework to a language? PHP has templating frameworks too.</comment></comment>


Node-fxos – Node Libraries for FirefoxOS Development - <AUTHOR> https://github.com/nicola/node-fxos

<comment><AUTHOR> This are the set of tools that I developed in Mozilla this Summer to improve the development experience for FirefoxOS.

Example of usages that I envision are: deploy and reload CSS without webIDE, bind FirefoxOS console to your terminal, gulp automation.

Here is more: [http://nicola.github.io/node- fxos/](http://nicola.github.io/node-fxos/)</comment>


We're Reading Fahrenheit 451 Wrong (2018) - <AUTHOR> https://thefrailestthing.com/2018/06/15/were-reading-fahrenheit-451-wrong/ <comment><USER2> I think the anti-intellectual theme of Fahrenheit 451 is pretty clear. The story spends a lot of time describing the vapid media that everyone consumes. I don't see how anyone could interpret it to be solely about censorship if they actually read the book, to be honest.

In my very humble opinion, I don't think the book has aged well. I believe the internet really upended the central premise.

The book described society devolving into an illiterate, pleasure-seeking dystopia. The main feature of the Fahrenheit 451 world is a centralized monoculture which is established through trashy tv shows, advertising, and comics.

Social media is extremely shallow, sure, but we also have historically unprecedented access to almost unlimited information. We now have media that is so diverse, and of such specificity, that it has essentially eliminated shared culture and narrative.

It seems the path to the 21st century dystopia is having too much radically decentralized information, rather than a lack of it. Now the concern isn't people being deprived of information. To the contrary, the concern now is people consuming the 'wrong' or 'fake' information. We now have intellectuals intentionally depriving the world of revolutionary research because of this.

<comment><USER3> > _In my very humble opinion, I don 't think the book has aged well. I believe > the internet really upended the central premise. The book described society > devolving into an illiterate, pleasure-seeking dystopia. The main feature of > the Fahrenheit 451 world is a centralized monoculture which is established > through trashy tv shows, advertising, and comics._

Sure sounds like 2019 to me. In fact, far more 2019 than the era when the book was written.

> _Social media is extremely shallow, sure, but we also have historically > unprecedented access to almost unlimited information._

And what we've learned is that access to information means nothing without the ability to process it. And that too much information makes things even worse drowning everything in a sea of noise.

> _We now have media that is so diverse, and of such specificity, that it has > essentially eliminated shared culture and narrative._

On the contrary, I find that we have solidified an once diverse culture to a couple of monocultures.

Case in point the Top 20, which is almost all the same kind of music today.

<comment><USER2> Not a new development in the 21st century. The closer you get to the advent of recorded music and broadcast radio, the more homogenous the music selection was. Accessibility to alternatives was expensive/impossible. This goes for every other kind of media.

If you don't like the 'Top 20' then I presume you listen to alternatives. How did you find them? The internet perhaps?

<comment><USER3> > _Not a new development in the 21st century_

The global monoculture of BS commercial music is a new development in the 21st century.

Peoples and cultures used to have a huge variety of music and styles all over the world, even if "accessibility" to it from the comfort of ones home outside a specific region wasn't cheap/possible.

> _If you don 't like the 'Top 20' then I presume you listen to alternatives. > How did you find them? The internet perhaps?_

Doesn't really matter, as culture is not what people consume in private, but what most consume and influences their public discussion. Some obscure artist I only share with 10K or 100K people might as well not exist culturally.

<comment><USER4> It's not a monoculture if you can listen to something else. Nearly everyone I know who listens to top hits music also listens to other genres.

Top hits are just designed to be as agreeable to society as possible. That's what makes them more popular than anything else.

It's like claiming salt is causing a food monoculture because so many people are using it.

<comment><USER3> > _It's not a monoculture if you can listen to something else. Nearly everyone > I know who listens to top hits music also listens to other genres._

A culture is what people (more or less) share. That part is very narrow today, when it wasn't e.g. in the 60s and 70s.

Niche genres people listen in addition to the top hits but don't share don't enter the cultural sphere.

> _It's like claiming salt is causing a food monoculture because so many > people are using it._

No, it's like claiming that whereas once people used to see a variety of movie types in the theaters, now every second movie is a superhero one.

That's true for what people see in the main, and it's true as to what the celebrated, talked about, and influential movies are, even it's easier that ever for everyone to also download and watch some niche movie from whatever era (which most don't bother).

</comment></comment></comment></comment></comment></comment><comment><USER5> I read Fahrenheit 451 again a month ago and it was much more relatable than the first time I read it.

The pattern of going from point A to B and being told to do that by someone or something as quickly as possible is the norm. If you have a demanding job and a family at the end of most days it's easy to tune out and only have the desire to feel comfortable. You've been exhausting yourself to be 'accepted' by society.

Thinking for yourself and finding moments to do whatever you wanted whenever you wanted was dangerous in Fahrenheit 451. I think that is becoming very real nowadays. If you told someone you went for a walk aimlessly in a park and stared at flowers for 20 minutes with your phone turned off you could be viewed as a social deviant to some degree. Your wife or girlfriend might be upset because they couldn't get ahold of you. A friend or coworker might be frustrated because they needed to tell you something that "couldn't wait".

That's where the danger lies. Society dictating how you think and how you should feel all the time. Technology is only a tool that makes it more efficient.

During the Summer of Love thousands of people just up and left their lives to spend a summer doing whatever they wanted. The only way they could be reached was by telephone or letter and that was if they wanted to be contacted. I honesty don't think a movement like that or an era like the 60s is possible anymore. People are too attached to their phones and what society expects out of them.

<comment><USER6> I knew someone who's former partner called him a narcissist solely because he'd randomly walk places or go to different coffee shops depending on if one was busy, or if one was just near a park where he wanted to exercise etc. She believed this after watching a YouTube video titled "narcissists live in the moment." Strange times for a person to be called that when all they want to do is have a human moment outside of online connection and algorithms.

Society needs dopamine detox days as much as we need holidays.

<comment><USER7> > She believed this after watching a YouTube video titled "narcissists live in > the moment."

Micro-radicalisation. Not quite the same as flat earth or anti-vax, but still junk.

</comment></comment></comment><comment><USER8> The Denham'a Dentriface example is a pretty accurate prognostication about what would happen to the Internet. On many sites today it is impossible to think about the content what with the interposed advertising that pops up in the middle as you're scrolling, pops out of corners, etc. Informative content is whittled down and shifted from text to low-density media like video.

The Internet is a shadow of its former self. As a teenager I'd avidly read tech sites. This sort of in-depth article was common: [https://www.realworldtech.com/jaguar](https://www.realworldtech.com/jaguar). Gamers overran most of then. Today, you go to something like Toms Hardware and it's advertising encrusted trash. RWT has been reduced to posting a couple of articles a year. Ars no longer has anyone who knows how a computer or operating system works, though at least its ads aren't the worst.

<comment><USER9> It feels like I forgot to renew to the internet so I'm stuck with the demo version.

As you said, it's just so light on content and heavy on ads in places.

<comment><USER10> I would say this has a lot to do with the increase in accessibility and subsequent marketization reducing what used to be a fairly niche service attenuated to like minded scientific or at least exploratorily minded people to a common denominator that maximizes profits

</comment></comment></comment><comment><USER11> It's been a while since I read 451, and I definitely remember it differently than this portrayal. It sounds to me as if it was more insightful than I gave it credit for.

I've fallen into the pattern mentioned in the article and book: too distracted to sit down and have a long, quiet read. Part of this is due to having young kids and little high-quality spare time. But part, too, is due to addiction to distraction (such as Hacker News)!

<comment><USER12> I can give you one secret, which is that despite what you hear in the press, the phone can be a double-edged sword, one that can also cut _for_ you, instead of against you, with just a bit of discipline. Non-zero discipline, but not impossible amounts of discipline. With a book-reading app, you can get through anything, even War and Peace, in ten minutes here, ten minutes there, and maybe 40 minutes in the evening if you can scrape it together.

I'm saying this not because I lack the attention span to read for three hours, because I still can... the problem is assembling those three hours when you've got a job and young kids.

I've also been learning a foreign language for about an hour a day over the past year and a half, and believe me, very few of those hours have been contiguous. But I can recover five minutes here and five minutes there, and finish up in the evening, and I'm making real progress. (Unlike reading, where the attention being cut up will diminish the impact, once you're memorizing vocab and such, it's actually possible that breaking it up throughout the day is a _benefit_ rather than the same amount of time in one block. It may help convince your brain that what you're doing is important and shouldn't be discarded, because it keeps coming up, rather than being something it can compartmentalize easily.)

With a bit of creativity you can turn this to your benefit, or at the very least, _somewhat_ to your benefit rather than merely to your continued disadvantage.

<comment><USER13> I had pretty much stopped reading for enjoyment before smart phones. Have plowed through a bunch of books now thanks to the Kindle app. It's a combination of always being with you, remembering where you were across devices, and being able to adjust the font size to whatever's comfortable at the time. The kids getting older doesn't hurt either :-).

<comment><USER14> I consumed a lot of books with Audible last year when I had a commute. It's amazing how much time you can fill during those getting from A to B trips.

</comment></comment></comment></comment><comment><USER15> That's exactly what Ray Bradbury himself said. He was responding to the invention of television and the addiction to shallow entertainment he believed it would bring to the society.

We don't always need to interpret literature in accordance with the author's original intentions, but it helps to acknowledge and remember them.

Having said that, though, I'd like to ask why Bradbury bothered to include a powerful image of censorship (burning of books) in the story if that was't what he intended to focus on. It would seem that a population addicted to shallow entertainment won't even need firemen to burn their books; they'll just let the dead trees rot in a basement somewhere.

Perhaps censorship was needed because there's always a small number of people who find books interesting. Who are attracted to deep thinking. Who will develop and harbor subversive ideologies as a result, and who can incite a revolution when the conditions are ripe. As long as these people exist, the powers that be have a reason to fear. As long as some of us are reading books, there's hope. Or at least that's what I think Bradbury was trying to say, especially at the end.

<comment><USER16> Yes. Bradbury himself here in an article from 2007:

[https://www.laweekly.com/news/ray-bradbury- fahrenheit-451-mi...](https://www.laweekly.com/news/ray-bradbury- fahrenheit-451-misinterpreted-2149125)

</comment></comment><comment><USER17> The Airpods article is interesting. Airpods seem to be changing the office as well.

People are doing their entire routine at the office with Airpods: going to the coffee maker, to the cafeteria, to the bathroom, going to meetings (then taking them out there, I hope!).

I'm not sure the people who do it want to portray the image of "don't you dare talk to me", but that's how I interpret it. If no one can talk to anyone without deliberate interruption, it seems like we'd lose workplace camaraderie.

<comment><USER18> I agree. I don't walk around with mine during standard hours. I usually also only wear the one that people can't see when they come into my hours, and I apologize if someone says something to me while I have them in. I think it's very important to appear accessible and to hear and participate in serendipitous conversation.

</comment></comment><comment><USER19> Previous discussion of a similar (and IMO better) article on the book: [https://news.ycombinator.com/item?id=14992956](https://news.ycombinator.com/item?id=14992956) . The article under discussing there includes lots of quotes from Bradbury himself.

</comment><comment><USER20> As I've gotten older, I've started noticing that culture goes through endless time loops like we're riding a toy train. Back in the 90s, we listened to disco and wore bell bottoms just like our parents did. Today, I see teenagers wearing overalls and boots and listening to Nirvana (which is quite heartwarming, honestly - at least there is hope for the future).

I'm going to go out on a limb and say that social media is just another cultural deviation. As a society, we haven't said yet that it's rude to talk loudly into your cell phone in public, or stare into it when you're surrounded by people also staring into it, or wear headphones everywhere like the gym where you might learn something if you ever talked to anyone.

It's an eerie feeling to see the world a step or two back, to take in the big picture when everyone else is jacked in. I can't really blame people for putting on blinders, as bleak as these times are. Sure, we have unlimited access to news and information. But news is mostly bad, because that's where the money is. Even the best news like NPR leads to depression, especially when you realize that the main news networks broadcast spin now instead of investigative journalism, and they're all anyone watches.

I have no deep epiphany here. But I just want everyone to know that this profound cultural cynicism we're experiencing right now is quite familiar to me, because it's what I grew up with in the 80s and 90s while most of the world was distracted with Monday Night Football. The world's been burning that entire time, most people actively tune it out, and the people like us who see through the veil see more than ever.

<comment><USER21> >Today, I see teenagers wearing overalls and boots and listening to Nirvana (which is quite heartwarming, honestly - at least there is hope for the future).

I'm puzzled what in that is at all heart-warming? Or hope-giving?

edit: They're genuinely curious, non-rhetorical questions!

<comment><USER22> The person that you are replying to presumably grew up with overalls and Nirvana.

<comment><USER20> No hah :-) I grew up in the the Donny Darko era of pastels and nanny state 1950's era abstinence of the late 1980s and early 90s which resulted from AIDS and the war on drugs. Grunge/alternative/Nirvana was the first "real" cultural experience I had. Saying no to materialism by wearing overalls is the visible expression of questioning authority and the status quo.

I miss many aspects of the 90s and what they stood for. But I'm inspired by today's youth and how they will pierce the veil in their own way.

</comment></comment></comment></comment><comment><USER23> > Bogost examined Airpods' potential long term social consequences. "Human > focus, already ambiguously cleft between world and screen," he suggests, > "will become split again, even when maintaining eye contact." A little > further on, he writes, "Everyone will exist in an ambiguous state between > public engagement with a room or space and private retreat into devices or > media."

I do think the Airpods are pretty revolutionary. For starters - Apple built a custom chip for them. There are very few companies that have the resources to do such a thing. As a result, even though they are imperfect, they are still far and away a pretty revolutionary technology.

It is interesting to look at the social consequences of the Airpods. For starters, they are expensive, so in some sense they are a status symbol, especially for the younger generation.

The Atlantic Article the author mentions is interesting though - the thought that a technology melds so well into our daily lives and workflow that it creates a further social rift is scary.

</comment><comment><USER24> Reading this reminds me how my High School Teacher prodded a cold-war, Orwellian, censorship interpretation out of us in exams.

But Bradbury was definitely on to something deeper.

I'd forgotten all about the Seashells and 4 walled televisor in this classic novel. Definitely a great metaphor for today's social media.

</comment><comment><USER25> FYI the audiobook version narrated by Tim Robbins is _fantastic_. It is more of a performance than a reading.

</comment><comment><USER26> I enjoyed reading this post, thank you. The cultivation of attention and thus self care is a significant theme in the work of Bernard Stiegler, which, if you haven't encountered it, may be of interest.

</comment><comment><USER27> Our attention is a valuable resource that we too easily give away for free. Social media (and in the past, television) are the junk food of information.

</comment><comment><USER28> required reading for Professor Brody's class. Stevens Higher Institute of Technology circa 1966. I still don't understand what it had to do with fixing radios tvees and computers.

</comment><comment><USER29> (2018) June 15, 2018.

<comment><USER30> Thanks! Updated.

</comment></comment><comment><USER31> Wrongly.

<comment><USER21> Actually "wrong" seems OK here, according to the first and only page I consulted:

"... _wrong_ can also be an adverb. There's nothing in the least new about this — the _Oxford English Dictionary_ has examples from the thirteenth century onwards.

Robert Burchfield noted in his 1996 revision of _Fowler's Modern English Usage_ that "The subtleties attending the various uses are considerable", pointing out that the OED devotes five times as much space to adverbial _wrong_ as it does to the notionally correct _wrongly_.

The quick and easy rule is that _wrongly_ appears before the verb being modified ("the earlier case was wrongly decided") and _wrong_ after the verb ("he answered the question wrong"). Like most such rules, it's not even half the story. Style guides and grammars for learners try to give more complete guidance, variously stating that, if the situation is formal, _wrongly_ may be the better choice in either position; if the adverb comes before the verb, _wrongly_ is the only possible form; if the verb is a common short one, such as _do, get, have_ or _go_ , it often forms a set phrase in which _wrong_ is the idiomatic choice ("don't get me wrong", "she did him wrong", "how did he go wrong?"); _wrong_ is preferred after the verb when the intended meaning is "in an unsuitable or undesirable manner or direction" or "incorrect" (as in spelling something incorrectly); if it means "falsely", then _wrongly_ is the correct form ("rightly or wrongly", "the award was denied him wrongly", "he was incapable of acting wrongly"..."

[http://www.worldwidewords.org/qa/qa- wro2.htm](http://www.worldwidewords.org/qa/qa-wro2.htm)

So..maybe your objection stems from the over-informal feel of adverb "wrong" in a headline.</comment></comment>