"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I drafted a rather longer reply to this, but thought better of it. I'll
> say only this
> programming is *not* hard, but it cane be made hard.

As a professional SW developer, I can tell for sure that it depends a lot on the
size (and even more so complexity) of the project, and the operational
parameters to match (memory limits, performance requirements, stuff like that).

If your projects are the size and complexity of a typical POV-Ray scene with
some occasional loops, you're right: That's not hard at all.

If however your project is a POV-Ray animation employing some mechanics
simulation, and you don't have access to a mech sim framework developed by
someone else already, you *might* come to the conclusion that programming can
also be hard all by itself.

And if you were to develop software for a bluetooth handsfree unit to be
integrated into a car, or a modern computer game, you'll certainly find how
hard programming can be.


One problem with OOP support in many mainstream languages is probably this:
They're designed to manage complexity in medium-sized projects (for really
large projects, even those languages may not be good enough); if they do that
well, nobody will complain about the additional overhead they impose, because
it really pays off a lot. However, in very small projects this overhead becomes
more of a burden than a benefit, because the projects don't really have much
complexity in need of being managed.

Mind you, this overhead is imposed not by object-oriented programming as such,
but by the languages. The more formal it is, the more suited it is to manage
complexity. But, of course, that formalism makes it also less suited for
programs you could throw together in a few hours if it weren't for the
formalisms.

I do love Microsoft's C# programming language and IDE: It's really one of the
most powerful environments I have ever used for development, and it's really a
pleasure to use it. I can't think of anything better suited for projects the
size an experienced hobbyist programmer could ever hope to pull off alone.

However, when I develop, say, a small straightforward command line tool I expect
to throw together in a matter of two or three days, C/C++ is actually my
favorite weapon: I can start off with plain old-school C imperative programming
(interspersed with some C++ syntax that has nothing to to with OOP, like line
comments, references, bool data types and the like); if I then happen to
encounter some unexpected complexity, I can throw in a bit of C++ to define
some objects anytime, but keep the program C-style otherwise.

This is the kind of OOP support I'd expect for a POV-Ray SDL: As long as your
project is straightforward, it doesn't bother you with any formalism
whatsoever. But when the task at hand gets complex, that OOP support is right
there for you to use, with all the formalism you need.

Post a reply to this message

Stephen <mcavoysAT@aolDOTcom> wrote:
> >> I propose Ook!
> >
> >Stupid monkey.
> >
> >(*hands over banana*)
> >
> >
>
> Ooo! Big trouble when the librarian gets you :-)

Ook.

Post a reply to this message

On Sat, 25 Jul 2009 12:42:08 EDT, "clipka" <nomail@nomail> wrote:

>Stephen <mcavoysAT@aolDOTcom> wrote:
>> >> I propose Ook!
>> >
>> >Stupid monkey.
>> >
>> >(*hands over banana*)
>> >
>> >
>>
>> Ooo! Big trouble when the librarian gets you :-)
>
>Ook.
>
>
No use trying to soft soap now Oook!
    :)
-- 

Regards
     Stephen

Post a reply to this message

clipka wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
>> I drafted a rather longer reply to this, but thought better of it. I'll
>> say only this
>> programming is *not* hard, but it cane be made hard.
> 
> As a professional SW developer, I can tell for sure that it depends a lot on the
> size (and even more so complexity) of the project, and the operational
> parameters to match (memory limits, performance requirements, stuff like that).
> 
> If your projects are the size and complexity of a typical POV-Ray scene with
> some occasional loops, you're right: That's not hard at all.
> 
> If however your project is a POV-Ray animation employing some mechanics
> simulation, and you don't have access to a mech sim framework developed by
> someone else already, you *might* come to the conclusion that programming can
> also be hard all by itself.
> 
> And if you were to develop software for a bluetooth handsfree unit to be
> integrated into a car, or a modern computer game, you'll certainly find how
> hard programming can be.
> 
> 
> One problem with OOP support in many mainstream languages is probably this:
> They're designed to manage complexity in medium-sized projects (for really
> large projects, even those languages may not be good enough); if they do that
> well, nobody will complain about the additional overhead they impose, because
> it really pays off a lot. However, in very small projects this overhead becomes
> more of a burden than a benefit, because the projects don't really have much
> complexity in need of being managed.
> 
> Mind you, this overhead is imposed not by object-oriented programming as such,
> but by the languages. The more formal it is, the more suited it is to manage
> complexity. But, of course, that formalism makes it also less suited for
> programs you could throw together in a few hours if it weren't for the
> formalisms.
> 
> I do love Microsoft's C# programming language and IDE: It's really one of the
> most powerful environments I have ever used for development, and it's really a
> pleasure to use it. I can't think of anything better suited for projects the
> size an experienced hobbyist programmer could ever hope to pull off alone.
> 
> However, when I develop, say, a small straightforward command line tool I expect
> to throw together in a matter of two or three days, C/C++ is actually my
> favorite weapon: I can start off with plain old-school C imperative programming
> (interspersed with some C++ syntax that has nothing to to with OOP, like line
> comments, references, bool data types and the like); if I then happen to
> encounter some unexpected complexity, I can throw in a bit of C++ to define
> some objects anytime, but keep the program C-style otherwise.
> 
> This is the kind of OOP support I'd expect for a POV-Ray SDL: As long as your
> project is straightforward, it doesn't bother you with any formalism
> whatsoever. But when the task at hand gets complex, that OOP support is right
> there for you to use, with all the formalism you need.
> 
> 
Your points are well taken, I should have said programing is not 
*fundamentally* difficult.
A particular programming task may be difficult because it require a lot 
of time and effort, learning
the idiosyncrasies of all the systems involved and a lot of trial and 
error. A great deal of
experience programming may also be required. But fundamentally, 
programming is not difficult.
But it can be made so.

David

Post a reply to this message

David H. Burns wrote:
> Your points are well taken, I should have said programing is not 
> *fundamentally* difficult.
> A particular programming task may be difficult 

This, to me, sounds like saying "Chess isn't hard, only the opponents are!"

-- 
Chambers

Post a reply to this message

David H. Burns 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.

> programming is not difficult.

Then why do you have such a hard time understanding simple things like OO 
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

Chambers wrote:
> David H. Burns wrote:
>> Your points are well taken, I should have said programing is not 
>> *fundamentally* difficult.
>> A particular programming task may be difficult 
> 
> 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. But pursuing it anyway, the rules and moves of chess are 
relatively
simple. One can easily learn and use them, however the rules and moves 
*could* be made so
complex that it would be almost impossible to play even against an easy 
opponent.

David

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:
>> Your points are well taken, I should have said programing is not 
>> *fundamentally* difficult.
> 
> It is fundamentally difficult. 

I disagree strongly!
It's as fundamentally difficult as any
> applied mathematics. 
I disagree here too. I would say that programming is less difficult that 
much
of applied mathematics. And applied mathematics is in general not 
fundamentally difficult.
For sufficiently small problems, you may be able to
> do it in spite of it being fundamentally difficult.

This would seem to contradict the definition of fundamentally difficult.
> 
>> programming is not difficult.
> 
> Then why do you have such a hard time understanding simple things like 
> OO programs? :-)

They do not seem very simple to me, but a number of folk have said they 
are, so I may
have psyched myself into believing they are too hard and complex like 
many students
psyche themselves into believing that, say, chemistry is difficult and 
thus have a hard time with it.
Unfortunately they are encouraged (unconsciously or otherwise) by 
chemists themselves and
even by teachers. To my mind OOP with all its polysyllabic terminology 
is a fad and an obstructive
one -- but it may be that I am wrong and that my attitude has, so far, 
kept me from diving into OOP,
which in reality is relatively easy. :)

David


>

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:

>> programming is not difficult.
> 
> Then why do you have such a hard time understanding simple things like 
> OO programs? :-)
> 
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.

DHB :)

Post a reply to this message

David H. Burns wrote:
>> It is fundamentally difficult. 
> I disagree strongly!

How much do you know about it?

It's fundamentally difficult in that each line of a program does something 
new. If it wasn't new, it would already be finished and you'd just use it.

Building a 51-story office building is marginally harder than building a 
50-story office building.  Building a 51-million LOC program is not 2% 
harder than building a 50-million LOC program, because each of those new 
lines is something brand new, doing something never before done in that 
program, and needs to get plugged in. If it wasn't, it would still be a 
50-million LOC program with handfuls of calls to existing subroutines.

By the way, adding that appropriate handful of calls to existing subroutines 
is the area in which OOP powerful. If you don't understand the benefits of 
OOP, it's because you've never written a program difficult enough to need it.

>> It's as fundamentally difficult as any applied mathematics. 
> I disagree here too. I would say that programming is less difficult that 
> much
> of applied mathematics. 

*All* of programming *is* applied mathematics.

> And applied mathematics is in general not fundamentally difficult.

Sure. That's why they teach it in grade school.

>> Then why do you have such a hard time understanding simple things like 
>> OO programs? :-)
> 
> They do not seem very simple to me,

Yet, oddly enough, hundreds of thousands of professional programmers seem to 
manage it all the time, in spite of you claiming it's not particularly 
difficult.

> but it may be that I am wrong and that my attitude has, so far, 
> kept me from diving into OOP,
> which in reality is relatively easy. :)

Or, maybe, you're just not very good at programming, so anytime you look at 
something big enough to be difficult, you decide it's not really because 
it's difficult or you're incapable, but because everyone else in the whole 
world is lying to you for selfish ends?

-- 
   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