 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> P.S. It may well be that programming itself is easier than understanding
> a written program.
Funny enough, lumps of glass and metal can understand a written program, but
we've not been able to get any silicon chips to actually be able to write
significant programs.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> David H. Burns wrote:
>>> It is fundamentally difficult.
>> I disagree strongly!
>
> How much do you know about it?
>
I have programmed a lot, albeit all small stuff. More complex programs
are of course more difficult
and OOP may be justified if it makes that more easily. Programming
should not be restricted
to "professional programmers" anymore than writing a paragraph should be
restricted to
professional writers!
>
>> And applied mathematics is in general not fundamentally difficult.
>
> Sure. That's why they teach it in grade school.
Now you're just being silly! In fact they *do* teach it in grade school.
Two apples plus
three apples equals five apples.
I think I'm going to cut out. This thread has become to personal.
It was fun though. Thanks to all who participated! :)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> David H. Burns wrote:
>> P.S. It may well be that programming itself is easier than
>> understanding a written program.
>
> Funny enough, lumps of glass and metal can understand a written program,
> but we've not been able to get any silicon chips to actually be able to
> write significant programs.
>
I don't see how this comment applies, but at this point, it doesn't matter.
I'm sorry if I hurt some feelings. :)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> > Your points are well taken, I should have said programing is not
> > *fundamentally* difficult.
>
> It is fundamentally difficult. It's as fundamentally difficult as any
> applied mathematics. For sufficiently small problems, you may be able to do
> it in spite of it being fundamentally difficult.
Ah - here come people who have a precise *definition* of words like
"fundamentally" and "difficult" :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > This, to me, sounds like saying "Chess isn't hard, only the opponents are!"
> >
> This is a poor analogy. In chess the major difficulty is the opponent,
> but there is no opponent in programming.
Well, the task to solve with the program is, sort of. And in practice it *is* by
far the major difficulty.
Possibly not though if you're programming only as a small hobby.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> P.S. It may well be that programming itself is easier than understanding
> a written program.
> I'm certain that is sometimes (maybe often) true of C programs.
It is for certain with programs written in a language you as the reader are not
familiar with.
And yes, programmers tend not to put much effort into making their programs
readable, so it often is the case, too, with programs written in a language you
do know quite well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Ah - here come people who have a precise *definition* of words like
> "fundamentally" and "difficult" :P
http://en.wikipedia.org/wiki/No_Silver_Bullet
http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf
"""
The essence of a software entity is a construct of interlocking concepts:
data sets, relationships among data items, algorithms, and invocations of
functions. This essence is abstract in that such a conceptual construct is
the same under many different representations. It is nonetheless highly
precise and richly detailed.
I believe the hard part of building software to be the specification,
design, and testing of this conceptual construct, not the labor of
representing it and testing the fidelity of the representation. We still
make syntax errors, to be sure; but they are fuzz compared with the
conceptual errors in most systems.
"""
"Fundamental" means basic or essential.
"Difficult" means requiring great physical or mental effort to accomplish or
comprehend.
So, yeah. If you actually study this stuff, you realize why programming
(amongst many other fields of endeavor) is fundamentally difficult.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> Programming
> should not be restricted
> to "professional programmers" anymore than writing a paragraph should be
> restricted to
> professional writers!
Who said it should?
> Now you're just being silly! In fact they *do* teach it in grade school.
Math is hard! Let's go shopping! </barbie>
> I think I'm going to cut out. This thread has become to personal.
It just seems to me that someone who has never designed or written a large
program telling me that "hey, your profession is not really hard, you're
just hallucinating" is rather insulting.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I have programmed a lot, albeit all small stuff. More complex programs
> are of course more difficult
> and OOP may be justified if it makes that more easily. Programming
> should not be restricted
> to "professional programmers" anymore than writing a paragraph should be
> restricted to
> professional writers!
And guess what - it isn't.
Grab any language you like, get a compiler (or interpreter) and go ahead.
"But," you'll say, "all out there these days has been invaded by OOP and is of
no use for me!"
Here's good news for you: You're wrong.
Fact is that yes, today's mainstream languages virtually *all* come with OOP
support, so they can be applied to large and complex projects.
Fact is also, however, that older languages have not ceased to exist, and there
are even modern compilers and interpreters being developed for them. Some have
introduced dialects with OOP support, but without breaking compatibility.
You love Pascal, but Borland has discontinued its Turbo-Pascal IDE/compiler
series some decade ago, and the old versions can only produce obsolete 16-bit
code? Then maybe you want to have a look at Free Pascal, which even comes with
a clone of the good old Turbo-Pascal IDE. Or just have a look at
http://en.wikipedia.org/wiki/Pascal_(programming_language) to see what else is
currently cooking with that language.
Your favorite language is some other? Just have a look at Wikipedia whether
there's modern compilers or IDEs out there.
Just don't expect professional SW developers from stalling the technological
advancement of *their* weapons of choice just because you don't grok them. That
would be like trying to stop the advent of fountain pens because you as a
hobbyist writer would prefer to stick with the good old dip pen.
Guess what: You can still get dip pens *today* if you really want one. Despite
other "hypes" like ballpoint pens, mechanical typewriters, electrical
typewriters, and nowadays personal computers, first with typewheel printers or
needle dot matrix printers, later with inkjet or laser printers... but well,
who needs them? They have killed the art of writing with dip pens, haven't
they?
The only things from this list that seem to actually have died out are
mechanical typewriters (where electric ones won't do, too often weight or
maintenance is likely to be an issue as well, making pens or pencils the weapon
of choice) and typewheel printers (having been out-evolved by inkjet and laser
printers in terms of quality, and unable to compete with impact dot matrix
printers for carbon copy applications).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
>>> This, to me, sounds like saying "Chess isn't hard, only the opponents are!"
>>>
>> This is a poor analogy. In chess the major difficulty is the opponent,
>> but there is no opponent in programming.
>
> Well, the task to solve with the program is, sort of. And in practice it *is* by
> far the major difficulty.
>
> Possibly not though if you're programming only as a small hobby.
>
>
I'm not sure exactly what you mean. If you mean "The task to accomplish
with the
program is the major difficulty in practice.", I agree and that would be
true for
projects large or small, professional or hobby. The difficulty of a
programming task
is determined by the nature of the task not the difficulty of
programming per se. But
even an easy programming task can be made difficult by programming tools
that are
difficult to use.
As I said in another post, I'm about ready to cut out of this thread. I
don't want to quit
without reiterating what a wonder program Pov-Ray is. My hat's off to
anybody and everybody
who contributed to making it what it is. I couldn't have done a tiny
fraction of it -- to tell the truth,
I never would have conceived of it or thought it could be done if I had!
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
