clipka wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:

>>> Yes, being active in the development of POV-Ray 3.7 I *may* happen to personally
>>> get my hands dirty on the code of POV-Ray 4's SDL engine.
>> So it is so after all
>> :(

> 
> So it is *what* after all? Me single-handedly going to take over the world or
> what??

That's what it sounds like, the Pov-Ray world anyway. You've greatly 
increased my paranoia.
Any day now I expect the carpenter's union to redesign and rebuild my 
house not for
convenience or comfort but to teach me the current accepted practice in 
carpentry.
> 
> Mwahahaha - Yeeees - I've always wanted to do that...
> 
> Ah, BTW & FYI: Me being a contributing developer to POV-Ray doesn't mean that
> I'm member of the official dev team. I do contribute code now and then, but as
> for making decisions about which direction to go, the buck does *not* stop
> here.

Despite my concerns, I do appreciate all the work that the official and 
unofficial
of Pov-Ray have done over the year --excellent work for my part.

David :)

Post a reply to this message

Chambers wrote:

> For one, OOP more closely models how many people think of problems, 
> while functional programming more closely models how mathematicians 
> think of problems.  

??!! Though the second clause of this sentence seems true  to me, nothing
  that I have read or heard in a long time seems so obviously false! It 
makes
me wonder if I'm communicating with an entity of a different a species 
or even
a different genus! (Is there an exclamation or ??!! icon?)

David

Post a reply to this message

>> This is where I mutter something about functional programming being 
>> the future, and everybody agrees with me...
> 
> There is still some debate about that, of course :)

That was actually sarcasm. ;-)

> For one, OOP more closely models how many people think of problems, 
> while functional programming more closely models how mathematicians 
> think of problems.

Depends who you think you're aiming your programming language at.

> It is not yet clear which one is better for managing 
> large, complex programs in general.

People who use Haskell casually build interpretters, compilers, logic 
simulation systems, and other things usually thought of as "hard" in 
normal programming languages. Whether this is to do with Haskell or the 
sort of people who use Haskell remains to be seen of course... ;-)

> (especially since there are many 
> things a computer does that are still more closely aligned with 
> imperative programming.  These things are easier to wrap in OOP, which 
> has concepts for both data and actions).

One might ask when computers will start to be designed to operate in a 
more functional way...

Post a reply to this message

> That's what it sounds like, the Pov-Ray world anyway. You've greatly 
> increased my paranoia.
> Any day now I expect the carpenter's union to redesign and rebuild my 
> house not for
> convenience or comfort but to teach me the current accepted practice in 
> carpentry.

Even if POV4 does change to an OOP model that you don't like, a) that is not 
going to be released for decades, and b) you are free to still use the 
latest stable 3.x release.  I wouldn't worry about it.

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> Chambers wrote:

> > For one, OOP more closely models how many people think of problems, 
> > while functional programming more closely models how mathematicians 
> > think of problems.  

> ??!! Though the second clause of this sentence seems true  to me, nothing
>   that I have read or heard in a long time seems so obviously false!

  And exactly what is it that makes it false?

  Object-oriented programming closely matches the thought process of people.
OOP can be deconstructed into to most basic elements: Concepts and algorithms.

  People think about things conceptually. For example, you can have one pen,
one car, one dog, and so on.

  Moreover, people use hierarchies of concepts. Some concepts are more
abstract while other concepts are more concrete. For example, the concept
of "animal" is more abstract than the concept of "dog" or "cat", which are
more concrete. Moreover, there's a hierarchical relationship between these
concepts: A dog is an animal, and a cat is an animal (but a dog is not a cat).

  Concepts can have properties to them. For example a dog has color, weight,
gender, race, etc. These properties can be different for different dogs.
Likewise the concept of "book" can have many properties, including its title,
author, date of publication, cover picture, table of contents, and so on
(all of which in themselves are also concepts).

  The other basic element of OOP is algorithms. These can be thought in the
same way as food recipes. Food recipes use some concepts (ingredients, cooking
utensils, etc) and a list of instructions on how to prepare the meal.

  This is the way people think naturally, and object-oriented programming
simulates this kind of design: It defines concepts (which may be hierarchical)
and algorithms on what to do with those concepts.

  Now please explain to me exactly what here is "so obviously false"?

-- 
                                                          - Warp

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> It is not yet clear which one is better for managing 
> large, complex programs in general

  I have hard time believing that large programs written in a functional
language like Haskell don't use one of the basic features of OOP: Modularity.

  Modularity (and the abstraction related to it) is one of the most essential
properties of a large project, if you want it to be manageable.

  Functional programming sounds to me more like just a way of expressing
what you want to do (ie. algorithms), not how you should distribute your
code among modules. Modularity transcends things like imperative or
functional programming paradigms. You could say it's a metaparadigm used
in many if not most large projects, regardless of the language used.

-- 
                                                          - Warp

Post a reply to this message

On 07/23/09 08:07, David H. Burns wrote:
> ??!! Though the second clause of this sentence seems true to me, nothing
> that I have read or heard in a long time seems so obviously false! It makes

	Perhaps it's because you tried learning OOP from C++/Java?

	I'm sure you think in OOP all the time with POV-Ray. You create a 
sphere. It's an object with certain properties (texture, location, etc). 
Now let's say you want to rotate the sphere, does it hurt so much to do 
something like:

mysphere.rotate(45)

	Let's say you want to have lots of balls in your scene. You want some 
to be red, some blue, and some green. And some of _those_ you want to be 
translucent.

	So you create your "basic" ball as a sphere with little texture. You 
subclass it to create two kinds of balls: "solid" and "translucent". In 
terms of actual code, you just create a new object that is the subclass 
of your "basic", and you merely add to it the texture that makes it 
translucent.

	Then you can subclass each to get the red, blue and green balls.

-- 
No, Taco Bell is NOT the Mexican Phone Company!

Post a reply to this message

On 07/23/09 07:55, David H. Burns wrote:
> That's what it sounds like, the Pov-Ray world anyway. You've greatly
> increased my paranoia.
> Any day now I expect the carpenter's union to redesign and rebuild my
> house not for
> convenience or comfort but to teach me the current accepted practice in
> carpentry.

	Try lying in front of the house when the bulldozers come. And if you 
see someone coming along hugging a towel, become friends with him. 
Otherwise your life will be in danger.

	And not because of the bulldozers.

-- 
No, Taco Bell is NOT the Mexican Phone Company!

Post a reply to this message

Warp wrote:

>   This is the way people think naturally, and object-oriented programming
> simulates this kind of design: It defines concepts (which may be hierarchical)
> and algorithms on what to do with those concepts.
> 
>   Now please explain to me exactly what here is "so obviously false"?
> 

*I* don't think, naturally or otherwise, like any OOP programming I have 
seen!! You may be trying to
read your on programming philosophy onto the world, or we may be of 
different genera. :)

David

Post a reply to this message

Neeum Zawan wrote:

>     I'm sure you think in OOP all the time with POV-Ray. You create a 
> sphere. It's an object with certain properties (texture, location, etc). 
> Now let's say you want to rotate the sphere, does it hurt so much to do 
> something like:
> 
> mysphere.rotate(45)
> 

No! I think in terms of objects, not of OOP. The concept of an "object" 
as used
in Pov-Ray in a valuable tool for thinking and programming -and used 
well there.
What I have seen of OOP programming is something else. :)

David

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> *I* don't think, naturally or otherwise, like any OOP programming I have 
> seen!! You may be trying to
> read your on programming philosophy onto the world, or we may be of 
> different genera. :)

  You clearly don't understand what "object-oriented programming" means.
Then you come here to tell us that you don't want it, whatever it might be.

-- 
                                                          - Warp

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> What I have seen of OOP

  Clearly you haven't. You don't even understand what "object-oriented
programming" means.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Object-oriented programming closely matches the thought process of people.

I think it's more like how people categorize real-world stuff. Since a lot 
of programming is essentially simulating the real world, OO makes sense.

There's a bunch of things that go on in the real world that don't make sense 
to do with OO: expert systems, board game AIs, financial analysis, 
accounting, etc.

There's a bunch of things that make sense with OO: Windowing system, 
interactions between businesses and customers, etc.

To say "people think in OO" is to miss that in many situations people don't 
think in OO.

>   This is the way people think naturally,

I would say this is *A* way people think naturally.  Something as simple as 
a decision table or decision tree is another way people think naturally.

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

Invisible wrote:
> One assumes that if you don't need foo(), you wouldn't bother including 
> the header file. 

You may use printf() without using sprintf(), fprintf(), and vprintf(). But 
they're all in the same header file.

In any case, I'm telling you what's *correct*, regardless of whether you 
think it's good style. :-)

>> Sort of. That's called "linking." Then there's "loading", which is 
>> when you put it into memory and *again* adjust a bunch of addresses.
> 
> Right. So what you're saying is that there's actually a second linking 
> stage each time final executable is run?

No, there's loading. :-) If the software does both steps, then it's a 
"linking loader".

But yes, there can be multiple linking phases, especially with DLLs and such.

If you have code compiled to run at 0x100 and you copy it from disk to 
memory at 0x300, you need to add 0x200 to every address that points into the 
program. That's loading. Often not needed nowadays with CPUs that can handle 
code that uses only relative offsets.

> In summary... you can't call the OS from C. You can only write C wrapper 
> functions around the assembly code that calls the OS. (And the wrapper 
> then of course looks like a normal C function...)

Right. Generally speaking.

I've always wondered why people think C is good for writing kernel-level 
code, as the only facility in C that actually deals with the sorts of things 
you do in a kernel is "volatile".

>> It's an instruction that invokes an indirect branch.
> 
> I see. So that's the mechanism on the IA32 platform, is it? (I thought 
> only the BIOS uses this method...)

I believe so. I stopped paying attention around the 286 era.

> Interestingly enough, the Motorola 68000 does in fact have two modes of 
> operation: "user mode" and "supervisor mode". I have no idea what the 
> distinction is.

Some opcodes in user mode will cause a software interrupt instead of doing 
what they do in supervisor mode. For example, trying to turn off the 
interrupts will "trap" instead of turning off the interrupts. (Really? 
68000? Not 68020?)

> the MMU-enabled variant of the CPU could support memory protection if 
> you wanted.

Yes. There's actually two things you need for demand-paged VM. You need 
virtual addressing (which the 68010 supported, I think), and you need 
restartable instructions (which the 68020 supported). If you try to store 
four bytes, and the first two bytes get stored and the second two hit a page 
that has to be swapped in, you're kind of hosed if your processor doesn't 
deal with that properly. (Say, by checking before you store anything that 
all the pages are available, or "unwriting" the failed write, or something.)

> And finally, it's perfectly possible to make a multiuser OS without 
> memory protection. It just won't have any memory protection.

You can do the memory protection in software, tho. Not *too* uncommon.

-- 
   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:
> In fact, one of my biggest complaints with C# is the lack of class 
> prototypes.  I miss having a public interface which fits entirely on one 
> (maybe two) screen(s). 

That's an IDE issue, not a language issue. See, for example, Eiffel's IDEs.

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

Warp <war### [at] tagpovrayorg> wrote:
>   Object-oriented programming closely matches the thought process of people.
> OOP can be deconstructed into to most basic elements: Concepts and algorithms.
>
>   People think about things conceptually. For example, you can have one pen,
> one car, one dog, and so on.
>
>   Moreover, people use hierarchies of concepts. Some concepts are more
> abstract while other concepts are more concrete. For example, the concept
> of "animal" is more abstract than the concept of "dog" or "cat", which are
> more concrete. Moreover, there's a hierarchical relationship between these
> concepts: A dog is an animal, and a cat is an animal (but a dog is not a cat).

Ah, yes - here we enter the realm of blah that scared *me* away from OOP when I
first came into contact with it:

"WTF - what does *this* crap have to do with *programming*?!"

Honestly, even as a professional SW developer for over a decade now who
definitely prefers OO concepts, I think this is perfect BS.

Despite all claims, I'm convinced this has virtually *nothing* to do with how
normal people *really* think (at least when faced with the task of explaing to
some dumb box how it should *do* something), and has even less to do with OO
*programming*.


David, you hear me? *This* is *not* OOP. This is indeed BS originally from
people leaning on the shallow theoretical side, trying to sell "OO"-labelled
products (compilers, tools, training, consulting, whatever) to people who
haven't experienced the benefits of OOP in practice yet.


*True* OOP is primarily about encapsulation: You highly integrate data
structures and the algorithms operating on them into so-called "objects"; you
precisely define what operations there should be to manipulate the data (for
instance, on a data structure to be used as a stack, you'd primarily want a
"push" and a "pop" operation, plus maybe a few more), and you hide the data
structure from any other code (to the best extent possible with the chosen
language), to prevent the data from being manipulated in any different way.
This is a very powerful tool for keeping track of how and where the data
structures are actually manipulated, so you can more easily change the inner
workings of an object if needs be.

Second, OOP is about "polymorphism": You define operations that should be
possible on various different types of objects (for instance, you might define
a "compute bounding box" operation for all geometric primitives as well as CSG
aggregates) without necessarily doing the same way internally, so they can be
easily processed alongside each other by the same calling code for some purpose
(e.g. get the bounding boxes of all objects) despite any differences in how the
particular operation is actually performed for each type of object.

These, in my eyes, are the most important aspects of OOP. There are others, like
"inheritance" (you might implement part of a new object type by simply referring
to - aka "inheriting from" - a similar object's existing implementation where
applicable, allowing you to easily re-use the existing code) that are of
practical value, too, but I wouldn't rank them as important as encapsulation
and polymorphism.


Strangely enough, inheritence is what the typical blah seems to focus on; on the
other hand, maybe it just feels that way because it's the only thing *really*
unfamiliar to a programmer: Encapsulation, for instance, could be regarded as
modularization driven to the extreme; and as for polymorphism, most programmers
will at least know the underlying problem of how to manage a collection of
elements with different data types. But inheritance? There's really nothing
like this in the world of classical imperative programming, nor does there seem
to be any need for it. Indeed, it is a solution for a problem you won't even
encounter unless you have already entered the realm of OOP. So it's somewhat
ridiculous trying to *introduce* OOP with this.

(I must confess that without this discussion, I would probably try the same
approach to introduce OOP to someone - even though I should know better,
originally having been deterred by this myself; never gave much thought to it
though until now.)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I've always wondered why people think C is good for writing kernel-level 
> code, as the only facility in C that actually deals with the sorts of things 
> you do in a kernel is "volatile".

  Because C allows many types of low-level optimization that are very
difficult, if not even outright impossible, in higher-level languages.

  For example, you know how a C struct will map onto memory locations,
on every possible platform which your kernel can be compiled for. You know
exactly what assigning one struct instance to another entails as machine
code. If you need a pointer which should point to a raw memory address,
you can create one. You can be sure that something like garbage collection
will *not* suddenly and unexpectedly kick in during a highly-critical
operation. If needed, you can even write inline-asm for things which cannot
be done in C directly (eg. write or read from ports, issue some exotic CPU
commands such as disabling interrupts, etc).

  And of course C allows for programmatical optimizations which can often
be difficult in higher-level languages. Memory usage optimization would be
the main example. In something like a kernel you really don't want to waste
too much memory if you don't have to.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> That's an IDE issue, not a language issue. See, for example, Eiffel's IDEs.

  IMO a language shouldn't rely on IDE or text editor features in order to
be readable.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Because C allows many types of low-level optimization that are very
> difficult, if not even outright impossible, in higher-level languages.

>   For example, you know how a C struct will map onto memory locations,
> on every possible platform which your kernel can be compiled for.

Not in a portable way. You don't know what kinds of padding happen, or what 
order the integers are in.

> You know
> exactly what assigning one struct instance to another entails as machine
> code. 

That's true of lots of low-level languages too. FORTH and Ada both spring to 
mind, for example. Lots of languages of the same ilk have instructions for 
laying out structures at a per-byte level. (Erlang? Modula-whatever?)

 > If you need a pointer which should point to a raw memory address,
> you can create one. 

Not in C. Only in some language that looks like C but invoked undefined 
behavior.

> You can be sure that something like garbage collection
> will *not* suddenly and unexpectedly kick in during a highly-critical
> operation. 

True, but there are lots of languages I consider better than C (as in, more 
powerful) that don't have GC. Anything with managed memory is going to be a 
mess for writing kernel code in, I'll grant you. :-) At least for a general 
kernel where you can't control what else runs.

 > If needed, you can even write inline-asm for things which cannot
> be done in C directly (eg. write or read from ports, issue some exotic CPU
> commands such as disabling interrupts, etc).

But not in C. That's kind of my point. There's whole bunches of stuff that 
happen in kernels that C just doesn't define, just like this.

>   And of course C allows for programmatical optimizations which can often
> be difficult in higher-level languages. Memory usage optimization would be
> the main example. 

I'm not sure what that means. If I have an array of 12-bit values in C, 
that's a PITA to implement compared to a lot of other languages (including C++).

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

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> That's an IDE issue, not a language issue. See, for example, Eiffel's IDEs.
> 
>   IMO a language shouldn't rely on IDE or text editor features in order to
> be readable.

So you'd rather rely on the programmer doing a job the IDE ought to be 
automating, just to insist it's there?

We're discussing basically manually built .h files vs automatically built .h 
files, and you're suggesting that manually built .h files are better because 
the compiler can force someone to provide them, whereas with an IDE they 
might not have a nice summary?  I don't think you really mean that.

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

clipka <nomail@nomail> wrote:
> Ah, yes - here we enter the realm of blah that scared *me* away from OOP when I
> first came into contact with it:

> "WTF - what does *this* crap have to do with *programming*?!"

  It has to do with program design. The larger the program is, the more
important it is for it to have been designed properly. A large program
without proper design easily becomes unmaintainable and incomprehensible.

  One of the most basic methods for keeping a large program manageable is
to subdivide it into smaller parts, hierarchically. When you write something
inside the large program, you shouldn't have to be keeping in mind the
*entire* program in order to be able to write that small part. You should
be able to keep in mind only the *relevant* parts of the rest of the program
necessary to make that small part work.

  It's the same in almost everything that is big and complex, not just
programming. The CEO of a large company doesn't have to worry about what
every and each single one of the ten thousand employees is doing. That would
be impossible. He just can't be managing ten thousand things at once. It
becomes even more complicated when they have sub-contractors and other such
companies to deal with. Instead, there's a *hierarchy* of management in the
company: The CEO controls a dozen or so bosses, who control a dozen of
managers, who control individual employees, or however a big company is
subdivided.

  The functionality of a large program can be largely divided into a
hierarchy by distributing the code logically into functions. However,
functions are not enough when you need to handle enormous amounts of
different types of *data*. Data management has to also be divided into
logical parts, often hierarchically.

  The solution presented (although not originally invented) by object
orientedness to this problem is the concept of modules: Modules can have
both functionality and data, and they enclose both in a way that makes
managing the data easier in a large project. Modules can also form a
hierarchy (so modules can define sub-modules inside them, or own instances
of other modules, etc).

  Most concepts can be naturally expressed as modules. If you have, for
example, the concept of "string", you can write a module which represents
such a string, with all the necessary data and functionality related to
strings. When such a string module has been properly designed, it becomes
easier and more manageable to handle strings in the program. The rest of
the code doesn't have to worry about how strings are handled; they just
use the functionality provided by the module. This also makes it easier
to *change* the implementation of this string module without breaking
existing code.

> Despite all claims, I'm convinced this has virtually *nothing* to do with how
> normal people *really* think (at least when faced with the task of explaing to
> some dumb box how it should *do* something), and has even less to do with OO
> *programming*.

  Oh, it has a lot to do with how normal people think, and how other things
(such as big companies) are organized.

  When you go to a grocery store to buy food, you don't have to care how
the grocery store works internally. You just use its "interface" to buy the
food and that's it. The store takes care of its own inner functionality.
That's modularity and object-orientedness in action, in real-life.

> David, you hear me? *This* is *not* OOP. This is indeed BS originally from
> people leaning on the shallow theoretical side, trying to sell "OO"-labelled
> products (compilers, tools, training, consulting, whatever) to people who
> haven't experienced the benefits of OOP in practice yet.

  I'm sorry, but I think that the one writing bullshit is you.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Because C allows many types of low-level optimization that are very
> > difficult, if not even outright impossible, in higher-level languages.

> >   For example, you know how a C struct will map onto memory locations,
> > on every possible platform which your kernel can be compiled for.

> Not in a portable way. You don't know what kinds of padding happen, or what 
> order the integers are in.

  Yes, you do. Maybe you didn't understand the "on every possible platform
which your kernel can be compiled for" part?

  Ok, maybe I expressed myself poorly and it should have written "on every
possible platform your kernel has been ported to".

> > You know
> > exactly what assigning one struct instance to another entails as machine
> > code. 

> That's true of lots of low-level languages too. FORTH and Ada both spring to 
> mind, for example. Lots of languages of the same ilk have instructions for 
> laying out structures at a per-byte level. (Erlang? Modula-whatever?)

  The difference is probably that neither FORTH nor Ada have the same amount
of libraries, platform support or optimizing compilers, nor are they nearly
as popular.

>  > If you need a pointer which should point to a raw memory address,
> > you can create one. 

> Not in C. Only in some language that looks like C but invoked undefined 
> behavior.

  Of course in C. And "undefined behavior" can also mean "works as desired
in this platform". When you know what the compiler is doing, and you are
writing platform-specific code, C allows you to do a whole lot of things
you can't do with other languages.

  Most DOS demos written in C used raw pointers (eg. to the VGA memory
buffer). They worked just fine on that platform.

> >   And of course C allows for programmatical optimizations which can often
> > be difficult in higher-level languages. Memory usage optimization would be
> > the main example. 

> I'm not sure what that means. If I have an array of 12-bit values in C, 
> that's a PITA to implement compared to a lot of other languages (including C++).

  It means that many if not most of the "high-level" languages pay zero
attention to memory usage. They freely and carelessly allocate memory like
it was candy because, you know, all computers have gigazillions bytes of
RAM and any program written in that language will be run alone, so it
doesn't have to worry about other programs which might also want some of
the memory.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> That's an IDE issue, not a language issue. See, for example, Eiffel's IDEs.
> > 
> >   IMO a language shouldn't rely on IDE or text editor features in order to
> > be readable.

> So you'd rather rely on the programmer doing a job the IDE ought to be 
> automating, just to insist it's there?

  Yes, because IDEs are necessarily quite platform-specific.

> We're discussing basically manually built .h files vs automatically built .h 
> files, and you're suggesting that manually built .h files are better because 
> the compiler can force someone to provide them, whereas with an IDE they 
> might not have a nice summary?  I don't think you really mean that.

  You said "That's an IDE issue, not a language issue." I read that to mean
that a language (like C# in this case) doesn't need to be designed to be
readable because an IDE can be used to make it readable.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   When you go to a grocery store to buy food, you don't have to care how
> the grocery store works internally. You just use its "interface" to buy the
> food and that's it. The store takes care of its own inner functionality.

And remember that the store also has food ordering at the back end, 
accounting, paying employees, filing taxes, cleaning the floors, predicting 
how much food needs to be ordered, etc. *that* is where the modularity comes 
in, and the OO, even more than just "buying food". A program that only deals 
with one kind of interaction is like a database with only one primary key.

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

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> *I* don't think, naturally or otherwise, like any OOP programming I have 
>> seen!! You may be trying to
>> read your on programming philosophy onto the world, or we may be of 
>> different genera. :)
> 
>   You clearly don't understand what "object-oriented programming" means.
> Then you come here to tell us that you don't want it, whatever it might be.
> 
I have seen a number of object oriented programs. And I did not like 
what I say.
They are pretty nigh incomprehensible to me. I know they were produced 
(or claimed to
be produced) by object oriented programming. Now it's true that the 
process of programming
is different from the program produced, but the product that I see gives 
little indication that
  it was produced by thought processes like mine. I don't presume to say 
that you don't naturally
think like object oriented programming, but since I have more experience 
*my*mind than you,
I can assure you that I don't! I definitely would not like to see the 
Pov-Ray scripting language
turn into something like those examples of OOP I have seen.

BTW I forgot one other possibility: You might be a genus. I once worked 
with an old fellow who
was a near genus (at least) in programming. His mind seemed to work in a 
way in almost diametrically
opposed to mine. Any time we tried to work together, we started with an 
argument but ended
accomplishing our task. He' dead now; I wonder what he would have 
thought of OOP, it might
have been his native language. :)

David

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> >   You clearly don't understand what "object-oriented programming" means.
> > Then you come here to tell us that you don't want it, whatever it might be.
> > 
> I have seen a number of object oriented programs.

  Ironically, by saying that you are only *confirming* what I just wrote.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> What I have seen of OOP
> 
>   Clearly you haven't. You don't even understand what "object-oriented
> programming" means.
> 
OK so I don't. Tell me. :)

Post a reply to this message

Warp wrote:
>   Yes, you do. Maybe you didn't understand the "on every possible platform
> which your kernel can be compiled for" part?

I'm just saying that's not really well-defined in *C*. It's 
compiler-specific, not C as such.

>   The difference is probably that neither FORTH nor Ada have the same amount
> of libraries, platform support or optimizing compilers, nor are they nearly
> as popular.

True. And those things feed on each other.

>   Of course in C. And "undefined behavior" can also mean "works as desired
> in this platform".

That's what I'm distinguishing. That's why I say C, as such, isn't very good 
for that sort of thing. You can do it, but only because you look at what 
your particular compiler generated for some piece of otherwise undefined 
code, and say "yes, that's what I'd like."

> When you know what the compiler is doing, and you are
> writing platform-specific code, C allows you to do a whole lot of things
> you can't do with other languages.

I'd phrase that as "the compiler will generate code for programs without 
defined semantics that's often what you want."

>   Most DOS demos written in C used raw pointers (eg. to the VGA memory
> buffer). They worked just fine on that platform.

Maybe I'm more of a theoreticist, but "it works for me" isn't how I like to 
write kernels. ;-)

>   It means that many if not most of the "high-level" languages pay zero
> attention to memory usage.

I'm not saying every programming language is appropriate for writing 
kernels. I'm saying there are good high-level languages both more powerful 
and safer that are better than C, and I'm not sure why they're not more popular.

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

scott wrote:
>> That's what it sounds like, the Pov-Ray world anyway. You've greatly 
>> increased my paranoia.
>> Any day now I expect the carpenter's union to redesign and rebuild my 
>> house not for
>> convenience or comfort but to teach me the current accepted practice 
>> in carpentry.
> 
> Even if POV4 does change to an OOP model that you don't like, a) that is 
> not going to be released for decades, and b) you are free to still use 
> the latest stable 3.x release.  I wouldn't worry about it.
> 
> 
If that be the case, shall we postpone this discussion for
twenty years or so? :-) Did that produce a wink.

David

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   Of course in C. And "undefined behavior" can also mean "works as desired
> > in this platform".

> That's what I'm distinguishing. That's why I say C, as such, isn't very good 
> for that sort of thing. You can do it, but only because you look at what 
> your particular compiler generated for some piece of otherwise undefined 
> code, and say "yes, that's what I'd like."

  There aren't many programming languages out there which would allow the
same kind of "controlled compiler abuse" as C, which is precisely why it's
so popular to write kernels and device drivers.

  Of course not all kernels in existence have been written in C (or asm),
but right now I can't say what other languages have been used to write
kernels.

> >   Most DOS demos written in C used raw pointers (eg. to the VGA memory
> > buffer). They worked just fine on that platform.

> Maybe I'm more of a theoreticist, but "it works for me" isn't how I like to 
> write kernels. ;-)

  Sometimes you just have to. No programming language can account for every
single feature a kernel needs. Sometimes you just *must* bypass the standard
language and poke the hardware directly.

  The only other alternative would be to write the kernel in assembly, which
would be enormously less portable and less manageable than C.

-- 
                                                          - Warp

Post a reply to this message

Neeum Zawan wrote:

>     Try lying in front of the house when the bulldozers come. And if you 
> see someone coming along hugging a towel, become friends with him. 
> Otherwise your life will be in danger.
> 
>     And not because of the bulldozers.
> 
I'm not at all clear what this means. Submit to the destructors (or to 
your fate)?
Do you mean OOP is a bulldozing machine predestined to level all. That 
I'm an
obstructor of the progress man and should be removed? That my life is
in danger from irate OOP programmers? What did you mean?

David

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> Neeum Zawan wrote:

> >     Try lying in front of the house when the bulldozers come. And if you 
> > see someone coming along hugging a towel, become friends with him. 
> > Otherwise your life will be in danger.
> > 
> >     And not because of the bulldozers.
> > 
> I'm not at all clear what this means. Submit to the destructors (or to 
> your fate)?
> Do you mean OOP is a bulldozing machine predestined to level all. That 
> I'm an
> obstructor of the progress man and should be removed? That my life is
> in danger from irate OOP programmers? What did you mean?

  Can I ask you how old are you?

  You don't understand the concept of smileys, you don't understand the
concept of object-oriented programming, and you can't even get a hitchhiker's
reference.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   You said "That's an IDE issue, not a language issue." I read that to mean
> that a language (like C# in this case) doesn't need to be designed to be
> readable because an IDE can be used to make it readable.

No, that was specifically in response to "I like header files because it 
gives me a nice summary of the functionality of the code." I'd rather have 
the specification of the code there once, and to have tools to generate 
documentation from the code, rather than to have the compiler require me to 
write the same specification twice just so it knows there's documentation.

I dunno - on big projects, I usually wind up writing a program that reads my 
.C files and generates the .H files automatically anyway. But then, I'm the 
kind of programmer who documents code before writing it, which is apparently 
terribly rare.

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

Warp <war### [at] tagpovrayorg> wrote:
> > "WTF - what does *this* crap have to do with *programming*?!"
>
>   It has to do with program design. The larger the program is, the more
> important it is for it to have been designed properly. A large program
> without proper design easily becomes unmaintainable and incomprehensible.

You didn't get my point.

*Now* you're talking about something OOP- and programming-related:
Modularization. But what on earth does your previous post's talk of "concepts",
pens, cars, dogs and cats have to do with this?

Well, with some experience with OOP concepts, *I* do know how to map them to the
constructs prevalent in this type of blurb, but it's still blurb and not the
real thing.


>   One of the most basic methods for keeping a large program manageable is
> to subdivide it into smaller parts, hierarchically. When you write something
> inside the large program, you shouldn't have to be keeping in mind the
> *entire* program in order to be able to write that small part. You should
> be able to keep in mind only the *relevant* parts of the rest of the program
> necessary to make that small part work.

BTW, note how the blurb may help to confuse: You're now talking about modular
hierarchies (going back to cats, they're comprised of a body, a head, for legs
and a tail); in your previous post, you were talking about conceptual
hierarchies (cats and dogs both being animals).

You *need* the modular hierarchies for large projects; but the blurb focuses on
the conceptual hierarchies.

>   The solution presented (although not originally invented) by object
> orientedness to this problem is the concept of modules: Modules can have
> both functionality and data, and they enclose both in a way that makes
> managing the data easier in a large project. Modules can also form a
> hierarchy (so modules can define sub-modules inside them, or own instances
> of other modules, etc).

Note that encapsulation in OO goes a step beyond what would typically be
considered modularization: A module is typically thought of as a collection of
code, typically coming with various data structures and a bit of module-global
data as an aside, and a project would typically have one instance of each
module. In OO, the focus is more on the data and the interface, with the code
taking on the role of an aside, and the whole project would be dealing with
multiple instances at once.


> > Despite all claims, I'm convinced this has virtually *nothing* to do with how
> > normal people *really* think (at least when faced with the task of explaing to
> > some dumb box how it should *do* something), and has even less to do with OO
> > *programming*.
>
>   Oh, it has a lot to do with how normal people think, and how other things
> (such as big companies) are organized.

Read again: "(at least when faced with the task of explaing to some dumb box how
it should *do* something)"

And notice that I'm talking about the blurb here, the cats and dogs and pens BS,
*not* OOP. I *do* agree that OO is indeed a very natural way of thinking when
analyzing or planning complex systems. It also very closely resembles the
design of e.g. complex machines, btw. But the typical OOP introduction blurb
tends to be very far from that.

And yes, in a sense this may further some "elite" thinking: With OOP being
introduced this way, students may get the impression that it is something
totally different from older programming paradigms, when in reality it is just
adding a few not really complicated concepts.


>   I'm sorry, but I think that the one writing bullshit is you.

Well, sorry if I got you a bit upset - I didn't do full justice to your post, as
it's still rather on the humane side of blurb; but it's still blurp-ish enough,
and I know you have a tough skin.

Post a reply to this message

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>>>   You clearly don't understand what "object-oriented programming" means.
>>> Then you come here to tell us that you don't want it, whatever it might be.
>>>
>> I have seen a number of object oriented programs.
> 
>   Ironically, by saying that you are only *confirming* what I just wrote.
> 

OK I have seen OOP programs but I don't know what object orient 
programming mean.
Object Oriented Programming does produce Object Oriented Programs, but 
looking
at them doesn't tell me what Object Oriented Programming means. I'll 
accept that. Now, I ask again
tell me what Object Oriented Programming means.

David

Post a reply to this message

Warp wrote:
>   There aren't many programming languages out there which would allow the
> same kind of "controlled compiler abuse" as C, which is precisely why it's
> so popular to write kernels and device drivers.

True, but there are a number that do. :-)  Most people don't need controlled 
abuse.

> but right now I can't say what other languages have been used to write
> kernels.

Well, Ada is high on the list, as is FORTH. Algol was used for the B-series 
from Burroughs. That's why I mentioned them.

>   Sometimes you just have to. No programming language can account for every
> single feature a kernel needs. Sometimes you just *must* bypass the standard
> language and poke the hardware directly.

Sure. But, for example, take a look at the list of things that Ada defines 
how to do that C doesn't that would be useful for kernels:

Interrupt hooking, interrupt prioritization, interrupt disabling while 
running a higher-priority interrupt. Packed structures where you can define 
what and where every bit goes. Switching stacks (as in, context switching). 
Atomically writing to memory-mapped hardware. Test-and-set. Dynamically 
loading code and then executing it. Mapping data structures to particular 
addresses. Well-defined language structures for inline assembler. Plus 
everything C++ does (including interfacing to other calling conventions) 
except maybe turing complete templates. :-)

Oh, and I think it handles segmented memory, but I might be mistaken there.

Sure, if you need to invoke some magic opcode to blink the front panel 
lights, it's going to be really hard to make that portable. But you can do a 
lot better than C does.  Of course, Ada has another 25 years of experience 
on C, so it's not really a fair comparison.

I really think C got off the ground just by being used for the first 
portable kernel. The same as FORTRAN still being tops in numeric analysis 
because it had the first portable numeric analysis libraries.

>   The only other alternative would be to write the kernel in assembly, which
> would be enormously less portable and less manageable than C.

As I said, lots of kernels are written in FORTH (for small machines) or Ada 
(for dangerous machines).

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

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> Neeum Zawan wrote:
> 
>>>     Try lying in front of the house when the bulldozers come. And if you 
>>> see someone coming along hugging a towel, become friends with him. 
>>> Otherwise your life will be in danger.
>>>
>>>     And not because of the bulldozers.
>>>
>> I'm not at all clear what this means. Submit to the destructors (or to 
>> your fate)?
>> Do you mean OOP is a bulldozing machine predestined to level all. That 
>> I'm an
>> obstructor of the progress man and should be removed? That my life is
>> in danger from irate OOP programmers? What did you mean?
> 
>   Can I ask you how old are you?
> 
>   You don't understand the concept of smileys, you don't understand the
> concept of object-oriented programming, and you can't even get a hitchhiker's
> reference.
> 
True, I didn't recognize the reference to the Hitchhikers Guide and 
wouldn't have
for a million years without your hint.  I have read it, saw the PBS 
version and
had successfully forgotten them. And I didn't know how to make smileys, 
if that constitutes
not understanding the concept. And I don't know much about OOP 
programming, but
these exchanges have taught me a lot about OOP devotees.


I'm 63 over the hill and senile. Just an uncultured ignorant old retard 
who needs to get out
of the way and let you young folk take over.

Can I ask how old you are? :)

David

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Sure. But, for example, take a look at the list of things that Ada defines
> how to do that C doesn't that would be useful for kernels:
>
> Interrupt hooking, interrupt prioritization, interrupt disabling while
> running a higher-priority interrupt. Packed structures where you can define
> what and where every bit goes. Switching stacks (as in, context switching).
> Atomically writing to memory-mapped hardware. Test-and-set. Dynamically
> loading code and then executing it. Mapping data structures to particular
> addresses. Well-defined language structures for inline assembler. Plus
> everything C++ does (including interfacing to other calling conventions)
> except maybe turing complete templates. :-)

An interesting thought here:

How high is the influence of the most favorite programming languages on the
further development hardware design?

> As I said, lots of kernels are written in FORTH (for small machines) or Ada
> (for dangerous machines).

Maybe the latter is somewhat comforting. Not that the pure *existence* of
dangerous machines would be.

Post a reply to this message

scott wrote:

> 
> Even if POV4 does change to an OOP model that you don't like, a) that is 
> not going to be released for decades, and b) you are free to still use 
> the latest stable 3.x release.  I wouldn't worry about it.

Crap. I'm gonna be old by the time its released.


-- 
~Mike

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> Now, I ask again
> tell me what Object Oriented Programming means.

  I have already written extensively about it in several posts in this
thread.

-- 
                                                          - Warp

Post a reply to this message

clipka <nomail@nomail> wrote:
> *Now* you're talking about something OOP- and programming-related:
> Modularization. But what on earth does your previous post's talk of "concepts",
> pens, cars, dogs and cats have to do with this?

  In object-oriented programming a class is basically a user-defined type,
and a user-defined type is a concept. For example, "a string" is a concept,
and a string class is the implementation of that concept.

  A concept is basically something which behaves in a certain way. By writing
a class you are defining how it behaves.

  Inheritance is related to a hierarchy of concepts: More concrete concepts
inherit from more abstract concepts. For example, a file input stream may
inherit from a more generic input stream, both of which are concepts.

  The animal-dog example is not at all far-fetched. If you were to write
some kind of life simulation program with different plants and animals,
the classical inheritance hierarchy would, in fact, be basically perfect
for designing all the entities in that program.

> >   One of the most basic methods for keeping a large program manageable is
> > to subdivide it into smaller parts, hierarchically. When you write something
> > inside the large program, you shouldn't have to be keeping in mind the
> > *entire* program in order to be able to write that small part. You should
> > be able to keep in mind only the *relevant* parts of the rest of the program
> > necessary to make that small part work.

> BTW, note how the blurb may help to confuse: You're now talking about modular
> hierarchies (going back to cats, they're comprised of a body, a head, for legs
> and a tail); in your previous post, you were talking about conceptual
> hierarchies (cats and dogs both being animals).

  I don't see how those are mutually exclusive. A dog may be composed of
several parts, and a dog may be an animal, both at the same time. I really
don't see the problem.

  (In fact, inheritance and composition are two concepts of OOP.)

> You *need* the modular hierarchies for large projects; but the blurb focuses on
> the conceptual hierarchies.

  In many programs inheritance is best used to describe conceptual hierarchies.
It may not be about dogs and cats, but it may be eg. about file or socket
handles, strings, database entries, or basically anything. The mechanics
are still the same.

> >   The solution presented (although not originally invented) by object
> > orientedness to this problem is the concept of modules: Modules can have
> > both functionality and data, and they enclose both in a way that makes
> > managing the data easier in a large project. Modules can also form a
> > hierarchy (so modules can define sub-modules inside them, or own instances
> > of other modules, etc).

> Note that encapsulation in OO goes a step beyond what would typically be
> considered modularization: A module is typically thought of as a collection of
> code, typically coming with various data structures and a bit of module-global
> data as an aside, and a project would typically have one instance of each
> module. In OO, the focus is more on the data and the interface, with the code
> taking on the role of an aside, and the whole project would be dealing with
> multiple instances at once.

  Modular programming does know the concept of instantiating modules. For
example the modula programming language (which is not an OOP language) has
modules with public and private interfaces, and which can be instantiated
and referenced. (What makes it non-OOP is that it doesn't support inheritance
nor obviously dynamic binding.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> As I said, lots of kernels are written in FORTH (for small machines) or Ada 
> (for dangerous machines).

  I wonder why Ada never got much popularity, even though it was really
pushed at some point (especially by the US government, AFAIK). Was it
lack of compilers for common hardware or something?

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> How high is the influence of the most favorite programming languages on the
> further development hardware design?

Exactly. The Intel line of x86s was originally designed for Pascal. You can 
tell by looking at the four segments (which map exactly to Pascal data 
spaces) and the "ret n" instruction, even if there wasn't historical 
documentation backing it up.

> Maybe the latter is somewhat comforting. Not that the pure *existence* of
> dangerous machines would be.

I figure if you're writing any code that kills >100 people when it crashes, 
you probably shouldn't be writing it in a language that wasn't designed for 
that. :-)

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

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> As I said, lots of kernels are written in FORTH (for small machines) or Ada 
>> (for dangerous machines).
> 
>   I wonder why Ada never got much popularity, even though it was really
> pushed at some point (especially by the US government, AFAIK). Was it
> lack of compilers for common hardware or something?

Expense, I think. The GNU Ada compiler is currently the most featureful out 
there. But to call yourself Ada (at least for the first decade or so) you 
had to pay a fairly large sum to pass certification tests. You couldn't put 
something out there you'd thrown together, followed most but not all of the 
standard, and had compiler bugs you'd fix in the next release, and still 
market an Ada compiler.

Since things like compilers *are* things for which FOSS works great, that 
kind of put a big dent in Ada's adoption, I think. That and the FUD, of course.

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

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> Now, I ask again
>> tell me what Object Oriented Programming means.
> 
>   I have already written extensively about it in several posts in this
> thread.
> 

Sorry, I'm no wiser for reading them; But don't sweat it. :)

Post a reply to this message

On Thu, 23 Jul 2009 14:51:47 -0700, Darren New wrote:

> Expense, I think.

And performance, at least with the early compilers.  We had an IBM 
mainframe at my university that one student compiling Ada on would bring 
to its knees for hours.

Jim

Post a reply to this message

On 23-7-2009 2:58, David H. Burns wrote:
> andrel wrote:
>> On 22-7-2009 1:26, David H. Burns wrote:
>>> andrel wrote:
>>>
>>>> That you see your smiley does not mean everybody else will.
>>>
>>> Thanks. Did you see it? I did when I read my own post. I don't think 
>>> it shows up in the text in
>>> my "sent" file. These matters get complicated.
>>> :) (smiley ?)
>>>
>>
>> I do. In your post, not when replying :) , neither yours nor mine.
>> The point I tried to make earlier is that it depends on the mail 
>> reader of the person *reading*. You don't have an influence on it. You 
>> type a colon followed by a bracket, that is what you sent and what is 
>> supported by NNTP. After that somebody is trying to cleverly replace 
>> them by rotated smileys, which is OK as long as they get it right :/
>> IIRC they have problems with exotic ones like \o/ perhaps because they 
>> can conceivably be in a real post or in /ASCII art/.
>>
>> In short, there is a big chance that what you will see is not what I 
>> wrote. Perhaps it is what I intended.
> 
> Thanks, again, Andrel. The smileys work, :/ and \o/ came through as the 
> Ascii characters.

:/ might have been a smiley too, but isn't in TB. I remember having 
problems to understand the \o/ when I first met him, and am not 
surprised that TB doesn't replace it. I was expecting italics for /ASCII 
art/ but apparently that should have been /ASCII/ /art/. which is 
strange because *bold face* and _under line_ do range over the space.

> I'm using Thunderbird.

me too.

Post a reply to this message

On 07/23/09 11:15, David H. Burns wrote:
>> I'm sure you think in OOP all the time with POV-Ray. You create a
>> sphere. It's an object with certain properties (texture, location,
>> etc). Now let's say you want to rotate the sphere, does it hurt so
>> much to do something like:
>>
>> mysphere.rotate(45)
>>
>
> No! I think in terms of objects, not of OOP. The concept of an "object"
> as used
> in Pov-Ray in a valuable tool for thinking and programming -and used
> well there.
> What I have seen of OOP programming is something else. :)
>
> David
>

	OK. I have no idea what you're saying.

	What is the "No" referring to? Are you saying "no, it doesn't hurt"? 
Are you saying "No, I hate that way of doing it"? Are you sweeping your 
hand across my whole message and saying "No! I can't stand it!"?



-- 
Thesaurus: prehistoric reptile with a great vocabulary.

Post a reply to this message

On 07/23/09 13:12, David H. Burns wrote:
>> You clearly don't understand what "object-oriented programming" means.
>> Then you come here to tell us that you don't want it, whatever it
>> might be.
>>
> I have seen a number of object oriented programs. And I did not like
> what I say.
> They are pretty nigh incomprehensible to me. I know they were produced
> (or claimed to
> be produced) by object oriented programming. Now it's true that the

	OK. Now I'm _really_ confused!

	Was your initial concern that POV-Ray - the *software* - will be coded 
using OOP?

	Or was it that the language that *users* of POV-Ray will have to use to 
describe their scenes will be OO?

	If the former, then your fears are way, way, off, and I suspect along 
with the others, that you don't know what OOP is.

	Yes, POV-Ray 3.7, the *software* will be written in C++, and will very 
likely use OO principles. However, I believe that the actual scripts 
that you as a *user* will write, will stay almost the same.

	*That* should be of really no bother to you. You may not know this, but 
a _huge_ amount of the software that you use was actually written using 
OO principles, in an OO language. Almost all large projects that were 
coded in C++ use OOP (and again, I'm sure you use *many* programs coded 
in C++). Everything written in Java uses OOP. Lots of stuff written in 
Python use OOP.

	Now if your concern is the latter (that you as a *user* will have to 
describe your scene using OOP), then your concerns are not entirely 
unfounded, but they won't be relevant for a while. 3.7 will allow you to 
code as you have mostly done.

	Version 4.0, though, will quite possibly have a different scene 
description language and the syntax you will use to describe your scene 
will be quite different. It's very likely that this will be OO, but as 
I've said a bunch of times, if they make a good SDL, it'll be 
straightforward. It could even be done in a way that a new user will not 
have to know what OO is, and only intermediate or advanced users will 
deal with the details of OOP.


-- 
Thesaurus: prehistoric reptile with a great vocabulary.

Post a reply to this message

Darren New wrote:
> No, that was specifically in response to "I like header files because it 
> gives me a nice summary of the functionality of the code." I'd rather 
> have the specification of the code there once, and to have tools to 
> generate documentation from the code, rather than to have the compiler 
> require me to write the same specification twice just so it knows 
> there's documentation.

Point taken.  I got in the bad habit of using my headers as my 
documentation, and coding my implementations to match them, rather than 
keeping the documentation separate :)

Of course, being Visual Studio, the Class explorer offers similar 
functionality, but it's not in the same form I'm used to from looking at 
header files.  Ah, well, I'll adjust eventually.

> I dunno - on big projects, I usually wind up writing a program that 
> reads my .C files and generates the .H files automatically anyway. But 
> then, I'm the kind of programmer who documents code before writing it, 
> which is apparently terribly rare.

Yes, it is rare.  But good, so keep it up :)

-- 
Chambers

Post a reply to this message