Board index » delphi » Re: Holding a program in your head

Re: Holding a program in your head


2007-08-26 10:39:47 PM
delphi11
James Gibbons writes:
Quote
>Wayne Niddery [TeamB] writes:
>>An interesting article ...
>>www.paulgraham.com/head.html
And I forgot to state the most important thing. It isn't really the
ability to keep the program all in your head that leads to the solution.
The most important thing is a full understanding of your application
domain. It is only by fully understanding what the program is really
trying to accomplish that you can put the logic and code together to
make it happen.
For example, I work with robots and use neural networks to provide them
with learning abilities. It was only a deep understanding of numerical
analysis and statistics that allowed me to come up with certain ideas
that made it all work properly. The other programmers at our company
complain that they can not penetrate my code and understand it. This is
largely a matter of training, and training just in computer science
doesn't quite hack it. All programmers can help themselves by deep study
of other knowledge domains, especially the ones they plan to work in.
James
 
 

Re: Holding a program in your head

Hi James,
I probably wasn't talking about large business systems, a business
system can be decomposed into a number of steps - i.e. business
processes, flows - all the different bits business analysts use. To say
one or two programmers could write for instance an accounting system
like SAP would I agree be crazy, but of course they are decomposed into
modules and so on.
I was thinking of something like photoshop or word they consist of an
inner core of functionality and a lot of external stuff like file
formats, gui and so on. Perhaps the core engine if you will, the bit in
the middle that has a myriad of interdependencies that hang together to
create the final app. Can they be engineered to exceed what a few people
can keep in there head? The current state of the art is no I believe.
For instance something that is a word processor that can also be used to
do say genetic algorithms. If the complexity could be made manageable,
then this would be a nice thing, academics could write there document
about the GA and just below the explanation is the GA working for all to
see as part of the document, you could dive into the code and there is a
nice formatted explanation of how it works, maybe a couple of animations
describing how particular algorithms work. To do this at the moment
would be a major development project, and the core could only be done
with a few key players - the upper limit on complexity of any app is
what a few key players can keep in there head, much like a collabarative
novel. You could make a web site that would sort of document it, but
still wouldn't be the living app, such a thing isn't possible at the
moment, and really even if you through a large amount of dollars at it,
it still couldn't be guaranteed to succeed.
When I first started coding I did SqlForms (an Oracle product that ran
on dumb terminals) - we had a metric - a small form took a day, a medium
one 2 to 3 days a big one 5 to 10 days. These were serious business apps
with a complexity that was comparable to any app used today, it ran a
whole university, there was a team of about 8 developers. I doubt that
any of the current tools could exceed this productivity, and indeed from
my experience they take considerably longer, sure they look prettier but
when you get down to what they actually do in business terms there is
very little difference (This by the way is an old rant of mine).
Why? because the complexity of the underlying frameworks is dependant on
a few key developers, and as the systems have become more complex and
the interdependencies have grown changes in the system take longer and
cause more side effects that very few can understand. This is before you
even write an app! Where was I, oh yeh, so still the systems are limited
by what a skilled developer can do and keep in there head. Alan Kay
(inventor of smalltalk) has said similar things. The idea that an app
can comfortably divided up and a person can write each little part is a
furfy at multiple levels with the current state of the art, and
unfortunately seems to remain so. Not sure if I made my point, or even
had one but - end of rant :-)
No there's more, this all comes about because of the multiple layers and
multiple languages that you need to develop an app today, e.g. a web app
with javascript, HTML, and the backend with Perl/Java/.Net whatever, the
plethora of technologies and internal layers, any one of which can throw
a bug and bring your app down is truly amazing, and really don't do much
more in business terms than they did 25 years ago. I think I am finished.
Dave
 

Re: Holding a program in your head

David Ninnes writes:
<snip>
All good points Dave. Paint .NET is an example of a Photoshop like
application built by two programmers. Not really a threat to Photoshop
because it lacks many features, runs filters about 4 times slower than
native code and can not deal with very large files. But it does show that
a two man team can create a very impressive application.
Quote
No there's more, this all comes about because of the multiple layers and
multiple languages that you need to develop an app today, e.g. a web app
with javascript, HTML, and the backend with Perl/Java/.Net whatever, the
plethora of technologies and internal layers, any one of which can throw
a bug and bring your app down is truly amazing, and really don't do much
more in business terms than they did 25 years ago. I think I am finished.
That goes along with my point that you need a deep understanding of the
application domain. You need to be strong in all the layers to put it
all together. It also makes your application only as good as the weakest
link in the chain. Use a buggy technology layer and it doesn't matter
how good you or the other layers are, the end product still sucks like
the weak link. That is why too much reliance on component software can
be a bad thing. I see this all the time with robot and PLC interface
drivers. They all have serious bugs that you need to know about and work
around.
One can make the argument that if it isn't broken, don't fix it. We all
have our favorite old systems we would love to keep using. Look at all
the Delphi programmers that haven't gone beyond D4 or so. Many CPAs are
still using DOS software. Unfortunately, managers like snazzy GUI
interfaces. I know one large company where the decision to buy an
inventory system was made on the fact that the cursor would change into
a hatchet and chop away at records being deleted. Great way to make a
buying decision!
James
 

Re: Holding a program in your head

"Marc Rohloff [TeamB]"
Quote
I wish I could charge mine for all the time I spend 'thinking' about a
problem when I wake up at 3 in the morning with the answer.
I say charge ... like a wounded buffalo! :)
 

Re: Holding a program in your head

"Kristofer Skaug" writes:
Quote
"I.P. Nichols" wrote
>
>I can not speak for nails but as a hammer-head I really enjoy banging their
>heads. ;-)

Happy for you, but OTOH you hammer-people have a reputation
for a unhealthily narrow world view.

I mean, honestly, do I look like a nail to you?
Well no not al all but I also enjoy banging pin-heads. ;-)
 

Re: Holding a program in your head

Rudy Velthuis [TeamB] writes:
Quote
Kristofer Skaug writes:

>"Rudy Velthuis [TeamB]" wrote
>>That hits the nail on its head.
>I find myself occasionally wondering whether nails really do enjoy
>being hit on their head, or whether this oh-so-inviting hammerability
>(Joel Spolsky calls it a UI "affordance") is just a cruel human
>prank, just like sticking a note "kick me" on someone's butt...

I don't think nails have feelings. <g>
I can tell you've never hit a nail with a hammer... A fingernail, that
is... <G>
David Erbas-White
 

Re: Holding a program in your head

David Erbas-White writes:
Quote
Rudy Velthuis [TeamB] writes:
>Kristofer Skaug writes:
>
>>"Rudy Velthuis [TeamB]" wrote
>>>That hits the nail on its head.
>>I find myself occasionally wondering whether nails really do enjoy
>>being hit on their head, or whether this oh-so-inviting
>>hammerability (Joel Spolsky calls it a UI "affordance") is just a
>>cruel human prank, just like sticking a note "kick me" on
>>someone's butt...
>
>I don't think nails have feelings. <g>


I can tell you've never hit a nail with a hammer... A fingernail,
that is... <G>
I have, actually, but they are not the kind of nails you should hit
with a hammer. <g>
--
Rudy Velthuis [TeamB]
"Should array indices start at 0 or 1? My compromise of 0.5 was
rejected without, I thought, proper consideration."
-- Stan Kelly-Bootle
 

Re: Holding a program in your head

"I.P. Nichols" wrote
Quote

Well no not al all but I also enjoy banging pin-heads. ;-)
Enough headbanging already! :-)
--
Kristofer
 

Re: Holding a program in your head

Just as salient from Graham - something I have been ranting about for two
years: www.paulgraham.com/microsoft.html
What's funny is that MSFT consumed the "personal computer" market and built
its market around it, which is every user is an island. When the idea of the
"personal computer" was suggested, I am sure the gray-haired eggheads at IBM
snickered at this notion. The "personal computer" had to happen, and it
created an industry with a lot of bright engineers (and continues to do so),
but we've got to grow past this silly notion of computing. Those engineers
at IBM were completely right, but not until some specific technologies that
even they didn't understand fell into place.
MSFT's success depends on a curtain hiding the wizard, like that of big oil
companies.
James
 

Re: Holding a program in your head

James Gibbons writes:
Quote
David Ninnes writes:

Hi James,
Excuse the long rant (don't use newsgroups late at night), I think we're
probably saying the same thing.
Quote
One can make the argument that if it isn't broken, don't fix it. We all
I am starting to think that the multiple layers are broken. If you take
a step back and look at what you're trying to achieve with a web based
app would anyone design the current system of
browser/languages/middleware/server? The layers of complexity are
introducing costs that aren't necessary.
Quote
interfaces. I know one large company where the decision to buy an
inventory system was made on the fact that the cursor would change into
a hatchet and chop away at records being deleted. Great way to make a
buying decision!
lol, it is difficult. As IT guys, I feel the requirements of an IT
system and what the costs are really need to be explained better than
they are at the moment. This probably stems from education of new IT
folk, as a profession we need to explain what we do and how to do it a
lot better in much the same way as doctors, lawyers and other branches
of engineering do this. IT growth needs to be driven less from this is
cool, to what do you need as an engineered solution.
cheers,
Dave
 

Re: Holding a program in your head

David Erbas-White a écrit :
Quote
I've solved so many problems this way, that at this point, my main
client will send me to TAKE a shower when we have a particularly vexing
problem...
My present client, with whom I have done some of my best inventing, does
recognise that I sometimes need to take a walk, go out for a cup of
coffee, etc and has been happy for me so to do on his time. As a result,
he has seen solutions take shape that neither of us could have envisaged.
BTW, the other side of the consultant/client coid is that he (the
client) is an excellent arguer. If either of us have an idea, we know
that we have to be able to justify that idea in the face of what
sometimes seems fatuous arguing from the other.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: Holding a program in your head

Adrian Gallero pretended :
Quote
Peter Morris writes:

>"The price is that the resulting code is bloated with protocols and
>full of duplication."
>
>That's the result of {*word*99} coders, not OOP. OOP helps to eliminate
>code duplication.
>
>"So it is a good tool if you want to convince yourself, or someone
>else, that you are doing a lot of work."
>
>Procedural programming is fine for simple applications that are very
>small, but for large apps OOP saves a whole load of writing.
>

Just my opinion here, but I don't think he is speaking of "procedural
programming" the way c or pascal might be. If you read Paul Graham
essays, he is a big proponent of lisp (and I think he mentions it
everywhere he can)

So, he is not comparing c vs c++ (or pascal vs delphi), but lisp vs
c++/delphi. CLOS does have closures that can do many of the things an
object can do (this is mentioned in the article), and probably save a
whole load of writing too (along with other features present in lisp
but not in oo languages).

Thanks Adrian. I was ready to write him off
as loony. Your comments helped me see his
writing from a better perspective.
Thanks,
Brad.
 

Re: Holding a program in your head

Kristofer Skaug was thinking very hard :
Quote
"I.P. Nichols" wrote
>
>Well no not al all but I also enjoy banging pin-heads. ;-)

Enough headbanging already! :-)
def: Programming - an excercise similar to banging your
head against the wall, but with less opportunity for
reward.
HTH,
Brad.