Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Forth Methodology of Charles Moore (2001)

ultratechnology.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: The Forth Methodology of Charles Moore (2001)

#51

Post by runlaszlorun »

7thaccount wrote: post #33
coliveira wrote: post #22

The main weakness of Forth is that modern programming is basically connecting pieces of APIs from different systems. This is true at the OS level, and much more so at the distributed level (web). So you're stuck with languages that help with this type of interfacing, such as Python and Java, while languages that excel in expressibility and logical development like Forth provide little benefit to the type of programmi…

You hit the nail on the head. My ideal world would involve me having an extended period of time to research a problem and then artfully craft a perfect solution to a problem that is beautifully documented. The world I live in is mostly crappy software products involving an infinite mess of APIs glued together and poor understanding of the core problem which leads to a huge mess. It's worse for the organization too, b…

> The world I live in is mostly crappy software products involving an infinite mess of APIs glued together and poor understanding of the core problem which leads to a huge mess.

And now we get to add frequent supply chain attacks to the list.

I recently tried NextJS even though I consider myself an ardent framework minimalist. Create app (or whatever) proudly proclaimed it had installed 666 packages. I took that as a hint and bailed…

Re: The Forth Methodology of Charles Moore (2001)

#52

Post by smitty1e »

kragen wrote: post #49
smitty1e wrote: post #48

Earlier quoted context omitted.

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.

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 unpredic…

I'm looking for an 80/20 answer here.

The 20% long(er)-term plays are going to require wisdom to sniff out.

Re: The Forth Methodology of Charles Moore (2001)

#53

Post by 7thaccount »

runlaszlorun wrote: post #51
7thaccount wrote: post #33

Earlier quoted context omitted.

You hit the nail on the head. My ideal world would involve me having an extended period of time to research a problem and then artfully craft a perfect solution to a problem that is beautifully documented. The world I live in is mostly crappy software products involving an infinite mess of APIs glued together and poor understanding of the core problem which leads to a huge mess. It's worse for the organization too, b…

> The world I live in is mostly crappy software products involving an infinite mess of APIs glued together and poor understanding of the core problem which leads to a huge mess. And now we get to add frequent supply chain attacks to the list. I recently tried NextJS even though I consider myself an ardent framework minimalist. Create app (or whatever) proudly proclaimed it had installed 666 packages. I took that as a…

An infinite tower of abstractions lol.

Re: The Forth Methodology of Charles Moore (2001)

#54

Post by bitwize »

exe34 wrote: post #50
bitwize wrote: post #26

Earlier quoted context omitted.

The problem with business requirements is that there are no systems analysts anymore; that work has largely been given to programmers. A systems analyst could determine what information each part of the business needs and what information it can provide to whom. With that information in hand, designing an information system becomes a relatively straightforward process; programming it even more so. The way we do thing…

the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users, and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work.

> the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users

This is really only an issue if you appoint programmers to serve as systems analysts. Sadly, this is all too common among businesses today.

Remember, programmers are detailists who must speak the language of the computer, and do not see the big picture, only one small part of a much bigger puzzle. A good systems analyst is a generalist who understands the business and can empathize with the users. They have strong communication skills, and can take a big-picture perspective and articulate their perspective and solutions clearly to management. They most certainly would not dismiss user requests and complaints as "incoherent ramblings". Programming and systems analysis are separate professions that require vastly different personality types, with the consequence that programmers make very poor systems analysts.

Re: The Forth Methodology of Charles Moore (2001)

#55

Post by exe34 »

bitwize wrote: post #54
exe34 wrote: post #50

Earlier quoted context omitted.

the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users, and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work.

> the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users This is really only an issue if you appoint programmers to serve as systems analysts. Sadly, this is all too common among businesses today. Remember, programmers are detailists who must speak the language of the computer, and do not see the big picture, only one small part of a much bigger puzzle. A good syste…

> and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work.

There's a reason we don't have them anymore.

Re: The Forth Methodology of Charles Moore (2001)

#56

Post by kragen »

smitty1e wrote: post #52
kragen wrote: post #49

Earlier quoted context omitted.

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 unpredic…

I'm looking for an 80/20 answer here. The 20% long(er)-term plays are going to require wisdom to sniff out.

little is scarcer

Re: The Forth Methodology of Charles Moore (2001)

#58

Post by bitwize »

exe34 wrote: post #55
bitwize wrote: post #54

Earlier quoted context omitted.

> the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users This is really only an issue if you appoint programmers to serve as systems analysts. Sadly, this is all too common among businesses today. Remember, programmers are detailists who must speak the language of the computer, and do not see the big picture, only one small part of a much bigger puzzle. A good syste…

> and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work. There's a reason we don't have them anymore.

You're putting the cart before the horse.

Again, gathering requirements is a time-consuming and confusing process, making the software late and often wrong, because most companies assign programmers to the systems analysis process, not people skilled in actual systems analysis. A good systems analyst has the empathy and high-level insight it takes to understand the existing business systems and the true needs of the users, and design a new system to better meet those needs -- traits sorely lacking in programmers. Note that a business system is not the same as software. It incorporates all of the procedures, whether performed by humans or machine, necessary for business operations.

As a consequence, we tend to declare that nothing can be done about gathering requirements and implement "Agile" methodologies, which are nothing more than institutionalized guesswork: in the words of Milt Bryce, "do a superficial feasibility study, do some quick and dirty systems design, spend a lot of time in programming, install prematurely so you can irritate the users sooner, and then keep working on it till you get something accomplished." And the software is still late and wrong!

Post reply on HN