Re: sh-boom again

John Doty wrote:
Is this the correct comparison? A document only understandable by English
speakers would not be considered poorly written (even by English majors),
because you simply can't write documents that are equally easily readable
by English readers, Japanese readers and illiterates.

The difference is that programming languages are orders of magnitude
simpler and more regular than natural languages.

One reason. But the main reason why you can pick up new mainstream languages
quickly is because they are just new dialects of a previous popular
language. Look at how difficult people find to learn Forth, which is
extremely regular and simple, and yet so much different than all the C-like
languages that are popular today.

Do you know what "deterministic" means? Probably not: computer
scientists stole it from physics, but trivialized it to mean
"predictable".

I do know enough physics to know what it means there. However, in real
computer science, "non-deterministic" does not mean "unpredictable".
Actually, a non-deterministic finite state machine* is equally to a
deterministic finite state machine, and there exists a transformation to
get from one to the other. The definition of "deterministic" there is:
There's a unique transition from one state to the next, determined by the
inputs and the previous state of the FSM.

*) the rule for a non-deterministic FSM to accept a pattern is: there exists
a possible sequence of states to accept the pattern.

Does that imply that the application experts can't write readable
requirements documents? I suppose so. My experience is that application
experts can't write requirements, because they don't know the
requirements.

I'd guess they know *their* requirements. They don't know how to figure
out the flow down to *your* domain. If they knew how to do that, they
wouldn't need you, because that's often much harder than mere coding.

I've proposed them to write down *their* requirements. That is to write down
how the input -> output relation is supposed to be. They told me they
couldn't, but instead they wrote down their proposed solution, which,
according to them, would give them what they want, and has been used for 20
years. It didn't give them what they wanted, because they missed several
parts in the equation, and changed too many other things. E.g. they reduced
the input power by a factor of 10 to get rid of an expensive transformer,
and assumed that the SNR of the output would be irrelevant.

Well, I've been on the other side of this. It's not that theorems are
untrustworthy, it's that the *application* of theorems is often wrong.
If the proof starts from the postulate that noise is stationary and
Gaussian, one ought to be nervous about about applying it to real world
noises that are neither stationary nor Gaussian. Unfortunately, dogmatic
specialists don't like to question the postulates that are fundamental
to their specialty.

Well, their proof started with assuming that there's no noise at all, and
that you can simply find the minimum of the signal curve to get a good
value - and to have good resolution with this "find minimum" algorithm, you
need large oversampling. Fact was that the exact minimum was undedectable
due to unavoidable noise in the ADC, and would have been hard to detect
even without the absense of noise. I didn't get to know of this "proof"
until it broke, which was quite late in the development. I also talked to
one of their contractors who was telling them the same thing I told them
for the last 10 years, but talking to a wall.

Well, when I worked at MIT we had a very bright CS student, and he
proposed (as a thesis project) to clean up the optical instrument
control software we'd developed in LSE (including significant
contributions from "programming illiterates"). He started with an
*extensive* analysis phase, with our blessing, but he wouldn't take our
advice and actually go to the telescope and assist an observer to learn
to use the existing software in a real situation.

No, that's not what I mean when I say "analysis". Analysis means gathering
data about reality just as well as arming yourself with a theory. I know
lots of people who fear going into the lab, because their assumptions all
break down when looking at the reality.

If you were reviewing the requirements for a car would you notice that
"the steering wheel must be accessible from the driver's seat" was
missing?

Yes, because I know how to drive. But if I wouldn't know anything in that
direction, I would probably miss it.

You need to find better customers.

Good idea, but customers don't grow on trees. My impression is that they
grow in mud, like the Uruk-Hais from Tolkien ;-).

I once had a programmer who literally demanded that we program him: we
needed to write all of our requirements out in pseudocode to make him
happy. Shoot, if we had time to do that we wouldn't have hired a
programmer in the first place ;-). In some ways, pseudocode is harder to
write than real code: how do you prevent errors? It's hard to unit test
pseudocode...

Sounds like a code monkey. I never understood how you can delegate things
that way, because, as you say, it becomes harder with the additional
indirection.

The same guy refused to participate in the hardware design review ("not
my area of expertise"), and then later groused about how difficult the
hardware design made his job. But that's *typical* of specialists.

You need to find better programmers. Don't take those that grow from trees.

I don't have a solution for a blame-based culture except stay away. On
the other hand, I've seen the application-oriented development approach
work repeatedly. For example, most of the software for the HETE-2
satellite (including critical onboard systems) was written by the
physicists who use it. Profession software engineering support was
mostly review and test, not design or coding.

Teaching a physicist how to program is not that difficult.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
.

Relevant Pages

  • Re: compiler for Chinese development language
    ... This relates to the development of vernacular ... Indian vernacular display, OS and programming languages. ... Bangla and other vernaculars. ...
    (comp.compilers)
  • Re: Head-in-the-Sand Liberals (LA Times Columnist)
    ... You claimed to have known several computer languages, ... If you lie about knowing computer languages, ... of the programming loop for a functional ... You also don't know Java. ...
    (rec.org.mensa)
  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
  • Re: GoTo in Java
    ... Scripting languages are programming languages; ... override the method.via an interface, or write a new method in the wrapper. ...
    (comp.lang.cobol)
  • Re: LISPPA
    ... >> a match for such imperative languages as C, ... >comparing Lisp with languages like C, Pascal and Basic, ... I can accept that Lisp tries to compensate of the lack of compile-time ... If you have tools of visual programming, nice editor, advanced ...
    (comp.lang.lisp)
Loading