WEBVTT 00:00:00.000 --> 00:00:01.350 align:middle line:90% 00:00:01.350 --> 00:00:03.870 align:middle line:84% I want to start this talk off, I want 00:00:03.870 --> 00:00:05.850 align:middle line:84% to contextualize this talk with something 00:00:05.850 --> 00:00:07.350 align:middle line:84% I think is sort of very culturally 00:00:07.350 --> 00:00:10.500 align:middle line:84% relevant, the thing that you see on the screen, the belief 00:00:10.500 --> 00:00:12.840 align:middle line:84% that many of us have that we are not 00:00:12.840 --> 00:00:17.376 align:middle line:84% real programmers for some amorphous definition of real. 00:00:17.376 --> 00:00:20.820 align:middle line:84% The danger, the terrible thing about this belief, 00:00:20.820 --> 00:00:24.787 align:middle line:84% is that it functions even if you don't know that you believe it. 00:00:24.787 --> 00:00:26.370 align:middle line:84% And the wonderful thing about the term 00:00:26.370 --> 00:00:28.800 align:middle line:84% that we have for it, imposter syndrome, 00:00:28.800 --> 00:00:31.740 align:middle line:84% is that upon hearing the term, people can suddenly 00:00:31.740 --> 00:00:33.720 align:middle line:84% realize that they've had this belief for years 00:00:33.720 --> 00:00:35.730 align:middle line:84% or, in some cases, decades and that it 00:00:35.730 --> 00:00:38.863 align:middle line:84% was working even though they didn't know they had it. 00:00:38.863 --> 00:00:40.530 align:middle line:84% This talk isn't about imposter syndrome, 00:00:40.530 --> 00:00:43.110 align:middle line:84% but we're going to look for this kind of belief 00:00:43.110 --> 00:00:46.140 align:middle line:84% underneath claims that programmers make, often 00:00:46.140 --> 00:00:50.070 align:middle line:84% in argument with each other, claims like I write tests, 00:00:50.070 --> 00:00:52.362 align:middle line:90% so I don't need types. 00:00:52.362 --> 00:00:54.570 align:middle line:84% We're going to look for what people believe when they 00:00:54.570 --> 00:00:58.440 align:middle line:84% say things like this, the things they believe and aren't saying. 00:00:58.440 --> 00:01:01.150 align:middle line:84% The title, as I said, is Ideology. 00:01:01.150 --> 00:01:02.580 align:middle line:90% I am Gary Bernhardt. 00:01:02.580 --> 00:01:05.340 align:middle line:84% And when I use the word ideology in this talk, 00:01:05.340 --> 00:01:07.060 align:middle line:84% I mean it in a very specific way. 00:01:07.060 --> 00:01:08.820 align:middle line:84% I don't mean that the cable news network 00:01:08.820 --> 00:01:12.480 align:middle line:84% definition or the popular pop culture definition of just 00:01:12.480 --> 00:01:13.998 align:middle line:90% political belief. 00:01:13.998 --> 00:01:15.540 align:middle line:84% And to see exactly what I mean, we'll 00:01:15.540 --> 00:01:18.000 align:middle line:84% take a brief detour into Donald Rumsfeld 00:01:18.000 --> 00:01:21.240 align:middle line:90% before we get to computers. 00:01:21.240 --> 00:01:24.720 align:middle line:84% He once said something in public about known knowns, 00:01:24.720 --> 00:01:26.868 align:middle line:84% known unknowns, and unknown unknowns, 00:01:26.868 --> 00:01:28.410 align:middle line:84% which earned him ridicule, because he 00:01:28.410 --> 00:01:31.740 align:middle line:84% made fine grained distinctions between words. 00:01:31.740 --> 00:01:35.910 align:middle line:84% And for those who don't remember, the thing that he 00:01:35.910 --> 00:01:38.078 align:middle line:84% said, I'll summarize it for you very quickly, 00:01:38.078 --> 00:01:39.870 align:middle line:84% there are things in this world that we know 00:01:39.870 --> 00:01:42.180 align:middle line:90% and we know that we know them. 00:01:42.180 --> 00:01:43.290 align:middle line:90% So known knowns. 00:01:43.290 --> 00:01:46.440 align:middle line:84% For example, Turing equivalent computers cannot solve 00:01:46.440 --> 00:01:47.760 align:middle line:90% the halting problem. 00:01:47.760 --> 00:01:49.590 align:middle line:84% We have never built a computer nor have 00:01:49.590 --> 00:01:51.810 align:middle line:84% we imagined one that can run a program that when 00:01:51.810 --> 00:01:54.420 align:middle line:84% given a second arbitrary program decides 00:01:54.420 --> 00:01:57.278 align:middle line:84% whether that second program terminates it or not. 00:01:57.278 --> 00:01:57.820 align:middle line:90% We know this. 00:01:57.820 --> 00:02:00.340 align:middle line:84% We have proofs going back to 1936. 00:02:00.340 --> 00:02:01.500 align:middle line:90% It's a known known. 00:02:01.500 --> 00:02:03.250 align:middle line:84% There are other things that we don't know, 00:02:03.250 --> 00:02:05.110 align:middle line:84% but we at least know that we don't 00:02:05.110 --> 00:02:07.150 align:middle line:90% know them, known unknowns. 00:02:07.150 --> 00:02:10.539 align:middle line:84% For example, does p equal np, the most famous open problem 00:02:10.539 --> 00:02:12.010 align:middle line:90% in computer science. 00:02:12.010 --> 00:02:13.940 align:middle line:90% We know this question very well. 00:02:13.940 --> 00:02:17.000 align:middle line:90% So it is a known unknown. 00:02:17.000 --> 00:02:19.000 align:middle line:84% And finally, there are things that we don't know 00:02:19.000 --> 00:02:21.190 align:middle line:84% and we don't even realize it, unknown unknowns. 00:02:21.190 --> 00:02:23.860 align:middle line:84% And this is what Rumsfeld was concerned with, 00:02:23.860 --> 00:02:25.560 align:middle line:84% because he was talking about war. 00:02:25.560 --> 00:02:27.310 align:middle line:84% And the classic historical example of this 00:02:27.310 --> 00:02:30.040 align:middle line:84% is the Japanese attack on Pearl Harbor. 00:02:30.040 --> 00:02:32.440 align:middle line:84% It's not that the American military didn't know 00:02:32.440 --> 00:02:34.010 align:middle line:90% the probability of the attack. 00:02:34.010 --> 00:02:35.920 align:middle line:84% It's that the concept of the attack 00:02:35.920 --> 00:02:40.473 align:middle line:84% wasn't even something that they were worried about. 00:02:40.473 --> 00:02:42.640 align:middle line:84% And this is where Rumsfeld stopped, because he's not 00:02:42.640 --> 00:02:45.520 align:middle line:84% a programmer, and he is happy to see 00:02:45.520 --> 00:02:48.463 align:middle line:84% two binary variables and only three entries in a table. 00:02:48.463 --> 00:02:50.880 align:middle line:90% [LAUGHTER] 00:02:50.880 --> 00:02:54.630 align:middle line:84% But this being Strange Loop, let's scoot this up. 00:02:54.630 --> 00:02:57.060 align:middle line:84% And the obvious fourth entry here 00:02:57.060 --> 00:02:59.890 align:middle line:84% is things that you know but you do not know that you know them. 00:02:59.890 --> 00:03:03.930 align:middle line:84% And this is what I mean by the word ideology in this talk. 00:03:03.930 --> 00:03:07.800 align:middle line:84% This is the type of belief that imposter syndrome is. 00:03:07.800 --> 00:03:11.930 align:middle line:84% It functions even though you don't know it's there. 00:03:11.930 --> 00:03:14.920 align:middle line:84% So now we can finally get to computer things. 00:03:14.920 --> 00:03:17.710 align:middle line:84% I want to begin for our first example 00:03:17.710 --> 00:03:21.760 align:middle line:84% with a pair of beliefs, a pair of claims that are often 00:03:21.760 --> 00:03:23.230 align:middle line:84% made by static language advocates 00:03:23.230 --> 00:03:25.090 align:middle line:84% versus dynamic language advocates. 00:03:25.090 --> 00:03:27.858 align:middle line:84% But that means I have to define what I mean by static. 00:03:27.858 --> 00:03:29.650 align:middle line:84% So in this talk, we're talking about the ML 00:03:29.650 --> 00:03:30.580 align:middle line:90% family of languages. 00:03:30.580 --> 00:03:32.260 align:middle line:90% We're talking about Haskell. 00:03:32.260 --> 00:03:34.120 align:middle line:84% We're talking about Rust, although maybe 00:03:34.120 --> 00:03:36.305 align:middle line:90% to a little bit lesser extent. 00:03:36.305 --> 00:03:37.930 align:middle line:84% When I say static, I mean these things. 00:03:37.930 --> 00:03:41.980 align:middle line:84% I do not mean C and Java and other curly brace languages 00:03:41.980 --> 00:03:46.530 align:middle line:84% with very weak type systems relatively speaking. 00:03:46.530 --> 00:03:49.020 align:middle line:84% So these two beliefs about-- or these two statements that 00:03:49.020 --> 00:03:51.220 align:middle line:84% people make about types and tests. 00:03:51.220 --> 00:03:53.670 align:middle line:84% The first is going to be uttered by a hypothetical static 00:03:53.670 --> 00:03:54.900 align:middle line:90% language advocate. 00:03:54.900 --> 00:03:57.060 align:middle line:84% And they say, Python needs tests because there's 00:03:57.060 --> 00:03:58.917 align:middle line:90% no type checker. 00:03:58.917 --> 00:04:00.500 align:middle line:84% I hope that everyone has heard someone 00:04:00.500 --> 00:04:01.792 align:middle line:90% say something like this before. 00:04:01.792 --> 00:04:03.768 align:middle line:84% Of course, not all static language programmers 00:04:03.768 --> 00:04:04.310 align:middle line:90% believe this. 00:04:04.310 --> 00:04:05.860 align:middle line:90% Probably most even don't. 00:04:05.860 --> 00:04:08.600 align:middle line:84% But this is the thing that people say. 00:04:08.600 --> 00:04:11.120 align:middle line:84% On the other hand, dynamic language advocates 00:04:11.120 --> 00:04:13.070 align:middle line:84% will sometimes say, I write tests anyway, 00:04:13.070 --> 00:04:15.220 align:middle line:90% so I don't need a type checker. 00:04:15.220 --> 00:04:17.220 align:middle line:84% And these are sort of exact opposite statements. 00:04:17.220 --> 00:04:18.920 align:middle line:84% One is saying that types replace tests. 00:04:18.920 --> 00:04:21.440 align:middle line:84% The other is saying the tests replace types. 00:04:21.440 --> 00:04:24.950 align:middle line:84% So either tests and types are deeply equivalent in a way 00:04:24.950 --> 00:04:27.020 align:middle line:84% that we've never really discovered 00:04:27.020 --> 00:04:32.263 align:middle line:84% but somehow these people know, or somebody is wrong. 00:04:32.263 --> 00:04:33.680 align:middle line:84% And I think it's the second thing. 00:04:33.680 --> 00:04:36.430 align:middle line:90% 00:04:36.430 --> 00:04:39.040 align:middle line:84% So let's dig into the way that these two programmers think 00:04:39.040 --> 00:04:41.320 align:middle line:84% about correctness, because correctness is really 00:04:41.320 --> 00:04:43.940 align:middle line:84% what we're talking about here, and the way that the languages 00:04:43.940 --> 00:04:45.940 align:middle line:84% that they use inform their understanding of what 00:04:45.940 --> 00:04:46.870 align:middle line:90% correctness even is. 00:04:46.870 --> 00:04:49.660 align:middle line:84% And we'll start with the dynamic language programmer. 00:04:49.660 --> 00:04:51.820 align:middle line:84% We're going to use an example of converting an RGB 00:04:51.820 --> 00:04:52.960 align:middle line:90% color to an HSV color. 00:04:52.960 --> 00:04:54.312 align:middle line:90% So a very simple function. 00:04:54.312 --> 00:04:56.020 align:middle line:84% We're not even going to look at the body. 00:04:56.020 --> 00:04:58.780 align:middle line:84% It just does the math on the color coordinates or color 00:04:58.780 --> 00:05:01.510 align:middle line:90% components. 00:05:01.510 --> 00:05:03.370 align:middle line:84% And hopefully a dynamic language programmer 00:05:03.370 --> 00:05:04.810 align:middle line:90% is going to write some tests. 00:05:04.810 --> 00:05:06.790 align:middle line:84% Maybe they write a test for a medium gray, 00:05:06.790 --> 00:05:11.680 align:middle line:84% a test for a white, a test for a black, and hopefully some non 00:05:11.680 --> 00:05:13.090 align:middle line:90% grayscale colors as well. 00:05:13.090 --> 00:05:14.830 align:middle line:84% And they end up with all these points 00:05:14.830 --> 00:05:17.560 align:middle line:84% where they have written these very specific tests. 00:05:17.560 --> 00:05:19.150 align:middle line:84% They show the behavior of the system 00:05:19.150 --> 00:05:21.520 align:middle line:84% and this very, this one exact situation. 00:05:21.520 --> 00:05:24.400 align:middle line:84% And from this, they infer that now the program 00:05:24.400 --> 00:05:28.090 align:middle line:84% is correct for this sort of region of program 00:05:28.090 --> 00:05:32.090 align:middle line:90% behavior of RGB inputs. 00:05:32.090 --> 00:05:35.870 align:middle line:84% Around this, there is this region of undefined behavior 00:05:35.870 --> 00:05:38.960 align:middle line:84% that the dynamic language forces to be 00:05:38.960 --> 00:05:41.100 align:middle line:84% a valid program in the sense that it will run, 00:05:41.100 --> 00:05:44.450 align:middle line:84% but the programmer has not considered what will happen. 00:05:44.450 --> 00:05:47.433 align:middle line:84% Things like what if there's a negative number? 00:05:47.433 --> 00:05:49.850 align:middle line:84% Hopefully the programmer thought of that and wrote a test. 00:05:49.850 --> 00:05:51.645 align:middle line:84% Probably a lot of people would not. 00:05:51.645 --> 00:05:53.270 align:middle line:84% What if there's a number greater than 1 00:05:53.270 --> 00:05:58.340 align:middle line:84% because the color components are 0 to 1 value range? 00:05:58.340 --> 00:06:00.730 align:middle line:84% What if we pass in integers instead of floats? 00:06:00.730 --> 00:06:02.730 align:middle line:84% Well, if it's JavaScript, there are no integers, 00:06:02.730 --> 00:06:04.700 align:middle line:90% so it doesn't matter. 00:06:04.700 --> 00:06:06.290 align:middle line:84% If it's Python 2, there are integers, 00:06:06.290 --> 00:06:08.030 align:middle line:84% and integer division returns integer. 00:06:08.030 --> 00:06:11.510 align:middle line:84% In Python 3, there are integers, but integer division returns 00:06:11.510 --> 00:06:12.355 align:middle line:90% float. 00:06:12.355 --> 00:06:13.730 align:middle line:84% So in Python, it actually depends 00:06:13.730 --> 00:06:15.022 align:middle line:90% on the version of the language. 00:06:15.022 --> 00:06:17.350 align:middle line:90% 00:06:17.350 --> 00:06:20.147 align:middle line:84% What if we pass in an extra element in the tuple? 00:06:20.147 --> 00:06:21.730 align:middle line:84% Well, if we unpacked it with indexing, 00:06:21.730 --> 00:06:23.740 align:middle line:84% then this will probably be silently ignored. 00:06:23.740 --> 00:06:25.960 align:middle line:84% If we unpacked it with tuple unpacking in Python, 00:06:25.960 --> 00:06:27.085 align:middle line:90% it will throw an exception. 00:06:27.085 --> 00:06:28.770 align:middle line:84% So it depends again on the language. 00:06:28.770 --> 00:06:29.770 align:middle line:90% What if we pass in null? 00:06:29.770 --> 00:06:31.540 align:middle line:84% This is the ever present question 00:06:31.540 --> 00:06:33.340 align:middle line:84% in most mainstream programming languages 00:06:33.340 --> 00:06:36.160 align:middle line:84% that most programmers don't consider for most functions, 00:06:36.160 --> 00:06:38.740 align:middle line:84% because it would be exhausting to do so. 00:06:38.740 --> 00:06:42.050 align:middle line:84% What happens if we pass in something like a date time? 00:06:42.050 --> 00:06:43.900 align:middle line:84% Well, Ruby's date time defines most 00:06:43.900 --> 00:06:47.113 align:middle line:84% of the mathematical operators for reasons. 00:06:47.113 --> 00:06:47.840 align:middle line:90% [LAUGHTER] 00:06:47.840 --> 00:06:51.135 align:middle line:84% And so this may actually return a value. 00:06:51.135 --> 00:06:52.510 align:middle line:84% And of course, in JavaScript this 00:06:52.510 --> 00:06:55.510 align:middle line:84% will return nonsense, because all expressions 00:06:55.510 --> 00:06:59.260 align:middle line:90% in JavaScript return something. 00:06:59.260 --> 00:07:02.440 align:middle line:84% So this is the reality of dynamic language programming, 00:07:02.440 --> 00:07:04.270 align:middle line:84% which everyone who uses those languages 00:07:04.270 --> 00:07:06.945 align:middle line:84% knows but doesn't like to talk about. 00:07:06.945 --> 00:07:09.070 align:middle line:84% Of course, there is this central region of behavior 00:07:09.070 --> 00:07:10.810 align:middle line:90% that we think of as correct. 00:07:10.810 --> 00:07:13.957 align:middle line:84% So maybe we think that 0.7 will give us the correct conversion 00:07:13.957 --> 00:07:15.790 align:middle line:84% and 0.3 will give us the correct conversion, 00:07:15.790 --> 00:07:18.280 align:middle line:84% even though we never wrote tests for those. 00:07:18.280 --> 00:07:21.370 align:middle line:84% So the reality is that that behavior is also 00:07:21.370 --> 00:07:22.870 align:middle line:84% undefined in the sense that we don't 00:07:22.870 --> 00:07:25.037 align:middle line:84% have any concrete evidence of what it's going to do. 00:07:25.037 --> 00:07:28.720 align:middle line:84% We just make this inference in our minds that these tests, 00:07:28.720 --> 00:07:31.360 align:middle line:84% these points turn into a generalized region 00:07:31.360 --> 00:07:33.570 align:middle line:90% of program behavior. 00:07:33.570 --> 00:07:35.590 align:middle line:90% Usually that belief is correct. 00:07:35.590 --> 00:07:39.670 align:middle line:84% Sometimes it's not, and that's why bugs happen. 00:07:39.670 --> 00:07:42.610 align:middle line:84% And the sort of way to summarize all of this 00:07:42.610 --> 00:07:45.480 align:middle line:90% is that tests are only examples. 00:07:45.480 --> 00:07:47.920 align:middle line:84% They do not establish categories of behavior. 00:07:47.920 --> 00:07:49.240 align:middle line:90% They can't do it. 00:07:49.240 --> 00:07:55.660 align:middle line:84% Humans imagine that they do it, but that is not actually true. 00:07:55.660 --> 00:07:58.800 align:middle line:84% So that is the dynamic language programmer's sort 00:07:58.800 --> 00:08:00.150 align:middle line:90% of view of correctness. 00:08:00.150 --> 00:08:02.520 align:middle line:84% They have to make this sort of leap of faith 00:08:02.520 --> 00:08:08.150 align:middle line:84% that is not justified by any kind of objective reasoning. 00:08:08.150 --> 00:08:09.635 align:middle line:84% Now let's turn to static languages. 00:08:09.635 --> 00:08:12.010 align:middle line:84% If you think I'm picking on dynamic language programmers, 00:08:12.010 --> 00:08:13.003 align:middle line:90% just wait. 00:08:13.003 --> 00:08:13.949 align:middle line:90% [LAUGHS] 00:08:13.949 --> 00:08:14.958 align:middle line:90% 00:08:14.958 --> 00:08:16.500 align:middle line:84% A static language programmer is going 00:08:16.500 --> 00:08:18.850 align:middle line:84% to start by, unsurprisingly, defining some types. 00:08:18.850 --> 00:08:20.770 align:middle line:84% Here we have an RGB type that's three doubles. 00:08:20.770 --> 00:08:23.290 align:middle line:84% We have an HSV type that's three doubles. 00:08:23.290 --> 00:08:24.640 align:middle line:90% I'm assuming nominal typing. 00:08:24.640 --> 00:08:29.420 align:middle line:84% So these types cannot be used in each other's place. 00:08:29.420 --> 00:08:32.242 align:middle line:84% We'll define a function whose type is RGB to HSV. 00:08:32.242 --> 00:08:34.159 align:middle line:84% So this function takes one of those RGB tuples 00:08:34.159 --> 00:08:36.200 align:middle line:90% and returns an HSV tuple. 00:08:36.200 --> 00:08:37.640 align:middle line:90% Very unsurprising. 00:08:37.640 --> 00:08:40.320 align:middle line:84% Again, we're not concerned with its body. 00:08:40.320 --> 00:08:43.360 align:middle line:84% And now suddenly we have in our heads 00:08:43.360 --> 00:08:45.210 align:middle line:84% the same region of programmed behavior 00:08:45.210 --> 00:08:48.450 align:middle line:84% that the dynamic language programmer had. 00:08:48.450 --> 00:08:51.900 align:middle line:84% And again, it contains things like 000, 111. 00:08:51.900 --> 00:08:55.980 align:middle line:84% We believe that the conversion will happen correctly 00:08:55.980 --> 00:08:58.810 align:middle line:90% for all these values. 00:08:58.810 --> 00:09:01.520 align:middle line:84% But that undefined space is now impossible. 00:09:01.520 --> 00:09:03.670 align:middle line:84% And this is the most obvious implication 00:09:03.670 --> 00:09:05.800 align:middle line:90% of a static type system. 00:09:05.800 --> 00:09:09.100 align:middle line:84% It makes all of those undefined, all 00:09:09.100 --> 00:09:12.220 align:middle line:84% those undesirable situations a compilation error. 00:09:12.220 --> 00:09:15.880 align:middle line:84% So we cannot pass in a fourth argument or a fourth value 00:09:15.880 --> 00:09:18.718 align:middle line:84% in the tuple, because this is not a legal program. 00:09:18.718 --> 00:09:21.260 align:middle line:84% In a dynamic language, we have to ask ourselves the question, 00:09:21.260 --> 00:09:22.552 align:middle line:90% what are the semantics of this? 00:09:22.552 --> 00:09:24.580 align:middle line:84% And we have to ask that for an infinite number 00:09:24.580 --> 00:09:26.510 align:middle line:90% of unanticipated situations. 00:09:26.510 --> 00:09:28.330 align:middle line:84% In a static language, the question 00:09:28.330 --> 00:09:30.640 align:middle line:84% is wrong, because this is not a program. 00:09:30.640 --> 00:09:32.530 align:middle line:90% This is not a legal program. 00:09:32.530 --> 00:09:34.960 align:middle line:84% And likewise for null, which these languages don't have, 00:09:34.960 --> 00:09:36.970 align:middle line:90% so that problem goes away. 00:09:36.970 --> 00:09:40.450 align:middle line:84% Likewise for things like passing in a date time 00:09:40.450 --> 00:09:43.380 align:middle line:84% or passing in an HSV when an RGB is expected. 00:09:43.380 --> 00:09:47.230 align:middle line:84% All the standard static typing stuff. 00:09:47.230 --> 00:09:50.860 align:middle line:90% But what about these cases? 00:09:50.860 --> 00:09:53.360 align:middle line:84% Negative numbers and numbers greater than 1. 00:09:53.360 --> 00:09:55.240 align:middle line:84% Well, if you're an Idris, then you, 00:09:55.240 --> 00:09:56.968 align:middle line:84% I don't know, write a proof somehow. 00:09:56.968 --> 00:09:58.760 align:middle line:84% I don't really understand how that happens. 00:09:58.760 --> 00:10:01.190 align:middle line:84% But by magic, the compiler can make 00:10:01.190 --> 00:10:06.163 align:middle line:90% these impossible situations. 00:10:06.163 --> 00:10:07.830 align:middle line:84% But in most static functional languages, 00:10:07.830 --> 00:10:10.870 align:middle line:90% we don't have that capability. 00:10:10.870 --> 00:10:14.070 align:middle line:84% So there is this region of the category of behavior 00:10:14.070 --> 00:10:19.090 align:middle line:84% that we told the type system is allowed that is actually wrong. 00:10:19.090 --> 00:10:22.620 align:middle line:84% And so what we're seeing here is types are only categories. 00:10:22.620 --> 00:10:25.920 align:middle line:84% And specifically, the granularity of the categories 00:10:25.920 --> 00:10:27.720 align:middle line:90% is limited by the type system. 00:10:27.720 --> 00:10:29.280 align:middle line:84% And in current languages, it's still 00:10:29.280 --> 00:10:34.630 align:middle line:84% quite coarse, current mainstream functional languages. 00:10:34.630 --> 00:10:36.610 align:middle line:84% So hopefully the static language programmer 00:10:36.610 --> 00:10:42.280 align:middle line:84% writes some tests in there and characterizes that behavior, 00:10:42.280 --> 00:10:44.800 align:middle line:84% because that is the only path they have left. 00:10:44.800 --> 00:10:46.750 align:middle line:90% The type system cannot do it. 00:10:46.750 --> 00:10:49.150 align:middle line:84% And they probably use QuickCheck or something fancy 00:10:49.150 --> 00:10:51.610 align:middle line:84% like that as opposed to the more vulgar 00:10:51.610 --> 00:10:53.770 align:middle line:84% tools that are used in most dynamic languages. 00:10:53.770 --> 00:10:56.260 align:middle line:84% But still, they need tests, and they 00:10:56.260 --> 00:10:58.630 align:middle line:84% have to make that same inference, that same jump 00:10:58.630 --> 00:11:01.780 align:middle line:84% to believing that they've characterized that region even 00:11:01.780 --> 00:11:05.100 align:middle line:90% though they only have examples. 00:11:05.100 --> 00:11:08.690 align:middle line:84% QuickCheck just makes more examples. 00:11:08.690 --> 00:11:10.570 align:middle line:84% So these are two very different ways 00:11:10.570 --> 00:11:12.280 align:middle line:90% to think about programming. 00:11:12.280 --> 00:11:14.773 align:middle line:84% And the languages force you into these ways 00:11:14.773 --> 00:11:16.690 align:middle line:84% of thinking about programming and specifically 00:11:16.690 --> 00:11:19.000 align:middle line:90% about correctness. 00:11:19.000 --> 00:11:21.070 align:middle line:84% And now we can go back to these things 00:11:21.070 --> 00:11:24.850 align:middle line:84% that these two people are arguing with each other say. 00:11:24.850 --> 00:11:27.457 align:middle line:84% When a static language programmer says that Python 00:11:27.457 --> 00:11:29.290 align:middle line:84% needs tests because there's no type checker, 00:11:29.290 --> 00:11:34.360 align:middle line:84% I think that it is motivated by a belief that they won't state, 00:11:34.360 --> 00:11:37.090 align:middle line:84% they probably won't even own up to, but I think that the belief 00:11:37.090 --> 00:11:40.150 align:middle line:84% that's functioning here is that correctness comes exclusively 00:11:40.150 --> 00:11:43.780 align:middle line:84% from categories, which would be true if you had an arbitrarily 00:11:43.780 --> 00:11:46.730 align:middle line:84% powerful type system, which you don't. 00:11:46.730 --> 00:11:48.230 align:middle line:84% Now, you won't get them to say this. 00:11:48.230 --> 00:11:49.250 align:middle line:90% They will deny this. 00:11:49.250 --> 00:11:54.110 align:middle line:84% And that is how these kinds of beliefs function. 00:11:54.110 --> 00:11:56.598 align:middle line:84% They structure the things you're saying. 00:11:56.598 --> 00:11:58.390 align:middle line:84% And maybe this one is not quite so obvious, 00:11:58.390 --> 00:12:00.390 align:middle line:84% but I think for the dynamic language programmer, 00:12:00.390 --> 00:12:02.330 align:middle line:84% it is much more obvious that they 00:12:02.330 --> 00:12:05.810 align:middle line:84% believe that correctness comes exclusively from examples. 00:12:05.810 --> 00:12:08.510 align:middle line:84% Because they've never used a static type system. 00:12:08.510 --> 00:12:10.310 align:middle line:84% So when they think of this other thing 00:12:10.310 --> 00:12:14.330 align:middle line:84% that people use to try to form beliefs about correctness, 00:12:14.330 --> 00:12:17.390 align:middle line:84% they can only imagine it in terms of the thing they know, 00:12:17.390 --> 00:12:20.718 align:middle line:84% tests, which are a totally different kind of thing. 00:12:20.718 --> 00:12:22.760 align:middle line:84% And so they say things like, I write tests anyway 00:12:22.760 --> 00:12:25.820 align:middle line:84% so I don't need a type checker, because they've incorrectly 00:12:25.820 --> 00:12:29.770 align:middle line:84% imagined what a type checker actually is. 00:12:29.770 --> 00:12:32.530 align:middle line:84% Both of these top statements and both of these bottom beliefs 00:12:32.530 --> 00:12:34.330 align:middle line:84% are sort of extreme versions, partly 00:12:34.330 --> 00:12:39.260 align:middle line:84% because I have to kind of make things move along quickly, 00:12:39.260 --> 00:12:43.520 align:middle line:84% but also because I think that these are real beliefs. 00:12:43.520 --> 00:12:45.485 align:middle line:84% And if that seems like a strange idea to you, 00:12:45.485 --> 00:12:47.110 align:middle line:84% just go read Hacker News for a few days 00:12:47.110 --> 00:12:49.930 align:middle line:84% and you'll find people saying this stuff. 00:12:49.930 --> 00:12:51.730 align:middle line:84% They'll use more words and probably 00:12:51.730 --> 00:12:53.980 align:middle line:84% be much meaner about it, but they'll say these things. 00:12:53.980 --> 00:12:56.443 align:middle line:90% 00:12:56.443 --> 00:12:58.610 align:middle line:84% So we went through those two examples pretty slowly. 00:12:58.610 --> 00:13:00.830 align:middle line:84% Now I want to accelerate, because I 00:13:00.830 --> 00:13:02.900 align:middle line:84% don't want to slowly sort of deconstruct 00:13:02.900 --> 00:13:04.830 align:middle line:90% all this stuff for hours. 00:13:04.830 --> 00:13:09.120 align:middle line:84% So let's talk about null briefly. 00:13:09.120 --> 00:13:10.770 align:middle line:84% In a dynamic language, null lives 00:13:10.770 --> 00:13:14.070 align:middle line:84% within that explicitly undefined space. 00:13:14.070 --> 00:13:18.060 align:middle line:84% The place where a tuple with an extra element lives. 00:13:18.060 --> 00:13:19.710 align:middle line:84% Every function could be passed to null, 00:13:19.710 --> 00:13:21.390 align:middle line:84% but we almost never think about it, 00:13:21.390 --> 00:13:22.830 align:middle line:90% because it would be exhausting. 00:13:22.830 --> 00:13:24.570 align:middle line:84% And if we wrote all those tests, we'd 00:13:24.570 --> 00:13:26.490 align:middle line:84% have just so many tests that usually 00:13:26.490 --> 00:13:27.550 align:middle line:90% didn't provide any value. 00:13:27.550 --> 00:13:30.207 align:middle line:84% So we just live with the uncertainty. 00:13:30.207 --> 00:13:31.790 align:middle line:84% And of course, the way that manifests, 00:13:31.790 --> 00:13:34.880 align:middle line:84% as anyone who has built a large system in a dynamic language 00:13:34.880 --> 00:13:38.113 align:middle line:84% knows, is that one function generates a null, 00:13:38.113 --> 00:13:40.280 align:middle line:84% and then it propagates and propagates and propagates 00:13:40.280 --> 00:13:41.965 align:middle line:84% and propagates through function calls, 00:13:41.965 --> 00:13:43.340 align:middle line:84% and then eventually someone tries 00:13:43.340 --> 00:13:46.880 align:middle line:84% to add four to it or something and you get an exception. 00:13:46.880 --> 00:13:48.320 align:middle line:84% And the exception occurs far away 00:13:48.320 --> 00:13:50.612 align:middle line:84% from the source of the null, and the source of the null 00:13:50.612 --> 00:13:53.350 align:middle line:90% is no longer in the trace back. 00:13:53.350 --> 00:13:56.725 align:middle line:84% So there's very little useful debugging information present. 00:13:56.725 --> 00:13:58.600 align:middle line:84% Of course, in a static language, this problem 00:13:58.600 --> 00:14:01.978 align:middle line:84% goes away, because null is part of that impossible space. 00:14:01.978 --> 00:14:03.520 align:middle line:84% There is no such thing as null, so we 00:14:03.520 --> 00:14:06.530 align:middle line:90% don't have to think about it. 00:14:06.530 --> 00:14:09.550 align:middle line:84% And the reaction-- when people encounter this idea 00:14:09.550 --> 00:14:13.200 align:middle line:84% for the first time, some of them say, 00:14:13.200 --> 00:14:17.410 align:middle line:90% but I need null to program. 00:14:17.410 --> 00:14:19.000 align:middle line:90% Well, that's what they say. 00:14:19.000 --> 00:14:19.990 align:middle line:90% I need null. 00:14:19.990 --> 00:14:20.890 align:middle line:90% People say this now. 00:14:20.890 --> 00:14:23.050 align:middle line:84% In fact, this was motivated by a Hacker News thread 00:14:23.050 --> 00:14:24.990 align:middle line:84% that I saw while I was preparing this talk. 00:14:24.990 --> 00:14:26.573 align:middle line:84% I've anonymized everything, of course. 00:14:26.573 --> 00:14:28.132 align:middle line:90% I don't want to shame people. 00:14:28.132 --> 00:14:29.590 align:middle line:84% But this is a thing that I actually 00:14:29.590 --> 00:14:31.690 align:middle line:84% saw someone say when I was working on this talk. 00:14:31.690 --> 00:14:36.240 align:middle line:84% And this only makes sense if you believe 00:14:36.240 --> 00:14:38.820 align:middle line:84% that null is the only way to represent absence. 00:14:38.820 --> 00:14:41.010 align:middle line:84% Because what you really needed to do is 00:14:41.010 --> 00:14:43.537 align:middle line:84% represent nothingness or the absence of a value. 00:14:43.537 --> 00:14:45.120 align:middle line:84% But if you only know one way to do it, 00:14:45.120 --> 00:14:47.560 align:middle line:84% then you sort of make this leap and say, 00:14:47.560 --> 00:14:48.900 align:middle line:90% well, that must be the only way. 00:14:48.900 --> 00:14:51.852 align:middle line:90% Null must be the only way. 00:14:51.852 --> 00:14:53.810 align:middle line:84% But you won't get them to say the bottom thing. 00:14:53.810 --> 00:14:56.150 align:middle line:84% Because if they even realized that they believed that, 00:14:56.150 --> 00:14:59.643 align:middle line:84% they could have asked the static functional language programmer, 00:14:59.643 --> 00:15:00.560 align:middle line:90% is this actually true? 00:15:00.560 --> 00:15:02.510 align:middle line:84% How do you represent nothingness? 00:15:02.510 --> 00:15:05.180 align:middle line:84% But instead they just said, programming in that language 00:15:05.180 --> 00:15:07.892 align:middle line:84% is impossible, that language you use, 00:15:07.892 --> 00:15:09.350 align:middle line:84% which is a very silly thing to say. 00:15:09.350 --> 00:15:12.470 align:middle line:90% 00:15:12.470 --> 00:15:15.100 align:middle line:84% Going back further in time, if we go back about five years, 00:15:15.100 --> 00:15:16.642 align:middle line:84% I think it was very common for people 00:15:16.642 --> 00:15:19.660 align:middle line:84% to believe that functional programming is inherently slow. 00:15:19.660 --> 00:15:22.570 align:middle line:84% Not just I used language X and wrote some slow code, 00:15:22.570 --> 00:15:26.290 align:middle line:84% but that functional programming is sort of in a universal sense 00:15:26.290 --> 00:15:28.780 align:middle line:90% slow. 00:15:28.780 --> 00:15:31.840 align:middle line:84% And this really mostly comes down to data structures. 00:15:31.840 --> 00:15:35.260 align:middle line:84% If you are thinking of naive implementations of arrays 00:15:35.260 --> 00:15:36.970 align:middle line:84% and lists, then functional programming 00:15:36.970 --> 00:15:38.260 align:middle line:84% is slow, because every time you want 00:15:38.260 --> 00:15:39.760 align:middle line:84% to change an array element, you have 00:15:39.760 --> 00:15:42.670 align:middle line:84% to allocate the whole array again and copy everything over, 00:15:42.670 --> 00:15:44.840 align:middle line:90% and it's very slow. 00:15:44.840 --> 00:15:47.110 align:middle line:84% But if you have persistent data types, 00:15:47.110 --> 00:15:50.390 align:middle line:84% like closure does, for example, then this isn't a problem. 00:15:50.390 --> 00:15:53.830 align:middle line:84% So in order to say that FP is slow, you have to believe, 00:15:53.830 --> 00:15:56.860 align:middle line:84% maybe without realizing it, that no faster immutable types 00:15:56.860 --> 00:15:58.600 align:middle line:90% exist. 00:15:58.600 --> 00:16:01.990 align:middle line:84% But persistent data types date back 00:16:01.990 --> 00:16:04.820 align:middle line:84% at least to '96, and possibly earlier, I'm not sure, 00:16:04.820 --> 00:16:06.550 align:middle line:90% but at least '96. 00:16:06.550 --> 00:16:10.150 align:middle line:84% So this was false long before the person ever said this. 00:16:10.150 --> 00:16:11.630 align:middle line:84% The top thing was false, that is, 00:16:11.630 --> 00:16:14.150 align:middle line:84% long before they ever said it, because the bottom thing was 00:16:14.150 --> 00:16:14.650 align:middle line:90% false. 00:16:14.650 --> 00:16:16.610 align:middle line:84% But you won't get them to say the bottom thing. 00:16:16.610 --> 00:16:17.900 align:middle line:90% They only say the top thing. 00:16:17.900 --> 00:16:19.358 align:middle line:84% The bottom thing is the belief they 00:16:19.358 --> 00:16:22.940 align:middle line:84% have that structures their understanding of the world. 00:16:22.940 --> 00:16:27.080 align:middle line:84% Going back further to 2000, this was one of my favorite things 00:16:27.080 --> 00:16:29.840 align:middle line:84% to argue about when I was just starting college at this time. 00:16:29.840 --> 00:16:31.423 align:middle line:84% That garbage collection is never going 00:16:31.423 --> 00:16:33.680 align:middle line:84% to be practical for real world software. 00:16:33.680 --> 00:16:36.050 align:middle line:90% I loved arguing about that. 00:16:36.050 --> 00:16:38.930 align:middle line:84% I believed that it was true, by the way, not the other way. 00:16:38.930 --> 00:16:41.660 align:middle line:90% I had the wrong belief. 00:16:41.660 --> 00:16:44.180 align:middle line:84% And much like the functional programming thing, 00:16:44.180 --> 00:16:48.440 align:middle line:84% this only makes sense if there are no better 00:16:48.440 --> 00:16:50.890 align:middle line:90% GC algorithms coming. 00:16:50.890 --> 00:16:55.210 align:middle line:84% Now, in 2000, my context for garbage collection was the JVM. 00:16:55.210 --> 00:16:58.780 align:middle line:84% And this was just before it got much better garbage collection. 00:16:58.780 --> 00:17:01.450 align:middle line:84% So I was thinking about the one second GC 00:17:01.450 --> 00:17:05.740 align:middle line:84% pause, which is not tenable for a lot of software systems. 00:17:05.740 --> 00:17:08.530 align:middle line:84% But what I failed to realize is that those massive GC 00:17:08.530 --> 00:17:10.420 align:middle line:84% improvements were coming in the near future, 00:17:10.420 --> 00:17:13.390 align:middle line:84% and they were based on work from the '80s and in many cases 00:17:13.390 --> 00:17:14.560 align:middle line:90% the '70s. 00:17:14.560 --> 00:17:17.724 align:middle line:84% So before I was alive, I was already wrong about this. 00:17:17.724 --> 00:17:18.385 align:middle line:90% [LAUGHTER] 00:17:18.385 --> 00:17:21.490 align:middle line:84% And I just needed to be a college 00:17:21.490 --> 00:17:24.470 align:middle line:84% student who liked arguing before it really came out. 00:17:24.470 --> 00:17:27.140 align:middle line:90% 00:17:27.140 --> 00:17:29.940 align:middle line:84% So I'm going to stop going through individual examples 00:17:29.940 --> 00:17:30.440 align:middle line:90% right now. 00:17:30.440 --> 00:17:32.150 align:middle line:90% I think the pattern is clear. 00:17:32.150 --> 00:17:33.680 align:middle line:90% You say the top thing. 00:17:33.680 --> 00:17:35.777 align:middle line:84% It only makes sense if the bottom thing is true. 00:17:35.777 --> 00:17:37.610 align:middle line:84% So in a sense, you believe the bottom thing. 00:17:37.610 --> 00:17:39.652 align:middle line:84% It's structuring your understanding of the world, 00:17:39.652 --> 00:17:42.660 align:middle line:90% but you don't realize it. 00:17:42.660 --> 00:17:46.440 align:middle line:84% If we kind of group these up, the belief 00:17:46.440 --> 00:17:48.190 align:middle line:84% that no faster immutable types exist, 00:17:48.190 --> 00:17:50.280 align:middle line:84% which motivates believing that FP is slow, 00:17:50.280 --> 00:17:52.870 align:middle line:84% and the belief that no faster GC algorithms exist, 00:17:52.870 --> 00:17:55.440 align:middle line:84% which motivates believing that GC is slow, 00:17:55.440 --> 00:17:58.350 align:middle line:84% and the belief that only null can represent absence, 00:17:58.350 --> 00:18:00.210 align:middle line:84% these are all kind of the same belief. 00:18:00.210 --> 00:18:03.450 align:middle line:84% This is the belief that I saw something with property X, 00:18:03.450 --> 00:18:05.010 align:middle line:84% therefore, the category of things 00:18:05.010 --> 00:18:07.960 align:middle line:84% has property X. I saw slow functional code, 00:18:07.960 --> 00:18:11.370 align:middle line:84% therefore a functional code will always be slow, et cetera. 00:18:11.370 --> 00:18:13.902 align:middle line:84% These are actually quite easy to dispel. 00:18:13.902 --> 00:18:15.360 align:middle line:84% When someone believes these things, 00:18:15.360 --> 00:18:17.640 align:middle line:84% you just tell them of the existence of an alternative. 00:18:17.640 --> 00:18:19.080 align:middle line:84% And some people will be very stubborn, 00:18:19.080 --> 00:18:21.540 align:middle line:84% and I don't know, claim that that alternative doesn't exist 00:18:21.540 --> 00:18:22.082 align:middle line:90% or something. 00:18:22.082 --> 00:18:23.940 align:middle line:84% But for the most part, people believe you, 00:18:23.940 --> 00:18:26.720 align:middle line:90% and the belief goes away. 00:18:26.720 --> 00:18:30.022 align:middle line:84% The nasty ones are beliefs like correctness comes exclusively 00:18:30.022 --> 00:18:31.730 align:middle line:84% from categories, because this is a pretty 00:18:31.730 --> 00:18:33.950 align:middle line:90% deep philosophical belief. 00:18:33.950 --> 00:18:36.530 align:middle line:84% And likewise for correctness comes exclusively 00:18:36.530 --> 00:18:38.450 align:middle line:90% from examples. 00:18:38.450 --> 00:18:43.883 align:middle line:84% And I can find myself believing both of these today 00:18:43.883 --> 00:18:45.050 align:middle line:90% depending on what I'm doing. 00:18:45.050 --> 00:18:46.550 align:middle line:84% If I'm programming in occam, well, I 00:18:46.550 --> 00:18:48.020 align:middle line:84% stop thinking about examples, and I 00:18:48.020 --> 00:18:52.190 align:middle line:84% stop thinking about exceptions to the types 00:18:52.190 --> 00:18:53.570 align:middle line:90% that I am creating. 00:18:53.570 --> 00:18:56.060 align:middle line:84% And in a dynamic language, I write 00:18:56.060 --> 00:18:58.640 align:middle line:90% the 0, 1, many a lot tests. 00:18:58.640 --> 00:19:02.570 align:middle line:84% And then I sort of don't think about are there 00:19:02.570 --> 00:19:04.610 align:middle line:84% members of the category I just established 00:19:04.610 --> 00:19:06.080 align:middle line:90% that should not be there. 00:19:06.080 --> 00:19:10.130 align:middle line:84% Did I fail to actually define the category? 00:19:10.130 --> 00:19:11.870 align:middle line:84% And I don't know how to stop doing this, 00:19:11.870 --> 00:19:14.735 align:middle line:84% but I think realizing it is important, mostly 00:19:14.735 --> 00:19:16.610 align:middle line:84% because it will make you a better programmer, 00:19:16.610 --> 00:19:18.890 align:middle line:84% but also because it'll stop making you write angry Hacker 00:19:18.890 --> 00:19:19.550 align:middle line:90% News comments. 00:19:19.550 --> 00:19:22.570 align:middle line:90% 00:19:22.570 --> 00:19:25.270 align:middle line:84% It's important to note that imposter syndrome is also 00:19:25.270 --> 00:19:26.230 align:middle line:90% in this category. 00:19:26.230 --> 00:19:28.480 align:middle line:84% This category of beliefs where even when 00:19:28.480 --> 00:19:31.780 align:middle line:84% you know that you have this belief, it still functions. 00:19:31.780 --> 00:19:34.050 align:middle line:84% It still governs the way you understand yourself, 00:19:34.050 --> 00:19:36.175 align:middle line:84% in this case, as opposed to understanding software. 00:19:36.175 --> 00:19:39.210 align:middle line:90% 00:19:39.210 --> 00:19:42.600 align:middle line:84% And so this bottom category is the one that's scary. 00:19:42.600 --> 00:19:45.960 align:middle line:84% The top one is just sort of an inconvenience. 00:19:45.960 --> 00:19:51.630 align:middle line:84% And if you could turn ideology about technical topics 00:19:51.630 --> 00:19:53.370 align:middle line:84% into sort of a substance, like a fluid 00:19:53.370 --> 00:19:56.670 align:middle line:84% and pour it into a vessel of some kind, 00:19:56.670 --> 00:20:00.600 align:middle line:84% I think that vessel would be Hacker news. 00:20:00.600 --> 00:20:03.960 align:middle line:84% Whether we're talking about type systems or tests, dynamic 00:20:03.960 --> 00:20:07.170 align:middle line:84% or static, whether we're talking about the meritocracy 00:20:07.170 --> 00:20:11.820 align:middle line:84% or the market, if you just read any Hacker News thread that it 00:20:11.820 --> 00:20:14.280 align:middle line:84% has a lot of comments and is a contentious topic, 00:20:14.280 --> 00:20:17.730 align:middle line:84% you will find people where you can see the things they believe 00:20:17.730 --> 00:20:19.440 align:middle line:90% but don't realize they believe. 00:20:19.440 --> 00:20:22.230 align:middle line:84% It's just staring at you in the face. 00:20:22.230 --> 00:20:26.970 align:middle line:84% And that makes it sound like maybe ideology is universally 00:20:26.970 --> 00:20:30.270 align:middle line:84% bad, but the first time I gave this talk, 00:20:30.270 --> 00:20:31.930 align:middle line:90% I think I gave that impression. 00:20:31.930 --> 00:20:34.920 align:middle line:84% So I will just note one bit of ideology 00:20:34.920 --> 00:20:37.560 align:middle line:84% that is very nice to have, which is the belief 00:20:37.560 --> 00:20:40.035 align:middle line:90% that hurting people is bad. 00:20:40.035 --> 00:20:41.910 align:middle line:84% It structures our understanding of the world. 00:20:41.910 --> 00:20:44.700 align:middle line:84% You don't have to consciously stop every time this comes up 00:20:44.700 --> 00:20:47.130 align:middle line:84% and think, is hurting people bad? 00:20:47.130 --> 00:20:48.572 align:middle line:90% It just kind of works, right? 00:20:48.572 --> 00:20:50.530 align:middle line:84% Even when you don't consciously think about it. 00:20:50.530 --> 00:20:54.450 align:middle line:84% So it's not that world structuring beliefs are bad, 00:20:54.450 --> 00:20:55.860 align:middle line:90% it's that they're powerful. 00:20:55.860 --> 00:20:58.260 align:middle line:84% And in some cases, they are very difficult to get rid 00:20:58.260 --> 00:21:01.590 align:middle line:84% of, and they lead us to treat each other badly but also 00:21:01.590 --> 00:21:04.890 align:middle line:84% to make bad technical decisions, like not writing tests 00:21:04.890 --> 00:21:07.650 align:middle line:84% for the parts of a function that the pipe system cannot 00:21:07.650 --> 00:21:09.710 align:middle line:90% characterize. 00:21:09.710 --> 00:21:13.070 align:middle line:84% And with that, I thank you all very much for coming. 00:21:13.070 --> 00:21:15.820 align:middle line:90% [APPLAUSE] 00:21:15.820 --> 00:21:22.000 align:middle line:90%