Everything Is Just Functions: 1 week with David Beazley and SICP

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.

The thing is, I find immutable is safer. Less side effects is more predictable. OO is used often when things can just be functions. I love gamedev, and OO makes a lot of sense there because all of the computations and unsafe code is kind of okay. But for webdev FP makes so much more sense. For SAAS something like elixir enables me to write more reliable / less buggy / better tested code.

>At the end of the day, it’s grounding to remember there’s mutable memory and a CPU processing the code.

And yet goto is even less popular than Lisp despite being the only way that CPUs implement control flow.

What's even more bizarre is that despite caches being the only way to get any performance out of modern CPUs we still don't have a language that treats the memory hierarchy as a first class citizen. The closest is Linux flavored c with a sea of underscores.

Lisp has goto, if you want it. :)

I confess it has made transcribing some algorithms a bit easier.

Like Common Lisp Object System?

Besides, stuff like forEach, map/reduce was already present in Smalltalk collections, and was copied into Object Pascal, C++, even if without first class grammar for it.

Exactly because the underlying memory is mutual, there are mechanisms in ML languages to mutation, when really needed.

How do you deal with lack of types? (I know elixir is adding types but from my understanding it's nothing like e.g. typescript)

I'm thinking about learning elixir but lack of types is kind of a turn off for me.

If I could get one wish, it would be to ban "makes sense" from any engineering discussion ever. Facts do not "make sense" the world is not a "sense making" machine. We make sense of the world and of the facts. Something feeling intuitive, which is what people often mean when they claim something "makes sense", just means it slots into your existing experience.

In Elixir specifically you've got structs that are somewhat similar to types, %MyStuff{}, and if you need to you can use Ecto to get some guarantees. You also tend to focus more on the shape of data than the name, e.g. with pattern matching in places like function declarations and case expressions, which emulates quite a bit of what you typically use a type system to accomplish.

Here's a summary of the type system they're exploring for Elixir: https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

> How do you deal with lack of types?

Not GP but I'm using Clojure for both the front-end (ClojureScript) and the "back-end" (server running Clojure), sharing Clojure code between the two.

Clojure is not typed but I use Clojure specs. It's not a type system but it's really nice. You can spec everything, including specc'ing functions: for example you can do stuff like: "while in dev, verify that this function returns indeed a collection that is actually sorted everytime it is called". I'm not saying: "no types + clojure specs" beats types but it exists and it helps to solve some of the things types are useful for.

https://clojure.org/guides/spec

Not the other commenter, but my team has been using Elixir in production (soft real-time distributed systems) for several years to great success. The approachable syntax has been great for folks new to the language coming on board and sort of, not realising they’re “doing FP”.

Generally I’d say Elixir’s lack of “hard” static typing is more than made up for what you get from the BEAM VM, OTP, its concurrency model, supervisors etc.

That said if you’re interested in leveraging the platform whilst also programming with types I’d recommend checking out Gleam (https://gleam.run), which I believe uses an HM type system.

Even in GameDev there is a strong trend towards data-oriented programming and stateless logic, led by the ECS (Entity-Component-System) paradigm.

ECS is all about composition rather than inheritance, and decoupling logic from data. It is not strictly immutable for performance reasons, but it has a similar character as the immutable functional state-management frameworks in WebDev (Redux, Elm and co).

It's not just about maintainability, it actually can be awkward to fit certain patterns into ECS, but it has significant advantages in terms of performance (particularly being CPU cache-friendly) and being able to massively parallelize safely and without having to think too much about it. It can also be a helpful abstraction for distributed computing and networking in multiplayer.

> _for example you can do stuff like: "while in dev, verify that this function returns indeed a collection that is actually sorted everytime it is called"._

This sounds interesting. Do I understand correctly, this checks the "spec" at runtime? What happens if a spec fails?

Fewer side effects.

I don't find it bizarre: even assembly language don't have much control over the memory hierarchy, there's prefetch load and nothing else...

So much the worse for assembly language.

Lest we forget that modern x86 machine code is an assembly language and the machine code, or microinstructions in newspeak, is completely hidden from view.

"Young man, in mathematics you do not understand things. You just get used to them.” - John von Neumann