gary_bernhardt

I removed the "power law" language from the post, other than a quick "this is often called a power law, which probably isn't correct" note. I don't want to get bogged down in statistics when all I really care about here is "it's fat and one sided".

I thought about trying to clarify this, but "power law" is the term that's been thrown around to describe this effect in software systems for many years. Really, I only care about the fat-one-sided-ness (for its practical implications); I don't care so much about the precise mathematical formulation.

Whoa, you're right! He referenced it neither by 7-character short hash nor by full hash, and I didn't think to check intermediate hash lengths. I've updated the post to reference that email.

It's possible to be a world-class programmer and think that test doubles are a silly waste of time. Many of the programmers whom I admire most think that. Nothing that I said precludes it. I now regret writing my monthly comment on the web.

I didn't say that you are wrong. I didn't say "that everyone with experience agrees with [me]". I specifically used the words "mostly favored by" twice. Mostly does not mean "everyone".

It's fine if you want to use different words. But you either have words for the different types or not. And if you have separate words, you either use the five existing ones or try to push five new ones. I think it's significant that you objected to my claim about the popular taxonomy without suggesting five alternative terms with even a fraction of the adoption. (I've built an entire career partly on popularizing this stuff and I've never even encountered a competing set of terms!)

I agree with you in general. In this case there's only one coherent taxonomy in widespread use so I think it's reasonable to say "just use it".

It's unfortunate that people who aren't already experts on a topic can't tell whether that kind of decree represents consensus or someone's idiosyncratic opinion (and there's plenty of both in general).

Framing is a different thing, though, and I can't comment there since I haven't re-read the whole article recently.

There are objects that demand to be interacted with; there are objects that allow only certain predefined interactions; there are objects that allow any interaction and record them all for later inspection; and there are objects that are simple implementations of interfaces whose "real" implementation is more complex. Each of these object types exists in practice, and each is clearly an example of some larger category.

One group of people says "these should all be called mocks". Another group says "these are mocks, stubs, spies, and fakes, respectively, and collectively these are called test doubles". You can prefer the simplicity of calling them all "mocks" (simplicity is nice) but that leaves you with no way to distinguish between the types.

These categories seem like hair-splitting if you've written relatively few tests using test doubles. Once you've written a few thousand, you start to wish for even finer-grained distinctions. This is how basically everything works as you get deeper into the details: you need words for the fine-grained distinctions.

As far as I know, there has never been a competing set of terms. The only major positions are "we should use [the words I mentioned above]", which is mostly favored by those who have used a lot of doubles; and "we should not use separate words at all", mostly favored by those who haven't used a lot of doubles.

Spies are a different thing: they allow any interaction, recording it all so that you can inspect it layer. Python's "mock" library, for example, is mostly a spy library.

You're probably thinking of Scott Alexander's nootropics survey. http://slatestarcodex.com/2016/03/01/2016-nootropics-survey-...

That doesn't contradict the quote that you provided. The quote just says "the compiler will reject the program at compile time [if there's no valid proof]", which is true.

I don't see the problem here. I said that Idris will reject the program if the proof fails. That's what you're saying too, unless I'm very confused. (It's late, so maybe I am?)

It's generally (or maybe universally) more difficult to "get" dependent typing than plain old ML-family static typing. I mean, this HN comments page alone has multiple threads where people don't think that the "x > y" proof example even works. For most programmers, that's how non-obvious the possibility of proving nontrivial properties of code is. Maybe I should change the wording in the OP to make it clear that I'm talking about the set of ideas required to use the language, not the characters that need to be typed into a computer to make it work.

This is a decent summary of why I'm doing it. Wikipedia is full of "high quality" content, where "high quality" means "directly exposing every detail that anyone ever thought to nitpick", and this topic is a nitpicker's paradise. There's value in that detail-heavy style, but it's difficult to learn from and it's a type of writing that I rarely want to read. As for opinions (and lack thereof), they prevent Wikipedia from saying many things that are both well-known and easily stated. The lack of clear summaries of widespread disagreeing opinions keeps our implicit knowledge implicit.

It doesn't say "type checking", though. It says "the language", which I think of as including the respective preludes.

There are online conferences, but they're very different from the in-person ones. Here are some properties of in-person conferences that are difficult to replace.

* Some talks are long, intricate stories, and you get much more out of them by paying close attention. (David Beazley comes to mind.) From experience, I can say that I'm far more likely to divide my attention at home than in an in-person talk, and I'm not unusual here.

* Sometimes, there's no talk that grabs you in a time slot, but that can lead to pleasant surprises. This is especially effective if you intentionally choose topics that are unfamiliar, then let the physicality of the room force you to pay attention (because it would be rude not to).

* Running into people randomly in the hall makes for serendipitous conversations that wouldn't have happened otherwise. People get jobs this way; open source projects start this way. The global Code Retreat movement started this way due to a conversation at CodeMash years ago. (That conversation began by us talking about the ethics of the meat in the sandwiches.)

* If there are people who you put on a pedestal as untouchable divine entities, meeting them will usually fix that. I don't mean that they don't deserve respect, but simply that everyone is human. You might be appalled to learn that your favorite programming tool's author likes music that you find repugnant. This is valuable; we're people. You'll be less likely to appeal to authority unthinkingly if you've been appalled by authorities' taste in music.

* It's vulgar to put this so bluntly, but a lot of power is brokered in person at conferences. Not through mysterious back channel conspiracies, but through normal human interactions. If I've met you in person, I'm more likely to trust you; you're more likely to come to mind when someone asks "do you know anyone who can do x?"; etc. Anyone who doesn't participate is at a disadvantage here (and many surely don't care, which is fine).

(Source: I've spoken at about 40 conferences, give or take, and attended many without speaking as well; I've made a lot of friends who do the same; I shot an unpublished documentary that was sort of about this; and I have repugnant taste in music.)

Yep, that was my motivation: to hint at deeper connections to programming at large, rather than focusing on technical concerns that are confined to parser implementation and therefore esoteric to an outsider.

It's not part of the Python grammar as specified in the file called Grammar in the canonical implementation of the language (https://github.com/python/cpython/blob/master/Grammar/Gramma...). Of course it's part of the grammar in the larger sense. I don't think that that distinction is important when trying to convince someone with no theoretical background to learn these topics, which is what the video in question is trying to do.

I went back and forth on that statement for exactly this reason, but kept it because the whitespace is handled in the lexer, as you mentioned. The Python grammar itself is context-free, and the grammar is the only part that I expect the series to examine.

Extreme pro-Python statements about "one way to do it" are usually made by relative newcomers who are caught up in their enthusiasm for purity. (This exuberance is natural, and is a big part of the language adoption cycle.) Extreme anti-Python statements about "one way to do it" are usually made by outsiders viewing Python through accounts given by enthusiastic newcomers. This exuberant-newcomers-vs-skeptical-outsiders dichotomy isn't representative of the actual Python culture, which is much more sensible and practical than all of this implies. If you go to PyCon and attend talks by long-time Python folks, you won't find them advocating anything like blind adherence to "one way to do it".

To get specific, the wording in PEP 20 is: "there should be one, and preferably only one, obvious way to do it". Note that the dominant idea here is that there should exist some obvious way. It's merely preferable that there be only one way. Again: this is sensible, but it's not good fodder for newcomers craving purity, or for detractors craving straw men.

PEP 20 itself is often elevated to religious levels of importance, as if it were a design document that served as a blueprint for the design of Python. It's absolutely not that; it was written by Tim Peters (not Guido!) fully eight years after Python's first release. Here's the original email that Tim sent to comp.lang.python on 4 June, 1999: https://groups.google.com/d/msg/comp.lang.python/B_VxeTBClM0.... Note how he finishes: "If the answer to any Python design issue isn't obvious after reading those -- well, I just give up <wink>." Tim is very particular about his winks, and that's not even a <0.5 wink> or a <0.9 wink>, but a full, unqualified <wink>.

To put all of those pieces together: (1) we have a short, tongue-in-cheek document written after-the-fact. (2) It's misinterpreted as a design document for an entire language and ecosystem. (3) A secondary portion of one of its points is misinterpreted to be the entirety of the point. (4) This is done by exuberant newcomers and skeptical detractors who don't accurately represent the Python culture as a whole. This is why you get the impression that the community is adamant about "one way to do it". It's a reasonable extrapolation from the visible evidence, but it's not true.

Then keep exactly your preferred high-performance database design, but derive its data from maildir, such that all mail is persisted in maildir first.

There's nothing stopping a mail client from maintaining arbitrary indexes, caches, etc. in addition to the maildir.

I will now justify some jokes that I made four years ago.

Most of my work that you've praised so highly concerns improving software quality and the experience of programming. Wat is about one of the underlying causes of low software quality and unpleasant experiences of programming.

Specifically, none of that JavaScript behavior is undefined. Brendan Eich specifically chose to define all of those conversions in those ways. JavaScript was designed to do what the programmer doesn't want (silently perform nonsensical conversions) rather than what they do want (throw an error). There are reasons for this, but in its current use context that decision is not what we want. Many people watch Wat and go on to learn all of this; there are dozens of blog posts, Stack Overflow questions, etc. where the behavior in Wat is dissected in detail. For example: http://stackoverflow.com/questions/9032856/what-is-the-expla... or http://blog.caplin.com/2012/01/27/the-why-of-wat/

Many programmers think that their tools work reliably; that they don't encounter problems often; that popular programming systems are fundamentally reasonable; that mistakes are always the programmer's fault. These people are wrong, to everyone's detriment. The easiest remedy is to show them, rather than tell them. Many people -- far too many now to count -- have said that Wat made them begin to realize how broken our tools are. That's a prerequisite to engaging with my (and others') longer-form work on improving things.

I could do a talk explaining all of this with examples and so on, but it would be full-length, not a lightning talk. My full-length talks get maybe 100k views, so the audience would be 5% of Wat's 2m views. Wat must be short, and therefore context-free, to work.

pain is information

Yes, that's very common formatting (except for the whitespace immediately inside the square brackets, which violates PEP 8, but that's incidental to the question of line breaks).

Those are tiny screencasts, some as short as just a few frames, embedded in a Keynote file. I re-recorded some of them several times in my hotel room that afternoon to make sure that there weren't distracting typos. I can't get to that level of polish when doing it truly live, but with enough practice runs I can get close enough that no one is ever waiting for me.

Thanks. It takes a lot of effort to make live coding that smooth. The initial practice run of a 12-minute screencast was often 30-60 minutes, which would be boring and usually contain less information than the shorter final version. That difference came mostly from sinking effort into it: continuous simplification of examples, explanation, and even wording; and practicing until I (as the speaker) found myself engaged the whole time, with no spots where my attention dipped significantly.

Huh? Imperative programming is still the dominant programming paradigm, as it's been since the first programmable computers.

You're talking about implementation now. The text you quoted said "references' introduction into high level languages", not "references' use in the implementation of high level languages". The quote was about languages' conceptual models, not their underlying implementation forced by a particular type of CPU that code written in the language happens to be running on. A language can present value semantics while doing structural sharing using references underneath, as Clojure's persistent data types do.

Rewind to 2006. Should we implement Python in Python? Of course not; it's not useful! PyPy should not be done! It's literally 50 times slower than CPython!

Fortunately, the PyPy folks have stuck with it, and PyPy is now faster than CPython across the board. Many other languages have also been implemented using its considerable infrastructure. Compiler experts have been minted from scratch. Should it have been done? Yes.

Even with the vulgar assumption that "practical utility" is the only source of good, this type of project is good.

In most languages, a type mismatch would always correspond directly to a type name mismatch. In e.g. Python (since it has a clear module system), if I know that f() returns a datetime.datetime, and I know that g(t) takes a datetime.datetime, then I know that they will compose. (Modulo bugs of other types, of course.)

When using NPM, I don't have that guarantee. The docs for these libraries could clearly state that they'll integrate around the datetime type, but that may be false in practice. And I'll only know that ahead of time if (1) I know that they both use datetime internally, (2) I know exactly the versions of datetime that they use, and (3) I know exactly how datetime changed in between those versions. With non-vendoring package management, I don't have to know any of these things.