This version of the site is now archived. See the next version at v5.chriskrycho.com.

Differences of Opinion

March 12, 2017Filed under Tech#links#pedagogy#programming languages#software developmentMarkdown source

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.

The Book of F♯

A so-so book about a slightly strange language.

July 21, 2017Filed under Tech#book-reviews#fsharp#pedagogy#programming languages#writingMarkdown source

Level up your `.filter` game

A really *smart* introduction to functional programming.

August 18, 2018Filed under tech#functional programming#javascript#links#pedagogyMarkdown source

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.