| ggroups@bigfoot.com 2007-04-02, 8:04 am |
| On Apr 1, 11:28 pm, "topmind" <topm...@technologist.com> wrote:
> S Perryman wrote:
[ stuff snipped because it is only relevant to comp.object ]
TM> Programming is mostly about psychology, for good or bad. Multiple
TM> paradigms and techniques can deliver the "proper" answer because
they
TM> are all Turing Equivalent. Outside of execution speed, science
and
TM> math does not tell us very much about "what is better". I've yet
to
TM> see a good paper on the subject from ANYONE.
TM> ACM has purposely avoided such issues because they couldn't apply
real
TM> science to evaluate such claims. They slunk back to hardware and
TM> execution effeciency issues instead.
TM> Software engineering is more like
TM> how to organize your desk than it is about making a machine run
faster
TM> or having fewer parts. And people organize their desk to fit
their
TM> psychology, not tune an equation.
[color=darkred]
>No, most of it is not, especially outside of performance issues. It
>would be nice if it was that way because then we could use formal
>logic in these debates instead of fuzz-guns, but as it stands, it is a
> "soft science", much like psychology and journalism.
Then it should be easy for to provide an extensive list of all those
aspects of software engineering that are not applying a theory to
solve a
real problem.
[color=darkred]
> Good idea.
So here we are then.
But I have (some apology to comp.software-eng denizens :-( :-) ) .
[color=darkred]
[color=darkred]
[color=darkred]
>Unless you can show source code, a resume bragging contest will not
>get us anywhere because none of it can be verified by the reader. We
>are testing paradigms, not people anyhow. COBOL and Assembler systems
>are also successful some of the time, I would note. Thus, if an
>instance of success is proof, then we should go back to COBOL and
>assembler.
1. Why do you continually avoid telling Usenet about what types of
system
you have specifically worked on ??
You seem keen to demand something as non-trivial as source code, yet
so afraid to state something as simple as what you have actually
worked
on. Are the systems that you have worked so trivial from a s/w
engineering viewpoint that you fear being a laughing stock ??
[ stuff snipped because it is only relevant to comp.object ]
2. Feel free to show how known s/w engineering aspects such as
complexity
management, change management, product line architecture, scalability,
fault-tolerance and all the other things for which there is a
theoretical
basis, has not helped me build better systems for the large-scale
high-
performance telecoms systems that I have worked on.
TM> Software is in the Dark Ages as far as science, but it is not my
TM> fault. I am just the messenger.
[color=darkred]
>Thanks to Dr. Codd and RDBMS, not OOP.
Showing your utter ignorance about software engineering.
And you wonder why comp.object (for starters) treats you as an utter
joke.
[ stuff snipped because it is only relevant to comp.object ]
Regards,
Steven Perryman
|