Re: OOF & menu driven coding ?

AliBama@gmail wrote:

When you take a meat-pie from the fridge and pop
it in the microwave-oven, you are 'compliing the
source from: digging the coal > transporting to
the power station > generaing electricity > ..etc.

Of course you could just rub 2 sticks together
to make fire to get the heat. That would be
just one stage of 'translation': like forth ?

.....

IMO this 'skipping the compiler, which can
match a natural human-representation with the
machine representation', and doing the
'translation' at the VM level, like forth,
is absurdly non-productive.

You have presented a sort of philisophical opinion, and I want to
respond similarly. Of course opinions differ, I want to point out ahead
of time that while we don't completely agree we could both be
objectively correct in slightly different contexts. And maybe some of
our opinions are neither correct nor incorrect but just aesthetic
judgements.

First off, if you have everything already set up just so, you've done it
before and you know just how, then it's very easy to take a meat pie
from the refrigerator and heat it in the microwave. The problems come
when things get less routine. If the directions on the package say to
run your microwave at 40% power, do you know how? Is it easy to play
with it and find out? What about defrost setting? I know how to do both
of those because I carefully read the directions, but I haven't done
either enough to be real confident. My defrost setting allows four
different things to defrost -- ground meat, steaks and chops, boneless
poultry, and bone-in poultry, and it demands I estimate the weight which
must be less than a pound and the method to enter the weight is not
intuitive. When I try to defrost something following the directions the
result is not what I expect, but I can eventually get things defrosted
with it. "Not routine" can be a problem.

Second, what happens if your electricity goes off? Then your microwave
doesn't work and your refrigerator starts thawing. To make that system
reliable you need a backup generator, and you need to take it out and
test it regularly to make sure it actually works. Backup systems that
don't get tested are a problem because in an emergency when you need
them is not the best time to test them and fix them. "Reliability" can
be a problem.

Third, what if you're building something new? If you have to wire your
kitchen before you can plug in your microwave, that's a problem. Worse
if you have to wire the whole house. Problem: "Connecting to the big
system."

Fourth, tied in with the reliability issue, once you depend on the whole
system with digging coal and making electricity and all, you depend on
the whole system to work. If the coal miners go on strike, or the power
plant workers, or if for any reason the system fails, you tend to go
down with it. Human systems benefit from redundancy. If one power plant
fails all the other power plants carry the load. If one railroad bridge
fails you reroute the traffic over the other bridges. Etc. But that
takes a lot of judgement. When systems run by default, redundancy is as
likely to cause problems as prevent them. One component may fail in a
way that allows another to do the work, or it may fail in a way that
prevents others from doing their own work. "Failsafe systems fail, by
failing to fail-safe." John Gall. Problem: "Complexity".

I think that things like object systems can be a big help if they're
done very well. Ideally it should be obvious where the boundary line is
between routine use that you know instinctively how to do, and
nonroutine use that might have some problems. Ideally all the little
inconsistencies will be removed. When you do something new you estimate
how big it will be and get a sense whether it's worth hooking it up to
an object system. Too small and it's easier to just do it. Big enough
and yet simple enough, and it's less work to build the objects and use
them.

Poorly done object systems have hidden complexity. When something goes
wrong the right thing to do is delve into that complexity and find out
what's wrong, and then fix it and make the whole thing simpler and more
intuitive -- so it's harder for that kind of problem to happen again.

But particularly when there are time pressures the natural approach is
to try out variations and find one that works, without quite
understanding what the problem was in the first place. Chances are when
you do that, it will work -- most of the time. And somebody else who
depends on your work will find his stuff also works most of the time,
but he can't fix it. He has to deal with both the problem you worked
around, and your code too. And if he plays with it to get something that
works....

When everything is simple and obvious, that isn't such a problem. The
other day I wrote a line of code to put into a post on clf, and I wasn't
sure which way the < should go. Instead of thinking it out, I just
tested it and switched it when it turned out I had it backward. It was
easier than thinking. But when you try that approach where there's
hidden complexity it's likely to bite you.

I read that when OO was first invented, the theory was that you'd get
brilliant software designers creating objects that were easy to use, and
then lots of average programmers could use them easily without ever
changing them. I think that might work well. It means when you design an
object you ought to spend about 20 times as much effort as usual
checking whether anything could go wrong with it, and whether it fits
the conceptual model for all the other objects it's likely to be used
with. Get a lot of beta testing done. And when you're sure it's perfect,
then release it for lots of other people to use, because this sort of
effort is probably not worth doing for just you. When multiple people
add objects to the same software project that might be a danger signal.
When new objects are added too fast that's a danger signal, they
probably haven't been tested enough, mulled over enough, beta-tested
enough, and their interactions with other objects (and the conceptual
interactions, how the habits you develop with one object affect how you
expect the other to behave) haven't been explored enough.

I can imagine that a good object system can be a tremendous help. And
also I can imagine that maybe most of the people who don't like objects
have suffered with a bad object system. The idea has tremendous
potential, but every time somebody muffs it that potential looks more
remote.

And that applies to Forth too. Forth promises that you can keep things
simple, keep the interactions small and predictable, make it so the
errors don't happen much and are easy to track down when they do happen.
When it works it works very well. But every time somebody fails to live
up to that potential, when we make things that are unnecessarily
complicated anyway, when errors hide in that complexity that are only
found later, we give other people the idea that Forth is not that good
after all.

Eg. for OOF, why do the acrobatics in forth
and have the resultant runtime work, when
one could just eg. have a menu-tree to pick
off the 'constructs' and fill in the args,
and have machine code generated,
ready to run the job and not translate the
forth source.

The source would be edited as [mostly?all]
predetermined constructs,
a bit like working with a spread ***,
or 'filling forms'.

You can't get away from thinking. You have to make the decisions about
what you want and some about how to get it. It's better when you don't
have a lot of boilerplate standardised stuff you have to copy out by
rote or copy-paste, the time you spend on that is time you aren't
actually noticing the real problem and choosing.

So if you're talking about choices that OOF forces you to do repeatedly
that are actually routine and always done the same, by all means
automate them away. And if you have a way to present the choices that is
easier to keep track of and reduces the typing, that's good too. Focus
on the choices that have to be made and ignore the boilerplate. But if
important choices get hidden in the boilerplate that's bad.

IMO this 'skipping the compiler, which can
match a natural human-representation with the
machine representation', and doing the
'translation' at the VM level, like forth,
is absurdly non-productive.

OOP is good when it's done exceptionally well and bad when it's done
without enough thought. Kind of like Forth. If somebody codes quickly
and makes a bunch of conceptual mistakes, how productive is that? If you
can provide them with tools that let them make mistakes faster, does
that make them more productive? Forth is a great tool for people who use
it well. It lets them put things together simply and transparently. I
have the idea OO is like that except it's designed to be terser and less
transparent. So you can think at a high level of abstraction and it's
quicker and easier, provided nothing goes wrong. The better you do at
making sure the abstractions always work as expected, the better it is.
.

Loading