4 ms·

You seem to favor human brain cycles over CPU cycles. Conversely, time spent on memory management and pointer arithmetic is time that could’ve been used to add

You seem to favor human brain cycles over CPU cycles. Conversely, time spent on memory management and pointer arithmetic is time that could’ve been used to add value to the world.

jnsaff2 4y ago
Well for code that gets executed billions of times spending more human cycles seems a fair trade off. For boring old corner shop crud, maybe not.
- heresjohnny 4y ago
  Most code isn’t fire and forget though. Bugs occur, requirements change. The human cycles are a perpetual investment. And Python is simply very, very maintainable. I do agree that there is a point where the scale tips. I wonder where that is, and what kind of application we’re talking about then. Many applications are at their basic level old corner shop crud, really.
- Turing_Machine 4y ago
  > Well for code that gets executed billions of times spending more human cycles seems a fair trade off. Do you feel the same way about (e.g.) modern mechanized farming compared to classic farming that used human labor (generally unfree and unpaid labor, such as serfs or slaves)? "Efficiency" is not the only goal that matters.
  - jnsaff2 4y ago
    I don’t get your analogy. Comparing manual labor to industrialized farming is comparing (paper) accounting books to programming. Whether you add gps based differential seeding to just doing it by ‘feel’ but still with machines is the difference of programmer brain cycles. Efficiency is not all obviously and there are different efficiencies one can find relevant. Why is this controversial?
    - Turing_Machine 4y ago
      You're advocating for more programmer work and less machine work. The situations are exactly the same. Just because programming is "brain work" rather than "muscle work" doesn't somehow make it not work.
      - jnsaff2 4y ago
        You not saying you are not a troll does not make you any less of a troll.
        Turing_Machine 4y ago
        You suggesting that I am a "troll" does not exculpate you from answering the question. Your argument is that programmers should use less-convenient and more painful languages to save energy. The argument that agriculture should be performed by unpaid peasants or slaves is exactly the same. Edit: it doesn't actually matter if they are paid or not (although they generally weren't). The history of human progress is pretty much defined by using energy to replace human scutwork.
alar44 4y ago
You don't "manage memory" unless you're writing C, and if you think "pointer arithmetic" is hard, you're a beginner level programmer.
maxbond 4y ago
Not a true dichotomy though. I'm more productive in Rust then I am in Python, and I'm not currently spending time managing memory or doing pointer arithmetic (you can end up doing some of that where it's inescapable, eg cyclic data structures & embedded devices/interfaces that requires manipulating memory). Though YMMV as far as productivity goes. There are of course many languages that occupy a similar niche, this is just the one I happen to favor.

You seem to favor human brain cycles over CPU cycles. Conversely, time spent on memory management and pointer arithmetic is time that could’ve been used to add value to the world.

jnsaff2 4y ago

Well for code that gets executed billions of times spending more human cycles seems a fair trade off. For boring old corner shop crud, maybe not.

heresjohnny 4y ago
Most code isn’t fire and forget though. Bugs occur, requirements change. The human cycles are a perpetual investment. And Python is simply very, very maintainable. I do agree that there is a point where the scale tips. I wonder where that is, and what kind of application we’re talking about then. Many applications are at their basic level old corner shop crud, really.
Turing_Machine 4y ago
> Well for code that gets executed billions of times spending more human cycles seems a fair trade off. Do you feel the same way about (e.g.) modern mechanized farming compared to classic farming that used human labor (generally unfree and unpaid labor, such as serfs or slaves)? "Efficiency" is not the only goal that matters.
- jnsaff2 4y ago
  I don’t get your analogy. Comparing manual labor to industrialized farming is comparing (paper) accounting books to programming. Whether you add gps based differential seeding to just doing it by ‘feel’ but still with machines is the difference of programmer brain cycles. Efficiency is not all obviously and there are different efficiencies one can find relevant. Why is this controversial?
  - Turing_Machine 4y ago
    You're advocating for more programmer work and less machine work. The situations are exactly the same. Just because programming is "brain work" rather than "muscle work" doesn't somehow make it not work.
    - jnsaff2 4y ago
      You not saying you are not a troll does not make you any less of a troll.
      - Turing_Machine 4y ago
        You suggesting that I am a "troll" does not exculpate you from answering the question. Your argument is that programmers should use less-convenient and more painful languages to save energy. The argument that agriculture should be performed by unpaid peasants or slaves is exactly the same. Edit: it doesn't actually matter if they are paid or not (although they generally weren't). The history of human progress is pretty much defined by using energy to replace human scutwork.

alar44 4y ago

You don't "manage memory" unless you're writing C, and if you think "pointer arithmetic" is hard, you're a beginner level programmer.

maxbond 4y ago

Not a true dichotomy though. I'm more productive in Rust then I am in Python, and I'm not currently spending time managing memory or doing pointer arithmetic (you can end up doing some of that where it's inescapable, eg cyclic data structures & embedded devices/interfaces that requires manipulating memory). Though YMMV as far as productivity goes. There are of course many languages that occupy a similar niche, this is just the one I happen to favor.