3 ms·

you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your

by exe34 2y ago

you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your paycheck or give it to somebody else.

smitty1e 2y ago
That is: there are more dimensions to real-world solutions than purely technical.
- kragen 2y ago
  that's jeff's main point here
  - smitty1e 2y ago
    And yet we watch organizations overlook the fullness of the problem on essentially a daily basis.
    - exe34 2y ago
      muh shareholder value
      - smitty1e 2y ago
        Sure, but that is purely tactical, getting one to the next quarterly earnings statement. The strategic question is why going long (or, a better strategic/tactical balance) seems so impossible.
        kragen 2y ago
        it's easy to convince yourself you're playing the long game when you're just screwing up. even in retrospect, it can be hard to tell if you were making a reasonable bet that happened not to pay off, rather than just a dumb bet—or, if you won, to what extent you were making an unreasonable bet that happened to pay off, rather than a savvy one. multiply this by the inevitable fact that, acting in a complex and unpredictable world, everyone is mostly acting out of profound ignorance finally, aside from unpredictability, rapid innovation and capital growth implies a high discount rate: any new innovation must compete with the risk-free return on capital. if we assume 5% per year, we must discount a return 20 years in the future by 64% (≈1-1/e) under these circumstances, it's sensible to focus on short-term gains with a rapid feedback loop, rather than long-term gains which might turn out to be chimerical
        smitty1e 2y ago
        I'm looking for an 80/20 answer here. The 20% long(er)-term plays are going to require wisdom to sniff out.
        kragen 2y ago
        little is scarcer
        exe34 2y ago
        is this a dead drop?
        kragen 2y ago
        every open comment thread is, but this one is so far unused
        smitty1e 2y ago
        Fnord
        bagas31 2y ago
        [dead]
kragen 2y ago
in pre-c programming practice it was common to write programming language keywords and variables in all upper case, among other reasons because teletypes and computer character codes often omitted lower case. in prose this rather rebarbative convention serves to distinguish them from natural-language words, much as we often use typewriter typefaces today. it is not intended as shouting, which i think is your reading. the loop we write in c as do { x(); y(); } while (!z()); is written in forth as begin x y z until and that is what the all-caps untils in this text refer to: three nested loops the thesis of this document is that you get faster results by taking the time up front to think your problem through until you understand it, and throwing away your code and hardware designs is not something to be afraid of i'm not sure jeff and chuck's results at itv bore this out; hardware kept evolving out from under them too fast, other people's code became more useful (because of shitty hardware, because of the free software movement, because efficiency became less critical, and because of higher-level languages with better reusability), and they ran out of money but simplifying a problem is still immensely valuable when you can do it. the problem with programming continues to be overcomplicating things
astrobe_ 2y ago
If you read the bio of Charles Moore [1], you will see for yourself that he is well aware of business constrains. Among other things he co-funded Forth, Inc. (which is still alive, as you can see) and was a Forth freelancer. I grant you in advance the point that it was 30-50 years ago and that the situation can be different today. It is however still worth following this methodology when you can afford. There's often a life after deadlines. But that's actually not something specific to Forth. Every programmer does that to some degree. Sometimes it is included in big and small so-called "refactoring" steps. Moreover, one could say at first glance that the core of this methodology is the well known "if you spend more time on design you will spend less time on code". The other thing is that, indeed, in this context it is less of a problem to throw away what you've done because of step 1-2. The phrasing is a bit too abstract; Perhaps clearer is what he said in an earlier interview: "Don't anticipate, solve the problem you've got." [2]. This piece of advice is so beneficial that it is almost a motto for me. It is also harder to do that one may think, because it is so easy to FUD oneself with "what if" and "what about" and sometimes you have to fight against your own hubris too (e.g. "I'll build something powerful"). So it requires some training; after all these years programming in Forth I still catch myself anticipating (e.g. "I think it could be useful to have that"). [1] https://www.forth.com/resources/forth-programming-language https://www.forth.com/resources/forth-programming-language [2] https://www.ultratechnology.com/1xforth.htm https://www.ultratechnology.com/1xforth.htm : Don't leave openings in which you are going to insert code at some future date when the problem changes because inevitably the problem will change in a way that you didn't anticipate. Whatever the cost it's wasted. Don't anticipate, solve the problem you've got.
- zelphirkalt 2y ago
  And yet it is wise to write code in a way that will lend itself well to additions later on. It is bad advice to forgo thinking about making ones code flexible and extensible. To simply spit out some code and without further thought accept the first barely working version of it. This will lead to obstacles, that in businesses will be interpreted as cost of changing something in the future, wgich in turn will lead to decision of simply never making this or that improvement. You will not be given the chance to revise your design later, in many cases, so you better make it work well the first time. One might not be able to anticipate future requirements, but there are situations, in which the engineer, provided they even get the right idea, can make their code reusable with little to no additional time needed, simply, because they know they they are doing and have experience with the matter. The worst that can happen to a product is, when less experienced engineers think to do well in telling the engineer with the experience, that this can be done in the future, when actually that future never materializes. Whole new directions of products die, because of this. Code might become even more, because of not anticipating things, and having to build workarounds later, because one does not get time to refactor and has feature pressure from management. It can all be pretty shortsighted and can limit the output that skilled engineers can provide. Bad management is gonna manage badly.

by exe34 2y ago

you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your paycheck or give it to somebody else.

smitty1e 2y ago

That is: there are more dimensions to real-world solutions than purely technical.

kragen 2y ago
that's jeff's main point here
- smitty1e 2y ago
  And yet we watch organizations overlook the fullness of the problem on essentially a daily basis.
  - exe34 2y ago
    muh shareholder value
    - smitty1e 2y ago
      Sure, but that is purely tactical, getting one to the next quarterly earnings statement. The strategic question is why going long (or, a better strategic/tactical balance) seems so impossible.
      - kragen 2y ago
        it's easy to convince yourself you're playing the long game when you're just screwing up. even in retrospect, it can be hard to tell if you were making a reasonable bet that happened not to pay off, rather than just a dumb bet—or, if you won, to what extent you were making an unreasonable bet that happened to pay off, rather than a savvy one. multiply this by the inevitable fact that, acting in a complex and unpredictable world, everyone is mostly acting out of profound ignorance finally, aside from unpredictability, rapid innovation and capital growth implies a high discount rate: any new innovation must compete with the risk-free return on capital. if we assume 5% per year, we must discount a return 20 years in the future by 64% (≈1-1/e) under these circumstances, it's sensible to focus on short-term gains with a rapid feedback loop, rather than long-term gains which might turn out to be chimerical
        smitty1e 2y ago
        I'm looking for an 80/20 answer here. The 20% long(er)-term plays are going to require wisdom to sniff out.
        kragen 2y ago
        little is scarcer
        exe34 2y ago
        is this a dead drop?
        kragen 2y ago
        every open comment thread is, but this one is so far unused
        smitty1e 2y ago
        Fnord
      - bagas31 2y ago
        [dead]

kragen 2y ago

in pre-c programming practice it was common to write programming language keywords and variables in all upper case, among other reasons because teletypes and computer character codes often omitted lower case. in prose this rather rebarbative convention serves to distinguish them from natural-language words, much as we often use typewriter typefaces today. it is not intended as shouting, which i think is your reading. the loop we write in c as do { x(); y(); } while (!z()); is written in forth as begin x y z until and that is what the all-caps untils in this text refer to: three nested loops the thesis of this document is that you get faster results by taking the time up front to think your problem through until you understand it, and throwing away your code and hardware designs is not something to be afraid of i'm not sure jeff and chuck's results at itv bore this out; hardware kept evolving out from under them too fast, other people's code became more useful (because of shitty hardware, because of the free software movement, because efficiency became less critical, and because of higher-level languages with better reusability), and they ran out of money but simplifying a problem is still immensely valuable when you can do it. the problem with programming continues to be overcomplicating things

astrobe_ 2y ago

If you read the bio of Charles Moore [1], you will see for yourself that he is well aware of business constrains. Among other things he co-funded Forth, Inc. (which is still alive, as you can see) and was a Forth freelancer. I grant you in advance the point that it was 30-50 years ago and that the situation can be different today. It is however still worth following this methodology when you can afford. There's often a life after deadlines. But that's actually not something specific to Forth. Every programmer does that to some degree. Sometimes it is included in big and small so-called "refactoring" steps. Moreover, one could say at first glance that the core of this methodology is the well known "if you spend more time on design you will spend less time on code". The other thing is that, indeed, in this context it is less of a problem to throw away what you've done because of step 1-2. The phrasing is a bit too abstract; Perhaps clearer is what he said in an earlier interview: "Don't anticipate, solve the problem you've got." [2]. This piece of advice is so beneficial that it is almost a motto for me. It is also harder to do that one may think, because it is so easy to FUD oneself with "what if" and "what about" and sometimes you have to fight against your own hubris too (e.g. "I'll build something powerful"). So it requires some training; after all these years programming in Forth I still catch myself anticipating (e.g. "I think it could be useful to have that"). [1] https://www.forth.com/resources/forth-programming-language https://www.forth.com/resources/forth-programming-language [2] https://www.ultratechnology.com/1xforth.htm https://www.ultratechnology.com/1xforth.htm : Don't leave openings in which you are going to insert code at some future date when the problem changes because inevitably the problem will change in a way that you didn't anticipate. Whatever the cost it's wasted. Don't anticipate, solve the problem you've got.

zelphirkalt 2y ago
And yet it is wise to write code in a way that will lend itself well to additions later on. It is bad advice to forgo thinking about making ones code flexible and extensible. To simply spit out some code and without further thought accept the first barely working version of it. This will lead to obstacles, that in businesses will be interpreted as cost of changing something in the future, wgich in turn will lead to decision of simply never making this or that improvement. You will not be given the chance to revise your design later, in many cases, so you better make it work well the first time. One might not be able to anticipate future requirements, but there are situations, in which the engineer, provided they even get the right idea, can make their code reusable with little to no additional time needed, simply, because they know they they are doing and have experience with the matter. The worst that can happen to a product is, when less experienced engineers think to do well in telling the engineer with the experience, that this can be done in the future, when actually that future never materializes. Whole new directions of products die, because of this. Code might become even more, because of not anticipating things, and having to build workarounds later, because one does not get time to refactor and has feature pressure from management. It can all be pretty shortsighted and can limit the output that skilled engineers can provide. Bad management is gonna manage badly.