 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> Something that people don't tend to believe: programming is *hard*. It
> is *not* a simple matter to sit down with a sheet of requirements, and
> pound out the class (though having a properly written spec makes it
> easier). And, believe it or not, most programmers' jobs could *not* be
> done by a bunch of monkeys.
>
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.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <Ben### [at] gmail com_no_underscores> wrote:
> > I wonder if it would it be possible for POV to expose its core functions
> > in a standard way (eg in a dll for windows), and then you can access
> > them from any programming language you like.
>
> I propose Ook!
Stupid monkey.
(*hands over banana*)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 25 Jul 2009 10:48:03 EDT, "clipka" <nomail@nomail> wrote:
>Chambers <Ben### [at] gmailcom_no_underscores> wrote:
>> > I wonder if it would it be possible for POV to expose its core functions
>> > in a standard way (eg in a dll for windows), and then you can access
>> > them from any programming language you like.
>>
>> I propose Ook!
>
>Stupid monkey.
>
>(*hands over banana*)
>
>
Ooo! Big trouble when the librarian gets you :-)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
