TypeScript's quirks: How inconsistencies make the language more complex - <AUTHOR> https://blog.asana.com/2020/01/typescript-quirks <comment><USER2> These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminated unions where the code and objects look like what you'd do in vanilla JS, but checked (and requiring the class to have a specific structure seems fine as limitations go).

I get how folks coming from "natively" static type systems could find all this weird, but I think by targeting "JS but with better checks" instead of a more fundamental redesign, the TypeScript crew have managed to build something that can get traction where other efforts have not.

<comment><USER3> If you can pass a Cat to a Dog function, where is the better checking?

That would be one of the hello-world test cases for a type checker bolted on to a dynamic language.

That type checker itself has _introduced_ the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.

<comment><USER4> Note that you can only pass Cat to a Dog function if:

* All fields of Dog are also present in Cat, with compatible type signatures

* All functions of Dog are also present in Cat, with comaptible type signatures

"compatible type signatures" does seem to leave some suprising co/contravariance holes still when using wider union types, but C#/Java arrays also have co/contravariance holes and we don't automatically write off their entire type systems because of it. Or, well, at least I don't ;).

As a meaningless point of ancedata: Making these types sufficiently equivalent to fall through this type safety hole appears to be rare enough that I've never done so by accident - allowing me to be suprised by the article's example of passing a class Cat to a class Dog-accepting function being legal. While typescript has never been my primary dayjob, it's been a significant secondary part of my dayjob and hobby junk.

(EDIT: Minor clarifications)

<comment><USER5> Another example of a hole: [https://www.typescriptlang.org/v2/en/play#code/MYGwhgzhAECSB...](https://www.typescriptlang.org/v2/en/play#code/MYGwhgzhAECSB2wBOBTAti+AXFToG8AoaaAS0VQ2wAoAPALmngFc0AjXASkZfdwOIkyAM2jUsATwAOKAPaja0AIQBeFdADkvDkg2cBQoVgAWSWQHcmKSwFEkZpNQAGAEny0AvmRhhobyTLy0J4ANEyyWNC+2rhOnADcgiQehEnQqFjMSPDB0ADU0ACMicmEKYTkOEjCYMAo0ADKWEgIyOiYVQZkFO00DEysOtAAPtAQzeQA5twDfEiJ5cLMiFiksjnkbVRYdIzjSFNhm5QduIxNLT3bXDyD- EQkGVkbV6dIAHTHvTu0CWWpAHoAdA7A5GIUAEwAZm8UTGE3gkzC8AicJiSEIQOgTlaJ2wsWgABNZCgYCjIqQ0FIQN9ulUanVsRdcd9YoRgOsILIae8QLJJtQvttqBpIVCNMjrHBXvjHJx5fFoIQgA)

</comment></comment></comment></comment><comment><USER6> The following is purely anecdotally, my opinions is solely based on my personal experience with the language.

As someone who learned TypeScript just by using it and without any serious "study", I'll have to disagree the basic premise of the article.

I already knew about almost everything the article mentioned and nothing really seemed weird to me at the time.

The only point that I did not know about is type narrowing not working on nested objects, because that came up exactly 0 times in about 50k lines of TypeScript so far.

Half of the points made are actually TypeScript being _lenient_ (interfaces allowing excess properties, classes working like interfaces). In my book this makes the TS easier to work with, because it gets out of the way when it's not needed.

Classes essentially working like interfaces is probably a result of TS wanting to be backward compatible with JS, because when you enrich your existing JS lib with type information, TS can't know about your "classes" \- they're a runtime thing. Treating them the same as interfaces can make this much nicer.

It also allows 3rd party code to add extra properties to your new-instanciated object and using an interface to reflect the change, but still being able to pass it to stuff expecting the original thing. This way you can have type safety without losing JS features.

<comment><USER7> > TS can't know about your "classes" \- they're a runtime thing. Treating them > the same as interfaces can make this much nicer.

No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types.

> This way you can have type safety without losing JS features.

IMHO, you can't get type safety out of an unsound type system. (Which TypeScript is, by choice.) I think surprises like the above drive that point home.

<comment><USER8> TypeScript's goal isn't to be sound. Its goal is to be a balance between type- safety and effort. Full type safety would require a lot of runtime checks injected into the final JavaScript, which TypeScript intentionally avoids.

JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.

<comment><USER7> I understand that, which is why I said 'Which TypeScript is [unsound], by choice'.

Disagree that full type safety would require a lot of runtime checks. That's not the experience I've had in ReasonML.

<comment><USER9> ReasonML is exactly the kind of backwards incompatible change that would be necessary. You cannot mix reasonML and JavaScript freely together.

</comment></comment></comment></comment></comment><comment><USER10> This article makes me think about the "rust compile times are terrible" blog post from the other day.

If you spend a lot of time with a technology, day in and day out, you get intimately familiar with all of its shortcomings, and sometimes you maybe lose some perspective.

Having used Rust (enough to see its innovations and promise) and TypeScript (daily), I think they are incredible languages and platforms. Sure, they have shortcomings, but I think it's important to keep in perspective the huge advances in the state of the art they have brought us for these trade offs.

<comment><USER11> Nothing wrong with highlighting areas for improvement, though.

</comment></comment><comment><USER12> I don't agree with the article's claim that discriminated unions are just a JS compat feature. Many APIs type JSON serialised entities using a string property and this feature makes it very easy to write interfaces and code to work with them.

<comment><USER13> Author here! Yeah I think you are right that discriminated unions are useful more broadly than just legacy JS code.

That being said, I still think TypeScript's solution to handling them of using "type guards" where the type of a variable changes in different scopes is definitely designed to match common JS patterns at the cost of added complexity. Most other languages I know of only have a single type for a variable (and if you want to pattern match you must give each case a new variable name).

<comment><USER14> > Most other languages I know of only have a single type for a variable

This may be pedantic, but with subtyping many OO languages can give many different distinct types for a variable. In Java you can assign any non- primitive typed expression to a variable of type Object. So almost any expression in Java can be typed as Object.

What you are describing as novel is rather the phenomenon of type refinement in a pattern match or conditional expression. When an expression undergoes pattern matching, its type becomes increasingly refined. This is a useful feature in intermediate-to-advanced Haskell (known as GADT) as well as dependently typed languages.

<comment><USER13> > In Java you can assign any non-primitive typed expression to a variable of > type Object.

Sure, but if you do this in Java you must use different variable names for the reference of type Animal and the reference of type Object.

I think algebraic data types and type refinement are great, but I'm not a fan of automagically changing the types of variables in different scopes if it can't be applied consistently.

</comment></comment></comment></comment><comment><USER15> Typescript is great but it has its evils because it's a superset of JavaScript. I really hope we get a modern language like c# where the types are guaranteed compile + runtime and you can't any-ignore problems.

The more I use typescript I realize I want a more sound and stricter language. Like no prototype overriding at runtime.

<comment><USER16> Noooo! Go away with those ideas! JavaScript is great _because_ it's not strict. That's the flexibility that allows for speed.

I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don't want to go to the moon and back creating types for all this crap, I'll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return.

I want the flexibility to incur tech debt where I want to, I don't want the language to get in my way. That's what makes JavaScript great!

<comment><USER17> In strongly typed languages, there are serialization/deserialization libraries that don't require you to type the entire JSON object - just the fields you care about.

<comment><USER18> I'm not a very skilled Haskell programmer, but every time I've tried to parse JSON in it I've felt a strong urge to switch back to Python or JavaScript. There are libraries that make it easier but I think it's always going to be hardly to get started with JSON APIs in a language with a powerful and strict type system. Of course, that extra up-front effort might be worth it in the long run due to the benefits of type safety, but as the grandparent said, sometimes programmers need the freedom to incur technical debt.

<comment><USER7> Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/

<comment><USER18> I was trying to use Aeson, which as noted in this excellent tutorial [1] (which didn't exist when I first tried it) is "hopelessly magical for people who try to learn it by looking at provided examples, and existing tutorials don't help that much." The rest of the tutorial should give you some idea of why I say that parsing JSON in Haskell is complex, at least if you're used to doing it in JavaScript.

[1]: [https://artyom.me/aeson](https://artyom.me/aeson)

<comment><USER7> I'm interested in specifically what issues you had with JSON.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I still don't understand what pulls developers to Typescript. The examples given show major flaws in this (duck)type system. That it works when you don't use the 'any' type and when you know how to avoid all the edge cases and workarounds, I know. But when I see an example like this:

      const shasta = new Cat("Maine Coon")
      printDog(shasta)
      > Dog:Maine Coon

I see a huge red flag. Coming from C/C++ it looks like a joke. Why are all these front-end static type fanatics not more interested in Dart, Purescript, Elm, etc..?

<comment><USER20> It just means that structural types are the default and you need to opt in to nominal types, when necessary: [https://www.typescriptlang.org/play/?ssl=13&ssc=1&pln=13&pc=...](https://www.typescriptlang.org/play/?ssl=13&ssc=1&pln=13&pc=22#code/C4TwDgpgBAIg9gcygXigbwFBW1ARgJwggBMAuKAZ2HwEsA7BLHQgQ2LjoBsQoASUSOQCudGgEch0CiAC2uOJwwBfDBgHQAwi2Ap0TbASJlK1eoxxRW7Lj37gIw0RKmz5ilRgDGHKlE- byLR1UNDxCEnIAIhgAZQAJSKglKBYKKCCAbi8fHX9gACZA7V08rO86X3YEcngkVFKgA) (there are other ways as well)

In something like Java, it's the opposite: you get nominal types by default and you need to opt in to structural types (via interfaces).

Because TS is built on a duck typed language, tons of existing libraries would break if they had to declare explicit nominal types as arguments. Or you'd need to add custom interfaces for each library you use. Structural typing is what you want 99% of the time.

<comment><USER13> I think that Flow's approach of using nominal types for classes and structural for everything else makes more sense. Are there really cases you expect classes to be structural types?

<comment><USER21> Objects in OCaml are all structurally typed.

</comment></comment></comment></comment><comment><USER22> Being able to gradually introduce types into an existing code base seems like a poor reason to use unsound or quirky features in a language. I'd then much rather use a small and consistent language if I'm going to compile to js anyway, even if it's not useful as a migration path.

What seems like a good reason for accepting language design tradeoffs on the other hand is the package ecosystem. A language that doesn't work seamlessly with existing _third party_ js is probably doomed. It's not too difficult to write a tiny language that is nice and consistent and compiles to js, but few will use it if you need ffi to interact with js code. The impressive engineering effort in TS is all about these tradeoffs.

This is why I'm having a hard time loving TypeScript, it's a language for solving a real world problem (bringing types to the js ecosystem) in a pragmatic way, and that rubs me the wrong way. It acknowledges that js, js developers, and js packages are not going to going away any time soon.

</comment><comment><USER23> Ok since we have a lot of TS people here maybe someone can help me out.

Let's say I have a simple interface with a few fields. I want to make sure incoming JSON conforms to that interface.

I realize at runtime the interface isn't there, but is there some tool I can use to compile a utility to check JSON against an interface without having to write a duplicative JSONSchema or something else?

<comment><USER24> io-ts [1] is what I think most people use for this

1: [https://github.com/gcanti/io-ts](https://github.com/gcanti/io-ts)

<comment><USER8> Personally I dislike the fact that io-ts requires taking a pure functional programming approach to this validation. For most cases I just want to throw an error if something doesn't match up. My main use case for this is validating that my UI and backend API have the same ideas about the shape of the data, which will either _always_ work or _always_ fail. All errors should be caught during development and testing, so the "either" case will never realistically be hit in production.

Because of this I prefer runtypes [1], because it's much more simple to get my desired behavior. My only gripe is that errors aren't all that descriptive.

I guess I could write a function to pipe/fold into the type, throwing a descriptive error if something fails, but I like the simplicity of runtypes.

Edit: I just discovered io-ts ErrorReporter [2]. That's way better than my solution, and I'm considering switching now!

1: [https://github.com/pelotom/runtypes](https://github.com/pelotom/runtypes)

2: [https://github.com/gcanti/io- ts/blob/master/src/ThrowReporte...](https://github.com/gcanti/io- ts/blob/master/src/ThrowReporter.ts)

<comment><USER25> We wrote a bunch of utility methods around io-ts at work with custom error reporting/handling, otherwise it can indeed feel a bit too fp-/boilerplate- heavy for your every day frontend development, especially in combination with other stuff such as rxjs/redux.

But once you have those set up, it's an easy breeze, and the benefits are enormous. Our helper-method with the hopefully self-explanatory name "validateOrThrow<T>(t:TypeGuardForT)" is essentially called at every point where there is some form of incoming external data, and the amount of debugging-headaches that have simply disappeared because of this is mind- blowing.

</comment></comment></comment></comment><comment><USER26> Let me be honest, but this article is just horrible. The whole article is for the sake of complaining (though I prefer to call this "nitpicking").

> 1\. Interfaces with excess properties

... in immediate objects, which will never be reused. This is nothing worse than golang emitting errors on every single unused variable. There are good reasons to behaviours like this, even though not always preferable.

> 2\. Classes (nominal typing)

It seems like the author straight rejects the idea of structural typing itself, by calling the concept itself a "quirk". This is rather about preference, not right-and-wrong. If this point is to be true, one should also reject duck typing, many other popular dynamic languages, a large portion of software industry, scientific researches, etc. Good luck with that.

> 3\. Discriminated Unions

While I do agree that it's a shortfall of TS type system, the example is simply unrealistic. Using composite values as type discriminator is a bad design. Plus, the compiler is not even allowing anything destructive nor bug- prone.

<comment><USER27> I don't want to go into detail, but everything the author said is true. These are real quirks, that aren't explained correctly in the documentation.

They are all justified, and the author acknowledges this, but nevertheless surprising.

</comment></comment><comment><USER28> After using TypeScript for the past couple of years, I've come to see it as simply another "embrace and extend" maneuver by Microsoft carve off a chunk of JavaScript mindshare, preying upon the naïveté of less-experienced developers who've fallen for the "static typing is safer" myth. TypeScript's decision to disallow JSDoc within .ts files [1] for example doesn't contribute anything positive to my impression of this syntactic pocket-protector. While the type hinting it provides is useful, the tradeoffs of added complexity, tool dependencies, and cross-compiling phase have made it more trouble than its worth in my opinion, particularly since tooling to provide code introspection and type hinting has already existed for a long time [2]. For new projects, I've begun using straight JSDoc, which is working beautifully with minimal setup [3] and provides all of the benefits I ever found useful about TypeScript, while remaining completely unobtrusive otherwise[4].

1\. [https://github.com/microsoft/TypeScript/issues/20774](https://github.com/microsoft/TypeScript/issues/20774)

2\. [https://ternjs.net/](https://ternjs.net/)

3\. [https://medium.com/@trukrs/type-safe-javascript-with- jsdoc-7...](https://medium.com/@trukrs/type-safe-javascript-with- jsdoc-7a2a63209b76)

4\. [https://fettblog.eu/typescript-jsdoc- superpowers/](https://fettblog.eu/typescript-jsdoc-superpowers/)

</comment><comment><USER29> The first example doesn't bother me and I think it's a weak argument. TypeScript allows literals[1] as types[0] so it is trying to use the object as a type.

The correct use of:

      printDog({
          breed: "Airedale",
          age: 3
      })

is to explicitly cast it:

      printDog({
          breed: "Airedale",
          age: 3
      } as Dog)

[0] [https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&p...](https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&pln=15&pc=2#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChkHIyYAUARnFAFzIBEFUtAlDQM5hSgDmA3PocXTlKNenABezNh259CRUg1FluU5O04heuAL65cAegPIAculwwAriARhg6EMgAOmsBiEwa7pjmT8CCA6s6AA2EAB0IehcJDDhgiS0gsxMuvpGyACaEKwW1rb2ji6gbpgA4pgAJrFemD7YfvKBIMFhkdGx8aRijEypOkA)

[1] [https://www.typescriptlang.org/docs/handbook/advanced- types....](https://www.typescriptlang.org/docs/handbook/advanced- types.html#string-literal-types)

<comment><USER30> Casting can hide errors. It's better to assign it to a variable first that has a type declaration.

        const dog: Dog = {
            breed: "Airedale",
            age: 3
        }
        printDog(dog)

An IIFE is safe too:

        printDog(((): Dog => ({
            breed: "Airedale",
            age: 3
        })())

<comment><USER31> Actually this cast is safe in TypeScript, additional variables are unnecessary.

The statement 'const d: Dog' and the expression 'd as Dog' are equivalent w.r.t. type safety. The compiler will error in both cases the if the value is not a Dog.

<comment><USER32> This is not correct. Following example is valid in strict TypeScript:

      interface Dog {
        breed: string;
      }
      const dog = {} as Dog;
      console.log(dog.breed);

Using `as` is very unsafe in TypeScript.

I've collected more quirks of `as` in this playground: [https://www.typescriptlang.org/play/index.html#code/PTAEAMEs...](https://www.typescriptlang.org/play/index.html#code/PTAEAMEsGd1AzArgOwMYBdIHtmgLYCGAnqADZZYDW0o0kppRANKAEaLqgrxYBO6KAugCmjUOgAWw3sNAxQyLKADuxcUpkAHXlgAmiVLMjoAUCFAEaBUJsQzxRTbNLCAbqNCoc0dLwOYcADozMABlYVk8PiNkENAJdHRNaAAuEABzYwlEVkCvPGA8SFQdaCx4dGAAFUdhUJLITUqYaERhaGAAdgAWAA4ARgBiFrb8vGFkdABabv6AVgGAZkWABgA2YKQ0ANwYAB4qgD4AClcCUjaU0CqASiuq0ABvE1BQGQFeXDOL4QBuEwAviYTOhaqAAGI4TgAXlAACJSJB0gk4aAAD7w8a6SCIPCojFw1hYUi6OH- EyQSbSeAEQygAAK0jKuGer3gkF4PgAcgRxlcfLxKel- kC4gBJXBuaQkVCWWTKKS4cCWOA0+g0dBKWXoVASCy4LCsVzYRAasHSHS8JhxKCwGw6fSGGi6doc4S6NjCCQEY18YKoUiWGgAYSeL1o6CEslhrNetH6AH1LFdHgCLDRGZycNa4-GEzArvtM8yTqmbtbw69oAAmJOpUAAbQRSJRLDhynQ8DhAF106AAIK8XjEPaQyaHHNxmv5+v7MfoBvdk5NxHI9Bwtsdrvd8vA3PQRZ1q7tzuoywQqGTquHgtyaCjqEnE9dm7hgEikxAA)

</comment></comment></comment></comment><comment><USER33> >> Real world JavaScript is inconsistent, messy, and complicated

JavaScript is consistent. Expressive languages such as JS are consistent in their permissiveness. It doesn't stop developers from doing irrational things like comparing objects with numbers just like TypeScript doesn't stop developers from writing all other kinds of flawed logic.

TypeScript basically only protects code from typos. The worst bugs I see in production systems are almost never caused by typos or by comparing incompatible types; usually they're caused by issues in the flow and manipulation of data; for example the same instance is being modified in two different parts of the code without the other part of the code being aware of it; or in the case of pure FP a function is using outdated instances because a change in the underlying data source did not propagate through correctly, etc...

TypeScript is to a software developer what a spell checker is to a book author; it's convenient but once you run the final product past your editor- in-chief (whose analogy in the software world are unit/integration tests), the spell checking didn't actually add any value; at best it saved your editor-in- chief some time. It has no bearing at all on whether or not you'll get a Pulitzer Prize or a top ranking on Amazon.

The downside to TypeScript is compile time and this is a significant drawback IMO because it slows down iteration time significantly. Time spent waiting for the build to finish is time that was not used to add new tests and new features.

If you add up all the time that all developers on a project spent on waiting for the build (or lost their focus/train of thought as a result of waiting for the build to complete), how many extra unit or integration tests could have been written using that lost time? I think if you do the math, you will find that TypeScript is a net liability to the project.

<comment><USER34> You obviously never wrote TypeScript with strict flag turned on. It does control flow analysis, not just typo checking.

<comment><USER33> It does 'Control Flow Based Type Analysis' \- Meaning that it only analyzes control flow for the sole purpose of determining type correctness which adds almost no value to the project.

It doesn't prevent asynchronous control flow issues like for example;

\- Having two different parts of the code simultaneously (asynchronously) mutating the same object and causing data inconsistencies.

\- Your code starts a new asynchronous job (e.g. setInterval) in the background without killing the previous/existing job which was launched earlier.

\- An event listener was registered for the same event multiple times (e.g. from inside another event handler) without unregistering the previous listener and so every event now triggers multiple updates instead of one (and CPU usage keeps going up and you have a memory leak).

\- It doesn't tell you when you forgot to trigger a specific event

\- Or guarantee that two different parts of your code never run in parallel (asynchronously) when mutating some state.

\- Or that you missed an edge case and forgot to update a specific instance's property

\- Or that you were modifying the original instance of the object instead of merely a copy/clone of it as you assumed (or the opposite was necessary and you made the reverse assumption)

Only a human brain can prevent those issues (and the list of such difficult issues is practically infinite; my list is a tiny sample) and those are the real issues in software development, not typos and auto-completion.

Unless you're a web developer and your job only involves writing static webpages, you are likely to encounter much more difficult problems in your career besides not having automatic method name completion or typo prevention mechanisms. These problems I described above are complex enough that they make all the problems solved by TypeScript seem negligible. TypeScript's compile time delay becomes a bottleneck when trying to debug and resolve real difficult problems.

<comment><USER34> > the list of such difficult issues is practically infinite

Precisely. No matter how good a language is, you can always say "but it doesn't do xyz". If you want to replace the human brain by a language, then you're looking for AI, not a language.

I understand what you mean, and I agree that these things are lacking from TypeScript. And I would love them. TypeScript is slowly adding more and more things, mitigating issues one by one, which were previously dissed off by developers with "it doesn't even do xyz".

I have my job because my brain is smarter than TypeScript's compiler. And it does help me, because I know which things I don't have to think about anymore, based on how I write the code. So it does help me, because I think less about the set of problems which it DOES solve.

</comment></comment></comment></comment><comment><USER35> There are problems in their approach:

In the first case the behavior is quirky because they are passing an untyped object into a function. If the object is typed the behavior is consistent.

The second example is about classes. Classes are created as easy extension objects via inheritance and poly-instantiation. Those ideas are friendly concepts for many developers but they increase complexity so I intentionally avoid classes and use a custom ESLint rule to enforce such.

In the third case they can solve for complexity with a simple refactor. The two interfaces are structurally identical so they should be a single interface with either a union on property values (static literals) or by defining a property again a union of other interfaces called by reference.

</comment><comment><USER36> It can only be more complex, then be simple.

If Typescript never existed, people got used to simple nominal typed languages like Java would never notice there are much more advance type system ahead, and what can it potentially bring us - the lambda cube, the dependent type, the Curry-Howard correspondence.

After everyone have a much better understanding in type and the complexity in Typescript, simpler and more powerful languages would take off.

</comment><comment><USER37> Regarding #2, if the class has any private properties (even if the classes have the same private properties) they are no longer assignable.

</comment><comment><USER38> How does TypeScript ensure encapsulation if it doesn't have nominal types?

Edit: The article says "magical hidden properties".

<comment><USER39> Programming TypeScript has a section on "Simulating Nominal Types" [1]. You define a type that's impossible to create naturally, and provide a function that asserts something is of that type.

        type CompanyID = string & {readonly brand: unique symbol}
        type OrderID = string & {readonly brand: unique symbol}
        type UserID = string & {readonly brand: unique symbol}
        type ID = CompanyID | OrderID | UserID

        function CompanyID(id: string) {
          return id as CompanyID
        }
        ...

TypeScript can be very confusing sometimes, and given the learning curve I'd caution someone trying to learn modern JS away from starting out with it. But in even small codebases it's an amazing improvement in safety, especially for refactoring.

[1] [https://learning.oreilly.com/library/view/programming- typesc...](https://learning.oreilly.com/library/view/programming- typescript/9781492037644/ch06.html#nominal-types)

<comment><USER19> > TypeScript can be very confusing sometimes

That's not good. A type system should be crystal clear, predictable and reliable.

> and given the learning curve

Types should not be a complex thing with a steep learning curve. If you know Assembler and C it's pretty clear what types are about. Added complexity to your codebase is what you should try to avoid at all times. We have a limited capacity of things we can think of at a time, developers should therefore focus on things that really matter. In my daily work I see highly complex piles of spaghetti in TS that are 'type safe' and easy to refactor..

<comment><USER20> I don't follow how knowing C and Assembler makes types clear and I'd love it if you could clarify.

Nominal types are really a compile time only thing: if you have two structs (or classes) with the exact same fields, I'd expect them to be stored the same way in memory. And as a result I'd expect any function to work on them just fine, as long as they find semantically valid data at the right offsets.

</comment></comment></comment></comment><comment><USER40> After using Clojurescript for some time, I don't even understand anymore what kind of problems Typescript supposed to be solving. Sometimes it feels it causes more headaches, to be honest.

</comment><comment><USER41> From the HN discussion about the video of "A Conversation with Language Creators: Guido, James, Anders and Larry"

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

[https://www.youtube.com/watch?v=csL8DLXGNlU](https://www.youtube.com/watch?v=csL8DLXGNlU)

I posted these Anders Hejlsberg quotes, who co-designed TypeScript, C#, Delphi, Turbo Pascal, etc:

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

>"My favorite is always the billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake." -Anders Hejlsberg

>"It is by far the most problematic part of language design. And it's a single value that -- ha ha ha ha -- that if only that wasn't there, imagine all the problems we wouldn't have, right? If type systems were designed that way. And some type systems are, and some type systems are getting there, but boy, trying to retrofit that on top of a type system that has null in the first place is quite an undertaking." -Anders Hejlsberg

>Andrew Hejlsberg:

>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.

>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.

>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.

>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi- paradigm.

>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".

>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.

>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.

>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.

And these Larry Wall and James Gosling and Guido van Rossum quotes:

>James Gosling wants to punch the "Real Men Use VI" people. "I think IDEs make language developers lazy." -Larry Wall

>"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling

>"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling

>"I have a feature that I am sort of jealous of because it's appearing in more and more other languages: pattern matching. And I cannot come up with the right keyword, because all the interesting keywords are already very popular method names for other forms of pattern matching." -Guido van Rossum

Also:

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

DonHopkins 10 months ago [-]

>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.

>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.

>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)

</comment><comment><USER42> To me, TypeScript is "perfect". Unlike other strictly typed languages (looking at you OCaml, ReasonML, Haskell), TS has never prevented me from achieving all three of:

1) Be type safe enough to guarantee practically bug-free code (at least with regard to types, you can always have logic bugs)

2) Actually achieve what I want to do in less than a day

3) Upgrade easily when a new version of the language/tooling is released

The only thing that's missing is indeed better nominal typing so that we can more easily discriminate between logically separate instances of strings and numbers. For objects it's actually good enough to qualify for "perfect".

<comment><USER43> TS has led me to a desire for more functionally pure typed code. I'm super interested in learning OCaml and ReasonML right now so I would be interested in understanding where you felt ReasonML falls flat vs TS.

<comment><USER42> I definitely recommend trying them, as it will be a great learning experience. It will probably even make your TS better.

What you won't be able to do is to actually ship a product easily, as the ecosystem is virtually non-existent. Documentation - virtually non-existent especially for actually creating working products.

Of course, there are exceptions to this (like the Facebook Messenger being written in ReasonML), but people tend to underestimate what kind of engineering effort went into that. If you actually want to do stuff by yourself, use TS.

<comment><USER44> And that's the funny bit because a lot of the quirks in TS are actually bits that are needed to integrate with other imperfect tools and libraries and deliver a fully functional product.

</comment></comment></comment></comment><comment><USER45> TyspeScript is nothing more than just better type annotations for JavaScript

</comment><comment><USER46> Sounds like we're about to see a book titled "TypeScript - The Good Parts". That was actually one of my favorite JavaScript books and led to my early adoption of CoffeeScript (since it purposely fixed the "bad" and "ugly" parts at the back of the book.

</comment><comment><USER47> Well, typescript is constantly improving over the years, witch each release you are able to represent more real-world JS patterns and type system is getting more strict options. So this 3 points from article might be improved in future.

About the point the article makes:

1) I remember when excess property check was introduces I was really happy! Because I remembered bug that would be caught with it. I had some interface with optional properties in common library and I renamed property name. Of course when I updated this library in another project I didn't get any compile errors because this was optional property and now I was just passing some extra property which was ignored. Excess property check would have found it because I was passing object literal.

Structural typing is great choice in Typescript because it's basically type- safe duck-typing which is used everywhere in Javascript projects. It's not uncommon to have one component that accept objects with some properties but this object contains many extra properties because it came from different component and these properties are used elsewhere. It's standard pattern in Javascript world. But when your function requires some object of given shape and you are _creating this object right now_ using literal syntax, then it's _really_ likely that you made a mistake. Why create extra properties for _just created_ object when you clearly see they are additional? And I read that Typescript teams is very happy with this feature[0].

However, excess properties check is great but useful only on call side. I cannot say that my function doesn't accept extra parameters. I would really love to get Exact types[1]. Which would allow me to force not having extra parameter in passed object.

2) As mentioned in article, Flow decided to have classes nominally typed. In Typescript everything is structurally typed so it's actually more consistent ;) I really hope we'll get nominal typing and opaque types sometime in future. I read TS team was thinking a lot how to do this. I don't remember what is the current status of this.

3) For me it's more problematic that Typescript doesn't narrow types of an union when you do conditional check. The reason is that in general it is unsound (but I think it would not be if you had only union of Exact types, that's another reason why I would love to have Exact types!).

Example in article doesn't have this problem so I guess this could have been improved. Sound like minor issue for me but maybe author could create suggestion on github to improve it and allow discriminator to be nested?

[0] [https://github.com/Microsoft/TypeScript/issues/12936#issueco...](https://github.com/Microsoft/TypeScript/issues/12936#issuecomment-284590083) [1] [https://github.com/Microsoft/TypeScript/issues/12936](https://github.com/Microsoft/TypeScript/issues/12936)

</comment><comment><USER48> I like how nobody has realized that typescript is classic Microsoft embrace, extend, extinguish. Oh no, they have "turned a corner". This is a different Microsoft! Haha.. they are exactly the same. Every single company has wanted to try and control JavaScript as it takes over more and more of the roles other languages used to fill.

Google failed with their new language, Microsoft is having some success. Google claimed "javascript was too slow, so we need Dart". Hmm, turns out to be complete bullshit and electron applications are now the standard way to create desktop applications. Microsoft is claiming "you need static typing", which is more bullshit.

First Microsoft embraced JavaScript, then they made TypeScript to extend it, and now there is talk of "hey why not just use c# with web assembly etc". "why not just make deno TypeScript only". "what if Chrome only ran TypeScript, would it be faster?".

With vscode->typescript->github, Microsoft is managing to gain control of the masses of mediocre developers, while the good programmers will always be elusive. A digital divide is getting bigger.

<comment><USER49> The only electron app I've ever used that wasn't slow/terrible is VSCode which happens to be written in typescript by Microsoft and it still occasionally decides to use 100% of my macbook's CPU making it entirely unusable until I restart, so I'm not sure that's a very good argument.

<comment><USER50> Do you think that's actually thanks to TypeScript? From what I know, TypeScript doesn't have an inherent performance quality that makes it better than JavaScript.

<comment><USER49> No, typescript has no impact on runtime performance that I know of.</comment></comment></comment></comment>


Ask HN: Ever run a conference? What's the best software to use? - <AUTHOR>

My company is overhauling our events management and registration processes right now. I'm loathe to build something from scratch, so I'm looking at third party solutions such as Amiando, Expectnation, Eventbrite, and Cvent.
Has anyone worked with any of these products? Any advice, reviews or other suggestions?
I don't believe I've seen this topic come up on HN before so thought I'd ask. Thanks! <comment><USER2> Usually the combination that I have been using for the events that I have planned, has been eventbright with pathable.com

Eventbright handles a lot of the registration problems very well. Although it falls down in the following areas, Paypal sucks natch, and it doesn't handle individuals buying more than one ticket well at all. i.e. 1 person buys 5 tickets for people at their company. All of the tickets belong to that person even if you want all of the different peoples names. The google checkout is a bit better than the paypal nightmare.

Pathable is really great, because it can pull the xml feed of your attendees out of eventbright, and has a lot of community features for your attendees. It sets up groups, lets people self tag their interests, handles emails between the people attending and really helps you establish a community between the people coming to your event.

Pathable also lets you print out fancy looking name badges with peoples names on them, and the names of people that they should talk to at the event (as an option). Anyway Pathable is good stuff.

</comment><comment> chris-top eventbrite.com is so bitchen' it hurts. Ouch!

<comment><AUTHOR> My only complaint right now is that it only offers payment via Paypal and Google Checkout. If it weren't for that, I probably would have settled on it.</comment></comment>


Hacker News - <AUTHOR> https://news.ycombinator.com/ <comment><USER2> One of the most addictive websites on the web today.</comment>


Ask HN: Languages to learn in 2019 for Data Science? - <AUTHOR> Besides Python, any languages that can make a difference for data science? What would you recommend and why?! <comment><USER2> I would recommend... statistics.

If you already know Python, learning how to do the same things in a different environment doesn't really add a skill to your resume. It probably means you can apply for more jobs/work on different projects but for each job/project you would be the same candidate as before. Almost like branching out your skill tree rather than extending it.

On the other hand, at a time when importing a library and throwing it on a dataset (without understanding what it actually does) is becoming easier, having a comprehensive understanding of probability, statistics, calculus and linear algebra would be a huge differentiator.

As far as languages go, Scala comes up a lot in data science job postings where I live, but my experience is limited only to trying out the Scala API of Spark. Maybe someone with more experience can shed some light on this.

</comment><comment><USER3> R ... The language is just a joy to use.

* Great environment with RStudio

* Awesome plotting and visualization with ggplot

* Very welcoming community with a very diverse background ranging from social science to quantitative finance

Basically for everything except deep learning R is a great alternative to python. If you rely on advanced statistics I think R is the way to go.

<comment><USER2> > R ... The language is just a joy to use.

My experience has been the exact opposite. R is great as an interactive statistical environment. But if you need to build data-intensive applications in it - it's still powerful but somewhat slow and also a bit of a mess: many exceptions, special cases, strange design choices and multiple ways to do the same thing. It can get the job done, but there is an unpleasant learning curve to get used to all the weirdness.

</comment></comment><comment><USER4> Julia, with its 1.0 release and much needed stability, is a joy to work with with. It's blazing fast compared to Python. The learning curve may be steep though.

</comment><comment><USER5> I don't actually recommend it but Matlab is annoying good at a lot of things you want for data science.

I'd only recommend Matlab for data science if you already know it (say you're studying engineering) and are looking to start with data science.

<comment><USER6> I have found Matlab as a great tool to write scrips to do data exploration and manipulation; then later on I can easily reimplement the same workflows or algorithms into something like a python notebook and also have the added benefit of more flexible and open frameworks (for stuff like ML with keras and tensorflow).

<comment><USER5> Sounds like you just know Matlab better then, I think python, and especially notebooks, are also very good for data exploration and manipulation. I've recently switched over from doing everything in Matlab to everything in python. Although I do occasionally fall back to Matlab for things like 3D plotting.

Also, if you like Matlab/know it well, you might want to look into the deep learning toolbox (if you have access to it). I found I was able to do all the stuff I was doing in keras with Matlab. Haven't learned to recreate all the stuff I was doing with tensor flow there, but it might be possible.

</comment></comment></comment><comment><USER7> Clojure is a data-oriented language. quick guide here: [https://hackernoon.com/clojure-functional- programming-38cc6a...](https://hackernoon.com/clojure-functional- programming-38cc6a9298f5)

Others on the internet say:

"Teaching a python Dev Clojure would be small fraction of there time.

Some of the libraries people reach for in Python for DS aren't even necessary in Clojure. Pandas is a good example of this.

Data Science is as wide a field as programming, there are lots of things that a JVM based language would be great at."

Source: [https://www.reddit.com/r/Clojure/comments/7jdaac/clojure_dat...](https://www.reddit.com/r/Clojure/comments/7jdaac/clojure_data_scientists/)

IMO learn a little lisp ASAP

</comment><comment><USER8> Learn make. IMO, Makefile is a very flexible way to combine the best of breed from matlab/octave, R, Python, etc in to a single pipeline. Each processing step spits out file dependencies for the next and so on.

</comment><comment><USER9> JavaScript. I know this could be a little controversial but with more and more people learning JavaScript and porting of tensor flow,torch into javascript, I believe this is the language which will take data science to masses of developers.

<comment><USER7> JavaScript is cute, I use it as a puppet language

</comment></comment><comment><USER10> Java. Because if you're using Spark heavily, then being able to make your own microservices allows great scaling.

</comment><comment><USER11> I am learning Python. So I'll go for it.</comment>


UCI Researchers Accidentally Make Batteries Last 400 Times Longer - <AUTHOR> http://www.popsci.com/researchers-accidentally-make-batteries-last-400-times-longer <comment><USER2> The title is a bit ambiguous ("Batteries last 400 Times Longer") and could be interpreted that the battery can store 400x more energy. It would be more precise to say that the discovery was for batteries that can last through 400x more discharge/recharge cycles.

<comment><USER3> Yes, though either way it's good. If you can manage 400x more discharge cycles for little extra cost that could REALLY bring the cost of electric cars down, though the article doesn't say whether this design can in principle manage the power requirements of a car..?

</comment></comment><comment><USER4> There is a part of me that loves these stories about serendipitous discoveries. Of course the trick is to recognize what you have found and to use that information.

Some technology/inventions discovered by accident: penicillin, x-rays, post-it notes, pacemakers, ink-jet printers, saccharin, microwave ovens, potato chips/crisps and of course Coca Cola.

<comment><USER5> >There is a part of me that loves these stories about serendipitous discoveries.

The discovery of LSD is a fascinating example of this.

Hofmann experienced some sort of altered state of consciousness after first synthesising it. The interesting thing is that it lasted about two hours, which means he could not possibly have accidentally ingested some.

He then reports he has a "peculiar presentiment" that there's something special about it, so decides to deliberately take a dose. The rest is history.

</comment></comment><comment><USER3> Promising! As ever the proof is when they make a working prototype to demonstrate this in an everyday battery, as stories like this abound. Fingers crossed.

</comment><comment><USER6> E should like this</comment>


Crossing The Street - <AUTHOR> http://sohailprasad.com/crossing-the-street

<comment><USER2> You forgot one type of person. "People who wait for the walk sign because they've got other things on their mind and make the conscious choice to leave deciding when to cross the street up to the street light." Waiting for the light lets you cross the street with hardly any thought at all, freeing that thought up to do other things.

These people realize you can only do so many tasks so why not delegate the least value-added (what are you going to gain by earning 15 seconds) of the tasks to someone - or something - else? It's a no-stress, win-win to give yourself one less thing to worry about.

<comment><USER3> I was about to say the exactly the above.

        People who evaluate the situation for themselves and cross on their own terms

What if you are someone who has evaluated the situation and decided that you will wait for the sign, or you will just cross as other people are doing so? How can you tell when someone has evaluated the situation and exhibited on of the above behaviours?

<comment><USER4> Now that we've read his post, if we follow his guidelines, we're back to being a follower.

</comment></comment></comment><comment><USER5> And then there's people who understand how risk compunds over a large number of instances.

Yes, I wait for the green light. Because every single time I make a judgment call that it's safe despite the red light, I have a _tiny_ increase in the likelihood that there might be an accident. (No, waiting for green alone is not good either. There's always a risk. Situational awareness is good. But walking on red carries a bit more risk than walking on green, all other things being equal)

And since I do cross many traffic lights every single day, that tiny risk compounds. And compounds. And compounds. And if only a single, tiny accident happens, the time I saved by "making a judgment call" for thousands of crossings is all gone.

But hey, if you think life passes me by, more power to you. Glad you get to feel like a rebellious risk taker, living at the edge, always aware.

<comment><USER6> As my high school drivers ed instructor always said: "Colored lights are physically incapable of stopping a moving car."

If there's one thing that I've learned being a pedestrian in NYC for the last 10+ years: Traffic lights are very loosely correlated with driver behavior. In my experience, you're far better off making decisions based on observing cars and drivers than faith that a red light means anything to a cabbie in midtown during rush hour.

<comment><USER5> See above: "Situational awareness is good. But walking on red carries a bit more risk than walking on green, all other things being equal"

Trust me, even in NYC, cars are slightly more likely to drive on green than on red.

Or, in other words, a green light is a necessary but not sufficient precondition if you want to achieve minimal risk for your crossing.

</comment></comment></comment><comment><USER7> Hot tip: filter uncommitted make-your-own-rules types by looking at driving instead of walking.

Any Joe Schmo can jaywalk, but it takes a real free spirit to decide no cars are coming and run that red light.

</comment><comment><USER8> That's a neat bit of people-watching. My favorite way to learn about someone is to physically spar them. You learn a lot about a person -- how aggressive or defensive they are, their cleverness or ability to improvise creative solutions, how they respond when backed into a corner, and how they react when given control over the ring.

</comment><comment><USER9> While this might be a nice sociological observation, or a neat metaphor for life, I think it's taking it too far. Yes, we judge people a lot. But trying to pidgeonhole people's personalities based on how they cross the street is a bit ridiculous. I think people need to be aware of the subconscious judgments we make, and how wrong they often are. Open-mindedness is one of the greatest virtues to strive towards IMO.

</comment><comment><USER10> My new micro-hobby is waiting for the walk sign. The whole point is to experiment with self-discipline and not following the herd. It's hard to stay put when someone crosses while I wait, and I find that fascinating!

</comment><comment><USER11> I used to be a "cross on my own terms" type. Then I moved to Seattle.

On my first day exploring downtown, I crossed when no cars were coming (or even approaching from far away) and got dirty looks from the gaggle of Seattlites in front of me waiting for the signal to change. (It did finally change as I stepped onto the opposite sidewalk.) After a few weeks, I just stopped putting myself in the spotlight like that.

Now, when I go back to NYC, people seem irritated when I forget where I am and stand there waiting.

<comment><USER12> Here in Seattle, the pedestrian signals are serious business. A colleagues dad was given a $70 ticket for crossing on Stop.

Going back to London / NYC, I always forget to just do it and walk across whenever the opportunity presents itself.

</comment></comment><comment><USER13> I suspect you are going to get a lot of "you are wrong" comments; primarily from people who would say "I cross slowly, but I am not average!" Good post, I liked it.

<comment><AUTHOR> Thanks!

That's expected - after all, everyone think's they're above average ([http://www.cbsnews.com/8301-205_162-57568186/everyone- thinks...](http://www.cbsnews.com/8301-205_162-57568186/everyone-thinks-they- are-above-average/)), it's the phenomenon known as illusory superiority... "On a scale of one to 10, you probably think you're a seven. And you wouldn't be alone."

(Disclaimer: though granted, I'd hazard a guess that most HN readers are generally above average.)

</comment></comment><comment><USER14> This is a great analogy of why I prefer New York City over San Francisco.

SF is filled with "wait for the walk sign" type of folks, while NYC is filled with "cross on their own terms" types. If you ever see someone waiting for the walk signal in NYC, it's a good bet that they're a tourist.

<comment><USER15> The "risk takers" who "cross on their own terms" can be equally judged as "gamblers" who gamble with their life. I mean this whole analogy given by article poster is pointless first of all. And then comparing SFers with New Yorkers based on their road crossing habits is even more pointless. In developing countries (like India), where in most cities/towns there is no designated zebra stripe crossing (and definitely no push button pedestrian crossing signals), every one crosses at their own terms, some times dodging medium sized vehicles, giving respect to large vehicles and stopping smaller vehicles(bicycles, bikes etc) by waving their hand as they cross over. From the street hawkers to the bankers, from a school going teen to the old man with walking stick, every one does that. How does that give you any insight into the psyche of a person !! Or the psyche of a geographical region? New Yorkers cross on their terms more often possibly because there's just more people, lot of whom are in rush and "crowd learns soon from the behavior of few"

Trying to glean any meaning from such behavior is a futile exercise.

</comment></comment><comment><USER16> What about "People who would like to 'evaluate the situation for themselves and cross on their own terms' but must instead wait for the walk sign because the cops in their town have nothing better to do than give jaywalkers a $200 ticket"?

<comment><AUTHOR> Metaphorically speaking, the cops around town that "keep people in line" are just like people in life who "make the rules." They're there to enforce social norms; thus people who say "this is just how it is" when faced with a new situation. Point being, not enough people are willing to ask "why?"

Not arguing the technicalities of crossing the street or why laws are made, just noting parallels between a decision that people make unconsciously every single day and its relation to life and the "big picture."

<comment><USER17> Your metaphor is based on people breaking laws or not. I bet the risk takers are mostly wealthier and whiter than law abiders.

</comment></comment></comment><comment><USER18> If someone crosses an empty street (i.e. no honking and swerving) how do you tell if they're #1 or #4?

</comment><comment><USER19> You are under arrest for jaywalking!</comment>


Show HN: Emoji Ipsum - <AUTHOR> http://github.brandonanzaldi.com/Emoji-Ipsum/ <comment><AUTHOR> There seems to be Lorem Ipsum-esque generators for basically everything from kittens to Samuel L. Jackson nowadays, but surprisingly, I couldn't find a single one for emoji. It's largely useless, but a fun toy nonetheless.</comment>


Git is hard - <AUTHOR> http://vimeo.com/60788996

<comment><USER2> Using Git can be easy to understand, as it takes only a few commands to make it usable. git commit, git add, git push, git pull, etc. That's enough to get most users, including people that would normally be afraid to use a command line, to a state where they can contribute to a git repo.

And if the work is being done in Github, then the person can use the Github apps to just-get-the-work-done. No command line.

What makes git hard are the men "helping" the woman in this video. Devs create these crazy rules around branching and rebasing, which results in:

1.) Hours wasted while people try to comply with a process they don't understand, and

2.) Timid work, as everybody's afraid that stepping on the wrong stone will trip a booby-trap that messes everything up, looping back to (1).

There is a workflow that people were following without git. They'd make changes, save them, and then move on. If someone else made changes, they'd bring those changes in (i.e. merge) and move on. In my experience, most people understand that. All of the rebasing nonsense is getting people nowhere.

A deep understanding of git should not be a requirement to use git anymore than I shouldn't need to know how my car works to drive to work. The goal is to get where we need to go, not to have the perfect vehicle and trip. Your git repo might get messy sometime, shrug, sorry -- development can be messy sometimes. Use the git experts abilities to clean it up, rather than try to get everybody to a git expert level.

Git experts: Keep. It. Simple.

</comment><comment><USER3> That's not about git. That's about ``Fool may throw a stone into a well which a hundred wise men cannot pull out''.

</comment><comment><AUTHOR> This video is funny because it's true.

Git is practically unusable for all but the simplest things without a good set of aliases or wrapper scripts.

<comment><USER4> It's true only from your world view. You should have titled the post "Git is hard for me" but it would have attracted less eyeballs.

I'm a daily user of Git interacting with thousands of developers committing against the same repo. Here's my sole alias

l = log --graph --pretty=format:'%C(yellow)%h%C(cyan)%d%Creset %s %C(white)- %an, %ar%Creset'

I'm not saying that "I'm so smart I don't need aliases" or that "you're so dumb that you need them" which is how my post is likely to be interpreted.

I'm saying that your past usage and experience may differ so much that it's hard to change the patterns set in your brain. I work with folks who have used Perforce for a decade and struggle with Git. They're super smart but Git is very different and therefore difficult for them at least at the start.

Generally speaking I would recommend avoiding sugar. I sometimes interview folks with so many Bash aliases on their own workstation they can barely navigate using vanilla Bash.

<comment><USER3> I understand Perforce users you are talking about, but their problems are temporary and that's OK - almost anyone changing main language from Java to Haskell need some time to start feeling comfortable and get productivity to his usual level.

But about Bash aliases - is there any real need to use vanilla Bash (or sh, or ksh, or csh) when he has his settings/aliases file with him?</comment></comment></comment>


Google Allowed Advertisers to Target "Jewish Parasite" - <AUTHOR> https://www.buzzfeed.com/alexkantrowitz/google-allowed-advertisers-to-target-jewish-parasite-black <comment><USER2> What's ironic is that morally speaking, they should milk those nazis dry. Instead, by being racist, they aren't getting targeted advertising, which is likely to their benefit.</comment>


First Experiments in Web Design - <AUTHOR> http://www.techcreation.sg/page/design/Web%20Design

<comment><USER2> Not to underscore the value of self-creation (I remade my own personal webfront recently using Django, and nothing's a more valuable coding experience than making something you use yourself) but I think the primary advantage of CMSes like Wordpress and especially Tumblr to designers and developers aren't the bundled, predefined designs but the ease of publication: you can absolutely rip apart a tumblog's design (or even create one from scratch: <http://www.tumblr.com/docs/en/custom_themes>) but you have simple, easy methods of creating and disseminating content.

<comment><AUTHOR> In a way, part of the point of the whole exercise was the self-creation. Setting up a personal website from scratch has a lot of pieces, and graphic- design is something I had never touched in my life. I thought it was quite cool to see the designs improve as I iterated.</comment></comment>


Clojure in Python - <AUTHOR> http://framegen.wordpress.com/2010/08/22/clojure-in-python/ <comment><USER2> I wonder if the increasing number of projects that use the "Clojure" name to market themselves (really having little in common with Clojure) is reason for worry or a sign of Clojure's success?

</comment><comment><USER3> I did not see a link for the code.

<comment><USER4> Or understand what it does.

I learned yesterday that a closure is a function that's saved in a variable with out being effected by the context its run in, just the context it was saved in.

<comment><USER5> This actually refers to the programming language called clojure, _not_ the concept of closure.

</comment></comment></comment><comment><USER6> I implemented something along these lines many years ago: <http://github.com/cageface/lython>

It was a fun hack but it just seemed lispishness is really something you want to build in as close to the ground up as possible. Still, it is cool that python makes it so easy to work directly with its AST.</comment>


Tell HN: I'm 17 and I made a site with Ruby on Rails - <AUTHOR> http://debate-zone.com

<comment><USER2> I'm not sure why it matters that you're 17...?

<comment><USER3> agree , should of asked to review

</comment></comment><comment><USER4> 502 Bad Gateway.

Nginx is a great choice however :)

<comment><AUTHOR> Really? You must have visited at the exact moment I restarted the server. Yeah, nginx is great, it's the default at WebFaction.

<comment><USER5> Check out HAProxy. It's nice for displaying a friendly error message if it can't find any available backends.

</comment></comment></comment><comment><USER6> Well done. Congrats!</comment>


Musk Says F-35 No Match for Drones - <AUTHOR> https://www.businessinsider.com/elon-musk-f-35-drone-fighter-2020-2 <comment><USER2> Is his point that the G tolerance of a pilot is the principle limitation on what maneuvers can be performed by a jet?

Its pretty clear that this reading of the headline is incorrect: "there currently exist drones which can take on the F-35 in aerial combat". I believe that Musk just meant "the future of aerial combat will be unmanned", but it needed to be phrased as a maximally hot take for clicks.[0]

[0] [https://twitter.com/elonmusk/status/1233478599170195457](https://twitter.com/elonmusk/status/1233478599170195457)

<comment><AUTHOR> Well he said in references to drones "The F-35 would have no chance against it,"

Perhaps it would be more accurate to say the Musk thinks the F-35 is no match for future drones?

Also, I think besides G tolerance there is the issue that a pilot with a pressurized air system, controls, glass cockpit, ejector seat etc. adds a lot of weight and drag.</comment></comment>


Coronavirus lockdown: German lawyer detained for opposition (Apr. 14) - <AUTHOR> https://www.ukcolumn.org/article/coronavirus-lockdown-german-lawyer-detained-opposition <comment><USER2> I've followed this case with great interest over the last days. And as much as I would have like things to be like they seem - our government silencing once of the only opposing voices (like they did often in the last years) - it's not like that this time. You can read the things she had written on her page and even listen to the phone call with her sister where she describes the entire ordeal. Frankly: She's a nutjob.

<comment><USER3> The website takedown seemed unnecessary and questionable (I'd personally hope it will be found to be wrong), if her description of police behavior is accurate they were more violent than necessary. Which means this case needs to be watched and makes looking at her mental health look bad, even if probably justified.

<comment><USER2> The site was always up for me but yeah maybe someone did intervene. Often those are the hosters themselves. I don't think our government is competent enough to close websites this fast even if they wanted.

These cases of unvoluntarily hospitalizations are always difficult and deserve to be watched. I just wanted to put the case into context for non-Germans from what I could gather. And at the very least she's shown some very odd behaviour, which supports the police version.

<comment><USER4> I did not follow this issue closely when it happened, is there a credible source on who took the website down yet? That honestly sounds a bit quicker than German LE normally acts in IT matters.

edit: ah great, thanks.

<comment><USER3> T-Online reported that the hoster (1&1 Ionos) did it after a "police request" (other media reports referenced T-Online for this detail): [https://www.t-online.de/nachrichten/deutschland/id_87685030/...](https://www.t-online.de/nachrichten/deutschland/id_87685030/kritik- an-corona-massnahmen-ermittler-sperren-homepage-von-coronoai-anwaeltin.html)

</comment></comment></comment></comment></comment><comment><USER5> she was detained because of her weird behavior and was released on the same day

Earlier she declared the various restrictions in Germany because of Corona for ended. She ordered Germany to end closing of shops, etc... She also ordered Germans to only drive 130 km/h on the Autobahn.

[http://www.beatebahner.de/lib.medien/Corona%20Auferstehungs%...](http://www.beatebahner.de/lib.medien/Corona%20Auferstehungs%20Verordnung.pdf)

Weird...

<comment><USER3> Not on the same day, but apparently in the meantime: [https://www.welt.de/vermischtes/article207246011/Heidelberg-...](https://www.welt.de/vermischtes/article207246011/Heidelberg- Anwaeltin-Beate-Bahner-in-Psychiatrie-eingewiesen.html) (link posted by /u/tastroder below)

</comment></comment><comment><USER6> This is fake. [https://www.presseportal.de/blaulicht/pm/14915/4571083](https://www.presseportal.de/blaulicht/pm/14915/4571083)

Google translate:

"There are currently reports in public, especially on the Internet, that the accused are forced to be placed in a psychiatric clinic. To this end, the public prosecutor's office in Heidelberg and the police headquarters in Mannheim state that neither the placement of the accused in a psychiatric clinic nor any other coercive measure was ordered as part of the criminal investigation against the accused."

<comment><USER3> > _as part of the criminal investigation_

Here's the statement about taking her into the clinic: [https://www.presseportal.de/blaulicht/pm/14915/4571057](https://www.presseportal.de/blaulicht/pm/14915/4571057)

Please be more careful with the label _fake_.

<comment><USER4> > Please be more careful with the label fake.

What you posted does not contradict that conclusion. Police thought medical advice was in order since she was acting paranoid, she attacked the officers. Hardly the dream conspiracy theory she makes it out to be. German police does not determine if somebody belongs in a psychiatric clinic, they merely presented her in front of somebody to assess if she is a harm to herself or others in that case.

<comment><USER3> I (on second read probably mis-)read the post as denying she was taken into custody at all. It's more helpful to spend a sentence clarifying what the difference is that's pointed out than saying "fake".

<comment><USER4> Okay that's true, no idea why there's even two press releases on this. Might be some odd privacy protection technicality / maybe it's technically two different calls / cases or something. Apologies, I'm just a bit annoyed that this conspiracy theory crap gets airtime at the moment.

</comment></comment></comment></comment></comment><comment> def- See also this subthread from yesterday about the same topic: [https://news.ycombinator.com/item?id=22865408](https://news.ycombinator.com/item?id=22865408)

</comment><comment><USER4> "Confinement of whistleblowers in psychiatric institutions, an old Soviet technique," yeah... great, credible reporting right there. /s

This person seems about as credible as any Reichsbürger, the German equivalent of sovereign citizens. She continued to spew her hoax crap since day 1 of her reasonable temporary detention because they gave her phone to her, and she's free again. If you're looking for erosion of democracy, this isn't it. It's, besides the usual minor shortcomings, a system of health care and authority working as intended.

<comment><USER3> > _and she 's free again_

source?

<comment><USER4> [https://www.welt.de/vermischtes/article207246011/Heidelberg-...](https://www.welt.de/vermischtes/article207246011/Heidelberg- Anwaeltin-Beate-Bahner-in-Psychiatrie-eingewiesen.html)

"Die am Ostersonntag in die Psychiatrie gebrachte Anwältin hat inzwischen die Einrichtung verlassen können. Das bestätigte die Klinik am Mittwoch gegenüber t-online."

The bar to hold somebody in a psychiatric environment against their will is pretty high in Germany.

<comment><USER3> Thanks! I had seen a report that the official decision about this was to be made today, but nothing about the result yet.

</comment></comment></comment></comment><comment><USER7> The most outrageous part is committing that lawyer into a psychiatric institution. (Almost) unbelievable.

More generally, the Corona virus is not an excuse to disallow protest activity, at the very least - even if one believes that such activity endangers the protesters' health. Not to mention the fact that it is quite possible (though perhaps less effective) to protest while maintaining a 2-meter distance from others.

</comment><comment><USER8> On a related note:

What No One Is Saying About the Corona Crisis by J. Corbett

[https://youtu.be/lmHRYzF0dyQ](https://youtu.be/lmHRYzF0dyQ)

Each and every basic human right already is or is going to be violated and annihilated on the premise of this "pandemic". It's time to question, what's your line in the sand here, and if you have a line in the sand at all, and what you're going to do, when the police breaks into your home. How far is too far?

There was one comment that really states it brilliantly:

"As someone with a compromised immune system, I want to put out there that I don't want you, or anyone you know to have to be out of a job, or unable to make ends meet, in an effort to protect me from getting CV. I don't need any of this, as I am an adult, capable of protecting myself. If I felt that this virus were a danger, I would stay home, and restrict my own movement to prevent an illness. I would never expect others to surrender their movement for my benefit.

The worst part of this event, is the economic impact of having so much of the workforce without work. Many folks live hand to mouth, and it would appear that the people in charge either didn't think of the financial impact of those folks, or they just don't care. The bills don't stop coming, even though the paychecks have, even my wife has been laid off, and she recently discovered that her employer is in chapter 11 bankruptcy. So, who knows if she will even have a job at the end of this... My oldest daughter is also unemployed as a consequence of the shutdowns. I am certain that there are thousands of others going through the same thing right now. It is a real shame. This lockdown needs to end. If people want to stay home for a couple more weeks, let them do it without penalty. If people want to open their business, let them. It's time to stop this collective madness."

This is fucking serious. This is more serious than anything before. As serious as it can get. And absolutely no one has the idea of what can be done on the individual or even collective level to fight back.</comment>


Federal Loan Data Disclosure - <AUTHOR> http://graphicsweb.wsj.com/php/Federal-Loan-Data-Disclosure.html

<comment><AUTHOR> also: [http://www.businessinsider.com/the-largest-single-loan- given...](http://www.businessinsider.com/the-largest-single-loan-given-to- bank-during-crisis-47942000000-2010-12)

filter by "Barclays" to confirm the number. Note the amount is in millions.

the data is downloadable on scribd in pdf here: [http://www.businessinsider.com/check-out-which-banks- receive...](http://www.businessinsider.com/check-out-which-banks-received- pdcf-loans-when-2010-12#ixzz16tRcNYtt)</comment>


Coordination, Good and Bad - <AUTHOR> https://vitalik.ca/general/2020/09/11/coordination.html <comment><USER2> Vitalik is the creator of Ethereum. Ethereum is a platform for permission- less, programmable money and code that moves money and digital assets. Over $100 billion in assets are now operating on Ethereum. Here is a link to an explorer for USDC, a digital asset that is backed by dollars that has about $2 billion custodied by Coinbase and Circle [https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0c...](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48)

I guarantee you that nearly every digital asset breaks numerous laws in every developed country. Bitcoin and Ethereum help violate money laundering laws every hour as many $10k+ transactions execute without proper forms filed with government agencies. Whereas it takes a shitload of money to obtain money transmitter licenses in the USA to operate in every state, it's trivial to accept huge amounts of money across state and international borders once you create a cryptocurrency wallet.

I'm saying this because the technology has surpassed the laws. As Uber and Airbnb became so successful that governments bent, so too is cryptocurrency powered by blockchain technology forcing the government's hands. A paradigm shift is occurring under everyone's noses!

If you choose to ignore blockchain, don't be surprised when it becomes a very crucial technology. It is upending centuries of financial customs, rules, laws, and institutions.

<comment><USER3> "A very crucial technology" to whom? For what purpose?

<comment><USER2> To build a financial system completely separate from the state. To avoid fiat currency, if you desire. To conduct commerce without government interference whatsoever.

This is not a pipe dream. This happens every day in increasing numbers. I'm sorry if you don't like this.

<comment><USER4> > _This happens every day in increasing numbers._

Nope. Bitcoin trading volume (for example) has plummeted to a miniscule fraction of its late-2016 hype height.

<comment><USER2> It doesn't seem you are familiar with this space, given that Ethereum transaction gas fees have hit sustained all time highs. Bitcoin and Monero transaction counts are extremely high despite the price of the assets being well beneath their height, signaling organic adoption and utility beyond speculation.

It's difficult for people outside of this space to see, as you only notice when news hits the front page. I work at a major crypto exchange (Poloniex) and all of our metrics are very bullish. I don't think your 2017 opinion is relevant anymore.

<comment> roland-s Does high tx count and low price really mean utility? Seems it could also mean market is unsure of the asset's intrinsic worth and speculations are constantly in flux. Or could mean lots of speculative alts being built on top of main chain, things like Omni?

</comment></comment></comment></comment></comment></comment><comment><USER5> > there are mathematical proofs that at least one stable Nash equilibrium must > exist in any game

That's actually not true. E.g. the game "you get the amount of money you ask for" has no equilibrium because you can always ask for a larger number. The proof on wikipedia doesn't apply to this game because the strategy space isn't compact. In real life, this doesn't come up much because usually your strategy is bounded somehow (e.g. you are limited by available cash+credit). I'm not as familiar with the other conditions listed and how they might relate to game strategies, but it would be interesting to hear an example game for each.

<comment><USER6> Does your example classify as a game? Who are you playing against? Usually nature isn't consider a "player" per say, but rather just defines an environment. Otherwise, a game consists of three structures[0]:

• a collection of participants, or players.

• Each player has a set of choices, or strategies, for how to play/behave.

• Combined behavior results in payoffs (satisfaction level) for each player

Macroeconomic theory handwaves and says assets are generally bounded above by some non-binding constraint to rule out this behavior you've pointed out, for the record.

[0] Lazy google search result scribbed liberally from [https://www.cs.cmu.edu/~avrim/598/lect0504GameTheory.pdf](https://www.cs.cmu.edu/~avrim/598/lect0504GameTheory.pdf)

</comment></comment><comment><USER7> Hmm. In the context of cryptocurrencies, I wonder what incentivizing defection would look like? eg. if several entities are colluding on a 51% attack, what mechanism would benefit a defector controlling 20% while screwing over the other colluding 31%, thus warning the non-colluding 49% of the collusion?

</comment><comment><USER8> Interestingly, in a somewhat related notion, I've been noticing that there's been a recent push in society towards individuality (over collectivism). In the way people view right or wrong, many have started to believe in their own preferences as ideals. While it's good to have differences, it's interesting to see the downstream effects of an overcorrection for the self. For example, doctors are now being accused of immorally attacking someone for being obese (seen as a personality trait), when in reality they're just trying to help patients be aware of their unhealthy habits so they can improve their condition.

Because we tie how we view the world to our individuality, we also adopt our own flaws as part of our objective compass. And things get interesting when people with that same frame of mind run into each other.

</comment><comment><USER9> I've always felt that 'moral barriers' were the main forces which have allowed capitalism to operate relatively smoothly in the past (at least in some countries). That's why I've always been against Milton Friedman's philosophy that each person should only be motivated by-self interest.

In many ways, this philosophy is the reason why we ended up where we are today; with a deep and growing class divide fueled by colluding self- interests, moral depravity and hypocrisy.

This is because self-interest and cooperation are not mutually exclusive; it's the opposite; they are mutually reliant.

But cooperation born out of self-interest does not yield the same results as cooperation born out of altruism and a sense of moral justice or collective pride.

</comment><comment><USER10> > price for some product between $5 and $10; the differences within the range > reflect difficult-to-see factors such as the seller's internal costs, their > own willingness to work at different wages, supply-chain issues and the > like.

No! Why is it so difficult for people to understand that price is set by supply and demand? Cost has absolutely no influence on how much the customer is willing to pay.

<comment><USER11> >Cost has absolutely no influence on how much the customer is willing to pay.

Giffen goods are an example of where that isn't true. I have personally experienced it myself when I became more tempted to buy BTC as the price started rising.

<comment><USER10> It still has nothing to do with cost though.

The only things influencing price is always the product and the consumer. How much it cost to make the product has nothing to do with that price, even for giffen goods.

<comment><USER11> You're right, I had an incorrect definition of "cost".

</comment></comment></comment></comment><comment><USER12> I never thought of "unstable games" before and that is quite revelatory when thinking about money, but I do wonder about cooperation because maybe not in Ethereum-land is there much joint minting of money, but there are subtle systems forces in place in the physical world that do mint money cooperatively and that might skew some of these perfect mathematical results, for example.

</comment><comment><USER13> Vitalik is spinning a false dichotomy. Saito ([http://saito.io/arcade](http://saito.io/arcade)) has already solved the 51 percent attack.

The mechanism used (using fee collection as work) eliminates the profitability of collusion while still rewarding cooperation.

</comment><comment><USER14> Still tons of misunderstanding in this space.

The financial system is supposed to have regulations that protect everyone in an economy. But, what they've ended up doing over the years is only applying to small players and retail (everyday) investors.

Trump and his friends front ran the market crash. Then, after a records stimulus was passed, profited as over 200k US citizens died. That's just America (though America is the defacto reserve currency since WW2). They don't get punished, and they are just the _obvious_ cheaters in the game of international finance and crony capitalism.

The USD is also the de-facto currency for: child pornographers, international hits and murder contracts, paying for military grade weapons, enforcing sanctions on entire economies, drugs, money laundering, literally everything-- because it is _the_ reserve currency.

Enforcement is for the people at the bottom, not the top. Ethereum can't change that, it's just offering the same financial services that crony capitalism offered but with a MORE oligarchical rules set. That's why it's funny his "ideal" and "realistic" pictures for success in cooperation both have pictures of castles.

Bitcoin is anarchist money (for now) because it uses entropy to secure instead of force/violence (all fiat currency requires a military to secure). It questions the some of the base authorial structure of all human society/nation-state economics. It is built with disorder in mind. It has built in distrust of authority. Authority is(or requires) force (to enforce). It's important to question authority--that's the only way to progress, no power/responsibility/trust should be given indefinitely. With that in mind.

Ethereum is a new form of authority, just like Bitcoin. But, it does some different stuff with the responsibility that is bestowed upon it. Ethereum owners (people who design, say, "smart contracts," or whatever), have already abused their power, this makes it more dangerous than Bitcoin. Recent SushiSwap stuff. Eth classic is constantly getting 51% attacked. There has been rollbacks. The devs change the inflation rate at will. They are constantly trying to move at a breakneck speed, so it's scary for people who want to hold money long term because you never know what you're gonna have to adapt to, or whatever. It is designed to play with new trust models, it's totally different than Bitcoin. Could be fun, but is designed to be more of a wild west than Bitcoin. If anything it's really better to see it as another layer to Bitcoin. If it surpasses Bitcoin in value, something will surpass it. If Bitcoin fails, it will likely fail since it is tied to the Bitcoin economy (wrapped Bitcoin, code similarities and cryptography standards used). If you're interested in Ethereum, there's already a better Ethereum, it's called TRON. And what about Polkadot. etc etc.

If you're interested in going down this rabbit hole. Start with tech deflation.

IMO, On a macro level we're seeing the same thing that happened after the industrial revolution, leading up to WW1 (though historians still argue about the cause of WW1--I think it's clear they'd have a lot to argue about if we had a WW3 soon, as well). It's called tech deflation. Of course, I'm not a historian or an economist. SO TAKE THIS ENTIRE DIATRIBE WITH A GRAIN OF SALT.

Deflation is political suicide because business money goes where there is promise of a strong consumer base and labor force. But inflation is also effectively gaslighting citizens of the inflating nation-state. That's why we see such disparity through asset bubbles and pops every decade. The problem isn't inflation, though, it's that there isn't another legal option for all people. Money is a good that is consumed like anything else. You can keep fiat AND your Amazon gift card AND have some Bitcoin. Accept deflation into your life. Bitcoin is an anti-inflationary anti-censorship (Ethereum is not) choice, it is the best option for an equally distributed access to deflation that humans have right now (better than gold, or whatever, anyway). Honestly, believe it's the best first step to preventing a third world war.

Ignore Vitalik's grains of salt, ignore my grains of salt

Buy Bitcoin</comment>