Deno will stop using TypeScript - <AUTHOR> https://startfunction.com/deno-will-stop-using-typescript/ <comment><USER2> There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds.

[1]: [https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...](https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#)

First paragragh of that document:

> Update June 10 2020: I saw that this design doc was being discussed more > widely. Most people don't have the context to understand this narrow > technical document - it is only applicable to a very particular, very > technical situation in the internals of Deno. This is not at all a > reflection on the usefulness of TypeScript in general. It's not a discussion > about any publicly visible interface in Deno. Deno, of course, will support > TypeScript forever. A website or server written in TypeScript is a very very > different type of program than Deno - maybe much more so than novice > programmers can appreciate - little of Deno is written in TypeScript. The > target audience is the 5 to 10 people who work on this particular internal > system. Please don't draw any broader conclusions.

<comment><USER3> Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.

<comment><USER4> I thought the "novice" programmer remark was a pretty cringe-worthy comment.

The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".

<comment><USER5> I can sympathize with their issues. TS compiles are slow as fuck, and if I could find anything that was just as nice without the long compiles I'd switch in a heartbeat.

But I don't think I'd ever want to go back to plain Javascript.

<comment><USER6> There are efforts to provide faster compilation times: \- [https://github.com/evanw/esbuild](https://github.com/evanw/esbuild) \- awesome, I use it for most of my ts projects \- [https://swc- project.github.io/](https://swc-project.github.io/) \- also awesome, but has some bugs

<comment><USER5> Esbuild is cool, but if it doesn't check the types then using Typescript is a bit pointless in the first place.

Guess a combination of esbuild during development, and tsc during commit would be the best of both worlds.

<comment><USER7> Not necessarily, TS issues are found in the editor which is where most of the use is. I don't test types only on compile but usually through VSCode itself.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal.

TS feels like something that was created to lure programmers who couldn't wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS.

It have never felt about it like something that would make my code better or more organized. It definitely slows me down with very little benefits in return. (Again, can't stress enough that this is a personal opinion based on personal use cases)

I appreciate that it forces me to be more intentional about organizing my code but I also get that when I use frameworks.

Of course I also appreciate when I can identify that an error is coming from a type mismatch, but as I said I learned to program in loosely typed languages first, so I never created that concept of defining types in my head. I'm always extra-aware of types mismatches in my JS code and is usually the first thing I check when something goes wrong. But I have never felt the need to have a way to explicitly define the types that I'm working with. I honestly fail to see the benefit when a large amount of code that you have to interact with (libraries and such) was written in classic JS.

Once again. Probably unpopular opinion, so I don't mind the downvotes.

<comment><USER9> I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I simply don't believe that. Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc.

<comment><USER10> I have a little less experience, only 30 years, but I have to fully agree with you. Not sure why you got down voted (maybe the religious popularity crowd rearing its head).

I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (and the class of bugs they prevent) do not outweigh the usually larger code size (and often even additional complexity).

Maybe I've just tried the wrong languages, but I was never convinced of the great improvements usually promised. At the same time, I have seen other people twist and jump through hoops, while vigorously holding on to their conviction how all that is an improvement.

Sure, some errors will move from run time to compile time with typed languages. But if those are a systemic problem in your code, you probably have even bigger things to worry about (the ones you already keenly pointed out).

From a cynical point of view, I can understand why corporate entities would love typed languages (for the increased code size and complexity), but that's another story.

<comment><USER11> > Not sure why you got down voted

For the (pretty obvious) logical error of claiming that you have to believe that most errors are caused by type mismatch to consider stating typing beneficial.

</comment></comment></comment></comment><comment><USER12> Why such a large, important project would want to drop static types is beyond me.

> TypeScript isn't proving itself helpful to organize Deno code. On the > contrary, the Deno team is experiencing the opposite effect. One of the > issues mentioned is that they ended up with duplicate independent Body > classes in two locations

This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just fine.

These folks are free to do what they want with their project, but this is not a good look, especially to those that are skeptical of the javascript ecosystem.

<comment><USER9> Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and important language in the world (probably in the history of programming), so that's two game-changers that don't require static typing.

<comment><USER13> Lisp is not popular.

Remove the browser practical monopoly, and JS popularity would vanish.

<comment><USER14> I disagree on the current sentiment but agree that browser monopoly pushed js on people. If js didn't evolve over the last few years (since es5), I would have believed removing it from the browser would kill it.

Right now, you have options to avoid writing js at all. There might be some glue code in js but you can write vast majority of your code in other languages and target js. People still choose to write in js.

Purescript, elm, clojurescript, kotlin, bucklescript, and the list goes on. There is a to-js transpiler for every popular language. Why aren't they seeing more usage?

<comment><USER15> tbh JS is popular only because of browser monopoly. JS became popular because of internet usage otherwise it would just die. It started with 1997 changed little at 1998 and 4th edition was even abandoned lol. and it took so long to evolve after that. in 2019 there was update and from 2015 we are seeing good progress. no we still cannot avoid because browser needs it. Hopefully wasm can replace but it still has long way to go.

So i don't subscribe to idea that js is not popular because of browser monopoly.

<comment><USER14> I am not disagreeing with that?

</comment></comment></comment></comment></comment></comment><comment><USER16> Here's the Deno Design document with the reasoning and some discussion about the decision: [https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...](https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview)

This post adds little to what's already said there.

</comment><comment><USER17> I'm a little shocked at some of the outcry in this thread. People are making it sound like they're switching from Rust to Ruby or extolling the virtues of types: TypeScript does absolutely nothing for you at runtime. There are no types, there are no type checks, its all the same guarantees as good ol' JavaScript. You still can't trust function parameters to be what they say. It's a Babel configuration with inline doc annotations.

If people are serious about types, then why isn't more front-end moving over to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even. TypeScript has convinced people they're getting the benefits of (strong?) types when they're just populating the auto-complete in VS Code.

<comment><USER18> TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io- ts.

<comment><USER17> But this is a niche application of TypeScript, most day-to-day front-end devs I've interviewed aren't reaching for fp-ts, let alone io-ts, whatever the benefits.

Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc? Why implement yet another FP runtime? If something like this is the surest way to make optimal use of TypeScript then I feel like we're just right back where we started.

For most devs, I'd wager they're still ending up writing all the same tests they were before TypeScript.

tsc even offers to just consume jsdoc annotations for crying out loud. If its just some kind of type convention sandbox, what did it really bring to the table?

<comment><USER18> Elm's got questionable support; I wouldn't feel comfortable recommending that at work, it'd be irresponsible.

PureScript I really like but it's a massive jump from JS/TS to PS/HS.

All of these languages are harder to abandon than a library in the same language you'll keep using if you decide against the paradigm down the road. Do I like this compromise? Not really, but it makes sense.

Also, advertising use of a functional language might open you up to candidates who wouldn't otherwise apply.

</comment></comment></comment></comment><comment><USER19> I'm a long time fan of TS, but I think this is a very exciting decision —- I have always been of the opinion any reasonably large project should workout a doubt use TS, so hearing about how this goes for them in 2/5/10 years in terms of how easily people are able to maintain code they didn't create, how readily large refactorings can be made, how often runtime type errors occur (not just the literal TypeError, but all the things TS can catch, like null checks, index typing checks, etc) will be quite interesting.

I wish them luck!

One note of concern though: in their design doc they say incremental compilation is the number one problem and list multi-minute compile times. That's huge! I wouldn't use TS either of it took minutes to compile my projects. However, I think there's room for improvement in their tooling if they took some time to explore what other large TS projects do instead of just giving up on it entirely —- VSCode for instance has incremental compilation in hundreds of ms or less.

<comment><USER20> What a measured response!

</comment></comment><comment><USER14> They should just use deno to run their setup, there would be no compilation if they did that. ;)

Someone is trying to rewrite tsc in rust for speed up here - [https://github.com/swc-project/swc](https://github.com/swc-project/swc)

Cool project for runtime checking with ts - [https://github.com/gcanti/io- ts](https://github.com/gcanti/io-ts)

Edit: Remove unmaintained runtime type checking library.

<comment><USER21> Instead of ts-runtime, use io-ts ([https://github.com/gcanti/io- ts](https://github.com/gcanti/io-ts)). That one is actually maintained, unlike ts-runtime!

</comment></comment><comment><USER22> I found sweet spot for myself - flow with types in comments. As weird as it sounds it works for me on quite complex projects very well. Unlike typescript, which is language transpiler like coffeescript - flow is just typechecker with guarantee that after stripping types the output is valid js. It wouldn't work with ts, which generates runtime code ie. enums etc. Very good type inference means types appear as type declarations and when declaring functions and pretty much nowhere else. The code has interesting haskell'ish feel to it, ie. most of the code looks something like this:

      const ofId /*: (Sql, number) => Promise<User> */ =
        (sql, id) =>
          ...

I'm very happy with it after using it on quite complex projects, writing libraries (ie. functional combinators for parsers, assertions/runtime types, template sql generators; and the rest from apis, business logic to anything that is needed).

Lack of libdefs is not a huge problem in my case. I have strong preference for shallow or no dependencies in projects and for things I use 3rd party code there are types or were converted from ts or simply added. Better support would help here but it was not a deal breaker.

Code editor support is not as good as ts but it does the job.

Another interesting effect is that arbitrarily deep npm linking is so much easier, the code is just js, doesn't need transpilation step, can be edited as is; I'm free to use any directory structure, ie. I often use root directory to drop files, they have natural require/import paths, no configuration etc.

For me, it's a joy to code like this.

<comment><USER23> typescript also supports type checking js code: [https://www.typescriptlang.org/docs/handbook/type- checking-j...](https://www.typescriptlang.org/docs/handbook/type-checking- javascript-files.html)

I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works!

Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.

<comment><USER22> You can't do too many things with jsdoc, can you? Ie. generics are not supported or basic things like importing types from other file, right? Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as well. It's absolutely not the same thing. With flow you get the whole flow, with jsdoc it seems some scraps of typechecking. Am I wrong?

<comment><USER23> Generics are supported via `@template` [https://www.typescriptlang.org/docs/handbook/type- checking-j...](https://www.typescriptlang.org/docs/handbook/type-checking- javascript-files.html#template)

types can be imported either explicitly via `require()` or via the `@type {import("foo").Bar}`

There are definitely some limitations and caveats, like `Object` being aliased to `any` (I think this is being changed in a new version), but it's still way better than untyped JS, and having typescript integration is nice since our devs are already using typescript in other places.

Can even using things like [https://github.com/typescript-eslint/typescript- eslint](https://github.com/typescript-eslint/typescript-eslint)

Flow is both more advanced and faster than Typescript, but the community isn't as large, so Typescript continues to gain marketshare

<comment><USER22> If it supports many constructs, why they don't switch to using it in deno?

<comment><USER16> I assume most of the minutes-long compile times they are running into are because of type checking. Moving types to comments wouldn't help that.

I don't konow why they aren't separating type checking and dev builds from each other, but there is just absolutely no way simple TS to modern JS (no compiling to old ES5) conversion would take that long for a 10k LOC project, it must be the type checking. I'm using TS through Babel and it has been a breeze for much larger projects than that. Babel just strips away the TS types and we do type checks via editor integration and a separate CI step. Can't recommend this setup enough.

<comment><USER22> It's not only compile times, it's also runtime code it generates and issues it creates in some cases, article mentions it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> > It's worth mentioning that Deno will stop using TypeScript only for the > internal Deno code: the Deno user code will still be in TypeScript and thus > type checked.

</comment><comment><USER25> It seems it might be an issue with their development abilities or problem- solving motivation:

1\. It seems that they write a ".d.ts" file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them "it was too much overhead and complexity when we attempted it before", which caused them to give up, a very dubious course of action.

2\. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead.

3\. They claim that "having two Body classes is obviously wrong" (?!). Of course having two classes with the same name in different namespaces/packages is perfectly fine in properly designed languages (including both JavaScript and TypeScript). Their "Header" shadowing problem also might be due to a lack of understanding of namespaces.

4\. They seem to conflate JavaScript vs TypeScript with single file vs multiple files. Of course you can have a single TypeScript file or you can have multiple JavaScript files and bundle them with any JS bundler or just concatenate them.

Given that their codebase seems to be complex according to their compile time claims and that they don't seem particularly skilled given their claims, using a type-deficient language will most likely result in software full of bugs.

<comment><USER26> > 2\. They claim that changes take minutes to recompile, but TypeScript can > compile incrementally, so this shouldn't happen assuming they are organizing > their code properly. Also, you can just translate without type checking, > which is no worse than using JavaScript instead.

Interested to know how you're actually supposed to do this. I don't do much web development, but the few times I've had to dive into our typescript code at work, I end up just modifying the compiled javascript to debug things because the compile loop is painfully slow.

<comment><USER27> It's a relatively new thing

[https://www.typescriptlang.org/docs/handbook/release- notes/t...](https://www.typescriptlang.org/docs/handbook/release- notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental- flag)

</comment></comment></comment><comment><USER28> I don't remotely see TypeScript as the end state of statically typed JavaScript. I think it was the first major project to prove how static typing could work and benefit browser applications. Flow and TypeScript are just the first generation. In the future I expect the type system to be integrated with the runtime. While there are projects that give you this (Elm, Reason, Bridge.net, Fable, etc.), they are nowhere near as universal as TypeScript nor is that really their aim.

<comment><USER14> I am a newbie reason user. I like the language and ocaml ecosystem but it is _just a bit_ of a pain to do anything practical with it. Soon you are writing a lot of js in reason. Compared to typescript, js and reason mixed code stings like a sharp contrast between sun and moon.

Until those languages make themselves feel just like js or completely remove excessive js interlop, they won't be as mainstream.

<comment><USER29> Huh, I don't share your experience at all. I maintain an F#-and-JS application and I'm constantly surprised by how well interpretation works. You literally just import F# code in JavaScript and use it, as well as the other way around.

Sure, if you want to make maximal use of the strong typing of F#, you'll have to annotate JS data as it comes in, but that is necessary complexity, not incidental. And if you're happy with having your F# code "dynamically typed", there's zero ceremony around importing JS stuff.

</comment></comment></comment><comment><USER30> > _I never have the class of bugs in my projects that people seem to laud > about typing to solve. It's kind of ridiculous_

You do have that class of bug. That's like a cpp programmer saying they don't need smart-pointers because they never introduce memory leak bugs. You're a human.

</comment><comment> brown9-2 > One of the issues mentioned is that they ended up with duplicate independent > Body classes in two locations

... choice of programming languages is irrelevant here.

</comment><comment><USER31> Needs "internally" at the end of the title.

</comment><comment><USER32> Discussion from two weeks ago: [https://news.ycombinator.com/item?id=23462506](https://news.ycombinator.com/item?id=23462506)

</comment><comment><USER33> Why remove it entirely rather than split off compilation and type checking? I'm not familiar with the Deno codebase, but a similar problem with large webpack projects is solved by having the type checking be an async process. This gives the best of both worlds as you transpiling alone is near instant.

<comment><USER34> As other's have pointed out, it really sounds like the deno devs were unfamiliar with what's available with build options for typescript. An unanswered question everyone is asking, why do they handwrite the .d.ts that can be autogenerated?

</comment></comment><comment><USER35> I used Typescript for 2 years, and I'm happy to report I'm dropping it and encouraging my team to do the same. Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time.

<comment><USER36> > Types are for compilers, not people, and personally I think there's more > disadvantages than advantages

The Haskell community strongly disagrees...

<comment><USER37> I dont know Haskell that well, but I thought it had strong static typing?

Though, Haskell figures out the types for you, instead of you typing them in, maybe thats a big difference. In Haskell, do you find you have to think about the types anyway, or can you code it like you would clojure?

<comment><USER35> I come from a clojure background, maybe that's why I don't enjoy TS. I find that large projects, so much code is un-necessary, people spend a lot of time troubleshooting types instead of building functionality. Of course it depends on the project. Social security #'s is a different scenario than something like a game or frivolous retail...

</comment></comment></comment></comment><comment><USER38> I wish Dart was more popular as a JS alternative. I've been using it recently it's really surprisingly productive and fun.

<comment><USER39> Does Dart still allow you to compile to JS or was that feature dropped?

<comment><USER40> It must; the SASS reference implementation is written in Dart and the npm package is transpired from that.

</comment></comment></comment><comment><USER41> So it happens again, yet another project discovers that whatever improvements a guest language brings into a platform, using it also has its costs versus using the main language of the platform.

</comment><comment><USER42> This is a great victory for Ecmascript. Typescript is a great hinting support language, I use it with JsDoc to check my (not transpired, vanilla js) code. But it cannot replace JavaScript and is not a JavaScript superset. I think If anyone what to accept the drawbacks of have transpiration of source files can choose better alternative to typescript.

</comment><comment><USER20> Everyone is drawing conclusions without much context. Read the design doc[0].

[0]: [https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...](https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#)

</comment><comment><USER43> I can fully understand that an additional tool layer can cause additional problems, but static type checking is a large quality win for large projects. There are workarounds to achieve similar results:

(1) Use a faster bundler like esbuild, here vite's similar considerations [1]

(2) Use Flow [2] and just strip it away before distribution like this Babel module [3]

\---

[1] [https://github.com/vitejs/vite#typescript](https://github.com/vitejs/vite#typescript)

[2] [https://flow.org/](https://flow.org/)

[3] [https://babeljs.io/docs/en/babel-plugin-transform-flow- strip...](https://babeljs.io/docs/en/babel-plugin-transform-flow-strip-types)

</comment><comment><USER44> "Always bet on JavaScript" holds true, I guess.

</comment><comment><USER45> There are tools to transpile typescript only, without doing typechecking, which dramatically reduces "compile time." It's very useful for a quick development iteration cycle, and then do a full type checking pass before merging and during CI.

</comment><comment><USER46> I'm doing a medium/large project in Coffeescript 2 and it's totally awesome. Rarely a type related bug and I'm progressing waaay faster than having to deal with TS in my way.

But for anyone enjoying to specify their types in detail, have fun!

<comment><USER47> wow that's cool to hear! I read about coffee 2 awhile ago and then heard nothing of it. I used to love coffeescript, arguably more than vanilla js, but forces that be led me to move on.

are you working with a team? if so was it easy to get buy-in?

</comment></comment><comment><USER48> Was using JS for about 6 yrs now and decided will start using TS for a new Node.js project. Admitted it has its warts ... hit my first bottleneck rightaway when parsing the request query param. TS Express bindings declare it as string | string[] | ParsedQs | ParsedQs[]. Ok extract it 'as' string and move on. But I find as I am using it more and more it is getting better (or I am getting more disciplined!) .. maybe I am reading this wrong re the long compile time reported, could the code not be broken into modules so the compile is more isolated ??

<comment><USER23> just a heads up, casting `as string` isn't safe since the request param could turn out to be an array.

If the request ends up with the query param as an array, there isn't a runtime to validate the cast and now the variable is typed as `string` but is actually `string[]`.

I think a safer approach is to use a validation library or refine the type with an if stmt and returning an error when it isn't a string.

I use the following lint to prevent all casts except `as const`: [https://github.com/typescript-eslint/typescript- eslint/blob/...](https://github.com/typescript-eslint/typescript- eslint/blob/master/packages/eslint-plugin/docs/rules/consistent-type- assertions.md)

<comment><USER48> Thanks for the headsup. I did realize that. It was a specific case of pulling a username from the query .. checking out the library ..

</comment></comment></comment><comment><USER49> It seems weird to ask other projects to use Typescript when running on Deno when Deno isn't using typescript internally? If you're the Deno team wouldn't you want to dogfood Typescript?

<comment><USER50> Different use cases = different technologies.

</comment></comment><comment><USER51> This seems to lend more credit to ReasonML. Compile times are faster and it doesn't bring the associated complexity of object types while still retaining the benefits of static typing.

</comment><comment><USER52> Thank you.

Finally people are speaking out against the madness of TypeScript.

Don't get me wrong. It is a technical achievement to put a static type system on top of JavaScript. And for libraries, it is useful. It let's the users of the library get hints and direction from an editor like Visual Studio.

But as a language. It is just not good. No way anyone would end up with a design like that had it been built from scratch without going through JavaScript first.

Remember when Java did generics and got flak because of type erasure? Compare with TypeScript ...

</comment><comment><USER53> Using JS instead of TypeScript is very short-sighted and they will regret it, eventually. Sounds like they got frustrated and gave up.

Their arguments remind me of someone saying they want to use Assembly Language instead of C++, because assemblers are faster than compilers, or to not have to worry about memory heap issues, etc.

All you're doing by switching from TS to JS, is trading one set of minor problems (which are solvable) to a more vast set of even larger problems that are NOT solvable.

<comment><USER2> Spoken like someone who's never solved problems with medium-to-large scale JS projects... criticising people who have.

<comment><USER53> Here's a pretty sizable project I wrote in pure TypeScript:

[https://github.com/Clay-Ferguson/quantizr](https://github.com/Clay- Ferguson/quantizr)

I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet understand the value of type-safety, it's only because you haven't lived long enough yet.

<comment><USER2> I do understand the value, thanks mostly to Haskell. I also know that (language- or tool-enforced) type safety and type discipline are separable concerns. I also understand when the former gets in the way, thanks to JS, TS, Rust, Lisp, and projects large and small, slow and then fast, fast and then slow, slow and then slow, and fast and then fast.

<comment><USER53> Every developer, regardless of skill level, makes mistakes and typos. The beauty of type-safety in TypeScript is that the compiler catches it instantly, in a way that is simply humanly impossible.

If I misspell something, or provide the wrong argument type to a method, or have args in wrong order, etc, it's caught instantly.

With JS you can have a typo that causes user malfunctions for YEARS before being found by a developer and fixed. Any developer who's done many years of both TS and JS would never in a million years consider going back to JS. Absolutely out of the question.

<comment><USER2> > Any developer who's done many years of both TS and JS would never in a > million years consider going back to JS.

Except, apparently, for the topic of this article.

> If I misspell something, or provide the wrong argument type to a method, or > have args in wrong order, etc, it's caught instantly.

Yes, I've heard the pitch before. I've even given it more than a few times.

Of course, if both of your arguments happen to be 64-bit floats, then the type system won't help you much if you get them in the wrong order.

However, when you want to change that function to take a closure instead of a number, the type system can be invisible or it can fight you. Some of us love the structure that a type system can provide. Some of us, like the one who started this website we're on now, also appreciate the power of languages that get out of your way and let you make your own brilliant mistakes. And some of us can appreciate the beauty of different language designs and approaches, and try to rise above dogma. Which, if you've been in this line of work for 20+ years, should be you.

<comment><USER53> > Except, apparently, for the topic of this article.

Well, Deno devs _did_ try to use TypeScript, and just ran into some challenges, and decided to throw the baby out with the bath water. I've seen this a lot in my 30yrs exp.: some developer/team runs into problems, gets frustrated, gives up, and decides the best decision is to _remove_ some important piece rather than _solve_ the actual problems.

The reason Deno is giving up TypeScript is representative of failure, and _not_ an indication them wanting JS instead of TS. What they _want_ is TS.

The rest of your reply is just stating some minor imperfections that are a billion miles from invalidating TS. And yeah, there's a place for JavaScript still, for small-scale tinkering, or perhaps even prototypes with only a few hundred lines of code. Any large scale project in JavaScript (not TS) is simply unfathomable to any modern developer worth his salt.

<comment><USER2> You're a dogmatic true believer, and it's rarely worth arguing with dogmatic true believers. Just notice that you threw everyone that disagrees with you (or rather, that comprehends a wider range of circumstances than you do) under the bus as "not worth [our] salt". That was not the right thing to say.

And you dismiss my reply (including the part where I point out that the website we are on was first developed in a Lisp) as "some minor imperfections". It's like you're satirizing the tunnel vision of the fundamentalist.

And, true to form, you "know" what the deno team wants better than they themselves do! I hope you can come back to this thread in a year or two with some perspective.

<comment><USER53> In the above discussion I focused on the technologies, programming languages, and the core of the technical issue. You seem to focus on personalities, feelings, and emotions. To each his own, I guess.

And about me knowing Deno _did_ want to, and _did_ attempt to use TypeScript: the _way_ I know that is because I _read_ the article, lol. Apparently you did not.

<comment><USER2> I did read the article, and also the design doc which I linked in my top-level comment.

The facts are that they started with TypeScript and moved away (for a particular internal component). The interpretation of that as _wanting_ to use it and _failing_ is yours. You could just as well see it as having made a mistake and then realizing it. But all of these _interpretations_ , by those of us who didn't have to make the choice and weren't there when it was made, aren't very helpful.

<comment><USER53> That's correct. They failed to get TypeScript to work. Thanks for reading that.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER54> I just hope in 5 years we're not seeing a talk saying that in retrospective, dropping static types was a huge error... and DoNe is a new project to fix issues like that!

(I'm just referring to this nice talk about the regretful mistakes done in Node: [https://youtu.be/M3BM9TB-8yA](https://youtu.be/M3BM9TB-8yA))

</comment><comment><USER55> Typescript may not work for all types of applications - in fact there is no language that does. So picking one project and generalizing it often comes out of inexperience.

As a counter example, VSCode is easily bigger than the Deno codebase. Again, that doesn't mean it's good for your project.

</comment><comment><USER56> You know when you say a word over and over again and it starts to lose meaning?

Well, I didn't have a clue what Deno was before, but now it's barely letters in a screen. This post says Deno _way_ too much. Deno.

</comment><comment><USER57> > While TypeScript is sometimes seen as an improved version of JavaScript, > this case is showing that in fact, it's not. It has flaws like any other > language.

This is not a language flaw. It is a tooling problem.

</comment><comment><USER58> I've migrated to Typescript and have been using it for about 2 years now. Maybe 1.5...

TS is the best language I've used. It supports frontend and backend and strict typing and it's scalable so I can refactor and know that my code still works.

The one thing its not good at is ML where Python is better but that's mostly because Python has better library support (not language design).

Here's the deal. When dealing with a large amount of code 80% of your dev time is spent maintaining code - NOT writing new code.

You can save a lot of time now writing new code and not using strict typing. OR you can spend a little bit of time now, maintaining your types, and save a MASSIVE amount of time later.

> \- TypeScript compile time when changing files takes several minutes, making > continuous compiling an excruciatingly slow process

I have a HUGE typescript repo and using a Macbook Pro from 2015...

With --incremental and --watch my build takes like 5 seconds. About 1 minute on the first build then about 5 seconds after that.

If your build is taking a long time - you're doing something wrong.

> The internal code and runtime TypeScript declarations must be manually kept > in sync since the TypeScript Compiler isn't helpful to generate the d.ts > files

What? How? That doesn't make any sense. You're doing something wrong here. If all the code is in typescript, you have no additional work to do. If it's in JS you just have to write your own .d.ts files manually.

Honestly it seems like this team just needs to sit down and understand how their tools actually work.

The one issue where Typescript DOES kind of suck is when dealing with webpack, typemaps, and types.

Many older projects just don't publish types and if you rely on them, and they refuse to publish types, you're going to be in a bit of pain.

You can write your own types though and we've been doing this internally and for some repos just forking them so it's a bit easier to work with them. They usually lag on publishing their types.

If you want to avoid all this pain you can just use webpack for your build system and Typescript for your code. We use lerna to build a multi-module system with --hoist to avoid duplicate dependencies.

[https://github.com/burtonator/polar- bookshelf](https://github.com/burtonator/polar-bookshelf)

... is the project we're working on if you want to check it out. Our internal build system isn't fully published yet as we're in the process of reworking it but we're open source so you can take a look if you want.

<comment><USER59> I'm wondering about "\--watch" too... My projects are compiled in the background, like pretty much _instantly_. The only time I wait is when I restart the applications.

But I suppose they are aware of this flag.

</comment></comment><comment><USER60> Is there a reason we can ONLY use JavaScript in the browser? The world would immediately become better if we added a different language compiler on in instead.

</comment><comment><USER61> Has anyone else experienced these issues? This reads more like product placement for Deno than a sincere criticism of TS.

<comment><USER26> I've definitely noticed that compiling typescript is slow and extremely resource hungry. It's amusing to me that our "web" stack is the most resource intensive part of our entire codebase at work.

A sign of the times I guess that a build system requires 8gb of ram to run. Could be we're doing something wrong, but from what I understand we're using a pretty vanilla setup.

<comment><USER2> Unfortunately the state of web dev in 2020 is such that using a vanilla "best practice" setup is very much doing something wrong.

</comment></comment></comment><comment><USER62> > While TypeScript is sometimes seen as an improved version of JavaScript, > this case is showing that in fact, it's not.

Woah, woah, hold on. This case is showing that in the very specific, atypical case the Deno team are using it in, TypeScript is not the right fit.

I'd rather read something that actually interviews the Deno folks about what they are doing, the underlying document is a pretty free ranging discussion and this writeup is making a few assumptions.

<comment><USER63> May as well drop tests and code reviews if it feels like it's slowing you down. For one-person or very small teams who have full context of a'll changes this can actually work very well. It's with more contributors participating in a mature project that you'd wish these things weren't dropped. Types can be added later so it's not like using php and later wishing you'd used Kotlin.

<comment><USER63> I'll add a datapoint of an analogous case. I updated a legacy java 1.x codebase that was running java 6/7 without generics. Having spent a small amount of effort over a course of months, all the type annotations were updated. It uncovered exactly one bug. The main improvement is for quickly gaining context in unfamiliar code and being able to enable warnings for newly written code without noisy error messages.

</comment></comment></comment><comment><USER64> I'm stoked on this change, frankly the TS layer being included in Deno felt like a mistake from the get-go and I'm glad they've come around on it. I've seen many transpile-to-JS languages come and go. Javascript is eternal.

(Though I also think TS is a verbose mess made so that enterprise programmers/managers can feel safe, but even if it was great I still think this would have been a good choice)

</comment><comment><USER65> When Deno initially mentioned they run Typescript directly I was intrigued. It's like running GCC every time you want to invoke the script.

That being said I run ts-node all the time with transpile-only and that is decently fast. Even on production where the minimal cost is incurred once when loading the module.

As for their problems mentioned on the document. That Header class has a .d.ts conflict on an interface. That could be solved with having namespaces in .d.ts or having I prefix for class interfaces. We do this all the time in our codebase.

I'm not entirely sure why they have two copies of things. The doc doesn't give much detail.

If you want things to be fast like nodejs, then the other option is to use //@ts-check comments on JS files, or with compiler allowJS and checkJS settings. Webpack checks all their JS.

TSC now also has an option to automatically generate .d.ts from JS files with jsdoc comments. With declarationOnly compiler flag. Many existing JS projects already do that.

So TLDR is. You don't have to ditch Typescript totally. Typescript can purely just be a checker that you run at CI time and it will work quite well with existing JS code. Although if you want super strict safety the .ts syntax is less verbose and nicer to write. Even then transpile only mode is much faster than running full tsc.

Remember: TS is a superset of JS. All JS is valid typescript. Sometimes we gotta structure the JS properly and that's where the issue is rather than the typesystem.

</comment><comment><USER4> I felt like the article and associated google doc were fishing for reasons to remove TS until ry finally mentioned "typescript provides an extra 500 lines and the namespaces make the code harder to reason with (V8 ingests these files directly)". IMO that was the only solid reason for the change.

</comment><comment><USER66> Always bet on Javascript.

</comment><comment><USER67> oh I thought at first that this meant they were dropping _support for_ typescript, not that they were stopping using ts under the hood.

Getting closer to the metal seems good!

</comment><comment><USER68> HN gods, an off topic question.

Would Deno become the new Node?

Do you see a vibrant ecosystem building around Deno?

What I am interested to know primarily is, is the architecture / stack / goals and vision that resulted in Deno viable in the long term?

<comment><USER69> Deno's main selling point over Node.js seems to be some dubious sandboxing. Unlikely to be compelling enough for people to rewrite their applications from using Node's stdlib to Deno's.

Personally, it makes me cringe to see hard-coded HTTP URLs in source code files for loading dependencies. They present it like we're stupid for using package managers all this time. What used to be a simple command line option (changing a package repo) is now a thousand file edit. Excellent.

</comment></comment><comment><USER70> Has anyone seen any comments by the TS team on this? Maybe they would be amenable to helping out if the Deno team contacted them.

<comment><USER71> Honestly, what is a meaningful answer when someone blames language for problem with having two separate classes with the same name?

</comment></comment><comment><USER72> Due respect, these are issues with how the Deno team uses Typescript, not with the language itself.

> TypeScript compile time when changing files takes several minutes, making > continuous compiling an excruciatingly slow process

Umm, you can compile single files, and serve them individually. It's no different from bundling (e.g. with webpack) Javascript.

> The Typescript structure that they're using in the source files that create > the actual Deno executable and the user-facing APIs is creating runtime > performance problems

Then use a better structure?

? TypeScript isn't proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations [https://github.com/denoland/deno/issues/4748](https://github.com/denoland/deno/issues/4748)

Then consolidate the two classes...? How is the the language's fault?

> The internal code and runtime TypeScript declarations must be manually kept > in sync since the TypeScript Compiler isn't helpful to generate the d.ts > files

Well, it can be. Fix your build rules.

> They're maintaining two TS compiler hosts: one for the internal Deno code > and another other for external user code even though both have a similar > goal

Again, not the language's fault.

\---

We've been using Typescript for a couple of years now, and it's been great. By trying to do things the right way, it actually _forces_ us to organize our code better. I think the Deno project would benefit from refactoring their code to solve their issues, instead of blaming the tools.

<comment><USER73> Your main point seems to be that these problems aren't the language's fault. But I don't see the Deno team claiming that to be the case. There's nothing wrong with choosing a language that works with how your team likes to develop software, and rejecting a language that doesn't work well for your team. Doesn't need to be anyone's "fault."

<comment><USER74> It's entirely valid for them to decide they don't want to change their ways. However, it is frequent that technologies will be rejected because the requisite learning to understand why and how to best use the technology is not done. A common example of this (in my observation and ignoring the application of the technology where it's entirely unnecessary) is NoSql where teams have attempted to use those databases as they used their relational counterparts which obviously didn't work because they didn't shift how they were thinking about using storage and structuring their systems. Anyway, that was how I read the GPs post, as attempting to note that the Deno team may not have pushed through the mental shift required to really get the most out of TypeScript.

[edit: not trying to take a stance in support of the GPS post or either side of this discussion, to be clear]

</comment></comment></comment><comment><USER75> Why Deno ?

<comment><USER76> Deno Deno deno deNo deNodeNodeNo...

<comment><USER75> That wasn't a question about the naming.

<comment><USER76> You might need to say a bit more about what it is a question about if you want an answer.

<comment><USER75> "Why X ?" is a common shorthand for "What is the raison d'être of X ?"

<comment><USER76> Well, in all the initial presentations Ryan Dahl gave about Deno, he phrased it as solving the things he'd come to realise he hated about Node. So that's what I take as the raison d'être of Deno - taking the lessons he'd learned from some years mainly coding Go and thinking about what he'd learnt from Node, and fixing what he could. Here's the classic video on the topic: [https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

</comment></comment></comment></comment></comment></comment><comment><USER77> I'm very perplexed about the reasoning.

Aside from the compiling takes time issue, the rest sounds like trolling.

If the code was organized in a way which is inefficient and confusing, I fail to see why checking types at runtime instead of compile types improves the structure. It's a completely separate problem.

</comment><comment><USER78> Yeah. Same same. Not working, so let's just fix it by creating another ecosystem instead of fixing compiletimes etc.

I will refuse deno. Too much ego in JavaScript-land. "Everybody wants to be like Mike". Errr Linus... Lowrey

<comment><USER62> Deno is made by the guy who made Node. So no change in notoriety there.

</comment></comment><comment><USER79> > TypeScript compile time when changing files takes several minutes, making > continuous compiling an excruciatingly slow process

They must be doing something horribly wrong, because tsc takes literally 1 second for my 3KLOC codebase[1] in incremental mode.

[1] [https://github.com/flatpickr/flatpickr](https://github.com/flatpickr/flatpickr)

</comment><comment><USER80> We were actually considering Deno because of its TypeScript support. We have a sizeable TypeScript codebase written for Node. This will probably make us more likely to stay in Node.

EDIT: I didn't read the article thoroughly. It looks like they're still supporting Typescript user code.

<comment><USER20> In the design doc, you can read this disclaimer:

> Most people don't have the context to understand this narrow technical > document - it is only applicable to a very particular, very technical > situation in the internals of Deno. This is not at all a reflection on the > usefulness of TypeScript in general. It's not a discussion about any > publicly visible interface in Deno. Deno, of course, will support TypeScript > forever. A website or server written in TypeScript is a very very different > type of program than Deno - maybe much more so than novice programmers can > appreciate - little of Deno is written in TypeScript. The target audience is > the 5 to 10 people who work on this particular internal system. Please don't > draw any broader conclusions.

</comment></comment><comment><USER81> Thank God, I would really appreciate this. The TypeScript usage was the one thing that I didn't like about Deno.

Why add complexity to a new project which starts from scratch? JavaScript is good enough and there's no need to make it confusing by adding another layer.

<comment><USER82> > JavaScript is good enough and there's no need to make it confusing by adding > another layer.

To some people, JS itself is relatively confusing, and TypeScript reduces that confusion.

EDIT: And... someone's clarification is saying this is internal framework code, not userland support for TS. Seems like a non-issue, really. They don't want to use it, but want to provide support for others to use it in their projects.</comment></comment>


Ask HN: What is your opinion about the sale of digital games? - <AUTHOR>

A company that has won, multiple times, the title of "Worst company in America" (EA Games) allows their customers to refund games within a 7 day period. Companies such as Steam, Microsoft, and Sony do not have allow refunds under no (Even if you meant to purchase the game as a gift) circumstances.
I am sure there are many points of discussion here; piracy being one. I would love to hear more from you guys.
P.S: Some "recent" events - http://www.gamespot.com/articles/valve-sued-by-australian-consumer-watchdog-over-st/1100-6421983/ <comment><USER2> Steam lets you buy games from multiple publishers, and a lot of times they have very good sales. I wouldn't call Steam a company, isn't the company Valve?

I'm not sure about other companies, but don't they only sell their own games? And they get a bad rap for being a publisher, not as a game-store. They might not be a good game-store, because they don't have games from other companies, only from themselves.

You are right that Steam's policy is to not offer refunds, and that is a horrible policy IMO, because you may buy a game, but your computer may not run it (if you're on the border of required hardware for example). But ease of use and deep discounts probably are more important than the refund issue for most honest customers (those who aren't interested in finishing game in under 7 days and returning it). Android offers two hour refund policy, which I think would be good.

In my opinion it's hard to compare a store such as Steam to a publisher such as EA. Even comparing Steam to EA's store, I don't think EA's store offers games from other publishers, so it's still hard to compare. This means Steam has far more games offered, some with deep discounts.

<comment><USER2> Also, to add, Steam doesn't check system requirements to even suggest that the game may not run on the PC. I had received a beta invitation and downloaded the game, before finding out it's 64 bit, sadly my PC still has 32 bit OS.

</comment></comment><comment><USER3> I think the problem is with the Australian case (I am Australian FWIW) is that typically these consumer laws apply to physical goods, and it works quite well in that domain.

If your fridge breaks in a short amount of time, say 6 months after you bought it, you are entitled to receive a refund or replacement, as long as you can prove your purchase (this doesn't necessarily require a receipt). There is an acceptable amount of time that a product should last that is covered.

This is much harder to assess with non-physical items, because they may be released broken, later broken by the devs, or in perfectly working condition, and depending on the situation it is essentially impossible for the vendor to assess whether it's the fault of the dev, the customer's hardware, or the customer just wants their money back because they finished the title.

FWIW I love the Australian consumer laws, I think they are extremely beneficial to the general public and they put the onus on companies to produce and stock well-produced goods and services. I'm just not sure how to appropriately apply this to the non-physical goods market.

</comment><comment><USER4> Did they "refund" on your card or just refund your EA wallet when you can only puchase EA stuff?

Also some people said that a videogame can be finished under 7 days with ease, however EA games aren't that kind imo.

<comment><AUTHOR> Some games can be finished in 5. I am thinking of even a 10-15 minute grace period.

I buy a lot of stuff on Steam for Dota 2 (cosmetics to support Valve). I usually just spam "next" and get it over with. Yesterday, I had to purchase a game for a friend and I forgot to tick the "Gift" checkbox.

Valve don't give a shit, no replies.

</comment></comment><comment><USER5> Yeah, since DRM makes it simple to disable refunded games there's really no good reason to disallow refunds. 7 days might be too long since many games can be finished in that time.

</comment><comment><USER6> Steam is well known to allow one refund per customer with close to "no questions asked" before cracking down.

<comment><AUTHOR> I wasnt able to do this..

</comment></comment><comment><USER7> love steam, but really want to be able to transfer games to friends. back in the day of cd/dvd games, u could actually pass games u dont play to others..

<comment><AUTHOR> Trading functionality would be nice.. Or even, convert your game to gift and send to a friend functionality.</comment></comment>


Enpass Password Manager - <AUTHOR> http://enpass.io/ <comment><USER2> The built-in password generation tool looks awesome. I'm curious though for people that do: why do you use tools like this for credit cards and other non- password information? Seems to me that all that information already lives in places where they are used: paper documents waiting for paper forms or in- person verification, credit cards saved in the sites they are used for...

or maybe I just answered my own question, why leave credit cards on sites anymore and risk it when you can always carry the info securely with you?...hmm.

</comment><comment><USER3> Cross-platform. Stays on my own device, or cloud sync (if I want). Nice looking. Good OS support. What's the catch?!

edit: password import is supported, haven't checked if export is yet.

<comment><USER4> "Pay once, use forever. No monthly or yearly subscription is required to use Enpass. You just need to upgrade the trial version only once for life time usage."

I don't see any pricing listed, if it is, it's not obvious. Wish services would stop hiding prices.

<comment><USER5> The mobile apps are $9.99

</comment></comment></comment><comment><USER6> Anyone use this? I've been looking for a suitable replacement for my current password manager ([http://timothyjc.blogspot.com/2010/12/wallet-for- android.htm...](http://timothyjc.blogspot.com/2010/12/wallet-for- android.html)) that is universally supported...

</comment><comment><USER7> Oh man,i've been using safeincloud till now, i'm going to try this for the simple fact that they also support linux :) I've been wanting ubuntu support for a while now!

</comment><comment><USER8> this just looks like a neater LastPass (or am I missing something?)</comment>


Ask HN: Distributed consulting agency, advice? - <AUTHOR> Hi, i start to create a platform where people can create their own team (inviting friends) for consulting project. My idea is create a web/mobile place with a lot of "teams" skilled in their things and if someone want to do something can search a great team (created by trusted people, in my team i want the best developer that i know) for doing that thing. I want to do this just because freelancer.com sucks and i want extra job for my free time to earn something more. Essentially is a team showcase and anybody can create your own "consultant agency" to work at home :)
do you think it makes sense?
Thanks guys <comment><USER2> The challenges I see:

1\. Vetting. Who vouches for the quality of each team?

2\. Market making. Who insures that most teams find work and that most people looking for a team find one?

These are typical of two sided market places and harder for a narrowly targeted marketplace than for a broadly targeted one -- how different is a consulting team marketplace from Ebay?

The existing sites have not died because they solved the two problems and the ways in which they suck mostly reflect how they solved those problems, e.g. low rates solves the market maker problem so long as some consultants will work at those rates.

Good luck.

<comment><AUTHOR> exactly! those are the main problems but what is in my mind is that this platform will serve to all those who want something "small" and cheap.

If i'm bank i will go definitely to ask the greatest but if you are a small business that does not want to spend too much should rely on small consulting firms for which they would pay more than 4 friends in his freetime (or if they can as full time job ) make this type of service.

A team of people who can work from home already take off their office costs :)

The quality of the team is at the discretion of the person who wants to rely on them (if I buy a XXX software company who guarantees me quality?).

Many would like to create their own company but few do because we are too high costs initials, here there are no costs, and if you're lucky someone entrusts :)

I guess the review team on clients, portfolio of various projects etc .. Also I imagine that if it spreads the same consulting firms iscrivino their team :)

It 'just a bad idea? :(

<comment><USER2> It's not a bad idea. It's a hard problem that hinges on several issues:

1\. Trust.

2\. Liquidity.

If the buyer and the seller both have to perform full due diligence before the transaction, there is little advantage to using the platform except for buyers and sellers who are already able and willing to perform due diligence.

If there is a low probability that a buyer will find what they are looking for there is a low probability that they will use the platform. If there is a low probability that buyers will use the platform, there is a low probability that sellers will sell on it. For sellers, the time and effort that goes into creating a presence is probably better spent on a platform more likely to produce sales...such as an owned website.

To put it another way, the challenges for the project as _a business_ are not technical. The challenges are overcoming the adverse economic incentives and alternative approaches by the parties. The existing platforms that we have all heard about have overcome those challenges and part of 'what sucks' about them is due to what is required to overcome them.

<comment><AUTHOR> makes sense! But, this platform is "completely" free. Can be the website of the team. I have a lot of people that asking on linkedin if i'm available for doing something. I think that if this platform is free (maybe you can pay for better placement of your "team" or for premium features) is amazing for all.

I mean, if a create a team with my 3 best developer and 1 designer can be an amazing team!

<comment><USER2> I am probably imagining something different from what you have in mind. An implementation might be a good way to communicate your vision. An implementation might also be a way to test your hypotheses about the utility of the platform.

</comment></comment></comment></comment></comment><comment><USER3> I would like access to a sql like query interface( with an api) to a global database of people with:

interests,

skills(with skill level and experience level), portfolio uploads,

links to websites(with links like worked on,designed, own etc.),

Geo location(general then shareable for specific details)

and a way to contact and types of opportunities they're open to.

on the flip side maybe a list of queries(skills they search for) associated with someone.

<comment><AUTHOR> sorry but i don't understand your comment. its a advice or what you need?

<comment><USER3> my idea of the ideal product for a marketplace for skilled workers.</comment></comment></comment>


5 Revolutionary Announcements Apple Could Have Made - <AUTHOR> http://www.wired.com/underwire/2012/09/alt-text-5-revolutionary-theoretical-apple-announcements/

<comment><AUTHOR> Or, to put it another way, the iPhone is now pretty much as good as it can be made, with current technology. There will not be another revolution in the next few years that matches the feeling you had when you first played with one.</comment>


The great American tax haven: why the super-rich love South Dakota - <AUTHOR> https://www.theguardian.com/world/2019/nov/14/the-great-american-tax-haven-why-the-super-rich-love-south-dakota-trust-laws <comment><USER2> >a South Dakotan trust protects assets from civil suits, ex spouses, ex business partners

Wow, that's actually crazy. I know dozens of people who have been sued in this way and have lost a ridiculous amount of money. 60% of Americans get divorced. This South Dakota thing is a feature for some and a bug for others.</comment>


Why do people hate CrossFit? - <AUTHOR> https://medium.com/i-m-h-o/6d606a0b7d31 <comment><USER2> I'm sorry, but this is is the biggest list of strawman arguments I've ever seen. People dislike CrossFit because elite CrossFitters are _perfect physical human specimens_ and they're jealous? Huh?

Here are the real concerns with CrossFit:

1\. Incredibly poor quality control across affiliates means that a lot of instructors are not well trained in teaching how to do mechanically complex lifts to participants that have never done them before.

2\. Which leads directly to increased rates of injury amongst participants trying to perform too many reps of the same exercise using too much weight causing their form to break down because their instructors are not paying attention to them. The culture of CrossFit exacerbates this by encouraging you to push yourself beyond your limits...and potentially beyond what is safe.

Now, if you luck out and end up at a good CrossFit gym with good instructors you might not ever experience these problems. But that's the issue. How do you, as an untrained athlete that has never done a power clean before, determine whether or not the instructors at your gym know how to properly teach them?

</comment><comment><USER3> I'd argue people don't hate CrossFit, they hate CrossFitters.

I don't hate Triathlon, I hate triathletes, I don't hate Apple, I hate Appholes (or fanbois or whatever you want to call them).

I've done Crossfit for about 8 months, it got me through a 3-day 4 stage mountain bike race when I hadn't been on a bike in a year. I truly feel there is no way I would have survived had I not built up my strength and endurance, and for me, Crossfit was just the ticket for that.

HOWEVER, I am always concerned when people identify so strongly with a brand/experience and feel the need to push it on everybody they meet. I've seen triathlon take over a guys life to the point where his wife left him, and took the kids (I think he may have lost his job too, but it was long ago, and I can't remember). All because it was so important to him to identify himself as an IronMan.

I've done Ironman, it was an ok event, far from the hardest thing I've done in my life, but you know what I couldn't stand about Ironman? The people. People who spent every waking moment trying to figure out how they could save 30 seconds on their time so that .... well, exactly, there is no point to it. But they'd go spend hours and hours on end trying to "improve themselves". But what are they really improving?

Now, Crossfit is a different animal, but for many people, it is still this addictive "I can be a better Crossfitter, I can be more competitive against other Crossfitters, I can talk about how much protein vs carbs I take in and how that affects my..." It's inane, it's boring, it's egotistical.

Did you regularly talk about how much you were lifting at the gym before? How many reps you could eke out at x amount of weight. If you did, that was pretty damn boring too!

There are lots of interesting things in the world, your gym habit isn't one of them.

So, put down the ego, and build something, this is HackerNews, not... well, something that none of us care about.

</comment><comment><USER4> Videos like this are why people dislike crossfit: [http://www.youtube.com/watch?v=M8up6A4QesU](http://www.youtube.com/watch?v=M8up6A4QesU)

Crossfit is just a very successful gimmick, but unlike the fad diets that are unlikely to cause harm, crossfit is likely to cause inexperienced people serious injury. The cult-like devotion they build in their participants, mixed with the bro-science they preach just adds fuel to the fire.

</comment><comment><USER5> The essential defense here is that Crossfit is just a workout, so there shouldn't be anything to hate. Which raises the question, if it's just a workout, why does it need hundreds of words defending it?

</comment><comment><USER6> Because they had a bad experience. It's as simple as that.</comment>


Tic-Tac-Toe Implemented in Single Call to Printf() - <AUTHOR> https://hackaday.com/2020/06/05/tic-tac-toe-implemented-in-single-call-to-printf/ <comment><USER2> The author originally wrote a paper provin that printf is Turing Complete [0].

Here is program itself and an actual, excellent write up [1].

@dang, you might consider switching the link to the GitHub. I don't think the Hackaday article actually adds anything new.

[0]: [https://www.usenix.org/system/files/conference/usenixsecurit...](https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper- carlini.pdf)

[1]: [https://github.com/carlini/printf-tac- toe](https://github.com/carlini/printf-tac-toe)

</comment><comment><USER3> There's a scanf in there...

</comment><comment><USER4> Note that the #define statements spell "noughts and crosses" when read vertically.

It's the little touches.</comment>


Burnout vs. Major Depressive Disorder (2014) - <AUTHOR> http://www.academia.edu/9672192/Burnout_vs._MDD_Major_Depressive_Disorder_differential_analysis_for_diagnosis_and_therapy_using_15_differential_symptoms <comment><USER2> So many things wrong with this (beyond the typos, misstatements of science, and so forth) it's hard to know where to begin.

Here's a simple algorithm: if you feel lousy (=sad, flat/unmotivated, fatigued, anxious) for at least a couple of weeks AND these symptoms are interfering with your life/causing you to change your behavior, OR you're having thoughts of death/suicide, talk to a professional. Could be an MD/RN or psychologist or social worker.

Thought experiment: you do some sort of asinine questionnaire like this one and it says you're experiencing burnout. You would... try to make changes AND seek treatment if needed. Conversely, it says you're experiencing depression. You would... try to make changes AND seek treatment if needed.

Sorry to be cranky, but this stuff presses my (professional) buttons.

<comment><USER3> Sounds like a great idea but when you feel that crappy it's going to be almost impossible to arrange that. The last time I was seriously depressed I actually managed to call a few places, soonest anyone could see me was like three months out. I just ended up drinking very heavily, fortunately that seemed to work.

</comment></comment><comment><USER4> I hope #2 meant to say "shift of environment" and not "shit of environment." Although, sometimes I look around when feeling burnt out and can't help but feel my environment is just that!

</comment><comment><USER5> The terrible grammar, spelling, and proofreading do not give me all that much confidence in the writer.

<comment><USER6> Everyone likes to say things like this, but is there actually data to back out up? Also, do you really need to have confidence in a writer? Shouldn't the arguments be able to stand for themselves?

<comment><USER7> The logic behind it is that if you've done a sloppy job with the presentation of your arguments, it becomes likelier that you've also cut corners during the research phase. It's not about the quality of the prose, but about the lack of effort for something so easily fixable (a software spellchecker will catch the most egregious mistakes).

I'm not aware of any hard data on the matter, but as you say, it seems like most people are concerned by this and yet the author did nothing about it, further cementing the careless attitude.

To be perfectly clear, my comment is a generalisation to answer your point, not a critique of this particular author or their work (I haven't read it).

</comment></comment></comment><comment><USER8> Ugh. Anyone want to post a PDF link, as opposed to the "give us your account handles so we know who's downloading this" technique?

<comment><USER9> [https://web.archive.org/web/20170811212743/http://www.burnou...](https://web.archive.org/web/20170811212743/http://www.burnout.nl/docs/differential- analysis-burnout-mdd-depression-symptoms-v2.pdf)

</comment></comment><comment><USER10> This article is so outrageous. These "categories" show such a limited and misinformed understanding about humans, which definitely does not take into account scientific literature. This makes me angry also, because it is articles like these make people wary of seeking help when they need it (rightfully, there ARE so many bad therapists and bad information out there).

If anyone wants to have an informed conversation with me about these topics, DM me on twitter @AzimuthPsych. Happy to provide useful and evidence based information.</comment>


Jaguar-Land Rover develops shape-shifting seats - <AUTHOR> https://www.dailymail.co.uk/sciencetech/article-7895207/Jaguar-Land-Rover-unveils-shape-shifting-car-seat-makes-brain-think-walking.html <comment><AUTHOR> The new seat design simulates the rhythm of walking - a movement known as pelvic oscillation to reduce the discomfort of sitting for too long in one place.</comment>


Counter Service Tipping: Who Gives? - <AUTHOR> https://www.nytimes.com/2019/09/15/travel/ipad-tipping-gratuity.html <comment><USER2> I'm all for it, as long as the options are reasonable, which means the lowest option should be 10%. It's annoying when the lowest option is configured to something like 18%. Generally, I'll tip 10% on to-go orders, 15% on counter service, and 20% for table service. Sometimes I feel charitable and tip $1 on a $3.50 coffee. Tipping helps subsidize low wages and I think it should be more adopted on the Internet (see my handle dot com).

</comment><comment><USER3> [https://news.ycombinator.com/item?id=20987429](https://news.ycombinator.com/item?id=20987429)</comment>


Planning to Go Down, HTTP Edition - <AUTHOR> http://blog.tedivm.com/rants/2014/01/planning-to-go-down-http-edition/

<comment><AUTHOR> Author here. I wrote this to elaborate on a comment I made here ( [https://news.ycombinator.com/item?id=7015508](https://news.ycombinator.com/item?id=7015508) ) about the best way to keep things running smoothly in the event of downtime. Preparing for downtime in advance can really make life a hell of a lot easier.</comment>


Announcing OmniAuth: Flexible, Unassuming Multi-Provider Authentication for Rack - <AUTHOR> http://intridea.com/2010/10/4/omniauth-flexible-authentication-for-rack

<comment><USER2> So the library is aggregating all the different authentication methods by the different providers and providing a single interface. This is pretty cool and should save a lot of time.

I've been working in the authentication/authorization space for a quite a while and the decision to hand off authentication to third parties can be a difficult decision. For social media applications it is ideal. But not everyone makes social media apps. There are lots of enterprise apps with valuable data behind them that would do well in keeping authentication tightly behind their own doors and guarding it closely.

There are issues that multi-provider authentication hasn't even touched that I feel are important if it is to gain more traction. I disagree that the 'sign up using a login and password' model is becoming the exception. I think it is nice to offer it but sometimes I like to keep my logins in separate spheres.

</comment><comment><USER3> We're using OmniAuth and it works wonderfully. It beats dealing with JanRain/Gigya for a single signon solution.</comment>


Startup Quote: David Karp, founder, Tumblr - <AUTHOR> http://startupquote.com/post/2129022765

<comment><AUTHOR> The more people we have on our team, the less room there is in the elevator and the more complicated everything gets.

\- David Karp (@davidkarp)

<http://startupquote.com/post/2129022765>

</comment><comment><USER2> I bet that he'd add the following today: "And the less downtime we'd experience."</comment>


Charlize Theron Negotiated a $10MM Paycheck After Sony Hack Revealed Unequal Pay - <AUTHOR> http://www.businessinsider.com/charlize-theron-10-million-huntsman-paycheck-2015-1

<comment><USER2> Hey, North Korea gets a point for women's rights!</comment>


Smallest Pc in the world | Gadget and Teknologi - <AUTHOR> http://serly.info/2010/04/smallest-pc-in-the-world/ <comment><USER2> Interesting find, the site linked from the article to the manufacturer, in turn links to this, a high speed link called 'spacewire':

<http://spacewire.esa.int/content/Home/HomeIntro.php>

Apparently that tiny cube has two of those links on board.

Much more info:

<http://en.wikipedia.org/wiki/SpaceCube>

[http://www.techeblog.com/index.php/tech-gadget/tiny-space- cu...](http://www.techeblog.com/index.php/tech-gadget/tiny-space-cube-pc)

[http://www.pcpro.co.uk/blogs/2008/07/03/introducing-the- spac...](http://www.pcpro.co.uk/blogs/2008/07/03/introducing-the-space-cube/)

The images are from 2006, so this thingy is not quite new. Has anybody seen them 'in the wild' ?</comment>


Apple Pay and iOS App Store under formal antitrust probe in Europe - <AUTHOR> https://techcrunch.com/2020/06/16/apple-pay-and-ios-app-store-under-formal-antitrust-probe-in-europe/ <comment><USER2> I'm somewhat conflicted: I can appreciate Apple wanting to make sure that apps on their platform perform and behave to their standards but it _is_ rather obnoxious that an app on their platform MUST use their payment system (and pay them a 30% cut) as well as being prohibited from accessing certain features like NFC. I could understand enhanced review -- even a higher price to justify the closer collaboration with Apple engineers -- for payment app makers who want to use NFC but to disallow it altogether crosses the line into anti- competitive behavior. I think Apple deserves to lose this one.

<comment><USER3> I'm on the fence regarding if they should win or lose this, but I'm glad the probe is happening.

</comment></comment><comment><USER4> [https://news.ycombinator.com/item?id=23537636](https://news.ycombinator.com/item?id=23537636)</comment>


Coursera courses on Android app - <AUTHOR> https://play.google.com/store/apps/details?id=org.coursera.android No more need to be on your laptop to get Coursera course... Awesome <comment><AUTHOR> No more need to be on your laptop to watch coursera courses... This is awesome</comment>


Sunyata - <AUTHOR> http://arram.posterous.com/sunyata

<comment><USER2> Nice Arram, thanks. I was just thinking the other day about how nice it would be if more people spent time once in a while refining their thoughts into an essay rather than barfing up conjectures as blog posts.

Interestingly, it may be that Heisenberg uncertainly requires that if you extract all of the information out of Riker in order to reform him, you must necessarily destroy the original Riker, saving you a bullet. (IANAP, _obviously_).

<comment><AUTHOR> Agreed that you couldn't actually get a _perfect_ copy (e.g. exchanging accuracy in momentum information for accuracy in position information), but it really doesn't matter. You change on a more dramatic scale when you go from a cold room to a warm room, or when you scrape your elbow, etc. Details at that scale are pretty irrelevant to _you_.

<comment><USER3> _Details at that scale are pretty irrelevant to you._

Sorry, but [citation needed]. Penrose, for one, thinks details on that scale are the _essence_ of you.

<comment><AUTHOR> You're talking about his quantum tubules theory of consciousness. Honestly, I think it's coming from the same emotional agenda that made Geocentrism and later Vitalism so popular. It's just the latest philosophical secret sauce.

Besides, that's just trying to explain qualia. Pretty sure no one thinks memories are quantum phenomena.

<comment><USER3> Actually Penrose isn't so much interested in qualia as he is in things mathematicians can do, but which Turing machines cannot (from <http://en.wikipedia.org/wiki/Quantum_mind> \- "Penrose is not interested in explaining phenomenal consciousness, qualia, generally regarded as the most mysterious feature of consciousness, but instead focuses mainly on the cognitive powers of mathematicians").

<comment><USER4> If I have closed timelike curves, an oracle for the halting problem, or the ability to perform arbitrary computations on real numbers in my brain, I would certainly like to know how to use them.

</comment></comment></comment></comment></comment></comment><comment><USER5> For those of you who haven't seen it, the movie _The Prestige_ (IMDB: <http://www.imdb.com/title/tt0482571/>) deals with this topic of transient existence of people, albeit in the context of magicians and science. It's a _very_ good movie, to boot.

<comment><AUTHOR> Yea, I was excited when I first saw that movie. The main character completely failed to understand what was going on: "Would I be the one transported, or the one in the tank?" He was both, but the selection bias of being able to ask that question would make him seem very lucky.

<comment><USER6> <http://en.wikipedia.org/wiki/Quantum_suicide_and_immortality>

</comment></comment></comment><comment><USER7> "Some say our memories are what make us us, but basic physics dictate that our memory has finite capacity. New memories supplant the old and the strongest are those recalled and refreshed frequently. Given a thousand years to live, you could conceivably forget everything you now know. Personal history is a revolving door."

Some people have a weird condition where they remember EVERYTHING from a certain point in their lives, they never forget anything. I'm sure they have a _finite_ amount of memory, but it's so big it's infinite _in practice_.

</comment><comment><USER8> Identity is indeed elusive. I tend to think of myself as a process too, i.e. a braid of selfupdating information embedded in space-time (did that make any sense? (-: ).

What puzzles me the most is the permanence of identity despite the siscontinuity of the conscious experience. Why and how am I still the same person in the morning than I was when I fell asleep?

One could argue that the abundant neural activity that happens during the night preservres yourself...

What about deep phenobarbital-induced general anesthesia, which induces a flat EEG? No more neural activity... Your self is preserved through the "structural" properties of your brain.

Which leads me to another point: the structure/function distinction is a false dichotomy, an artefact of the human thinking process. The concept isn't new for the many Lisp hackers around here, but the idea can be extended to the organisation of the universe. The (neuro)psychologist's structure is the neurologist's function. Recurse up to elementary particles whose dual wave/particle nature has been extensively documented.

Physics will not be complete until the nature of subjectivity is understood. It may never be complete, for that matter.

</comment><comment><USER9> Reminds me of Feynman's "The Value of Science" speech:

"For instance, the scientific article says, perhaps, something like this: "The radioactive phosphorus content of the cerebrum of the rat decreases to one- half in a period of two weeks." Now, what does that mean?

"It means that phosphorus that is in the brain of a rat (and also in mine, and yours) is not the same phosphorus as it was two weeks ago, but that all of the atoms that are in the brain are being replaced, and the ones that were there before have gone away.

"So what is this mind, what are these atoms with consciousness? Last week's potatoes! That is what now can remember what was going on in my mind a year ago -- a mind which has long ago been replaced.

"This is what it means when one discovers how long it takes for the atoms of the brain to be replaced by other atoms, to note that the thing which I call my individuality is only a pattern or dance. The atoms come into my brain, dance a dance, then go out; always new atoms but always doing the same dance, remembering what the dance was yesterday."

</comment><comment><USER10> If you're looking for a good introductory book to some of the buddhist/taoist/zen concepts touched upon in this article, I highly recommend Alan Watts' books.

Here's one that I've particularly enjoyed:

[http://www.amazon.co.uk/Eastern-Wisdom-Modern-Life- Collected...](http://www.amazon.co.uk/Eastern-Wisdom-Modern-Life- Collected/dp/1577311809/ref=sr_1_1?ie=UTF8&s=books&qid=1268337707&sr=8-1)

It's a collection of lectures that he gave over a decade or so, in the 60s. It introduces most of the really important concepts of eastern philosophy.

This book provides a nice follow-up to the previous one, with a much more complete, detailed, academic view of the topics, which helps gain a better understanding of it all:

[http://www.amazon.co.uk/Way-Zen-Vintage-Spiritual- Classics/d...](http://www.amazon.co.uk/Way-Zen-Vintage-Spiritual- Classics/dp/0375705104/ref=sr_1_3?ie=UTF8&s=books&qid=1268337772&sr=8-3)

<comment><USER11> The OP presents a conceptual, ontological claim ("...that all things lack absolute identity and are interdependent."), whereas in Buddhist practice, it refers to the _experience_ of looking for some inherent existence, and seeing nothing. It's not an ontological issue in that context: There could actually be an absolute identity, but it would have no bearing on the practice.

Alan Watts only ever confused me. These two guys made it a whole lot clearer for me. (Particularly Ken. I consider him my teacher.)

<http://unfetteredmind.org/audio/podclass.php?code=AP#here>

</comment></comment><comment><USER12> Really interesting article. Sunyata makes me think of string theory for some reason. To give another perspective on 'we are not matter', we can view ourselves as a configuration of atoms.

And if you zoom in more, those atoms (carbon, hydrogen etc.) are just different configurations of electrons, protons and neutrons.

At the end of the day, string theory zooms in even more and says that those particles are made of just one thing - a 'string'. And the different particles are manifestations of strings vibrating w/ different energies and patterns (like how a musical instrument makes different notes w/ different vibrations).

That idea paints the universe as as one grand orchestra. Each string not really different from the next (fungibility) and somewhat interdependent. In short, Sunyata.

<comment><USER13> We're a wave function, always in motion and never deterministic. We are a verb!

</comment></comment><comment><USER14> This sort of question about the difference between a copy of you continuing to exist, and you yourself (the original "copy") continuing to exist; whenever I see this question in its various forms, I wonder if the question is being truly sincerely asked.

The obvious and meaningful answer is that the experience _you_ have is of the total end of all further experience. Death. One or even a thousand completely perfect copies of you living onward in the universe is no comfort when the consciousness that started the whole game is not around to experience it.

Or in more simple form,

If you put someone to sleep, and haul them across a room, and then they wake up, this is totally different from writing down their entire molecuar composition, burning their atoms to a cinder, and then reconstituting said molecular composition on the other side of the room. What wakes up is not you. You are a burnt ash in the wastebin.

The truly fascinating question no one is discussing is: since our consciousness is made up of a vast combination of distinct physical parts, it could one day be possible to slowly replace those parts with artificial parts, with the transition from 100% original to 100% new parts being a transition in phases so small that the consciousness is never interrupted. The resulting being is YOU, but at the end, all of what was you is gone.

Addendum: People who have suffered severe trauma and lost large sections of the brain have managed to live. If the substrate of the mind in question was an artificial system that can deal with such traumatic removals of core pieces, is there some cross section of the constituent parts of the human mind that you could sever in half and end up with two distinct yet continuously conscious entities?

</comment><comment><USER15> How about this: with every breath, you inhale a million billion billion atoms of oxygen. When you exhale, these atoms take a couple of years to be uniformly mixed in the atmosphere. Chances are you a breathing oxygen that was once in the lungs of, say, Shakespeare! (though, also, in dog farts). Before that, this same oxygen was created by fusion in the inside of a star, which died so we could live.

</comment><comment><USER16> This article made me think of this :

" You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else. "

</comment><comment><USER17> The observation that boundaries of things are arbitrary is also important to materialist dialectics. Quote Leon Trotsky: "In reality a pound of sugar is never equal to a pound of sugar—a more delicate scale always discloses a difference. Again one can object: but a pound of sugar is equal to itself. Neither is this true—all bodies change uninterruptedly in size, weight, colour, etc. They are never equal to themselves."

</comment><comment><USER6> <http://en.wikipedia.org/wiki/Ship_of_Theseus>

<http://en.wikipedia.org/wiki/Identity_and_change>

</comment><comment><USER18> FYI, folks: 'Shoon-yuh-thaah', not 'piñata'.

.

</comment><comment><USER19> Your cells are new every 10 years. [Citation Needed]

<comment><USER8> ... with the notable exception of (most) of your neurons. The only exception happens in the hippocampus which is involved in long term memory.

(As a side note, a reduced turnover of these neurons is associated with depression, but I don't know what's the cause and what's the consequence.)

Some cells have a much higher turnover(almost daily). I think of the immune system and of some epithelial cells (especially in the digestive tract).

Your ten years figure seems to be a reasonable median, but I don't have any data to back it up either.

</comment></comment><comment><USER20> Very nicely put, thanks for sharing</comment>


Ask HN: Any startup interested by a junior intern ? - <AUTHOR>

I'm a junior looking for an internship in the US. Apparenlty, the big players only take grad students, so I was wondering if there's a startup there who'd like to hire a summer intern ?<p>I know well python, scheme, C and unix <comment><USER3> where are you located?

<comment><AUTHOR> i'm in paris, france

<comment><USER3> Is your intention to come to the states or build experience?

<comment><AUTHOR> i'd like to build experience, and I have to spend two months abroad - <USER2> particularly in the us.

<comment><USER3> email me donna (at) genuus (dot) com

</comment></comment></comment></comment></comment><comment><USER4> lets talk.

my gmail account is fbbwsa@</comment>


Engaging New Hires - <AUTHOR> https://hadalin.me/blog/engaging-new-hires <comment><USER2> Interesting suggestion. Have you put any of this into practice? Do you have any observations, learnings, or things to watch out for to share as to how this goes in practice?

<comment><AUTHOR> It happened to me actually about three years ago, but I don't think the CTO did it intentionally. I just remember the impact it had and that it made a lot of sense.</comment></comment>


A working scale model Cray-1A - <AUTHOR> http://chrisfenton.com/homebrew-cray-1a/

<comment><USER2> I remember seeing this about 9 months ago: <http://news.ycombinator.com/item?id=1645291>

I think at that point, it was still only 33MHz (he now has it running up to 50MHz), it sounds like he's also got a slightly more mature software toolchain now. Oh, and he's added a link to a DOS-compatible Cray simulator, for anyone who wants to play along at home without getting involved with the hardware side.</comment>


Transparent Privacy Control via Static Information Flow Analysis - <AUTHOR> http://research.microsoft.com/apps/pubs/default.aspx?id=152507

<comment><AUTHOR> I just thought it was kind of wild that not only does TouchDevelop now feature an app-store-within-an-app, but it has its own capability system that appears fancier than the one in the phone app store itself (or any other that I've seen).</comment>


Telegram's statement on "massive" hacker attack on Telegram in Iran - <AUTHOR> https://telegram.org/blog/15million-reuters <comment><USER2> Can't understand how a "very" secure app considers this an acceptable part of the threat model.</comment>


Gall's Law - <AUTHOR> http://en.wikipedia.org/wiki/Gall%27s_law

<comment><USER2> Gall's book (Systemantics) is a brilliant and whimsical classic about the unpredictable nature of complex systems. It deserves to be far better known.

<comment><USER3> I just finished reading it. Even though it's tongue in cheek humorous in some places, it's a must read for anyone who deals with systems (programmers/engineers/politicos/the average citizen).

One of the hardest things for a programmer to do is to NOT build a system. But sometimes (everytime?) the avoidance of a system (if possible) is the best option.

An example: Our company just implemented a huge ERP system from a well known vendor. As expected the problems we were trying to solve (resource management, etc) became secondary to keeping the system up and running. The system itself becomes the problem.

</comment></comment><comment><USER4> Simple and complex are relative terms. What a highly educated person anno 2009 would find simple might be complex to a uneducated person anno 1009.

Which implicates this "law" is also relative, making a more useful description: If you make something which seems complex to you, it will not work. Begin with something that is simple to you, and than evolve it in to something complex.

<comment><USER5> Brilliant point, and much more practical and useful than the law itself.

</comment></comment><comment><USER6> Summary: the law says "A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."

This is obviously closely related to Richard Gabriel's "Worse is Better", and the general philosophy of starting with a simple design, and iterating under the scrutiny of users.

</comment><comment><USER7> That "inverse proposition" is just the contrapositive: (a => b) <=> (¬b => ¬a).

The inverse proposition would be that if you take a simple system that works and evolve it into a complex system, the complex system will work.</comment>


Ask HN: How to sync background music to voice? - <AUTHOR> I am working on a side project where I am able to combine the voice from one music video to the background music of another video.
i.e Taylor Swift's voice from Last Christmas to the BGM of Van Halen's jump etc.
It is just not working. Are there any techniques to programmatically add the bgm appropriately?
Right now, I am thinking of reducing the BGM audio while the vocals are being played.
What is the right direction I need to take? <comment><USER2> If you use Spleeter you can isolate vocals and BGM. Maybe you are at that stage already. The problems you still need to solve, assuming you want them to blend aesthetically, is key and tempo. For this you will need to detect the key and tempo each part is in. Then you'll need to adjust the tempo and key from one or both parts to match. Even then you will still likely have a clash of structure where the verse and choruses don't match up or even worse structure dissimilarities. For this you need another neural net like Spleeter but trained to combine various structures of music, or of course you could do this part by hand.</comment>


Uber's Search for New C.E.O. Hampered by Deep Split on Board - <AUTHOR> https://www.nytimes.com/2017/07/30/technology/uber-search-for-new-ceo-kalanick-huffington-whitman.html?partner=rss&emc=rss <comment><USER2> More active discussion higher up on the front page:

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

</comment><comment><USER3> Reposting my comment, because I don't think enough ire has been directed at Uber's board...

Possibly the most incompetent board of directors in the past decade. Can't reign Travis in, couldn't avoid all of this by forcing Travis to get an adult COO like Sandberg, fire him after he takes a break to mourn his moms death. They should all resign as well. A boards job is to reign in the CEO's bad tendencies. Really what have any of them accomplished by being on the board? Is there anything they can point to? And on top of all of that, their busy leaking news instead of picking a CEO...

<comment><USER4> The issue was not that Travis or whoever would not be "adult". They were more adults then most of us. The issue was that they had low ethics, got what they wanted in any dirty way possible which brought them huge early success. The very same traits that brought them success are the ones that make it hard to get rid of him. Plus, the board is intentionally filled with people who are ok with people like Travis and companies doing whatever.

</comment></comment><comment><USER5> How irresponsible to get rid of the CEO of a company worth supposedly $70B with no idea who could replace him

</comment><comment><USER6> "On one side is Mr. Kalanick, who is plotting a comeback". One this phrase is enough to realize that Mike Isaacs is a Benchmark fanboy and he is expected to advance their side of the story, just as he did in the last months/years. Move on, no journalism here, just leaks and propaganda.

</comment><comment><USER7> I feel like this article could've been a third of its length, and was going to great lengths to fill space.</comment>


How selling Magic cards might land me in jail - <AUTHOR> http://www.reddit.com/r/magicTCG/comments/37tqqa/how_selling_magic_cards_might_land_me_in_jail/ <comment><USER2> "Jail"... of course.

Nothing in his story suggests jail, not even the tax evasion hinted at.

Certainly not the "Abmahnung" by a competitor. That's a civil matter.

Basically it's the same old story, as it happens with ebay a hundred times every day: guy thinks that he might get away with "selling privately", thus getting rid of consumer protection laws (that's the real issue here, not taxes, unlike all the speculation on reddit).

Commercial competitor - or sometimes the authorities - believe he's selling commercially.</comment>


How to Become a Technical HR Recruiter - <AUTHOR> http://www.stackoverflowcareers.com/blog/how-to-successfully-transition-from-a-general-to-technical-recruiter

<comment><USER2> What they don't seem to mention is how much of recruiting in general, and tech recruiting in particular, has devolved to low-wage, short term contract-based, easily outsourced, basically spam outfits. My ex is a 30 year tech recruiter and her and all her peers are having a miserable time of it.</comment>