Hacker News new | past | comments | ask | show | jobs | submit login

I agree with the sentiment that things should be made as simple as possible. The sine function really has no reason to be anything besides a function. I am not sure, though, that writing the simplest thing possible results in mostly pure functions. In my experience programming is mostly about managing a state. My programming jobs have generally been about tracking what the state of some other piece of hardware and/or software is. It seems hard to escape state in that case. In my spare time I have lately been writing a compiler like thing. That seems to be, among other things, about maintaining a stack of all the stuff that has been defined/declared previously. If so many things are about maintaining a state, how practical is this 'mostly functions' thing actually?



I would claim that the benefits of 'mostly functions' strongly depend on the task at hand.

For the field of compilers, I can for example see value in making program analyses pure functions that just compute information about the program and separate them from the program transformations that use this information to (impurely) manipulate code. This makes the analyses more reusable and probably makes reasoning about correctness easier.

For other tasks in the compiler, pure functions can be a pain. My favorite anecdote for this is that of a group of students in a compiler's course who insisted on writing the project (a compiler for a subset of C) in Haskell and who, when discussing their implementation in the final code review, cited a recent paper [1] that describes how you can attach type information to an abstract syntax tree (which is an obvious no-brainer in the imperative world).

---

[1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_004...


An ad hoc solution is also a no-brainer in Haskell. They didn't need to read a paper to solve this issue, they did because they wanted the fanciest solution that is extensible in all dimensions.


I recommend watching this talk:

“The Value of Values” https://www.infoq.com/presentations/Value-Values/

It explains what the difference is between state and value and why most (almost all) programs actually have very little state and can be written mostly stateless. It was a big eye opener for me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: