4 ms·

Really, there are no if+for, just compare and jump. Why don't we use what the metal uses, instead of these "expressive abstractions"? If+for have no deeper fou

Really, there are no if+for, just compare and jump. Why don't we use what the metal uses, instead of these "expressive abstractions"? If+for have no deeper foundational significance in the construction of programs or computations, literally, than say a lambda function. But because the latter is unfamiliar, it's spoken about in the same manner you present: as if it is some highly abstract, complicating, high-level feature (when truly that take is just baloney).

mbot5324 5y ago
> as if it is some highly abstract, complicating, high-level feature But symbol calculus is a highly abstract, complicating, high-level system assembled out more reality-based systems beneath it. If it seems simple to you, you're just under the curse of knowledge.
- reikonomusha 5y ago
  I'm not sure what a "symbol calculus" is. Do you mean "lambda calculus"? I think that's a lot less complicated and abstract than a fabled machine with an infinite tape that's controlled by a transition graph of symbolic states. :) And I don't know what a "reality-based system" is.
  - xyzzy_plugh 5y ago
    You're confusing computer science with writing software to run on hardware. Coding requires the latter, but not the former.
    - reikonomusha 5y ago
      Oof, and to think one could helpfully inform the other! :) To be clear, I am a programmer, not a computer scientist, so my opinions are based off writing code and managing teams to write code that works, and less so about abstract machinations of computer scientific thinking.
      - AmpsterMan 5y ago
        For the record, I generally think that people exaggerate the complexity of Functional styles. I think the reason that stateful, imperative code is the default is because that is how we tend to "think". Example, if I wanted to get a list of items for the grocery store, I get a piece of paper (instantiate an array), go through the list of things I might need (loop through a source array) and write down the ones I definitely need (append onto the destination array). If I run out of space, I get a new piece of paper and continue the process. With that algorithm, I can stop and test each individual statement; I don't need to "think about it" because I can write and execute a tiny part of it (even if I'm only executing it in my mind). In a functional style, I have to think more declaratively. Given all my items, filter out the ones that need replacing and give me that list. It's much easier to reason about abstractly, but I have no details about w how that's actually happening. I think this kind of thinking is superior most of the time: I would rather read map.filter.reduce more than a for loop with branch statements any day of the week, but I am trusting the implementations of the mapping and filtering and reducing functions. Of course, for any non-trivial algorithm one is still passing a function into the map/filter/reduce anyway so I can still reason about those smaller stateful sections without worrying about the map/filter/reduce piping. Perhaps I've never worked in a truly pure functional style so I may not be dealing with the mountains of abstractions others seem to complain about
- kaba0 5y ago
  Which without side effects can be very heavily optimized (probably even better) than imperative code? Hell, the pipelining inside GPUs, and CPUs are perhaps closer to lambda calculus than Turing machines. It’s not like the machine code will look much closer to your C code either. That’s also a spell of “compiler writers and hardware vendors trying to uphold the view that C programmers are so close to hardware and that memory access is flat”.
pdonis 5y ago
> Why don't we use what the metal uses, instead of these "expressive abstractions"? Because the "expressive abstractions" are much easier to reason about and save programmers lots of mental effort. And, as I have commented upthread, ifs and for loops are by no means the only such abstractions. > because the latter is unfamiliar, it's spoken about in the same manner you present: as if it is some highly abstract, complicating, high-level feature If expressing your program in the lambda calculus is easy for you to reason about and saves you enough mental effort, go for it. But don't expect your code to be readable or understandable by many other people. The reason why ifs and for loops (and other "expressive abstractions", since as I have said, those are by no means the only ones) are ubiquitous in programs is that they are easy for lots of programmers to reason about. Whereas the lambda calculus is only easy for a very small subset of programmers to reason about.
- reikonomusha 5y ago
  I'm not suggesting people "express programs in the lambda calculus", but instead that incorporating a philosophy of functions and their composition is not at all a bizarre concept. Loops and ifs work miserably with any hierarchical data, compared to recursion, for example. A lot of the world's data is hierarchical. We now have a chicken-egg problem. I can freely admit that for+if is easy for programmers to understand solely because of how we are educated, and not due to any Bruce Lee hocus pocus about simplicity or fundamentalism, as so many others here suggest. A programmer who, say, learned from SICP first would find a for loop awkward and bizarre when you could "just" tail-recurse.
  - pdonis 5y ago
    > incorporating a philosophy of functions and their composition is not at all a bizarre concept Sure, functions and their composition are very often another highly useful abstraction that is easy to reason about and saves the programmer a lot of mental effort. > We now have a chicken-egg problem. No, just a recognition, which was not there in the original claim, that ifs and for loops are not the only useful abstractions. > A programmer who, say, learned from SICP first would find a for loop awkward and bizarre when you could "just" tail-recurse. Perhaps, but I think such a programmer who needed his code to be readable and understandable by a lot of other people in a large project would end up inventing a "for-loop" macro or something similar that, while it might use tail recursion under the hood, would express the construct in a way that programmers could understand regardless of how they learned programming.

mbot5324 5y ago

> as if it is some highly abstract, complicating, high-level feature But symbol calculus is a highly abstract, complicating, high-level system assembled out more reality-based systems beneath it. If it seems simple to you, you're just under the curse of knowledge.

reikonomusha 5y ago
I'm not sure what a "symbol calculus" is. Do you mean "lambda calculus"? I think that's a lot less complicated and abstract than a fabled machine with an infinite tape that's controlled by a transition graph of symbolic states. :) And I don't know what a "reality-based system" is.
- xyzzy_plugh 5y ago
  You're confusing computer science with writing software to run on hardware. Coding requires the latter, but not the former.
  - reikonomusha 5y ago
    Oof, and to think one could helpfully inform the other! :) To be clear, I am a programmer, not a computer scientist, so my opinions are based off writing code and managing teams to write code that works, and less so about abstract machinations of computer scientific thinking.
    - AmpsterMan 5y ago
      For the record, I generally think that people exaggerate the complexity of Functional styles. I think the reason that stateful, imperative code is the default is because that is how we tend to "think". Example, if I wanted to get a list of items for the grocery store, I get a piece of paper (instantiate an array), go through the list of things I might need (loop through a source array) and write down the ones I definitely need (append onto the destination array). If I run out of space, I get a new piece of paper and continue the process. With that algorithm, I can stop and test each individual statement; I don't need to "think about it" because I can write and execute a tiny part of it (even if I'm only executing it in my mind). In a functional style, I have to think more declaratively. Given all my items, filter out the ones that need replacing and give me that list. It's much easier to reason about abstractly, but I have no details about w how that's actually happening. I think this kind of thinking is superior most of the time: I would rather read map.filter.reduce more than a for loop with branch statements any day of the week, but I am trusting the implementations of the mapping and filtering and reducing functions. Of course, for any non-trivial algorithm one is still passing a function into the map/filter/reduce anyway so I can still reason about those smaller stateful sections without worrying about the map/filter/reduce piping. Perhaps I've never worked in a truly pure functional style so I may not be dealing with the mountains of abstractions others seem to complain about
kaba0 5y ago
Which without side effects can be very heavily optimized (probably even better) than imperative code? Hell, the pipelining inside GPUs, and CPUs are perhaps closer to lambda calculus than Turing machines. It’s not like the machine code will look much closer to your C code either. That’s also a spell of “compiler writers and hardware vendors trying to uphold the view that C programmers are so close to hardware and that memory access is flat”.

pdonis 5y ago

> Why don't we use what the metal uses, instead of these "expressive abstractions"? Because the "expressive abstractions" are much easier to reason about and save programmers lots of mental effort. And, as I have commented upthread, ifs and for loops are by no means the only such abstractions. > because the latter is unfamiliar, it's spoken about in the same manner you present: as if it is some highly abstract, complicating, high-level feature If expressing your program in the lambda calculus is easy for you to reason about and saves you enough mental effort, go for it. But don't expect your code to be readable or understandable by many other people. The reason why ifs and for loops (and other "expressive abstractions", since as I have said, those are by no means the only ones) are ubiquitous in programs is that they are easy for lots of programmers to reason about. Whereas the lambda calculus is only easy for a very small subset of programmers to reason about.

reikonomusha 5y ago
I'm not suggesting people "express programs in the lambda calculus", but instead that incorporating a philosophy of functions and their composition is not at all a bizarre concept. Loops and ifs work miserably with any hierarchical data, compared to recursion, for example. A lot of the world's data is hierarchical. We now have a chicken-egg problem. I can freely admit that for+if is easy for programmers to understand solely because of how we are educated, and not due to any Bruce Lee hocus pocus about simplicity or fundamentalism, as so many others here suggest. A programmer who, say, learned from SICP first would find a for loop awkward and bizarre when you could "just" tail-recurse.
- pdonis 5y ago
  > incorporating a philosophy of functions and their composition is not at all a bizarre concept Sure, functions and their composition are very often another highly useful abstraction that is easy to reason about and saves the programmer a lot of mental effort. > We now have a chicken-egg problem. No, just a recognition, which was not there in the original claim, that ifs and for loops are not the only useful abstractions. > A programmer who, say, learned from SICP first would find a for loop awkward and bizarre when you could "just" tail-recurse. Perhaps, but I think such a programmer who needed his code to be readable and understandable by a lot of other people in a large project would end up inventing a "for-loop" macro or something similar that, while it might use tail recursion under the hood, would express the construct in a way that programmers could understand regardless of how they learned programming.