DEV Community: EstebanMarin

Learning Physics with Functional Programming and Haskell

EstebanMarin — Thu, 15 May 2025 05:09:39 +0000

TL;DR; I gave a talk at LambdaConf 2025 Youtube this is a follow up post. Haskell Files -> GitHub. I'll post the video once I get it

Also, please, if you like the post and get curious, make sure to buy the book from Scott N. Walck

This talk is about objects and arrows that point to objects. And you will see a lot of that throughout the talk

Last year I learned that functional programming is a great tool to learn Physics, because it’s a great way to write math.

You see, Physics is expressed in the language of Math.
The relation of Math and code is now more present than ever.
Therefore, applying my debugging skills as a software developer, I was able to get a deep understanding of physics whilst writing code, which was a lot of fun, and I want to share the experience with you.

With this talk, I hope to explain Newton’s second law, describing the problem through types and writing math as code to help us compute functions. This is a new perspective on learning Functional Programming and/or Physics.

Haskell is one of the best tools for drawing objects and arrows!!!!

People do not see this as a graphical language, but I would like to show otherwise.
We will derive our code implementation magically by taking a math equation and transcribing it letter by letter into Haskell code.

But we will get types for free!! And this is mind-bending.

Code will not feel like code.

Describing our domain problem through types

Here we are just writing types in Haskell

We start with a wrapper over double for a Real number, I know, big assumption, but let’s carry on.

We also see a function definition and each time you see an -> I want you to think of a normal math function.

The one you would write on a piece of paper

Visually, the Haskell compiler is representing the following

Everything encoded as a Real number: acceleration, velocity, position and time.

The interesting question is: How to jump between the endpoints?

How do you go from a position function to a velocity function, and even more interesting, how do you come back?

The answer is arrows!! And in Haskell, that's a function.

Describing the type of function in this question, we can start implementing code.

Defining velocity as distance travel through time.

Rewriting the definition for smalls t

And limiting the delta T to cero

We will arrive to the instantaneous velocity
Once we have definition of instant velocity.

We can implement derivatives in Haskell

The code in haskell is a one to one mapping of the function you would write on a piece of paper.

This can also be python code too.

The real kick comes when the Haskell compiler infers the types, which come for free!!!

(first mind blow moment for me) Thinking of calculus through types

We see that derivative is a higher order function,

I never really thought about derivatives as HoF, but there you go.

Higher order functions can help us glue code nicely

contributing us to build a very complex model

Now what we have a derivative definition.

Let’s revisit the core question of our initial model

How from position/time measurements can we infer the particle velocity and acceleration?

That’s really the question.

The Haskell implementation is straightforward and very ergonomic, using point-free notation

The derivative function gives the ability to move clockwise in the model,

And this is very powerful.

But, How can we reverse the movement, like going counter-clockwise?

Like what’s an antiderivative?

Before answering what an antiderivative is:

Let’s explore an old idea idea that came even before derivatives.

It’s dividing something by parts and sum them all together to get an approximation of the whole.

Here we are stating that

the area under the function is the bounded integral of a function between A and B

Using equational reasoning:

Means that the bounded integral is the area under the function.

The intuition I want to present here is thinking of what’s left of the equal sign as the math object we want to represent

And to the right of the equal sign as the way we get there, more precisely the right side

Is a computation that we will give to the computer.

Lets see how calculating an area does it look in haskell

Let's start with the sum of rectangles of height f(t) times some delta t

Now we need a stream of rectangles that are evenly spaced

Using the midpoint rule we are going to sample f(t) here

Which, I believe is a very concise way of expressing the implementation of an integral

We are summing all rectangles from a to b at a midpoint rule.

Now that we have our definition of bounded integral

Let’s explore the types the haskell compiler provide us

Next we see that an integral can be either Analytical like we learn in highschool, or numerical.

We want to do numerical integrations, more precisely, we want the computer to handle the integration for us

On top we define Numerical integrations is a Type that Takes a function to integrate lower and upper bound

Returns a real number as a result

Coming back to the question of how to move clockwise and counterclockwise

We let the geniuses enter the stage and we will take their work for face value, for now.

Newton states that:

Derivatives and unbounded integrals are just part of the same.

One is the inverse of the other.

Derivatives and unbounded integrals are just part of the same.

Mathematically, the fundamental theorem of calculus is presented as:

Derivatives and Antiderivatives equate

The bounded integral of f(x) in the interval a through b

Equates as the Anti Derivative at b minus anti derivative at a.

Revisiting the intuition of moving terms around to the right so we can give the computer to compute

And the mathematical object to the left. Lets actually get the Antiderivative of any function by

Revisiting the intuition of moving terms around to the right so we can give the computer to compute

And the mathematical object to the left. Lets actually get the Antiderivative of any function by

The Antiderivative of F(x) is

An initial value F at b plus the bounded integral of the function

And we can do bounded integrals in haskell already!! NUMERICALLY!!!

Writing this code in haskell, or mapping the math as code

we now have a function that can anti-derivate any function

Again code does not feel like code and

Lets look and learn from the the types we get for free!!

The type of Anti derivative is …… surprise surprise

a higher order function!!! Like derivative, takes a function returns a function

And we will delegate that computation to the answer to the computer so we can numerically get a useful realtime answer

This means, therefore

We have now a cute model in haskell that can solve any Kinematic high school physics problem.

Recapping:

Everything encoded as a Real number, acceleration, velocity and position.

and we can go from them and back using derivatives and anti-derivates.

Now lets actually play around with our code and test it in real life

Imagine we go outside and let fall several objects measuring it position, time and mass. Which leads us to a function as show.

Could we make predictions about velocity and acceleration???

The answer is yes!

We make a derivative of a parabola,

which is a slope and that’s velocity

Deriving a slope gives us ….?

A constant!!

Imagine yourself doing this experiment/measurement for several months
varying the mass of the object, and arriving to the same acceleration constant!!!

This is another moment of Netwon’s brilliancy because the notices that the constant acceleration is part of a bigger picture

Newton claims again.

Force is proportional to the mass times the acceleration,
here acceleration show as a second derivate, implying a differential equation.

How is this new Force Object relates to our initial model? We will encode it in a Real number as the others

Newton created the scientific method by dissecting problems into parts, and then compose that
Into a more complex model.

We start with a simple version of the problem how does the model behaves in constant force?

Like for example a as falling apple

All consistent with what we measured in the lab so this is useful.

Lets get more creative with our model can make predictions of velocity and position

When modeling a cyclist

Describing the pedaling motion as a step function as show (Describe the step function),

we want to move counterclockwise

And say something about the velocity and position?

Slopes should appear in the velocity gauge, and an increasing function in the position gauge

Let’s see if we can explore more connections of the model.

Like a direct arrow from Force to Velocity? What does it take to get there? What can we learn?

This arrow describes a air resistance problem

normally avoided in intro physics class as requires to solve a differential equation.

However, we are going to tackle it head on because it will give us the ability to solve differential
Equations in haskell

Lets go to the whiteboard

We are going to re-write newton's second law in terms of a velocity function derivative

Writing the expression in haskell is straightforward.

The sum of the force function depends of velocity at v0, summing all force functions and divide by m.

The main intuition here is that we will think of newton’s second law as a, wait for it:

first order differential equation generator function ( what a mouth full )
That takes a list of forces (a description of the system)

That is going to be injected to a integral/solver that will

arrive to a solution for velocity

We are going to solve this function using the Euler method

Visually the method takes an initial value calculate the slope using the next value of the function as an approximation

Obviously, with each step the approximation get worst, but the intuition will prove valuable.

It’s to our advantage to arrive to a solution numerically rather than analytically

The Euler Method will reduce to the solution to:

Velocity at T + delta T equals = initial velocity + derivative of velocity times delta T,

This is what’s called a initial value problem

then we will iterate over this function to get stream of solutions

Using velocity as a state descriptor of the system

Initial velocity and newton's Second Law as a predictor of that next state,

We can iterate over time to see our predictions evolve

Visually In our model …

Our model now has a new arrow that takes description of forces to velocity

Lets stimulate again the system with a the same step function and using the cyclist model

Now adding the air resistance to our model

What can we expect the velocity function look like?

By playing with the area and drag constant

One solution can look like a cyclist reaching terminal speed due to air resistance

Other is solution expresses velocity when pedaling head wind!!

Now as you can see this is a pretty cool model:

that solves differential equations

But can we improve it?

Yes we can:

How about we encode not over real numbers but over vector, and vector spaces.

How would that look like in Haskell?

Its a data structure that groups 3 values into one.

We enrich the space with the same operations we can do with Real numbers but fitted into Vectors.

For example tilda minus tilda. Takes vector A and Vector B to produce another vector thats a subtracted from b

We have scalar operations

Our last two: we have the dot product which takes two vectors and returns a Real number

And Cross product that takes 2 vectors and returns another Vector.

Now we want to see if vectors can handle derivatives and antiderivatives as that's how we jump between functions

The difference is barely noticeable in the implementation. And we are caring over the same intuition

We would like to abstract over all these wires and create a newton solver black box

The black box that we want to have is

1- given a Description of a system through the sum of Forces
2 - And a initial particle State

3 - return a position function that we can then derive to have a velocity function

We are not going to implement this black box but we are going to explore the types to understand how classical physics works under the hood.

Let’s quickly model a constant Force and constant Mass problem in space

The types will show you what’s happening and how the model predicts velocity

We take a numerical method (Euler or RUNGA-KUTTA 2)
Particle state
A delta Particle State

An initial State

We get our a position function

Rearranging some of the types in the black box, we will explore relativistic and newtonian predictions to the problem

Noticed how the type shows us that we are taking a one Body Force

A DIFFERENTIAL EQUATION, a particle state, a delta Particle state

The intuition that I want to show here that we have modularity in our code.

As we are using the same Differential equation solver for both Body problems.

See how Newton’s model wrongly predicts that velocity will increase without a cap

Newtonian predicts particle will surpass the speed of light

Whereas relativistic has an asymptote at the speed of light

We just went through 500 years of math and physics in less than 30 minutes, but we were able to take this ride because functional programming is a great way to write math, and math a great tool to handle complexity and describe nature.

I hope this inspires more developers to explore the side of code that is about using math and functions differential equations and math objects, rather blindingly in the next upcoming framework.

Being able to explore nature through Mathematical models using differential equations and making useful predictions though computers is a skill for the future for software engineers.

Thank you!

Explain to me how to nix and Haskell properly.

EstebanMarin — Wed, 05 Feb 2025 19:48:31 +0000

Looking for help on how to properly nix with Haskell

TL;DR I am looking for feedback on how to properly Haskell with nix.

The problem

I need to install locally Haskell, with reasonable integration with vscode (LSP as a minimun)

Most Modern Software engineers are not engineers at all.

EstebanMarin — Wed, 21 Aug 2024 12:56:03 +0000

They are at best artisans, at worst specialized monkeys.

TL;DR Concerning the engineering profession, do not call yourself a software engineer if you dislike/disapprove/do not know concepts like lambda calculus, category theory, or abstract algebra. Furthermore, Engineers are, by law, accountable for their work, we should ask so-called "software engineers" the same.

Background

I am a trained Electrical and Electronic Engineer. I came into engineering because I LOVED math, and lucky I got A LOT of it, most of my study books looked like this.

If you look at a mechanical engineer book it looks like this:

If you look at a Chemical Engineer book, you will see something like this

What do they have in common?... Engineers write Math

Engineers write math because it's THE ONLY TOOL AVAILABLE to understand complexity, fine-tune their intuition of the problem, explore possibilities and use that to stir their solutions. It's also the best communication tool out there and is very precise.

Can anyone picture a Civil engineer saying something?:

Math is overrated! I'll just start working on the bridge and let where it takes me

Even though it is ridiculous, with enough infinite tries and resources he will eventually construct a building see infinite monkey theorem

like if you put a monkey to type random keystrokes infinitely will eventually write any given text (infinite monkey theorem)

And for me, that's exactly how modern software is being built. It takes less than infinite time as the monkeys we use are a little more specialized but equally problematic to work with, especially the 10x.

So what do Software Engineering Books look like and how they should look like?

Engineers do not use all of math, math is too big for them to even need it all, but they use specialization of maths.

Electrical Engineers love imaginary numbers, Laplace/Taylor transformations, and linear algebra.

Chemical Engineers do stochastic processes, differential equations, statistics...

Software engineers, throwing the punch line of the post away here, they use no math. That is why their books mostly show hand-drawn pictures consisting (mostly) of boxes and lines connected with no other criteria than the one given by the author, arbitrarily. If that becomes popular enough, it becomes a sort of law everyone should predicate.

Book of software should be written with math like lambda calculus, abstract algebra, functional programming, or Category theory. However, at this point, most "Engineers" will frown upon it, arguing that Functional programming is an overkill.
Whenever I hear a Software "Engineer" complaining that FP, Monads, or Monoid are just overkill, and that's just fancy words for elitists, and you can do everything with plain JavaScript. It's me hearing that dumb Civil engineer again.

ACOUNTABILITY

Engineers in general are accountable by law for their work. This means that if they sign a blueprint with their calculations of a building, and that building collapses they are accountable for that, even going to jail if the incompetence is too much to bear.

WHY ARE NOT MODERN SOFTWARE ENGINEERS HELD TO THE SAME STANDARD? They are dealing with people's lives, livelihoods, savings, weapons of war, planes, and pretty much everything...

If people want the Software ENGINEER title, they should sign their work and be accountable. Once you own that type of responsibility, you start using the best tools around to do your work, like Math.

Summary

If you dislike functional programming, please do not call yourself and software engineer. You are an artisan at best, a specialized monkey at worst.

What haskellers do not want you to know.

EstebanMarin — Tue, 06 Aug 2024 19:30:14 +0000

The `Yin` and `Yang` of Functional programming

I am for one a person who is very excited about Functional Programming and Haskell.
Normally you will see me yaping on social media about the beauty of FP, and how it's the best thing ever invented since
sliced bread.

While functional programming offers many benefits, it also comes with its own set of challenges, much like anything else in life. Interestingly, the very features that are touted as advantages—immutability, ease of reasoning, and conciseness—can also become sources of difficulty. Thus, the dual nature of functional programming, like Yin and Yang, is revealed.

What is functional programming in a nutshell

Functional programming is a method or program construction that emphasises function and their application, rather than commands and their execution
Functional programming uses simple mathematical notation that allows problems to be described clearly and concisely
Functional programming has a simple mathematical basis that supports equational reasoning about the properties of programs.

(Source: Thinking functionally, Richard Bird) Chapter 1 page 1.

I will not go through the weeds of each bullet point, but generally, they say that FP is based on simple sound mathematical principles that make reasoning about programs easier.

I am showing 2 cases where it might not be necessarily the case.

The YIN and YANG

Conciseness

Let's take the following, program over 3 Natural numbers:

[1,2,3].map(x => x+1)
// [2,3,4]

Many people might think that this code translates to:

const arr = [1, 2, 3];
const result = [];
for (let i = 0; i < arr.length; i++) {
  result.push(arr[i] + 1);
}
result
// [2,3,4]

And they would be missing half the story, as this is only a partial implementation.

Great we took 6 lines and converted them into 1, so is this is what we solving?

The conciseness of the [1,2,3].map(x => x+1) is not about fewer characters, rather it hides from us several mathematical principles that will send us down a deep rabbit hole, (PLEASE BE AWARE I WILL BE USING scary words for a while)

What this code is saying is that we will be mapping over a data structure (natural numbers, that will need to be encoded in the language) that has properties of Functor and probably monad. Under the hood we would have something like this in Haskell, hidden by the standard library.

-- We NEED to encode the definition of numbers into the lang
data Nat = Zero | Succ Nat
-- equality type-class we need this in order to compare numbers
instance Eq Nat where
  (==) :: Nat -> Nat -> Bool
-- we need this in order to print results
instance Show Nat where
  show :: Nat -> String
-- provide binary functions we need this to tell the computer how to operate with numbers
instance Num Nat where
  (+) :: Nat -> Nat -> Nat
  (*) :: Nat -> Nat -> Nat
  abs :: Nat -> Nat
  ...
-- and finally after we can map over our natural numbers

Now Haskell hides this from you by providing utility data types such as Num Integer and their respective
instances of Eq, Semigroup, Monoid, Monad... and so on.
But there you go, it's concise mathematically speaking, but at the end, you are writing more lines of code.

Immutability

Probably the focal point of any OOP vs FP debate. Many FP elitists will look with disgust at any code that reassigns variable values, arguing that the state breaks the equational reasoning of programs. Where OOP pragmatics argue about the inherent performance. Both sides are right. I'll start by showing a beautiful canonical example of an FP function. Where laziness, recursive scheme and conciseness shine.

-- Fibonacci
fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n - 1) + fib (n - 2)

At a glance, we have described easily how to create fib numbers, but it's a terribly inefficient function, as it takes exponential time to evaluate. By not getting into details we can improve the time performance of this function, by using Tupling technique of parameters (Chapter 7.6 Thinking Functionally, Bird.).

fib :: Int -> Int 
fib n = fst (fib2 n)
fib2 0 = (0,1)
fib2 n = (b, a+b) where (a, b) = fib2 (n-1)

Evaluating fib now takes linear time, but the space involved is not constant (even ignoring the fact that arbitrarily large integers cannot be stored in constant space)

In order to constrain the space of our solution we will introduce the ST monad and the strict operator ($!). (See Chapter 10.4 Thinking functionally. Bird) like so.

fibST :: Int -> ST s Integer
fibST n = do { a <- newSTRef 0;
               b <- newSTRef 1;
               repeatFor n
                (do {x <- readSTRef a;
                     y <- readSTRef b;
                  writeSTRef a y;
                  writeSTRef b $! (x + y);
                readSTRef a})
              }

-- we need however to run the ST monad to get a proper value
runST :: (forall s . ST s a) -> a
-- Then we can finally have an efficient Fibonacci function that looks like
fib :: Int -> Integer
fib n = runST (fibST n)

I do not know about you, but I found this significantly harder to digest.

On the other hand, we can make a one-to-one translation of the Haskell code above in python as

def fib (n):
  a,b = 0,1
  for i in range(0, n):
    a, b = b, a+b
  return a

What this is telling us is that immutability is not only making our code more efficient but also easier to understand!

Summary

As much as I love functional programming and using maths. Going full-on math principles can make things easy to reason but hard to implement, but having an easy implementation can lead problems reasoning

DEV Community: EstebanMarin

Learning Physics with Functional Programming and Haskell

Explain to me how to nix and Haskell properly.

Looking for help on how to properly nix with Haskell

The problem

Most Modern Software engineers are not engineers at all.

Background

What do they have in common?... Engineers write Math

So what do Software Engineering Books look like and how they should look like?

ACOUNTABILITY

Summary

What haskellers do not want you to know.

The Yin and Yang of Functional programming

What is functional programming in a nutshell

The YIN and YANG

Conciseness

Immutability

Summary

The `Yin` and `Yang` of Functional programming