Eero Ahonen wrote:
> David H. Burns wrote:
>> (Laugh) I love it! What can be off-topic to off-topic?  What you mean, I
>> think, is that
>> this topic is forbidden! Or maybe simply unwanted.
>>
> 
> On-topic. Your conversation is clearly about Pov-RAY, so it would
> naturally fit onto the on-topic groups better than to shit-chatting
> off-topic group :-).
> 
> -Aero
I was told I was off topic in the programming group -- or maybe it's 
just what
I say, or how I say it, not the subject that's off-topic. But my critics 
are right;
I don't know enough detail to really discuss OOP. I just voice my 
objections
which apparently aren't shared.
:)

Post a reply to this message

>> Just because Java is OOP done wrong, and C++ is a superset of an 
>> already complicated language, doesn't mean that OOP is inherantly 
>> complex.
> 
> You may be right. The complexity that I see in C++ may derive mainly 
> from C. C,
> in my experience, is a fascinating and addictive language, but it 
> apparently allows,
> maybe encourages, writing code so complex as to be almost 
> undecipherable.

IME, programs written in C are almost always unreadable. But I'm biased. ;-)

> Maybe
> it bequeathed that legacy to C++ and other OOP languages and that it is 
> really foreign to
> OOP. Of course it matters little if OOP is not "inherently" complex if 
> all existing instances
>  are.

You're aware that there are OOP languages which aren't Java or C++, 
right? (For example, Smalltalk, Eiffel, JavaScript, CLOS, just off the 
top of my head.) C++ and Java are both very "impure" variants of the OOP 
vision. Arguably Eiffel is the purest. (And, arguably, Eiffel is quite 
complex - mostly because it provides MI and also generics.)

> And I don't really see the logic in spending
> months preparing to write a program that could be effectively written in 
> a simple language -- if such had survived.

Well now here *is* an interesting point... For small, simple programs, 
unstructured languages allow you to express your ideas as simply and 
directly as possible. The principle problem is that as soon as you start 
trying to write larger programs, they become a mess. This is why 
structured programming (of which OOP is simply a logical extension) were 
invented.

The question is... are any POV-Ray "programs" large enough to benefit 
from the extra structuring? I believe the answer is yes, but it's 
somewhat debatable.

Post a reply to this message

Thanks. I'll look at the discussion.general group. But, I've probably 
said all that I
ought.

David

scott wrote:
>> (Laugh) I love it! What can be off-topic to off-topic?  What you mean, 
>> I think, is that
>> this topic is forbidden! Or maybe simply unwanted.
> 
> No, it really is just the wrong group here.
> 
> If you look in the pov4.discussion.general group you will see that this 
> subject has already been discussed a lot, so please read through the 
> posts there, and if you feel you still have something to add then by all 
> means start a new thread.  Nobody is going to flame you for a forbidden 
> topic, I assume that the developers want input from as many users as 
> possible when deciding what to do for POV4.
> 
>

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> IME, programs written in C are almost always unreadable. But I'm biased. ;-)

  Your problem is that you refuse to aknowledge readability even for examples
which clearly are, probably because of some principle.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> IME, programs written in C are almost always unreadable. But I'm biased. ;-)
> 
>   Your problem is that you refuse to aknowledge readability even for examples
> which clearly are, probably because of some principle.

Oh, I have a far bigger "problem" than that: C is the number one 
language requested in job adverts. :-(

Post a reply to this message

> Oh, I have a far bigger "problem" than that: C is the number one language 
> requested in job adverts. :-(

So anyone interested in programming jobs might think it's a good idea to at 
least learn the basics...

BTW, at University there were *very* few people who failed to write C++ 
programs by the end of the course (and this was an Engineering course don't 
forget).  I really find it impossible to believe that you couldn't learn the 
basics of C++ from a book or decent web tutorial.

Post a reply to this message

>> Oh, I have a far bigger "problem" than that: C is the number one 
>> language requested in job adverts. :-(
> 
> So anyone interested in programming jobs might think it's a good idea to 
> at least learn the basics...
> 
> BTW, at University there were *very* few people who failed to write C++ 
> programs by the end of the course (and this was an Engineering course 
> don't forget).  I really find it impossible to believe that you couldn't 
> learn the basics of C++ from a book or decent web tutorial.

And when I was at college, we actually did a semester of C. I submitted 
a C program, which did actually do what it was intended to do. It took 
me an awefully long time to get it to work though. I was constantly 
tripped over by various things. You know, the usual:

- printf() exists.

- I keep having to look up the syntax for defining new data structures.

- C doesn't seem to distinguish between Booleans, integers, pointers and 
arrays.

- The whole issue of pointer syntax is just confusing.

- Splitting a program into more than one source file opens up a whole 
new world of pain. (Especially if you don't have the benefit of automake.)

I guess the basic problem is C's insistence on allowing you to do 
absolutely anything, no matter how stupid, and providing no help 
whatsoever in finding your mistakes. Couple that with a cryptic syntax 
where it's worryingly easy to say something completely different from 
what you actually meant and it's not the easiest of languages to use.

Fortunately, for my assignment, I merely had to write a program to "do 
graphics". (That was more or less the assignment brief. Do something 
that has graphics in it. Open-ended, much?) Fortunately, this doesn't 
involve very much sophisticated programming, just lots of algebra. I can 
just about handle that.

Still, writing code in C is the easy part. Unfortunately, as soon as you 
try to read somebody else's, you quickly realise that regular C 
programmers think it's A-OK to do random crazy stuff like using 
assignments as expressions or writing while-statements where the 
conditional test does all the work and the loop body is empty. (My 
particular favourit is performing pointer dereference, assignment, and 
incriment in a single statement... Probably very efficient at the 
machine level, but utterly opaque to read.)

As for C++... well that might be a little easier. Although the tutorial 
I was following explains things in a rather random-seeming order. (You'd 
think knowing how to write a class would be a higher priority than 
understanding const references, but hey...) It still has the basic 
problem of being a language that makes no attempt to stop you doing dumb 
things, and overly opaque syntax.

Post a reply to this message

> - Splitting a program into more than one source file opens up a whole new 
> world of pain. (Especially if you don't have the benefit of automake.)

You don't have to do this, and for tiny programs it's probably not needed. 
For larger programs I cannot begin to imagine how inefficient it would be to 
have it all in one file, let alone when I want to reuse an existing class in 
another project.

You sound like you need to get a decent book on C++ (NOT C) and get a modern 
IDE (Visuall C++ Express will let you do standard C++ without any .net stuff 
and is free).

Of course if you're stuck writing a whole program in one C file in notepad 
things are gonna suck big time.

Post a reply to this message

scott wrote:
>> - Splitting a program into more than one source file opens up a whole 
>> new world of pain. (Especially if you don't have the benefit of 
>> automake.)
> 
> You don't have to do this, and for tiny programs it's probably not 
> needed. For larger programs I cannot begin to imagine how inefficient it 
> would be to have it all in one file, let alone when I want to reuse an 
> existing class in another project.

The point is, as soon as you have more than one source file, you have to 
manually write header files, manually keep them synchronised with the 
source files, manually figure out the dependency tree, manually compile 
everything one at a time, manually recompile stuff as needed, and 
manually link it all at the end. Get any single step wrong, and at best 
you'll get an incomprehensible linker error; at worst you'll get a 
segfault. Good luck every figuring out why.

If you have automake, a few of those tasks become automated. But 
seriously, I'm used to having a language where you say "compiler my 
stuff" and it hands you a runnable program.

> You sound like you need to get a decent book on C++ (NOT C) and get a 
> modern IDE (Visuall C++ Express will let you do standard C++ without any 
> .net stuff and is free).

I've seen more adverts for C than for C++ (although there certainly seem 
to be quite a few for C++ as well). I think I might still have VS 
installed on my PC at home. I guess it's just finding the motivation to 
use a language which is over-complicated, unsafe and difficult when I 
could instead use one which is clean, simple and easy...

> Of course if you're stuck writing a whole program in one C file in 
> notepad things are gonna suck big time.

Actually, Borland's TurboC for DOS IDE. (Or, alternatively, Vim under 
Linux.)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> The point is, as soon as you have more than one source file, you have to 
> manually write header files, manually keep them synchronised with the 
> source files, manually figure out the dependency tree, manually compile 
> everything one at a time, manually recompile stuff as needed, and 
> manually link it all at the end. Get any single step wrong, and at best 
> you'll get an incomprehensible linker error; at worst you'll get a 
> segfault. Good luck every figuring out why.

  Do you honestly think that an IDE like Visual Studio is not going to
automatically create project dependencies for you?

  In the Unix side of the world knowing a bit of makefile syntax gets you
a long way. It's even possible to create a makefile (at least when using
gnu make) which automates mostly everything, including resolving dependencies.

  And for a small project a simple "g++ *.cc -o myprogram" will do just fine.

-- 
                                                          - Warp

Post a reply to this message