Eric Normand

The Eric Normand Podcast, previously titled Thoughts on Functional Programming. Despite the name, he also dives into e.g., some classic OOP material too, as well as general programming paradigm commentary.

https://ericnormand.me/podcast

A couple episodes you may be interested in:

"In this episode, I excerpt from and comment on Allen Newell's and Herbert Simon's 1975 ACM Turing Award Lecture."

https://ericnormand.me/podcast/computer-science-as-empirical-inquiry-symbols-and-search

"In this first episode of season 3, we analyze a great paper called Lisp: A language for stratified design. The paper asks the question "What is Lisp good for?"

https://ericnormand.me/podcast/lisp-a-language-for-stratified-design

"We read one of the great articles by Alan Kay, inventor of Smalltalk, called The Early History of Smalltalk."

https://ericnormand.me/podcast/the-early-history-of-smalltalk

I think this is a superb point. If you look at Clojure and Rich Hickey's justifications for it's design, he talks a lot about designing systems that work with a world that is changing constantly, interfacing with systems where you can't always guarantee a stable contract, solving problems that use non-elegant models, dealing with state and time, and change in ways you can't predict. Eric Normand wrote a great article on this and he comes from a dual Haskel/Clojure background [1]. Nominal static type systems absolutely have their place, especially with closed systems where the abstractions are different.

1: https://ericnormand.me/article/clojure-and-types

It is difficult to explain why, but there is actually a positive case to be made for dynamic typing. Their benefits are real but a lot less immediately apparent than the benefits of static typing. I think this article from Eric Normand captured some of it https://ericnormand.me/article/clojure-and-types. In my opinion languages like TypeScript where the type system is only a verification system and has no effect on the runtime, combined with its emphasis on structural types, existence of union/intersection types, etc, go a long way towards reducing the downsides of static types but not completely.

Ah, per limited edition & popular demand, will eventually be a real world, example of type sematics of the topoid ducktype. aka worn out & held together by duck tape.

At moment, looks like the electronic version seen as having an incompatible structural type system [0].

----

C/C++ has type punning [1].

Lisp has nil punning [2].

Python has duck typing.[3].

[0] : http://nullprogram.com/blog/2014/04/25/

[1] : http://en.wikipedia.org/wiki/Type_punning

[2] : http://ericnormand.me/podcast/what-is-nil-punning

[3] : http://en.wikipedia.org/wiki/Duck_typing

yes makes perfect sense everything you just said..so I suppose this is one reason why clojure doesn't have one library/framework to rule them all, Rich saying he gave us a tool to do what we want/need, and clojurists do just that! Do what makes best sense in your situation etc

unrelated sorta..

Really makes me wonder if the lisp curse is really not a curse, now that I also google it I see Eric Normand has something to say about it https://ericnormand.me/podcast/what-is-the-curse-of-lisp so maybe i should give that a listen!

AFAIK, all libraries are loosely coupled in Biff. Swapping out Hiccup / Rum for one of the other HTML templating options should be in "userspace"; straightforwardly so, without the framework maintainers intervention.

Ref:

Biff's own documentation: https://biffweb.com/docs/reference/architecture/#modifying-the-framework

HTML templating options: https://ericnormand.me/mini-guide/clojure-html-templates