Hacker News Reader

Comment by danielscrubs | Hacker News Reader

A sidenote: how great would it be if someday an abounded, well written, non buggy piece of code could just stand the test of time like math does?

Instead we throw projects and programming languages faster than I change my wardrobe. :)

View on HN

The maths of today has very little to do with the maths of 500 years ago, let alone 2500 years ago. Sure, we still have the Pythagorean theorem, but in today's modern formulation it's trivial. We still have numbers, but they are no longer something that can be totally ordered. With numbers we even turned things upside down, because we used to first try to define single numbers and only then collections of numbers. These days we say that "a number is an element of a number field", "a vector is an element of a vector space" etc. and we define the structures first. But the biggest departure probably is the widespread reliance on proof. In XVI century you could call yourself a mathematician without proving things, as long as the ideas you came up with worked in practice.

I'm sure that in the programming world we'll still have "if"s and variables/aliases 200 years from now. And that's right about how much commonalities modern mathematics has with the mathematics of the age of Euclid.

Disclaimer: I took a course in history of mathematics and I have to say, if I was born as little as 200 years earlier I wouldn't be able to stand mathematics. These days, it's actually interesting to me. Similarly to how mathematics in primary through high school is really boring.

I mean conditions exist in math already and I'd argue that there is a bigger chance qwerty is still the default keyboard layout than your Python 3 program working in 500 years.

How many of the popular languages even have formal specifications to use as a reference when the next CPU architecture comes along, or the next ABI?

The tools exist but I don't see people rushing to Modula-2 for example, which has.

It does remind me a bit of this paper "Boosting Vector Calculus with the Graphical Notation" [1], but we instead have over ten thousand only partially defined ones.

But I can agree that my view of math is a bit too rosy.

[1]: https://arxiv.org/abs/1911.00892

That's what initially drew me to Haskell, and how it seemed closer to math than most other programming languages.

Lazy evaluation brings this to the fore, especially with needing the programmer to make decisions about the sequencing of operations.

Consider these two statements:

  x = a + 5;
  y = b + 3;

So these statements describe the relationship between 'a' and 'x', and 'b' and 'y'. Great. With most programming languages, the programmer also must choose the sequencing of these operations. When they should occur, and in what order. With Haskell, this goes away.

The compiler / runtime system decides when (or if) the values of 'x' and 'y' will be evaluated. With a really, really smart compiler / runtime system, this can lead to great optimizations a C programmer would need to implement by hand when porting code to a new platform with vastly different performance characteristics.

Now... in practice... I found Haskell hard to get comfortable with. I'm quite happy with Rust these days though.

Reply on news.ycombinator.com