"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