gary_bernhardt

(I wrote the article.)

Our system uses io-ts to dynamically validate all incoming and outgoing API data. The static API types are guaranteed to match the io-ts codecs, so the runtime validation will match the static types.

Re: "it's misleading to say that this is a feature of TypeScript": I didn't say that. TypeScript makes this kind of static verification possible. It's impossible in JavaScript.

Re: "The benefit pointed out by the author of this article is in fact one of the few genuine gaps in TypeScript's capabilities": yes, it's a gap in TS. Again, TS makes it possible (as opposed to JS). io-ts (mentioned explicitly by name in the article) backfills the type erasure shortcoming for our purposes, at the expense of being more verbose and producing worse error messages when compared to first-class reflection in a non-type-erasing language.

Re: "going to lead to them getting hacked": no, io-ts isn't going to lead to that more than any other runtime validation scheme. If someone believes that TS' static types provide runtime guarantees, yes, they could write highly insecure API code. But it's hard for me to imagine someone getting to an experience level where they can write a server-side router that's generic over all possible API endpoint payloads, while at the same time not knowing that TS erases types at runtime. Erasure comes up early in the process of learning TS because it leads to surprising behavior, like objects at runtime having properties that aren't present in their static type.

That's a different issue. I was replying to the claim that Visual Studio itself vs. create-react-app itself is an "apples to apples comparison" (their words).

Dev dependencies are as dangerous as production dependencies and always have been. Read this from 1984: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...

Those 1,568 create-react-app dependencies are maintained by people you have no formal relationship to, and are all versioned independently. Visual Studio is one monolithic package released by one of the largest companies on earth. Microsoft is not going to back door you and it has a huge incentive to stop anyone else from directly back dooring you via Visual Studio. On the other hand, the maintainer of the event-stream NPM package, with ~1.5 million weekly downloads, recently gave control to a stranger. They successfully back doored it and evaded detection for over a month. https://blog.npmjs.org/post/180565383195/details-about-the-e...

There's nothing special about "backend". It's normal for the client side bundle to contain many dependencies that came from NPM.

That's not the kind of security problem we're talking about here. https://blog.npmjs.org/post/180565383195/details-about-the-e...

You acknowledge security as "the real issue" in your comment. I don't know how to square that with the first sentence in your comment, "I just don't see how this matters." It matters because of security, like you said.

"Why" is hard, but Python's packaging system was created when global installation was just how packaging worked. There may have been exceptions, but the first local package installation tool I knew of was workingenv (2006). It was the predecessor of virtualenv, which I think led directly to pipenv.

What is a function?

The classes serve to close some functions over variables for convenience; the attr_readers serve as destructuring functions for convenience; the += replaces a recursive function for convenience and familiarity. The function with the += doesn't mutate any value and it remains pure from all callers' perspectives.

You're complaining about syntax, but this screencast is about semantics.

You only have to copy if your array is implemented as a simple linear sequence of memory addresses. More advanced implementations don't have to copy everything. E.g., Clojure's vectors (its array equivalent) are effectively O(1) for the common array operations that are O(1) on naive arrays, like indexing and insertion. But Clojure vectors are still purely functional. (The actual time for some of those ops is O(log32(n)), but log32(1,000,000) = 4, so it's effectively O(1).)

The term for this is "persistent data structures", usually implemented via trees, where replacing an object in a vector is implemented by building a new tree, reusing all of the old nodes except the ones that appear in the path from the root to the replaced node. That's why Clojure's Vector is log32; it's a 32 b-tree. (I'm writing this from memory and have little Clojure experience, but I'm pretty sure I have it right.)

Many languages have implementations now, but most aren't as fast as Clojure's. E.g., there's immutable.js: http://facebook.github.io/immutable-js/

Tweets aren't editable so no need to handle that. Deleted tweets can be honored by updating the timeline to be `old_timeline - deleted_tweets + new_tweets`.

He wasn't rebutting the code; he was rebutting the claims about following the C standard, which were made separate from the code. You missed this because its' buried in all of Linus' ranting. Linus merged these changes a few minutes later with no further discussion.

You're right; I should've written the second thing. Too late to change it now, but I would if I could do it without causing confusion.

One year of others' time saved over five years would make him a 1.2x programmer.

Top of the file:

""" Game of Set (Peter Norvig 2010-2015) """

It's the name of the problem being solved.

`set` is a built-in. He probably didn't want to smash it.

Defining a function and immediately calling it prevents pollution of module scope. Without it, `photo` would be exported.

The tests are in the same file because it makes the example self-contained, I assume.

The experiments are run 100,000 times because they have a random component and this exercises the system.

That typing is in realtime! I rehearse screencasts until they flow naturally like you see here; there's no content editing and no script. I basically record the whole thing from beginning to end, over and over, until it doesn't change significantly from run to run and I don't feel it catching anywhere.

I do edit out pauses to breathe, to drink water, sometimes to double-check my thinking about what to do next, and occasionally to open a second terminal and check something.

Destroy All Software is six years old, so I've had a lot of practice. Most DAS screencasts require a couple hours of initial silent prep, then around 10 full runs from beginning to end. When it starts to flow well (run #5, give or take), I fire up ScreenFlow and start doing each run as if it might be the final published version (because it might actually be). With these longer "from scratch" screencasts, I only make one or two attempts per day; by then my throat and brain are both pretty tired.

I also live stream these on Twitch before making the final version, so you can see the sausage being made if you like! It's basically the same as what you saw in this video, but the pauses are there, you get to hear me become confused sometimes and comment on my mistakes, and there's a bit of Q&A afterward. The schedule isn't fixed, but I try to tweet with a couple hours' notice (https://twitter.com/garybernhardt).

It depends on where you look. Hacker News is pathologically tilted toward negative sentiment, usually in the form of look-how-smart-I-am. I also announce these screencasts on Twitter, where the the response is universally positive (in six years, I can't remember a single rudely negative comment about a Destroy All Software screencast). Not that Twitter lacks its own problems, of course!

Not right now, but only because the coupon code was removed a while back for Reasons. I need to re-add that. If you like, free to email support@ in a few months to ask whether it's done.

The code to make screencasts free has been in for a while, but I rarely used it with the computation series because most of them didn't make sense in isolation. These new ones do make sense alone, so I'll probably do this more.

I don't work with distributors at all because they tend to (a) want some level of control over content and/or the legal right to modify and reuse it, (b) offer unfavorable royalty rates, and (c) have mixed quality levels between the works they host. I like that DAS is a comparatively small body of work that people know by name and trust to be good.

Sorry, that's fixed now. I accidentally had it cutting off at midnight UTC. I just pushed expiration out by another day (and it's now judged by Pacific time, and the page says that explicitly for good measure).

When I accept an invitation to speak at a conference, I say "Yes, but I don't want to you to publish a video. If that's OK, then I'm in." Also, you may not realize this, but a lot of conferences are for-profit. It's not as if I'm tricking them by springing that constraint on them after the fact, and many of them are making money from the speakers' free labor to begin with.

Second, many many people have tried to build screencasting businesses. One of them turned into an 800 lb gorilla. Most of the rest don't exist any more. AFAIK, DAS was the second subscription-based screencasting company to exist, with the only prior art being a short-lived subscription option offered by TekPub (which was later acquired by the 800 lb gorilla). DAS still exists today, is still independent, and is still (almost) my only source of income, while dozens or maybe hundreds of others have come and gone. I'm sorry if you don't like the way I exercise control over my wholly-owned works, but my business model combined with control over my content has allowed me to do this successfully for six years (modulo a very long break in the middle). And I've never charged money for anything recorded at a conference; that wouldn't feel right.

Likewise. I've thought about doing this for years, especially since there are so many great works that are rarely read. Now I'm afraid that it'll be haunted by the specter of the time when someone did it and infringed my commercial work and I yelled at them for it.

If I were building this service, I'd do what several people in this thread have told you to do, and what I've already told you to do on Twitter: I'd ask for permission and only record an article after that permission is received.

As I just said to you on Twitter (https://twitter.com/garybernhardt/status/874884772174196737), this is blatant and willful copyright infringement. Maybe the owners of the other works that you're currently infringing on don't care. But if you continue to do this, you will eventually encounter someone who does care. And if it goes on for a while, and then they notice, and then they sue you for lost revenue (which you will probably settle extremely unfavorably because the infringement is so blatant) then it will be neither enjoyable nor profitable for you. The American legal system doesn't care whether "no harm [was] intended" if you are depriving people of the use of their copyrighted works.

Pull all infringing works from the site temporarily (which means every recording). Email the authors of the infringed works, asking them for permission. Never post another recording without permission. Maybe it will be an awesome service.

Here's one huge difference: https://news.ycombinator.com/item?id=14550931

(Specifically, this site is depriving me of income.)

I posted a copyrighted work on Destroy All Software, which offers paid subscriptions to that same work. You found a link designed to be shared as a sample and decided to copy my commercial work in full, on your website, behind your own login wall. You didn't ask first, or even tell me that you'd done it.

Links to that work convert into paying customers, which is how I buy food and pay my mortgage. You're not only infringing on my copyrighted work, but also depriving my small business of revenue. Remove the infringing copy of my work from your site immediately.

One of Destroy All Software's primary value propositions (even included in the subtitle of the front page of destroyallsoftware.com) is terseness. My customers pay me more money because I produce small things. You can get quantity anywhere.

No, it's OK for this to be on HN. I'm doing an experiment with the compendium where the individual articles are publicly linkable, but navigating to one from the index requires a subscription.

What were you trying to do, locate your favorite commit?

That would explain why the commit frequency seemed to improbably high. I just updated it with correct numbers. Thanks.