9 ms·

> you eventually "give up", and clock your 9–5 writing if+for making a fine living, but erroneously pass that off as a mature This comment sure indicates to me

> you eventually "give up", and clock your 9–5 writing if+for making a fine living, but erroneously pass that off as a mature This comment sure indicates to me where you most likely are on the curve. In all seriousness, I think this is considerably off the mark. After enough experience you realize that expressivity and convenience are antipatterns and don't actually simplify things but are harbingers of complexity, bugs, tech debt, even the downfall of organizations and products. Saying it is all ifs and for-loops is completely true. Everything else, all the abstractions and high level features, are just sugar. I try to keep a healthy and balanced diet, myself. > industry is slow to assimilate most state-of-the-art ideas, sometimes by as much as 40 years. Most of those ideas are terrible. The industry is so incredibly young and has experienced so much change over those 40 years that I have a hard time accepting the notion that the industry is slow to adopt. The reason the old building blocks are still popular is because they are a thin abstraction over how computers work, and ultimately that is at the root of everything we do.

reikonomusha 5y ago
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
- 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.
CuriousCosmic 5y ago
Personally I disagree. We should be using state machines and pure functions. If+for loops are just what's easiest to express in the major languages of today. they are no more or less computationally expensive but due to lack of tooling they are often cheaper to write. In languages and libraries that allow FSM and pure functional kernel based designs you can get just as clear logic that is expressible not just to the programmer but also to business personnel. It's counter-intuitive to a certain extent because so much of programming is built around imperative programming but FSM based logic is and will continue to be easier to understand long term because you can trivially visualise it graphically. This ultimately is what a lot of the functional paradigm is built around. Use the mathematical and graphical representations we've used to understand systems for decades. They are well understood and most people can understand them with little to no additional education past what they learned in their business or engineering bachelors degrees.
- marginalia_nu 5y ago
  > Personally I disagree. We should be using state machines and pure functions. If+for loops are just what's easiest to express in the major languages of today. they are no more or less computationally expensive but due to lack of tooling they are often cheaper to write. In my experience programming programming with primitives and basic flow control operations frequently tends to be at least be order of magnitude faster than more complex state management paradigms. Compilers are very good at optimizing that style of code. Loops often get unrolled, the and the branch predictor is kept happy. A good compiler may use vector expressions. In many cases with cold code it flat out doesn't matter, the CPU is plenty fast, but when it does matter, explicit if-and-for code absolutely mops the floor with the alternatives.
  - jatone 5y ago
    for loop goes brrrrrrrrrrrrrrrrrrr!
  - CuriousCosmic 5y ago
    At least in the C++ space, stuff like boost-sml is able to produce assembly that is often as fast or occasionally faster than handwritten if or switch based FSM logic.
pdonis 5y ago
> Saying it is all ifs and for-loops is completely true. Everything else, all the abstractions and high level features, are just sugar. You could just as well say that ifs and for loops are just sugar for gotos and all programming is just gotos. The reason ifs and for loops are used instead of gotos is that they are very useful abstractions that are easy to reason about and save the programmer lots of mental effort. But they are not the only such abstractions. To the extent that other abstractions can create problems, it's not because they're really just sugar for ifs and for loops, it's because they are not well crafted abstractions so they are not easy to reason about and don't really save the programmer any mental effort. But there are plenty of abstractions other than ifs and for loops that are well crafted and do save the programmer mental effort, in many cases lots of it.
- reikonomusha 5y ago
  I completely agree with this. A lot of people use the term "too much abstraction" when they mean "bad" or "ineffectual abstraction." For-loops can be a wonderful abstraction, but they're certainly no basis for all abstractions.
deleted 5y ago
[deleted]
feoren 5y ago
> Saying it is all ifs and for-loops is completely true. Everything else, all the abstractions and high level features, are just sugar You sound like the kind of person who thinks the ancient Greeks figured out all of math and everything that has happened since then is just fancy abstractions and sugar. Either software engineering can advance as a discipline, or it can't. You seem to be assuming it can't. > This comment sure indicates to me where you most likely are on the curve Never mind, you just sound like an asshole.
- Jensson 5y ago
  Math today does a lot of things you couldn't do with math back then. It isn't just syntactic sugar, there were simply lots of problems they didn't know how to solve since the math they had wasn't powerful enough to solve it. Calculus for example solved a lot of problems they have, and calculus isn't syntactic sugar for anything, it is a new instruction set. However the code abstractions people used 50 years ago could still implement all programs we have today. We added a lot of sugar on top, but the core of coding remained the same. For example, you could implement Map, Reduce etc in C, they are just functions and not novel features of programming.
CTmystery 5y ago
> After enough experience you realize that expressivity and convenience are antipatterns and don't actually simplify things but are harbingers of complexity, bugs, tech debt, even the downfall of organizations and products. Suggesting that experience leads to jettisoning expressivity is at odds with my direct observations of experienced software engineers working in large teams. The more experience, the _better_ the engineer gets at picking the right level of abstraction to write code that can be maintained by others. Picking a single point on the abstraction spectrum (just above goto but not below it!) is far too rigid for the diversity of tasks that software engineers need to solve.

reikonomusha 5y ago

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
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.

CuriousCosmic 5y ago

Personally I disagree. We should be using state machines and pure functions. If+for loops are just what's easiest to express in the major languages of today. they are no more or less computationally expensive but due to lack of tooling they are often cheaper to write. In languages and libraries that allow FSM and pure functional kernel based designs you can get just as clear logic that is expressible not just to the programmer but also to business personnel. It's counter-intuitive to a certain extent because so much of programming is built around imperative programming but FSM based logic is and will continue to be easier to understand long term because you can trivially visualise it graphically. This ultimately is what a lot of the functional paradigm is built around. Use the mathematical and graphical representations we've used to understand systems for decades. They are well understood and most people can understand them with little to no additional education past what they learned in their business or engineering bachelors degrees.

marginalia_nu 5y ago
> Personally I disagree. We should be using state machines and pure functions. If+for loops are just what's easiest to express in the major languages of today. they are no more or less computationally expensive but due to lack of tooling they are often cheaper to write. In my experience programming programming with primitives and basic flow control operations frequently tends to be at least be order of magnitude faster than more complex state management paradigms. Compilers are very good at optimizing that style of code. Loops often get unrolled, the and the branch predictor is kept happy. A good compiler may use vector expressions. In many cases with cold code it flat out doesn't matter, the CPU is plenty fast, but when it does matter, explicit if-and-for code absolutely mops the floor with the alternatives.
- jatone 5y ago
  for loop goes brrrrrrrrrrrrrrrrrrr!
- CuriousCosmic 5y ago
  At least in the C++ space, stuff like boost-sml is able to produce assembly that is often as fast or occasionally faster than handwritten if or switch based FSM logic.

pdonis 5y ago

> Saying it is all ifs and for-loops is completely true. Everything else, all the abstractions and high level features, are just sugar. You could just as well say that ifs and for loops are just sugar for gotos and all programming is just gotos. The reason ifs and for loops are used instead of gotos is that they are very useful abstractions that are easy to reason about and save the programmer lots of mental effort. But they are not the only such abstractions. To the extent that other abstractions can create problems, it's not because they're really just sugar for ifs and for loops, it's because they are not well crafted abstractions so they are not easy to reason about and don't really save the programmer any mental effort. But there are plenty of abstractions other than ifs and for loops that are well crafted and do save the programmer mental effort, in many cases lots of it.

reikonomusha 5y ago
I completely agree with this. A lot of people use the term "too much abstraction" when they mean "bad" or "ineffectual abstraction." For-loops can be a wonderful abstraction, but they're certainly no basis for all abstractions.

deleted 5y ago

[deleted]

feoren 5y ago

> Saying it is all ifs and for-loops is completely true. Everything else, all the abstractions and high level features, are just sugar You sound like the kind of person who thinks the ancient Greeks figured out all of math and everything that has happened since then is just fancy abstractions and sugar. Either software engineering can advance as a discipline, or it can't. You seem to be assuming it can't. > This comment sure indicates to me where you most likely are on the curve Never mind, you just sound like an asshole.

Jensson 5y ago
Math today does a lot of things you couldn't do with math back then. It isn't just syntactic sugar, there were simply lots of problems they didn't know how to solve since the math they had wasn't powerful enough to solve it. Calculus for example solved a lot of problems they have, and calculus isn't syntactic sugar for anything, it is a new instruction set. However the code abstractions people used 50 years ago could still implement all programs we have today. We added a lot of sugar on top, but the core of coding remained the same. For example, you could implement Map, Reduce etc in C, they are just functions and not novel features of programming.

CTmystery 5y ago

> After enough experience you realize that expressivity and convenience are antipatterns and don't actually simplify things but are harbingers of complexity, bugs, tech debt, even the downfall of organizations and products. Suggesting that experience leads to jettisoning expressivity is at odds with my direct observations of experienced software engineers working in large teams. The more experience, the _better_ the engineer gets at picking the right level of abstraction to write code that can be maintained by others. Picking a single point on the abstraction spectrum (just above goto but not below it!) is far too rigid for the diversity of tasks that software engineers need to solve.