HN Reader

They give a nice introduction to encoding state as pure functions. In fact, there are many more purely functional encodings for all kinds of data like trees, integers, sum/product types, images, monads, ...

The encodings can be a bit confusing, but really elegant and tiny at the same time. Take for example a functional implementation of the Maybe monad in javascript:

  Nothing = nothing => just => nothing
  Just = v => nothing => just => just(v)
  
  pure = Just
  bind = mx => f => mx(mx)(f)
  
  evalMaybe = maybe => maybe("Nothing")(v => "Just " + v)
  console.log(evalMaybe(bind(Nothing)(n => pure(n + 1)))) // Nothing
  console.log(evalMaybe(bind(Just(42))(n => pure(n + 1)))) // Just 43

Warning: Diving into SCIP/Lisp/Scheme can transform how you think about programming... food for thought is always welcomed! But applying those ideas wholesale to OOP codebases often backfires or gets pushback from teammates. Languages handle paradigms differently, and going against the grain usually leads to worse code.

Example: After Lisp, you might replace every for loop with forEach or chain everything through map/reduce. But unless you’re working in a language that fully embraces functional programming, this approach can hurt both readability and performance.

At the end of the day, it’s grounding to remember there’s mutable memory and a CPU processing the code. These days, I find data-oriented design and “mechanical sympathy” (aligning code with hardware realities) more practical day-to-day than more abstract concepts like Church numerals.

I recently came across the notion that you need inductive data types (and can't just use Church encodings) if you want to do theorem proving, like proving that `0 != 1`.

I threw up some content up here: https://intellec7.notion.site/Drinking-SICP-hatorade-and-why... , along with an unrelated criticism of SICP.

I'd like to better understand what the limitations are of "everything is just a function".

I've watched the actual SICP lectures before (the 1986 recordings on MIT OCW). They're often praised for the information density, but it actually still wastes a lot of time listening to students' Q&A, the lecturers drawing the class' attention to various attempts at "multimedia" presentation in the classroom, simply not having the entire lesson plan worked out in advance (i.e., not being able to preempt the Q&A) etc. For that matter, the sheer amount of time spent on writing things on a chalkboard really adds up.

And of course the order of the material could be debated and rearranged countless ways. One of my future planned projects is to do my own video series presenting the material according to my own sensibilities.

It's nice to hear that the course apparently still stays true to its roots while using more current languages like Python. Python is designed as a pragmatic, multi-paradigm language and I think people often don't give it enough credit for its expressive power using FP idioms (if not with complete purity).

The cons/car/cdr implementation as lambda was magical the first time I saw it. But it just shows that the language runtime must implement key/value dictionaries and you are able to borrow that implementation to make other data structures.

David Beazley is a bit of a legend in the python world and honestly this course seems a surprising idea but it took about two seconds thought before it seemed perfect match and Inhave signed up for the next one.

The relevant part is that this is basically how “software engineers continual education” is going to look like

The book itself is currently being discussed at:

https://news.ycombinator.com/item?id=42157558

Is there a reason why the link goes to the discussion at the bottom of that page rather than the beginning?

Could this be folded into the other discussion? (I don't see that the link has been posted there yet)

I think SICP is wonderful.

As I've learned more and studied more math though, I've come to the conclusion that the relation really is the more fundamental primitive. Every function can be represented as a kind of restricted relation, but the converse is not true, at least not without adding considerable extra gadgetry.

While of course relational databases and SQL are the best known examples of relational programming, and are highly successful, I still believe it's a largely untapped space.

However, my interest currently is less in the space of programming language design and more in teaching very young children the basics of math. And for whatever reason it's considerably easier to teach a predicate like "is big" as a 1-ary relation and "is bigger than" as a 2-ary relation than trying to capture the same concepts as functions.

There's a typo in the code in "the substitution model" section:

  ("+", ("fib", ("-", "n", 2)), ("fib", ("-", "n", 1))),

The two calls to `fib` are surely meant to be `fibonacci` since the latter is defined, but not the former. Indeed, the code is correct in the github repo:

https://github.com/savarin/pyscheme/blob/0f47292c8e5112425b5...

alternative take: everything is just sets

both can be a foundation for mathematics, and hence, a foundation for everything

what's interesting is how each choice affects what logic even means?

Not a fan of everything-is-a-function because it's oversimplistic and often unhelpful. Some of the issues:

- functions that don't fit in cache, RAM, disk, etc.

- functions that have explosive big-O, including N way JOINs, search/matching, etc.

- functions with side effects, including non-idempotent. Nobody thinks about side channel attacks on functions.

- non-deterministic functions, including ones that depend on date, time, duration, etc.

- functions don't fail midway, let alone gracefully.

- functions don't consume resources that affect other (cough) functions that happen to be sharing a pool of resources

- function arguments can be arbitrarily large or complex - IRL, there are limits and then you need pointers and then you need remote references to the web, disk, etc.

(tell me when to stop - I can keep going!)

Just fyi (perhaps @dang) this jumps to the Postscript of the blog post due to the anchor/hash in the URL. I was a bit confused initially.

Reading this brings back fond memories of taking CS61a with prof Brian Harvey at UC Berkeley some 25 years ago. Same book, same level of mind=blown, and very similar instruction style. we spent a semester instead of a week and if memory serves tuition was about the same, but they threw in some English and history courses as well :-)

> Everything Is Just Functions...

I'd iterate on that and say: everything is just languages and dialogues, with functions being one component of them. Over time, we’ve evolved from machine languages to higher-level ones, but most popular languages today still focus on the "how" rather than the "what".

Programming paradigms, even those like functional and logic programming, requires the "how". My rant is this: the next major iteration(s) in programming languages should shift focus to the "what". By abstracting away the "how", we can reach a higher-order approach that emphasizes intent and outcomes over implementation details.

I don't want to constrain this idea to Z3, LLMs, or low/no-code platforms, but rather to emphasize the spirit of the "what". It’s about enabling a mindset and tools that prioritize defining the goal, not the mechanics.

I know this contradicts our work as software engineers where we thrive on the "how", but maybe that’s the point. By letting go of some of the control and complexity, we might unlock entirely new ways to build systems and solve problems.

If I should be plain realistic, I'd say that in the middle, we need to evolve by mixing both worlds while keeping our eyes on a new horizon.

Shameless plug: https://aplaceofmind.notion.site/It-s-Lambdas-All-the-Way-Do...

I got to the same conclusion a while ago, except that I found that it's lambdas all the way down.

Dave is a stellar instructor with a bottomless well of knowledge. One of the few people I go to when I have a Python question I can't figure out. I've taken every course he has available: compilers, lisp, raft, and advanced python salary*. I can say definitively that my salary has doubled twice thanks to his courses, so well worth the effort from my opinion.

That being said... SICP, Compilers, and RAFT all left me with the gnawing feeling that there was more juice to be squeezed from computer science than I was able to understand.

Why were my parsers and compilers not bidirectional? Why am I writing a utilitarian OO parser for an elegant FP language? Why is there no runtime polymorphic isomorphism for my client/server RAFT nodes?[1]

Drowning in my own sorrows, I began binge drinking various languages, drifting from one syntax to the next. CL, Scheme, Java, C#, Haskell, Forth, TypeScript, Clojure... ahh, long love affair with Clojure. But in the end, even Clojure, for all of its elegance, could not solve the original problem I was facing and at the end of the day in many ways was just "a better Python".

I was nearly ready to call it quits and write my own language when all the sudden I discovered... Prolog.

Not just any Prolog-- Scryer Prolog. Built on rust. Uncompromising purity. And Markus Triska's Power of Prolog videos on YouTube.[2]

My God. They should have sent a poet.

Bidirectional parsing? No-- N-dimensional parsing vis definite clause grammars, ships with standard library. First class integer constraint solvers. And it is the first language I have ever worked with that takes the notion of "code is data" seriously.

Scryer is still a young language, but it's going big places. Now is a great time to get involved while the language and community is still small.

I will end this love letter by saying that I owe my career and much of my passion to Dave, and because of him Python is still how I earn my bread and afford expensive toys for my Yorkie.

You rock, Dave!

[*]: this was a typo, should be Advanced Python Mastery, but in my ways advanced python salary is actually more accurate, in my case anyway.

[1]: If issues like this don't bother you, and you haven't been coding for at least 10-15 years, maybe come back later. Learning Prolog and Scryer in particular is really hard at first, even harder than Haskell/Clojure.

[2]: https://youtube.com/@thepowerofprolog

David Beazley is using Scheme! That is a nice shift towards a civilized language. I hope he scraps the scheme-in-python section, but perhaps that is intended as an exit drug for Python addicts.

Surprised "mind-blowing" is not in the HN clickbait filter.

From my perspective all software is essentially applying transformation functions to some data.

There are externalities like networking and storage, but still data transformation in a way.

"Everything is just" approaches usually result in hammering things that don't fit into fitting. That often ends badly. Computing has been through, at least:

- Everything is just a function (SICP)

- Everything is just an object (Smalltalk, and to some extent Java)

- Everything is just a closure (the original Common LISP object system)

- Everything is just a file of bytes (UNIX)

- Everything is just a database (IBM System/38, Tandem)

So an integer is represented by how deep in the stack you are?

How do you represent an irregular float?

Has anyone read the new SICP with Javascript as language of choice?

Everything is just assembly!

Actually it is more like Algorithms + Data Structures = Programs.

Imagine if that statement applied to every non-digital thing as well.

And functions are just numbers combined with if/else's and a pretty name at the end of the day.

If this number, jump to numberA otherwise jump to this numberB. Also if numberC store numberD at numberE. ;)

The link takes around 10s to render. That's excessive for a text article.

Neat article. But it was very difficult to navigate for me because 99% I use the keyboard up/down arrows to scroll the page as I'm reading. This page swallows those keystrokes, apparently. Page up/down work, but sometimes. I never use page up/down while reading because I'll be in the middle of a sentence of a paragraph at the bottom, hit page down, and now I need to scan my eyes back to the top of the page. First, it introduces a hiccup in the middle of a sentence, and secondly, because of the hiccup I often want to go back a line or two to reestablish context, but it is now offscreen. Grr.

A computer fundamentally isn’t functions though. That’s not how a processor works. If functions are a useful abstraction, why haven’t functional languages taken off?

I think it's a cool book for students.

But for real world programming, the tedious ones is related to validation, parsing and other business logic.

So i prefer a book to help teach CS by using real world codebase to solve real world everyday problem as a software engineer instead.

You can have your cake and eat it.