[HN Gopher] The Curse of the Excluded Middle (2014)
___________________________________________________________________
The Curse of the Excluded Middle (2014)
Author : alexzeitler
Score : 14 points
Date : 2023-12-27 19:59 UTC (3 hours ago)
(HTM) web link (queue.acm.org)
(TXT) w3m dump (queue.acm.org)
| beanjuiceII wrote:
| whats it mean
| 082349872349872 wrote:
| imperative programming is like sitting in one chair; pure
| functional programming like sitting in the neighbouring chair;
| and Meijer's thesis in TFA is that "mostly functional"
| programming will turn out to be like attempting to sit in the
| space between them.
|
| for the title, see
| https://en.wikipedia.org/wiki/Law_of_excluded_middle
|
| (given his involvement with C#, I am willing to consider the
| notion that his views may well reflect having had unpleasant
| experiences. If Rust moves beyond the "innovator" segment, it
| would be a counterexample.)
|
| Edit: NB (2014) ; he may well have revisited this topic more
| recently?
| mrkeen wrote:
| In imperative programming, you write statements which change
| the state of the system.
|
| When you go to debug a method, you need to be able to recreate
| the state of the system in order see how the method misbehaves.
|
| But a _function_ always has the same output given the same
| input. It doesn 't matter how big the function gets or how many
| other functions it calls. So if f(1, "foo", 47) throws an
| exception on a prod server, you can run exactly that function
| locally and watch it throw the same exception.
|
| Now someone might come along and change f's source code so that
| it mutates something, or reads from something which can be
| mutated. And they might call f 'mostly functional'. But it no
| longer returns the same output for the same input. f(1, "foo",
| 47) may or may not equal f(1, "foo", 47), so you're back to
| debugging _methods_ , not functions.
|
| A method being 'mostly-functional' is like 'int i' being
| 'mostly-const'.
| asplake wrote:
| > The idea of "mostly functional programming" is unfeasible. It
| is impossible to make imperative programming languages safer by
| only partially removing implicit side effects.
|
| Except that people do it all the time, and they find it safer
| than not doing it.
| jt2190 wrote:
| If I understand the article correctly, even if the programmer
| is reasoning and coding functionally in an imperative language,
| the compiler can not assert that the code is safe for
| concurrency and parallelism. (You may find you get other
| benefits from programming functionally.)
| kupopuffs wrote:
| honestly, I've yet to see a practical application of pure
| functional programming that is that much better than mostly
| functional.
|
| it's hard for most people to follow a completely pure functional
| programming model, but certain concepts like anonymous functions
| are still very nice and practical
| Twey wrote:
| Every ten years it's discovered that another idea PL
| researchers have been harping on about about for forty years is
| very nice and practical once people get used to it :)
|
| I remember when anonymous functions (indeed, first-class
| functions at all) were considered academic nonsense that just
| obfuscated problems. After all, who can keep track of all that
| complexity of functions calling functions?
| stephendause wrote:
| > Imperative programs describe computations by repeatedly
| performing implicit effects on a shared global state.
|
| Is this necessarily true? In Rust programs, operations do not
| operate on a shared global state - at least not in the way I
| think most people would understand 'effects on a shared global
| state.'
| kibwen wrote:
| The enemy is shared mutable state. Functional languages solve
| the problem by focusing on immutability and statelessness,
| whereas Rust solves the problem by letting your state be shared
| _xor_ mutable.
| shermantanktop wrote:
| Tools that prevent the developer from expressing
| fundamentally invalid ideas? Great. Not so great are:
|
| - Tools that force the user to adopt a mindset that the tool
| designer prefers; essentially this bounds the expressive
| power of the tool artificially for aesthetic or other
| opinions.
|
| - Tools that prevent the user from even understanding the
| danger that the tool is guarding against. IMO developers need
| to know what concurrency is, what the range of various
| numeric types are, how signed values actually work. I know
| others disagree on this, but idiot-proof tooling doesn't help
| people grow past a certain point.
| qsort wrote:
| Idiot-proof tooling helps non-idiots, whereas idiots may
| not by definition be helped in any way.
|
| I know the internal representation of integers and floats
| and I know how important that knowledge is. I reverse-
| engineered a gnarly bug in a codebase just last month using
| it. I'd still rather my programming language have 10*100
| resolve to the actually correct answer rather than
| undefined behavior.
|
| I have written production code with pthreads, but I'd still
| rather use async if realistic for the task at hand.
|
| I know how to manage my own memory but I'd still rather use
| a GC'd language if realistic for the task at hand.
|
| I know how to write queries directly to the postgres
| socket, but I'd still rather use a proper client.
|
| I know how to write code in vi but I'd still rather write
| code in jetbrains.
|
| (...)
|
| Where does the fascination for not using proper tools come
| from? I'm reminded of this:
| https://www.youtube.com/watch?v=3I_Ds2ytz4o
| orwin wrote:
| Totally agree now that i'm old, but:
|
| > I know how to write code in vi but I'd still rather
| write code in jetbrains
|
| I hard pass on that, Jetbrains is probably the slowest
| IDE i have ever used. Probably great if your PC is a war
| machine, mine usually aren't (company provided ones, and
| my laptops).
|
| I'd rather code with an old vi with minimal plugin and
| color support than with Jetbrains. I was highly critical
| of Netbeans thanks to similar slowness issues when i used
| it for the first time 11 years ago (it was with a VERY
| large codebase), but Jetbrains is the worst. And this
| slowness triggers me too much to do anything.
| _0ffh wrote:
| I'd really love to use an IDE, but I haven't found any
| modern ones that I don't hate. Which is curious, since I
| used to love the Borland IDEs (Turbo Pascal, Turbo C).
| Maybe I'm just spoiled, but all the IDEs that I've tried
| since have managed to turn me off quite thoroughly, in
| one way or another.
| kibwen wrote:
| Title here should have (2014).
| alexzeitler wrote:
| done
| jackblemming wrote:
| I haven't found this to be the case at all, and have found great
| success in taking the good parts of OOP and functional
| programming.
___________________________________________________________________
(page generated 2023-12-27 23:01 UTC)