 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> 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 :)
That's a perfectly reasonable way to do it in a language that requires
headers to start with. A language with javadoc-like features? Nah.
The cool thing about Eiffel is you can not only produce a document that's
the equivalent of a .H or javadoc (doxygen, etc) file, but also a "flat"
version that includes all the documentation from the parent classes that you
didn't override. So if you want the docs for "hashtable implemented using
arrays of streams" documentation, you don't need to grope through three or
more superclasses just to understand what that one class does.
> 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.
Yep. And Smalltalk is even more different, since you can open browsers on
things like "all classes that implement a method called X". Smalltalk being
one of those "duck-typing" languages.
Speaking of which, what is "duck typing" that isn't just "dynamic typing"?
WTF does that even mean?
> Yes, it is rare. But good, so keep it up :)
I remember once way back, having written docs for the library, I was sitting
there coding it up. (The project was a rewrite from BASIC to C, so I had a
real good idea what the library needed to do.) I had a stack of
documentation, and I was implementing each function. The "best" programmer
in the company comes up and asks what I'm doing, and I tell him. He points
to the inch-thick print-out, asks what it is, and I tell him it's the docs.
He says, sounding baffled, "How can you write the docs before the program?"
I ask him "How can you know when you're done programming without writing the
docs first?"
Ah, fun times. The first time I ever completely stopped taking a job seriously.
--
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 wrote:
> Chambers <Ben### [at] gmailcom_no_underscores> wrote:
>>> the buck does *not* stop here.
>> Shouldn't that be "the Buck"? ;)
>
> ??
>
>
As in, David K Buck :)
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> What I have seen of OOP programming is something else.
Just out of curiosity (but you keep saying things like this, so I have
to ask), where have you seen OOP programming?
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Neeum Zawan wrote:
> 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?
That was my original concern but this thread seems to a mutated as
threads do.
Any opposition to OOP seems to arouse a lot of feeling.
>
> 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.
>
Yes, I'm now told that a new scripting language is decades away so I suppose
my major concern is about 20 years or so too early. What language or
with what
"philosophy" Pov-Ray is coded in is of only minor concern, if the end
product remains
usable to me.
It's all been very interesting, though.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Neeum Zawan wrote:
> 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!"?
>
I'm sorry to seem unclear, but to me it seems that the "No" and the rest
of my
statement clearly refer to the assertion that I think in OOP all the
time when using
Pov-Ray. It seems to me that I don't, though perhaps others may know my
mind better that I do. In fact. since OOP means Object Oriented
Programming, it seems
absurd to say that I think in it (or in any other kind of programming).
On the other hand,
I am repeated told that I don't know what OOP means; maybe it *doesn't* mean
"Object Oriented Programming"(acronyms are always obstacles to
communication),
but some philosophy or mystery into which I have not been initiated. In
any case, it seems
an overstatement at least for someone else to say I thing in it. :)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> David H. Burns wrote:
>> What I have seen of OOP programming is something else.
>
> Just out of curiosity (but you keep saying things like this, so I have
> to ask), where have you seen OOP programming?
>
Your point is well taken. I have *never* seen OOP *programming*. I
looked at some
short OOP programs or excerpts in C++, python, and Visual Basic --
though I believe that the
earlier VB code that I have seen aren't really OO, but simply have some
of the trappings.
The "OOP" code I've seen in VB could have been written without the
OOP-like veneer.
To actually see OOP "programming", I suppose I would have to see some
one actually
coding in OOP.
I don't want to have to write something like those programs, I have
seen to produce a Pov-Ray
script!
But, apparently, that is a worry for only the remote future.
David
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> Warp wrote:
>
>> The whole idea of object-oriented programming is to make it *easier* to
>> write programs, especially compared to straightforward
>> imperative/structured
>> programming (as the SDL is currently).
>>
>
> That I cannot believe!!
Now you guys know how *I* feel when I try to tell people that functional
programming is a good idea. ;-) Nobody ever seems to believe me...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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? :-)
Not if you want to influence the POV4 design, the discussions for that have
already started, although I suspect it won't be until after POV3.7 is out of
beta before any real work gets started on it.
> Did that produce a wink.
I got a smile :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> If that be the case, shall we postpone this discussion for
>> twenty years or so? :-)
>
> Not if you want to influence the POV4 design, the discussions for that
> have already started, although I suspect it won't be until after POV3.7
> is out of beta before any real work gets started on it.
Are they going on on some other Pov-Ray newsgroup? The Pov4 group I
could get to
seemed to be involved with other things. I may have said too much anyway.
>
>> Did that produce a wink.
>
> I got a smile :-)
Oh well...
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> David H. Burns wrote:
>> Warp wrote:
>>
>>> The whole idea of object-oriented programming is to make it
>>> *easier* to
>>> write programs, especially compared to straightforward
>>> imperative/structured
>>> programming (as the SDL is currently).
>>>
>>
>> That I cannot believe!!
>
> Now you guys know how *I* feel when I try to tell people that functional
> programming is a good idea. ;-) Nobody ever seems to believe me...
You encourage me. But we seem to be out of fad. ;-) :) (An attachment
to your email reader which converted all ASCII characters into icons
would be interesting -- or stand alone program. It's probably been done.)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Are they going on on some other Pov-Ray newsgroup? The Pov4 group I could
> get to
> seemed to be involved with other things. I may have said too much anyway.
Check the povray.pov4.discussion.general group, particularly the threads
"Next Generation SDL Brainstorming" and "Next Generation SDL: What's wrong
with Lua, JavaScript, ...".
If you have something to contribute (eg "Hey I think my suggestion is better
than any OOP idea I've seen, and here's why...") then you should post it in
that group. This group goes off-topic very quickly no matter what you say
:-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/09 02:53, David H. Burns wrote:
> Yes, I'm now told that a new scripting language is decades away so I
> suppose
> my major concern is about 20 years or so too early. What language or
> with what
> "philosophy" Pov-Ray is coded in is of only minor concern, if the end
> product remains
> usable to me.
The decades was an exaggeration. However, it is a while away. Work has
not begun on 4.0, and it intends to be quite different from today's
POV-Ray - and not just in terms of the scripting language.
--
AD&D Famous last words: Me first. Me first!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Check the povray.pov4.discussion.general group, particularly the threads
> "Next Generation SDL Brainstorming" and "Next Generation SDL: What's
> wrong with Lua, JavaScript, ...".
Thanks, Scott,
I see only 4 threads and neither of these. Thunderbird is giving me
problem?
I initially told it to download only 100 messages and can't get it to
down load anymore.
After unsubscribing and re subscribing a couple of times, it downloads
only 107. Maybe
power on power off will help.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/09 03:43, Invisible wrote:
> Now you guys know how *I* feel when I try to tell people that functional
> programming is a good idea. ;-) Nobody ever seems to believe me...
I, for one, propose that the SDL in POV-Ray 5.0 should be functional.
--
AD&D Famous last words: Me first. Me first!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/09 07:38, David H. Burns wrote:
>> Now you guys know how *I* feel when I try to tell people that
>> functional programming is a good idea. ;-) Nobody ever seems to
>> believe me...
>
> You encourage me. But we seem to be out of fad. ;-) :) (An attachment
Hardly, What you like is procedural. Functional programming is a whole
other beast altogether, where you normally don't do explicit loops but
use constructs like map, filter, etc. Lots of lambdas thrown in as well.
--
AD&D Famous last words: Me first. Me first!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The decades was an exaggeration.
I made a formula to figure out when v4 will be complete :-)
2009 + B + K*(A + B)
Where:
A = years already spent on v3.7 devlopment
B = years still to go until v3.7 is complete
K = multiplier for amount of work needed for v4 compared to v3.7
A is 5 I think? Choose some values for B and K and see what you get!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Now you guys know how *I* feel when I try to tell people that functional
>> programming is a good idea. ;-) Nobody ever seems to believe me...
>
> I, for one, propose that the SDL in POV-Ray 5.0 should be functional.
I'm not sure whether we should go for 100% functional, or do 95%
functional. You know, like the way SQL is 95% relational (but still 5%
procedural). I'm unsure at this time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Check the povray.pov4.discussion.general group, particularly the threads
>> "Next Generation SDL Brainstorming" and "Next Generation SDL: What's
>> wrong with Lua, JavaScript, ...".
>
> Thanks, Scott,
> I see only 4 threads and neither of these. Thunderbird is giving me
> problem?
I don't use Thunderbird, but maybe someone else might be able to help you.
In Windows Live Mail you can choose "Tools -> Get Next <X> Headers" where X
is the value you set for how many to download at a time - maybe there is
something similar?
If not then you can always use the web view here:
http://news.povray.org/povray.pov4.discussion.general/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Now you guys know how *I* feel when I try to tell people that functional
>>> programming is a good idea. ;-) Nobody ever seems to believe me...
>>
>> I, for one, propose that the SDL in POV-Ray 5.0 should be functional.
>
> I'm not sure whether we should go for 100% functional, or do 95%
> functional. You know, like the way SQL is 95% relational (but still 5%
> procedural). I'm unsure at this time...
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. The SDL parser just needs to be a
special case that parses the file and calls the same POV core functions that
you can from your own code.
It would make things like doing complex simulations much easier, because you
could use eg C++ to get good speed, and have POV render the result quickly
each frame. Also if you wanted to use Haskell, or anything else, you could.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott 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. The SDL parser just needs
> to be a special case that parses the file and calls the same POV core
> functions that you can from your own code.
>
> It would make things like doing complex simulations much easier, because
> you could use eg C++ to get good speed, and have POV render the result
> quickly each frame. Also if you wanted to use Haskell, or anything
> else, you could.
That's an interesting idea. However, I have a vague recollection that
this would be incompatible with the terms of the POV-Ray license.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> 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.
Yeah yeah yeah... sure... I'm repeating myself here: *I* know how to map your
words to OOP, so you needn't tell me. It still doesn't convince me that
OOP-newbies have any idea what this cats & dogs crap is all about, and
introducing OOP in a much different way would make it much easier to grasp.
Let alone that OOP is not just "OOP". It is a combination of multiple concepts,
many of which don't require each other; the typical blurp tries to introduce
the whole "concept" of OOP all at once, instead of introducing the concepts one
by one.
> [lotsa stuff skipped]
> 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.)
.... and that's a very typical example of how modularity is commonly percieved,
huh?
Yes, modules occasionally *are* instantiated and referenced; but in typical
modular projects they're *not*, and instead just resemble code libraries.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I remember once way back, having written docs for the library, I was sitting
> there coding it up. (The project was a rewrite from BASIC to C, so I had a
> real good idea what the library needed to do.) I had a stack of
> documentation, and I was implementing each function. The "best" programmer
> in the company comes up and asks what I'm doing, and I tell him. He points
> to the inch-thick print-out, asks what it is, and I tell him it's the docs.
> He says, sounding baffled, "How can you write the docs before the program?"
> I ask him "How can you know when you're done programming without writing the
> docs first?"
Now, ever wondered what the subtleties between SW development, programming and
coding may be?
What you did was SW development: Designing a program, then coding it.
What the other guy did was programming: Just make sure to produce a program, no
matter how...
:)
(BTW, did you know that your working style costs jobs? 'Cause as long as people
program software instead of developing it, you can't just outsource the coding
part to India... :P)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> >> Shouldn't that be "the Buck"? ;)
> >
> > ??
>
> As in, David K Buck :)
Ah - now here comes light ;)
But no: Leader of the dev team is currently Chris Cason :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I'm sorry to seem unclear, but to me it seems that the "No" and the rest
> of my
> statement clearly refer to the assertion that I think in OOP all the
> time when using
> Pov-Ray. It seems to me that I don't, though perhaps others may know my
> mind better that I do. In fact. since OOP means Object Oriented
> Programming, it seems
> absurd to say that I think in it (or in any other kind of programming).
> On the other hand,
> I am repeated told that I don't know what OOP means; maybe it *doesn't* mean
> "Object Oriented Programming"(acronyms are always obstacles to
> communication),
> but some philosophy or mystery into which I have not been initiated. In
> any case, it seems
> an overstatement at least for someone else to say I thing in it. :)
I'd guess you *do* some "OOP (= Object Oriented Programming) thinking" when
working with POV-Ray; it's just that you don't notice, because you admittedly
don't know what Object Oriented Programming actually is - you only know how
typical end results from such thought processes look like, when formulated in a
general-purpose language retrofitted to better support such formulations
("better" as in "better than nothing") - a language which, by the way, would
surely happen to be unsuited for a POV-Ray SDL.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/09 08:49, Invisible wrote:
>> It would make things like doing complex simulations much easier,
>> because you could use eg C++ to get good speed, and have POV render
>> the result quickly each frame. Also if you wanted to use Haskell, or
>> anything else, you could.
>
> That's an interesting idea. However, I have a vague recollection that
> this would be incompatible with the terms of the POV-Ray license.
The POV-Ray license will either disappear in 4.0, or will be made
compatible with one of those alleged "free" licenses.
--
AD&D Famous last words: Me first. Me first!
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I don't want to have to write something like those programs, I have
> seen to produce a Pov-Ray
> script!
Um... wait a second here: You've looked at code written to create POV-Ray code?
Now that's metaprogramming, which tends to look sick in *any* language that's
not designed for it, whether it be OOP or not.
> But, apparently, that is a worry for only the remote future.
Hmm... I don't really think so. Not if you talk about decares here. 3.7 did
indeed take a while to come out (still not released), but after all it was a
major rewrite of virtually the whole code, with some serious design changes to
get it to support SMP. Compared to that, I guess development of POV-Ray 4 will
be a piece of cake - the main objectives (um... no pun intended here, really)
being that major overhaul of the SDL (but that will just mean a rewrite of the
parser, leaving the remaining code untouched), and a change in licensing to go
for GPL (not much left to do there; AFAIK virtually all previous contributors
have given their OK by now, and the remaining pieces of code have been
completely re-written).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> I'd guess you *do* some "OOP (= Object Oriented Programming) thinking" when
> working with POV-Ray; it's just that you don't notice, because you admittedly
> don't know what Object Oriented Programming actually is -
We may all be engaging in muddy thinking and language here. I do kind of
think
in terms of "objects" when using Pov-Ray, but I wouldn't call that "OOP
(= Object
Oriented Programming) thinking", even if that phrase means
anything--which I doubt.
It might be more accurate to say that I am writing code which conforms
to the syntax dictated by
the SDL -- regardless of what kind of thinking leads to it. As I have
said several times before:
I think the concept of "object" is a real advance in programming but
"OOP" seems
a lot more than simpling making use of "objects" which "contain" both
data members
and functions ("methods")
>you only know how
> typical end results from such thought processes look like, when formulated in a
> general-purpose language retrofitted to better support such formulations
> ("better" as in "better than nothing") - a language which, by the way, would
> surely happen to be unsuited for a POV-Ray SDL.
This seems to be true, where would I find some *real* OOP to look at?
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>>> Check the povray.pov4.discussion.general group, particularly the
>>> threads "Next Generation SDL Brainstorming" and "Next Generation SDL:
>>> What's wrong with Lua, JavaScript, ...".
>>
>> Thanks, Scott,
>> I see only 4 threads and neither of these. Thunderbird is giving me
>> problem?
>
> I don't use Thunderbird, but maybe someone else might be able to help
> you. In Windows Live Mail you can choose "Tools -> Get Next <X> Headers"
> where X is the value you set for how many to download at a time - maybe
> there is something similar?
>
> If not then you can always use the web view here:
>
> http://news.povray.org/povray.pov4.discussion.general/
>
>
Thanks. I haven't had this problem with the other Newgroups. I'll look
at it via
the web.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Neeum Zawan wrote:
> On 07/24/09 07:38, David H. Burns wrote:
>>> Now you guys know how *I* feel when I try to tell people that
>>> functional programming is a good idea. ;-) Nobody ever seems to
>>> believe me...
>>
>> You encourage me. But we seem to be out of fad. ;-) :) (An attachment
>
> Hardly, What you like is procedural. Functional programming is a
> whole other beast altogether, where you normally don't do explicit loops
> but use constructs like map, filter, etc. Lots of lambdas thrown in as
> well.
>
So your not out of fad. My ignorance is showing. I'm not a professional
programmer
and have done little except for my own amusement. That being so much of
your
terminology is unfamiliar to me. I think that this thread is the only
time I have
actually talked to anyone specifically about programming theory --
although I did
a lot of reading a number of years ago.
You encourage me anyway.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> (BTW, did you know that your working style costs jobs? 'Cause as long as people
> program software instead of developing it, you can't just outsource the coding
> part to India... :P)
Heh. I'll keep that in mind.
--
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:
> 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. The SDL parser just needs
> to be a special case that parses the file and calls the same POV core
> functions that you can from your own code.
I think this came up a number of times in the past. I remember getting
brutalized for suggesting CIL ;-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/09 09:51, David H. Burns wrote:
> I think the concept of "object" is a real advance in programming but
> "OOP" seems
> a lot more than simpling making use of "objects" which "contain" both
> data members
> and functions ("methods")
As I said before, you have a "ball" variable, which is just a sphere
with everything you've defined (coordinates, texture, etc).
It has data members, which would be the aforementioned items
(coordinates, pigments, etc). It also may have methods, like rotate,
translate, etc. You could do:
ball.translate(1, 3, 5)
to translate it by <1, 3, 5>.
(The syntax may be a bit different - that's a minor issue).
I think you're worried that you'll somehow have to put all your code
into the methods of objects. Heck, for simple scenes, I doubt you'll
have to code _any_ methods. POV-Ray will provide standard methods to all
objects (like rotate, translate, etc), which you will merely use.
If you want to do regular for loops, etc, it need not be part of any
object method, but in your "regular" code. No one said that the new SDL
will force everything to reside in an object like Java does.
--
Cut my pizza in six slices, please; I can't eat eight.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I do kind of think
> in terms of "objects" when using Pov-Ray, but I wouldn't call that "OOP
> (= Object
> Oriented Programming) thinking", even if that phrase means
> anything--which I doubt.
Well, I do agree that "OOP thinking" is somewhat fuzzy.
Let me rephrase the whole smash like this:
What others call "OOP thinking" might be more familiar to you than you may be
aware of.
> It might be more accurate to say that I am writing code which conforms
> to the syntax dictated by
> the SDL -- regardless of what kind of thinking leads to it. As I have
> said several times before:
> I think the concept of "object" is a real advance in programming but
> "OOP" seems
> a lot more than simpling making use of "objects" which "contain" both
> data members
> and functions ("methods")
Yes; what you describe would be "encapsulation", which is just one major
building block of OOP. As I mentioned earlier, another important one is
"polymorphism", which you can think of as the ability to equip multiple
different objects with methods that have the same name and parameters, but
different code to match the object's data structure. An example is POV-Ray's
"sphere", "box" and all the other primitives using the very same syntax to
transform, apply textures, etc.
A third concept frequently encountered in OOP, "inheritance", on the other hand,
is in my eyes not really an essential part of OOP, but instead just a mechanism
(albeit a powerful one) to manage issues arising from polymorphism, both
regarding redundancy (different objects may be similar enough that parts of
their data structures and methods can be implemented in the very same way, so
it would be a waste of time to write and maintain that same code twice) as well
as object compatibility (compile-time detection of potential attempts to invoke
methods on objects that don't have them).
Atop of this are a bunch of design patterns which are associated with OOP,
probably for the sole reason that they're making such heavy use of
encapsulation and polymorphism that it would be extremely cumbersome to express
them in a non-OOP language.
Some other stuff often associated with OOP languages just happen to have become
popular in mainstream languages at the same time as OOP; for instance
"overloading" of functons (defining multiple functions of the same name but
with different parameter types); model-view-controller architecture (dividing
an application into three components referred to as model, view and
controller); to name a few examples.
>
> >you only know how
> > typical end results from such thought processes look like, when formulated in a
> > general-purpose language retrofitted to better support such formulations
> > ("better" as in "better than nothing") - a language which, by the way, would
> > surely happen to be unsuited for a POV-Ray SDL.
>
> This seems to be true, where would I find some *real* OOP to look at?
I don't know whether there exists such a thing as "real OOP to look at".
Whatever code you look at, if you're not familiar with the language you'll
probably see more of the language's peculiaritis than you'll see of the
programmer's original thoughts.
Academic languages are peculiar anyway; and non-academic languages tend to
accumulate traits over time that are peculiar because the original language
didn't have them.
In the case of POV-Ray, I still have to come across some language that wouldn't
outweigh the benefits by its peculiarities. The current POV-Ray SDL is so
well-suited to its basic task that it would be imprudent to go very far from
that, as far as the effective syntax is concerned. The only problem with it is
that it is particularly ill-suited for the non-basic tasks people want to use
it for these days. It is exceptionally good for *describing* a scene, but also
exceptionally bad for *generating* it (which doesn't mean it lacks the power;
being Turing-complete, you can do anything with the currend SDL; but what it
does lack is performance, some more consistency, and some more support for
OOP).
So what I'd go for is a language that is deliberately designed to be very
remniscient of the current SDL when it comes to describing scene elements, and
as straightforward when it comes to simple scene-generation tasks (like, say,
placing 100 spheres in a row) - any language imposing some overhead for these
two would be ill-suited for POV-Ray.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I think this came up a number of times in the past. I remember getting
> brutalized for suggesting CIL ;-)
.... and rightly so ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks. This is the best and most concise explanation of the basic
tenets of OOP that
I have read. Much better, for instance, than that in "OOP for Dummies".
clipka wrote:
>> This seems to be true, where would I find some *real* OOP to look at?
>
> I don't know whether there exists such a thing as "real OOP to look at".
> Whatever code you look at, if you're not familiar with the language you'll
> probably see more of the language's peculiaritis than you'll see of the
> programmer's original thoughts.
Perhaps I should have said where could I find some simple examples of
good OOP
programming. Any that would be very useful to me might be hard to find.
I have some
Python code for producing a Windows GUI "wrapper" around old Fortran
code. The results
are quite impressive. It's likely that this code would be as good
example as I can find --
though it's not especially simple.
>
> Academic languages are peculiar anyway; and non-academic languages tend to
> accumulate traits over time that are peculiar because the original language
> didn't have them.
>
The current POV-Ray SDL is so
> well-suited to its basic task that it would be imprudent to go very far from
> that, as far as the effective syntax is concerned.
Amen!
:) David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> Chambers wrote:
>> Just out of curiosity (but you keep saying things like this, so I have
>> to ask), where have you seen OOP programming?
>>
>
> Your point is well taken. I have *never* seen OOP *programming*.
<snip>
> To actually see OOP "programming", I suppose I would have to see some
> one actually coding in OOP.
I don't think you understood my point. I'm not talking about watching
someone as they write code. I'm talking about the source code itself.
What source code have you seen that scared you so badly away from OOP?
My guess (and it's just a hunch at this point), is that the OOP itself
isn't what scared you, but rather the complexity of the program. If
this is the case, then you're almost certainly guaranteed that the
program would have looked *worse* if it weren't OO.
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.
It's not for everyone, and some people are more suited to using the
programs they have than writing new ones.
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Chambers <Ben### [at] gmailcom_no_underscores> wrote:
>>>> Shouldn't that be "the Buck"? ;)
>>> ??
>> As in, David K Buck :)
>
> Ah - now here comes light ;)
>
> But no: Leader of the dev team is currently Chris Cason :P
I know, but I find it hard to pass up an opportunity for a good pun :)
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> (BTW, did you know that your working style costs jobs? 'Cause as long as people
> program software instead of developing it, you can't just outsource the coding
> part to India... :P)
In other words, he saves money by not creating *extra* work that his
employers have to pay for.
Way to go Darren, you deserve a raise! :)
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott 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!
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> Invisible wrote:
>
>>> 2. What would be so bad about this being true?
>> It would be too complex to be usable by ordinary folk (i.e. me).
>
> And exactly how do you know this?
>
OOP is the first three letters of oops!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
