Jim Henderson wrote:
> On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:
> 
>> What can be off-topic to off-topic?
> 
> Why, anything that's on-topic, of course. ;-)
> 
> Jim

Obviously, but I hadn't thought of it that way.

David

Post a reply to this message

Invisible wrote:
> clipka wrote:
> 
>> Once you've embraced the OO paradigms, you'll no longer wonder whether 
>> it's a
>> step back or sideways - you'll know that it's a step forward.
> 
> 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 :)

For one, OOP more closely models how many people think of problems, 
while functional programming more closely models how mathematicians 
think of problems.  It is not yet clear which one is better for managing 
large, complex programs in general (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).

-- 
Chambers

Post a reply to this message

clipka wrote:
> the buck does *not* stop here.

Shouldn't that be "the Buck"? ;)

-- 
Chambers

Post a reply to this message

andrel wrote:

Unfortunately, it seems to be in the nature of things that useless 
discussion drag
on and recur while the useful ones appear only once for a moment. But 
this one hasn't
been entirely useless to me. :)

The main problem though, apart
> from this being the wrong group is that you restarted a useless 
> discussion for the 42nd time.
> 
>> :)

Post a reply to this message

scott wrote:
> A lot of people just find it makes more sense to 
> have one file that neatly shows the interfaces and another to actually 
> contain the implementation code.

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).  Somehow, it seems to make things easier for me.

-- 
Chambers

Post a reply to this message

On Wed, 22 Jul 2009 20:00:21 -0500, David H. Burns wrote:

> Jim Henderson wrote:
>> On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:
>> 
>>> What can be off-topic to off-topic?
>> 
>> Why, anything that's on-topic, of course. ;-)
>> 
>> Jim
> 
> Obviously, but I hadn't thought of it that way.

That's perfectly OK - I was just kidding around, had hoped the smiley 
would tip that off. ;-)

Jim

Post a reply to this message

> The way this works on the Amiga is that you can't just *call* an OS 
> function. First you have to look up its base address in a table. 
> Basically, memory address 0x00000004 contains a pointer to a table. Every 
> OS function has a unique ID which is an offset into this table, which 
> enables you to lookup the function's base pointer. And then you can jump 
> to it. All of which takes about two-dozen assembly instructions...

On the Acorn there was an instruction called SWI (software interrupt) for 
calling OS and other module functions.  In the assembler it took a number or 
a string as a parameter (the assembler converted the string to the correct 
number), which defined the specific function you wanted to call.  I assume 
when the CPU got to the SWI instruction it jumped to a few lines of OS code 
which figured out where to actually jump to execute the instruction.

When you loaded "modules" to the OS (they were like services under windows) 
each module could register some functions with the OS.  Then you could call 
them with the SWI instruction.  It was pretty easy to use.

You could easily hack the system though by redirecting the interrupt handler 
to your code, calling the real OS handler, then passing control back to the 
calling program.  Of course in your code you could then check for certain 
functions (like reading the contents of a folder) and modify the results :-)

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> > the buck does *not* stop here.
>
> Shouldn't that be "the Buck"? ;)

??

Post a reply to this message

>> > the buck does *not* stop here.
>>
>> Shouldn't that be "the Buck"? ;)
>
> ??

I know in German you use a capital letter for every noun, but in English 
it's usually just for names.

Post a reply to this message

>> I see. So you still have to manually define what needs to be linked 
>> somehow?
> 
> Lets just say I'm working with source files right now where the line 
> used to compile the file takes up more than one screen of text in the 
> editor.

Yes. For some reason, this seems to be mandatory in all Linux 
development. I'm not sure why...

>> - When main.c is compiled, it produces main.o, which contains several 
>> references to a foo() that should exist somewhere, but we don't know 
>> where yet.
> 
> No. Only if main() actually calls foo().

One assumes that if you don't need foo(), you wouldn't bother including 
the header file. But sure, if the header declares a few dozen functions; 
you might not call every single one of them.

>> - The linker takes main.o and foo.o, and replaces every jump to foo() 
>> with a jump to an actual machine address. The resulting program is 
>> actually runnable.
> 
> 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?

>> What I can't figure out is what happens if foo() is actually a 
>> function somewhere in the OS kernel. 
> 
> It isn't. The read() function in C, for example, is in the C runtime 
> library (glibc or uclibc on Linux).  The linker always searches that 
> library as part of the linking process (unless you're doing something 
> funky like compiling the kernel). The read() function in that library is 
> written in assembler (because C is really not very useful for this sort 
> of work) and that assembler code copies items off the stack into machine 
> registers and then invokes an assembler instruction that causes the CPU 
> to set certain flags in the CPU registers that control permissions, 
> change memory maps, and eventually winds up branching to a particular 
> address in memory which the kernel has previously set to be a branch 
> instruction to the code to handle read().  So read() is normal, except 
> it's in a library the compiler always searches and contains assembly 
> language.

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

>> Presumably in each version of the kernel, the base address of this 
>> function is going to be different... so how the hell does the linker 
>> know what it is?
> 
> It doesn't. It executes a machine-code instruction that's essentially a 
> software interrupt. (That's why you see things like DOS functions being 
> described as "Int 21h" functions.)
> 
> 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...)

>> The way this works on the Amiga is that you can't just *call* an OS 
>> function.
> 
> There's no memory protection or kernel mode on AmigaOS. It can't be 
> multiuser.

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.

Additionally, the factory-standard Amigas had the "EC" version of the 
Motorola 68000 CPUs which lack an MMU. You can, however, replace this 
with a version of the CPU that possesses an MMU. Indeed, several 
companies offered the add-on boards, together with the necessary 
software to extend AmigaOS to support virtual memory. This suggests that 
the MMU-enabled variant of the CPU could support memory protection if 
you wanted.

And finally, it's perfectly possible to make a multiuser OS without 
memory protection. It just won't have any memory protection. (Meaning 
one rogue program can crash the whole system.) Arguably not very useful, 
but completely doable.

Post a reply to this message

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