 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dan P" <dan### [at] yahoo com> wrote in message
news:4039335d$1@news.povray.org...
> Thank you, Warp.
Uh, I said that, not him.
> This has been a puzzle for me for some time now: why do so
> many programmers write such awful code?
It seems impossible for me to make a statement without people taking it too far!
I'm *not* saying all abstraction is evil and should be avoided, but I'm also
*not* saying everything should be abstracted as much as possible. I'm talking
about finding a balance between the two, according to the needs of your task.
There is never any excuse for writing code that is needlessly difficult to read,
such as many unproffessional coders like to do in the flawed belief that it
makes them look clever.
However, there is good reason to sometimes write code that makes it harder to
see the overall structure if doing so provides you with some other useful
information. Obviously a balance must be found and that balance is different for
different applications, but in my work it is useful to avoid a lot of
abstraction.
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cjameshuff-CF95A3.17100922022004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet> wrote:
> I've written a raytracer using vectors that use operator overloading. It
> was much easier to see what the code did than it is in POV, which uses
> macros for the vector operations.
In the source code you have access to it doesn't!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tek" <tek### [at] evilsuperbraincom> wrote in message
news:40393ba8$1@news.povray.org...
> "Dan P" <dan### [at] yahoocom> wrote in message
> news:4039335d$1@news.povray.org...
> > Thank you, Warp.
>
> Uh, I said that, not him.
>
> > This has been a puzzle for me for some time now: why do so
> > many programmers write such awful code?
>
> It seems impossible for me to make a statement without people taking it
too far!
Oh, I'm sorry; I didn't think that sounded like you, Tek :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40392dba$1@news.povray.org>, "Tek" <tek### [at] evilsuperbraincom>
wrote:
> Well yes, I'm not debating that. I'm saying for what you're doing
> it's better to deal with things on a cleaner more mathematical basis,
> but for what I do at work it's better to deal with things on a more
> technical implementation-based level.
No...I don't give a damn about the mathematics. It's just cleaner
looking and easier to read with overloaded operators. Easier and faster
to write and debug, giving me much more time to spend on optimization or
extension of the program.
> > Yes you did...in a reply to one of my earlier messages:
> No, I said it was an argument against the *use* of operator overloading, not
> it's existence. I'm not saying it should never be used, I'm just explaining
> why we don't use it.
Then why did you even reply to my message?
> Which still is not a reason to hide what the code is actually doing.
The only information hidden is that which isn't of any use to the
situation anyway. You don't need to know exactly how vectors and
matrices are multiplied, it is enough to know that doing so is
time-consuming.
> Besides, a good optimiser does neither of those, you begin by
> profiling the system extensively to ascertain what is slow. It
> doesn't matter how cumbersome the big concepts are, or how badly
> implemented the low level things are, all that matters is how long
> things take.
I did mention "specific bottlenecks". How do you think those bottlenecks
would be found, if not by profiling the program?
> > And I don't buy your argument about vector-matrix
> > multiplication...if you're doing high-performance code, you should
> > always be aware of the types you're working with.
>
> But how do I gain this awareness if it's not my code?
You read the code.
> Last project I
> was on had 20 programmers, and I was one of the main people assigned
> to optimise things. It was more important to me to see how the code
> worked at a lower level than to see nice clean algorithms.
You regularly have separate programmers coding and optimizing? That does
not sound like a good idea...the person optimizing starts out knowing
nothing about the code.
And again, it's not about "nice clean algorithms", it's "nice clean
*code*" that lets you see what's being done!
> However I know there are other games companies that go all out for OO code,
> because they wish to code at a higher level. They do not produce such
> efficient code as we do :)
Then they're doing it wrong. And what company do you work for? I never
want to work there.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-CD5ABF.18305722022004@news.povray.org...
> In article <4039335d$1@news.povray.org>,
> "Dan P" <dan### [at] yahoocom> wrote:
>
> > > > > We like the clunkier syntax *because* it is harder to use and
requires
> > more
> > > > > thought from the programmer. In our situation this is a good
thing.
> >
> > Thank you, Warp. This has been a puzzle for me for some time now: why do
so
> > many programmers write such awful code? At first, I thought it was
because
> > they didn't want other programmers to understand it because they could
be
> > replaced. Then, I figured it was just because they were engineers with
no
> > sense of cognitive psychology. Finally, I read your message, and now I
> > understand it: these engineers are doing the world a /favor/ by making
code
> > hard to read because it makes other programmers think more. I get it
now!
> > It's alturism.
> >
> > Don't send me a resume.
>
> Warp didn't write that. And even if he had, your attack would have been
> completely unwarranted. Speaking as a member of the TAG, please stop
> these personal attacks, insults, and other anti-social behavior. Now.
That wasn't an attack, that was sarcasm. I apologize, Warp; I didn't realize
that wasn't you that said that. Chris, if you want to single me out, okay,
but this group is anything but friendly and I'm just as happy to remove it
from my newsgroups list as you are to remove me from it. Because I feel
personally attacked every time I write a message on this board, particularly
when I post code of any sort. Messages like, "You should read an OO book"
are pretty damned insulting and pretty damned personal so I ask you,
politely, to remove the double-standard when wielding your "big stick".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40393bc7$1@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> > I've written a raytracer using vectors that use operator overloading. It
> > was much easier to see what the code did than it is in POV, which uses
> > macros for the vector operations.
>
> In the source code you have access to it doesn't!
In the currently final version, the version that everyone has access to,
it does. ;-)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P <dan### [at] yahoocom> wrote:
> Because I feel
> personally attacked every time I write a message on this board, particularly
> when I post code of any sort. Messages like, "You should read an OO book"
> are pretty damned insulting and pretty damned personal so I ask you,
> politely, to remove the double-standard when wielding your "big stick".
No, there's no conspiracy against you here.
I don't tend to remember people names for negative things, but tend to
easily forget them. If I have a flamewar with someone and then it stops,
after a week or two I have probably already totally forgotten the name
of my "adversary". In fact, I wasn't completely sure if it was you whose
C code I commented when I responded with the OO things (and I didn't make
much effort remembering, for that matter).
Although you might feel like it, this is not a place where regulars
select some newcomer at random and start attacking him as a team effort.
That would be completely silly.
If you are receiving tons of negative responses, then think about why
that may happen. It's certainly not a conspiracy against you personally.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:403946d7@news.povray.org...
> Dan P <dan### [at] yahoocom> wrote:
>
> Although you might feel like it, this is not a place where regulars
> select some newcomer at random and start attacking him as a team effort.
> That would be completely silly.
> If you are receiving tons of negative responses, then think about why
> that may happen. It's certainly not a conspiracy against you personally.
Actually, I think I am wired a little different. Here's an example: when you
said to someone, "If you don't know what operator+() does with the type you
are using, then you should seek another job, IMHO," I thought that was far
worse than anything I have ever said to anybody on here by at least a factor
of 10. I've never said you weren't qualified to do your job or even hinted
at it. In my response, I indirectly said that I wouldn't want you working
for /me/. But, I think you aren't using an active reference in your
sentence. What I mean by that is I read your message as, "You, poster, don't
know what the operator +() does and, therefore, you should seek another
job." What I think you must be saying, if it isn't insulting, is, "If some
person doesn't know whwat operator +() does with the type you are using,
then that person should seek another job." Even that could be taken the
wrong way, but it is not direct and, therefore, not an "attack".
I think we have different parsers and I'm going to have to adjust mine to
get along here. Plus, I felt way more negatively about what I thought you
were saying because I have to deal with that on a daily basis and it just
makes my job hard... I was emotional and /wrong/ for being so.
Can I get another chance at fixing my parser?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> > And in real languages, you don't even have to tell the compiler to do
> > that. ;-)
> You don't need to do in C++ either. "inline" is only a hint to the compiler
> just like the "register" keyword. Most modern compilers will inline
> whatever they see fit, and some will even completely ignore the "inline"
> keyword and find a better selection of functions to inline.
What I meant when I said that the operator function should be made
"inline" was that it should be implemented where it's declared (or
at least at the same visibility level).
If the function is declared in a header file but implemented in a
separate object file then the compiler naturally can't inline it.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> Argh...forget about virtual functions. They are an artifact of C++,
> which does everything statically by default. I specifically said no
> static binding. No virtual functions, because everything is dynamically
> bound.
What do you mean "no virtual functions"? If every function is dynamically
bound, then *every* member function is virtual.
At least you should be able to specify a default implementation for
a member function or live it as purely virtual.
If you leave all the member functions as purely virtual, then what
you have is an interface.
> > A class is abstract if it has pure virtual functions (that is,
> > the class does not implement the virtual function(s) and thus cannot
> > be instantiated because of this; it can only be used through
> > inheritance so that the derived class implements the virtual
> > function(s) in question).
> Again, I'm talking about single inheritance. Multiple inheritance is not
> necessary, and is needlessly complex.
Who is talking about multiple inheritance here? I'm not.
And multiple inheritance may be complex from the point of view of
the interpreter/compiler, not from the point of view of the user.
Why should that be a limit?
> Abstract classes are not as useful
> in single inheritance models, interfaces cover their functionality.
I don't understand what you are saying.
Why have *two* types of classes when you can have just one?
And why abstract classes are not useful in single inheritance model?
> Interfaces render multiple inheritance + multiple abstract root classes
> obsolete, not the other way around.
Interfaces are a poor way of making multiple inheritance. They have
all the logical problems of multiple inheritance and they force you
to make code repetition.
I have never understood what's so good about interfaces.
> > That's right. *You*. But that's ok only for as long as you don't
> > distribute that library of yours containing public member variables...
> > Someone will inevitably use it in the wrong way and his code can then
> > break with an updated version of the library.
> That's their fault
You can't design libraries with that principle.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
