Chris Krycho
I was delighted to spend a bit over an hour chatting with Adam Gordon Bell on the Corecursive podcast. I was there officially to talk about TypeScript, and I did a lot of that… but we also dug into Rust a bit, of course, as well as talking about my schedule and “productivity”.
I’ve been podcasting for a few years now, but this was only the second time I’ve ever been on someone else’s podcast—and it was a blast. Thanks so much to Adam for having me on!
Maybe helpers for safe object lookup and Result helpers for exception-throwing code.
Yesterday while talking with my wife as we drove to spend some time with extended family, I caught myself: tempted to describe a given response to a particular cultural ill as a solution. This is a turn of thinking that’s especially tempting for engineers—and perhaps the more so engineers with a physics background (like me!). In two of the fields to which I have applied myself (physics and software), knowledge often genuinely appears in the form of solutions to problems. But the extent to which science (and scientism) on the one hand and engineering disciplines (especially software) on the other have come to the fore in our culture—the degree to which they have achieved nearly unassailable authority for us—means that we now too often take solutions as coextant with knowledge more generally.
This is solutionism, and it is bad. I noted above that two of the fields to which I have applied myself share this feature of having solutions to problems as their predominant form of knowledge. But this is not so in two of the other fields I have studied in some depth: for neither theology nor music is a solution very often in demand. Very different modes of thought and of reasoning are in play in each of those, and appropriately so.
So it was with some particular appreciation that I read this piece by L. M. Sacasas, reflecting on the recent New Yorker profile of Mark Zuckerberg. Sacasas rightly highlights how mistaken this solutionist frame of knowledge is. From his conclusion (emphasis mine):
Reducing knowledge to know-how and doing away with thought leaves us trapped by an impulse to see the world merely as a field of problems to be solved by the application of the proper tool or technique, and this impulse is also compulsive because it cannot abide inaction. We can call this an ideology or we can simply call it a frame of mind, but either way it seems that this is closer to the truth about the mindset of Silicon Valley.
It is not a matter of stupidity or education, formally understood, or any kind of personal turpitude. Indeed, by most accounts, Zuckerberg is both earnest and, in his own way, thoughtful. Rather it is the case that one’s intelligence and one’s education, even if it were deeply humanistic, and one’s moral outlook, otherwise exemplary and decent, are framed by something more fundamental: a distinctive way of perceiving the world. This way of seeing the world, including the human being, as a field of problems to be solved by the application of tools and techniques, bends all of our faculties to its own ends. The solution is the truth, the solution is the good, the solution the beautiful. Nothing that is given is valued.
The trouble with this way of seeing the world is that it cannot quite imagine the possibility that some problems are not susceptible to merely technical solutions or, much less, that some problems are best abided. It is also plagued by hubris—often of the worst sort, the hubris of the powerful and well-intentioned—and, consequently, it is incapable of perceiving its own limits. As in the Greek tragedies, hubris generates blindness, a blindness born precisely out of one’s distinctive way of seeing. And that’s not the worst of it. That worst of it is that we are all, to some degree, now tempted and prone to see the world in just this way too.
Adam Giese’s “Level up your .filter game” does something really interesting and helpful: it introduces a bunch of fairly sophisticated functional programming concepts without ever mentioning functional programming and without ever using any of the jargon associated with those terms.
“Level up your .filter game” gives you a reason to use some standard FP tools—currying, higher-order functions, composition—in your ordinary work. It’s pitched at working JS developers. It gives a real-world example of wanting to filter search results based on user input. It shows the utility of defining a bunch of small functions which can fit together like LEGO.
Filters are an essential part of JavaScript development. Whether you’re sorting out bad data from an API response or responding to user interactions, there are countless times when you would want a subset of an array’s values. I hope this overview helped with ways that you can manipulate predicates to write more readable and maintainable code.
I commend the piece to you not so much for the explanation of how to use JavaScript’s Array.prototype.filter effectively (though it has some good suggestions that way!) but primarily as a great example of the kind of pedagogy we need a lot more of to demonstrate the value of functional programming in ordinary, day-to-day development work.
Ember.Object world.
Maybe and Result types, and supporting both a functional style and a more traditional method-call style.
I could not possibly agree more with this view of teaching software/CS.
We are focused on introductory programming education at a high-school and collegiate level — what is often called “CS 1” and “CS 2” (roughly, the first year of college). Pyret is being actively used in everything from high-schools to upper-level collegiate courses, giving us a tight feedback loop.
Of course, even in that setting there are differences of opinion about what needs to be taught. Some believe inheritance is so important it should be taught early in the first semester. We utterly reject this belief (as someone once wisely said, “object-oriented programming does not scale down”: what is the point of teaching classes and inheritance when students have not yet done anything interesting enough to encapsulate or inherit from?). Some have gone so far as to start teaching with Turing Machines. Unsurprisingly, we reject this view as well.
What we do not take a dogmatic stance on is exactly how early state and types should be introduced. Pyret has the usual stateful operations. We discussed this at some length, but eventually decided an introduction to programming must teach state. Pyret also has optional annotations, so different instructors can, depending on their preference, introduce types at different times.
I’m delighted to see work on languages like Dr. Racket and Pyret, and the more so because the teams behind both have been willing to set aside many of the dogmas of how CS has been taught and actually do pedagogical research. Also: OOP is a useful tool, but I’m with them: treating inheritance as a first-semester concept is… nutty.
The whole “Why Pyret?” page is worth reading if you have any interest in programming languages or teaching software development and computer science.
keyof Follow-UpA month ago, Alan Jacobs asked about quality conservative Christian podcasts. Here’s a big part of why there are so few (at Mere Orthodoxy):
As a Christian in the world of podcasting—I have both a “two dudes talking” show (Winning Slowly) and also a “one dude talking with maybe a brief musical intro and outro” show (New Rustacean)—I found much to agree with, but also much to clarify and a few things to disagree with…
…
First, a set of theses on podcasting as a medium. Some of these are obvious; none are intended to be tendentious. Some of them warrant further explanation—for which, see below….
After which, 32 theses (and another ~3,000 words) on the constraints and challenges of podcasting as a medium.
Aside: the format of this particular piece is heavily inspired by Jacobs’ own “79 Theses on Technology. For Disputation.”
OH WOW: SpaceX first-stage landing footage… from the onboard camera. This is blow-your-mind incredible.
I always appreciate Ben Thompson’s takes, but this—on the Thiel/Gawker imbroglio—is one of his best posts ever.
This bit from the fish design document perfectly captures what git does wrong (emphasis mine):
When designing a program, one should first think about how to make a intuitive and powerful program. Implementation issues should only be considered once a user interface has been designed.
Rationale:
This design rule is different than the others, since it describes how one should go about designing new features, not what the features should be. The problem with focusing on what can be done, and what is easy to do, is that too much of the implementation is exposed. This means that the user must know a great deal about the underlying system to be able to guess how the shell works, it also means that the language will often be rather low-level.
—fish documentation
enums) and more on pattern matching
Dear Republicans: your opposition to net neutrality might be justifiable as something other than kowtowing to megacorporations if you ever got around to proposing something else. As is, all you’re doing is propping up some of the nastiest, most anti-consumer companies in the country and sustaining monopolies and duopolies, supposedly in the name of “free markets”.
Stop it.
N.b. This isn’t intrinsically a partisan issue. It’s become one, but mostly because Republicans have felt compelled to do the bidding of the telecom industry for… reasons.
The only thing worse than a government monopoly is a private monopoly.
If Republicans wanted to push for local loop unbundling in place of net neutrality, almost everyone would be for it. (The exception: telecom companies.)
Ooh, look! A beta for Reeder 3! Shiny!
Another one in the music industry—but in this case, companies taking the long view and advancing the good of the whole community, rather than just their own bottom line. (Spreadbury, the guy behind SMuFL, was one of the team laid off in the aforementioned layoff from the Sibelius team, and now heads the product development for a new notation software tool from Steinberg.)
Avid: charging Sibelius users more money than ever for less value than ever, after laying off their dev team a couple years ago just to maximize profits.
This is not Winning Slowly material here, folks. They lost me (and many other) customers along the way, and they’re headed further down that road here.
Subscription models for software can be valuable and reasonable—but the providers have to justify them with product to match. Avid isn’t, and hasn’t been. I’ve no doubt they’re continuing to profit in the short term, but this will no doubt erode their market position and waste an amazing product in the long term. Greed destroys good things.
<base>, and SVGxlink:href work correctly in Firefox.
I confess: my first response to seeing this page was a flash of anger: Hey, he didn’t just learn from my site configuration, he actually stole my site design_!_ And then I remembered: I open-sourced the design precisely so people could do that. This was just the first time I’ve ever actually had someone reuse something I did and shared like this. It was a strange (but ultimately wonderful) feeling. I hope to have it again many more times.
In any case, I rather like the tweaks Andrew Comenga made to my design to make it his own; go take a look!
The Verge:
“I don’t want a back door,” Rogers said. “I want a front door. And I want the front door to have multiple locks. Big locks….”
Rogers suggests the adoption of “front door” access will allow for essential security measures while keeping data safe from hackers or an outside attack. But opponents of the idea note that even broken into pieces, a master digital key creates security flaws. “There’s no way to do this where you don’t have unintentional vulnerabilities,” Donna Dodson, chief cybersecurity adviser at the Commerce Department’s National Institute of Standards and Technologies, told the Post.
That last bit is absolutely true. The government basically wants to make sure it can spy on anyone, any time it wants. That’s a bad, bad plan.
One thing I didn’t talk about in comparing reading experiences on a Kindle and on an iPad the other day is the elephant in the room: old-fashioned books. I enjoy Kindle and iPad, but I still love books best. Turns out I’m not alone… and there might just be reason for it.
Paper books were supposed to be dead by now. For years, information theorists, marketers, and early adopters have told us their demise was imminent. Ikea even redesigned a bookshelf to hold something other than books. Yet in a world of screen ubiquity, many people still prefer to do their serious reading on paper.
Count me among them. When I need to read deeply—when I want to lose myself in a story or an intellectual journey, when focus and comprehension are paramount—I still turn to paper. Something just feels fundamentally richer about reading on it. And researchers are starting to think there’s something to this feeling.
Pretty damning of the current (lack of a) regulatory regime, if you ask me:
According to a recent study by Ookla Speedtest, the U.S. ranks a shocking 31st in the world in terms of average download speeds. The leaders in the world are Hong Kong at 72.49 Mbps and Singapore on 58.84 Mbps. And America? Averaging speeds of 20.77 Mbps, it falls behind countries like Estonia, Hungary, Slovakia, and Uruguay.