An off-the-cuff stream of Functional Programming ideas, skills, patterns, and news from Functional Programming expert Eric Normand of LispCast.
Computer Science as Empirical Inquiry: Symbols and Search
In this episode, I excerpt from and comment on Allen Newell's and Herbert Simon's 1975 ACM Turing Award Lecture.
How far can we stretch technical debt?
Technical debt is a metaphor used to explain the tradeoff we all face when we have a deadline. How much is it worth to rush the code out the door? It's a good metaphor, but the term is often used these days to mean 'code I don't like'. In this episode, I examine the parts of the metaphor and ways in which technical debt differs from financial debt.
How to avoid premature optimization?
I explore why clean code is a lagging indicator and how the domain model is a leading indicator of maintenance cost.
What is domain modeling?
I begin exploring the process of domain modeling with a definition.
Computer Programming as an Art
I read from the 1974 Turing Award Lecture by Don Knuth.
Programmer as Navigator
We read and discuss the 1973 ACM Turing Award Lecture by Charles W. Bachman.
A good introduction to FP so far
To be honest, I had to do a lot of reading and watching videos about basic category/type theory in order to really understand what was going on. I’m not sure there is any way around that. It’s difficult to approach if you don’t have a strong foundation in math.
However, Eric does a good job of explaining some fundamental concepts in a way I could easily comprehend. Listen to this if you want to bridge your gap knowledge gap and step into the world of FP.
I really like the format and topics Eric tends to extrapolate on. Nice small pieces of insight from a really talented software engineer. Thanks!!
Inaccurate but good pedagogy
The positives are that this podcasts is presented with extraordinary attention to good teaching— modest pace, repetition, stick to one topic, and assignments.
The negatives however include inaccurate information, e.g. the dialog confuses associativity commutativity and idempotence and fails to observe for the listener when certain claims are the result of theses effects in concrete not individually. E.g. most of the claims on commutativity fail if the operation is not also associative.
Perhaps more concerning is that the lesson focus on saying a word and describe an example of an abstraction it represents. But they do not add any thing new. E.g. it is claimed at the start that the listener will know how to make things have some abstraction when in fact the lesson given is to observe something in your code base already has a behavior and then label it that way. There is no guidance to pull in abstraction from well studied and optimized libraries which is where the power of these observations lives.
Frankly time is best spent listening to experts however tough they present there topics. But perhaps this will improve.