[runeks]

Me too. Particularly because every programmer has their own idea of what a "right"/ideal style of programming is. Here, apparently, we must not use conditionals.

The more I write code the more I realize that the entire purpose of the code is to have some effect on reality, and the more reliably it can do this, the better the code. I find I code a lot better without design principles, because trying to remember which patterns are "good" and "bad" just obscures the attention I would have used to look at the code and sense whether something would work in this particular situation.

[userbinator]

The more I write code the more I realize that the entire purpose of the code is to have some effect on reality, and the more reliably it can do this, the better the code.

Very nicely put. The only "principles" I keep in mind when I write code are simplicity, correctness, and efficiency, and those tend to all be correlated.

[janekm]

Not functional code though. The aim of functional code is to be side-effect free, and affecting reality really gets in the way of that.

/snark, but articles like this really do fall into that trap...

[runeks]

I know you're making a joke, so I'm not writing this to correct you, but I'd like to point out that Haskell/pure FP is different not because it denies affecting reality, but because it only offers a one-way interface to affecting reality: it allows you to alter values in reality using pure functions, but it denies you the ability to "pull in" values from reality, into your pure functions.

This paradigm is powerful because it accurately reflects how our universe works: it is possible for a thought to affect reality (through a human being acting on it), but it is not possible to "pull in" an object from reality, into your mind. The only way to form a thought about something is to look at that thing, and try to construct - in your mind - a thought that reflects certain properties of the thing you're looking at. You can't "pull" that thing from reality into your mind, thus creating a thought. No such interface exists in this universe, as far as I'm aware.

It is, however, very possible for a human being to choose to act on a thought, thereby causing the thought to have a side effect. The analog to this in Haskell is applying a pure function to a value in IO. The function is pure, but we can use it to alter a value that resides in IO (reality). Similarly, a thought, in and of itself, does not affect reality (it is pure); it requires a human being to act on it - "apply it to reality" - in order for it to have an effect.

In short: Haskell allows your program to alter reality, but it does not allow reality to alter your program.

[eru]

Didn't they have some gratituous IO-monad stuff in the article?

[eru]

> The more I write code the more I realize that the entire purpose of the code is to have some effect on reality, [...]

Perhaps. But there's the effect you get from running the code on a computer. And the effect reading the code has on humans.

[runeks]

I'm not sure it's possible to write a piece of software that only you understand, that is of high quality (works reliably). I feel like code correctness (what a computer does with it) and readability (how well a human understands what is written) are two sides of the same coin.

I think I would argue that if someone has happened to write a program that is impossible to understand for human readers (unreadable), and yet it does exactly what it's supposed to do (is correct), at the very least this program will break when the author starts to refactor it, which always needs to be done at some point.

I agree that conveying an idea to another human being through code is useful, but I think the number of times a human being has written a piece of computer code only to convey an idea to someone else is fairly small. If I want to convey an idea to another person I write in words and concepts, but if I want something faithfully executed every time, I need to write the code. And perhaps someone will look at this code later, but the origin of the code was always to get something done, not conveying an idea to someone else.

[eru]

You can write a program that's hard to understand for humans, but comes with a computer-checkable proof of its correctness.

But aside from that pedantic possibility, I agree with most of the spirit of your comment.

Code can be useful to communicate with humans. In fact, the most expressive programming languages should be better at conveying precise descriptions of algorithms to other humans than natural language.

(Not a lot of programming languages reliably reach that ideal. Haskell sometimes comes close.)

I regularly write code that's meant to convey ideas, eg when explaining concepts, algorithms and data structures to people.