 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> Jon A. Cruz <jon### [at] geocities com> wrote:
> : Guess what? Those are many things that I specifically like about Java, and think
> : they help you to write good code:
>
> I still don't understand how.
>
> :> - The enum type has been left out:
>
> : This one is maybe so-so. I've seen it used well, but then again I've seen it
> : abused.
>
> This is the typical answer. A feature has been left out because it can be
> abused.
> : Overloaded operators make things a lot harder to read
>
> Again a typical answer.
> : Bad. Can be very powerfull in the hands of an expert, but then far more damage can
> : be done by it's use.
>
> Again the "let's limit what a professional programmer can do in order to
> prevent beginners from doing something wrong" effect.
>
> : Actually, it's quite clear. In Java all primitives are passed by value.
>
> No, it's not clear. There's nothing in the syntax that helps you see
> whether a variable is a reference or not. At least in C++ you immediately
> see from the definition of a function that "this parameter is a value and
> this parameter is a reference".
> On the other hand, as I said in the previous article, _everything_ in java
> are references, so once you get used to that it's not so big deal (the basic
> types are passed by value, but you can see it from the type of the parameter).
>
> : Java programming mindset, it's very simple. As opposed to C++ where these would do
> : two different things:
>
> : void F(int x)
> : { x = 5;
> : }
>
> : void F(int &x)
> : { x = 5;
> : }
>
> I don't understand what do you mean. It can be quite clearly seen (once
> you know the syntax, of course) that the second one changes the original
> value while the first one doesn't.
> And by the way, the second one is impossible to do in java.
Yes. That's my point. Impossible in Java.
In use, here is how the first one looks:
x = 2;
foo(x);
// what is x? 2
and here is how the second one looks
x = 2;
foo(x);
// what is x? 5
I don't have any problem when reading the function; the problem is in reading the
higher-level code that uses the function. By just reading the higher level code, one
has no idea if the value of x is changed by foo or not.
>
>
> :> - No templates:
>
> : Again, a very good thing.
>
> Why? I said why it's a bad thing. You didn't say why it would be a good
> thing.
> I have heard all those typical answers hundreds of times. I would like to
> understand them some time.
OK. I'm trying to help you understand the mindset. Remember this thread was on why
Java
programmers wouldn't be happy working in a C++ area. To a non-programmer it might seem
very similar, but the devil is in the details.
A lot of it boils down to the point you made: the "let's limit what a professional
programmer can do in order to prevent beginners from doing something wrong" effect.
That's close, but not quite what I was saying. I had said "expert user", not
"professional programmer". I have no problem with giving power to professional
programmers. The problem is that a huge number of them (perhaps 80-90%) are not quite
'expert' or 'guru'. And these are the programmers who may either initially create
software or come behind later to maintain software. The experts can handle the extra
stuff no problem, it's the other 80-90% of professionals who are the problem. (BTW,
I'm
taking that as a rough estimate from some studies in Code Complete, but as I have my
copy at work I can't cite specifics at the moment.)
Especially when it comes time to get the next version of your product out, and it's
been a year since the last one was touched, and the people who did that are no longer
with the company...
Regarding operator overloading, yes I think it has it's place in C++. But I have seen
it used in actual production code in ways that have actually caused real bugs and
problems for maintenance. If everyone who ever works at a company is in that small
percentage of programmers who are an order of mangnatude more productive, then good.
If
not...
Some of the problem comes from C++'s long history, over 20 years of accumulated
baggage, etc. More and more had been added on to C while keeping all (or most) of the
old way of C around also. thus templates were brought in to address some of the
initial
deficiencies of C++. Or rather to add more capabilities than the earlier C++.
If you drop the procedural approach and come at Java with a stronger OO design, then
it
is very nice. If not... it's doable, but not always pretty. As opposed to C++ where
one
can always drop back to doing basic C things and all is happy-happy.
Another thing that Java does differently is that usually you can only get a single
value returned from a method. Usually return status codes are no longer used since
exceptions can be thrown instead (another good thing that's in C++ also). Of course,
internal state of objects might get changed, but then if you need to access those
state
values you can either just access an exposed member, or call an accessor method.
Probably the main thing about Java and the Java mindset is that if applied to the
proper problems (key point - 'proper') good developers can come up with solid
solutions
in a much shorter timespan. Plus, if any decent effort is made, the later maintenance
of the program will be much less costly. Things like not having macros also help in
this area.
Interfaces in Java solve many of the problems that templates were created to address.
That's probably why I consider them not as necesary. However, there is some ongoing
debate about true generics being needed in Java.
And then there's probably a good way to sum things up. C++ is a language. Java is a
platform. C++ has done a lot to improve over C in this regard, but there are still
some
problems. Three years ago when I moved from doing occasional Java at work I was
editing
on a Windows box, building on Suns, and running on Linux. A year ago when I finally
got
Linux installed here at home, I was staying in it full time even though I was using NT
at work, and was often working from home.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > Yes, that would work...as long as you put everything at the start of the
> > scene. Which isn't always possible, with includes and macros for example.
>
> Here is a model which might be closer to a solution:
>
> One limitation of POV script is that it's not possible to
> pass values into it without editing the source. There is
> no C-style main(int argc,char *argv[]) and no way to
> read environment variables. In this sense, a pov scene
> is a void main(void) except that you can control the
> clock timer variable.
I see this and the following but as a dumb question, why? What
does it buy the user other than a few lines of source code in
some unusual scene? A development cycle shortening?
In my more interesting scenes again, the time to render exceeds
the time to think about. The time to think about exceeds the time
to type it in. In both cases replace exceeds with greatly
exceeds.
I can see folks interested in more familiar syntax but if you
are stuck with only one syntax, pretty soon you are going to be
stuck with only one language and then where will you be?
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> Speaking of errors something else that will have to be address is
> error handling of erroneous input. If the user_prompt is looking for
> a specific input and a wrong value is entered there needs to be
> some form of error trapping to get the right value from the user.
That is an old one and should have a library for it some place.
An error drops you back to the editor at the right line with the
error highlighted. But usually POV does the best it can with what
it has and doesn't get to excited over the issue.
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> Glen Berry wrote:
> > Hmmm... if a particular programmer could approve of for-loops, could
> > JPEG support happen in the future?
> The POV-Team has already officially announced that jpeg input support has
> been added to POV-Ray v3.5. Jpeg out will not be added or supported.
How could it be an output as it has to be a conversion from an
existing normal output to a compressed output and thus cannot be
written directly.
Jpeg input will give some interesting effects to height fields.
It can be tried right now by saving one to jpg with lowest and
highest resolution, converting back to something currently
readable and comparing. Smooth it.
There are so many mountains and so few rolling hills.
--
<A href="http://www.giwersworld.org">A free internet for a free
people.</a>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <38cd0388$1@news.povray.org>, "Johannes Hubert"
> <jht### [at] mailacom> wrote:
>
> > Just don't reinvent the wheel!
>
> What if I want to learn how to make wheels? And what if I can't find a
> wheel that fits?
Maybe you have not looked around? There are enough free ones out
there that I could make an 18-wheeler and have spares. Ain't a
dime's worth of difference among them in my never humble opinion.
> > Parsing and compiling is a well researched subject in computer science.
> > I recommend that you take a look at lex/yacc for example
> While those might be good for people who want rapid development, I am
> not sure they would apply in my case. I do think there is a set of
> Bison/Flex(or is it Flexx?) tools for CodeWarrior, but I have never used
> that kind of thing.
Not quite the same thing. In the days of patchpanels it was
considered a daunting task just to parse words (trailing
whitespace) properly. That turned out to be simple. Praise the
lord and pass the card deck.
Converting infix to postfix notation to machine language turned
out to be easy also. Doing so efficiently turned out to be a
bitch and half. How many passes does your compiler make?
I do not know about POV but it appears to make exactly one pass
before execution.
> > One of the standard books is: "The Theory and Practice of Compiler
> > Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
> > covers everything you need...
> > (you probably have it already :)
>
> Actually, I don't have it. All the books I have are a couple standard
> "learn C++" books:
> Teach Yourself C++ in 21 Days(got this when I took C++ at school)
> Programming with C++
> Rescued by C++
> C++ Primer Plus(this one is actually my favorite, I rarely use the
> others)
> And a couple C and Java books, and one Pascal book(also from a class I
> took at school).
That is something else entirely. The theory and practice of
compilers vice parsers (which are more like tokenizers in BASIC)
is something else entirely. Think about it. Everything you write
has to get to machine code instructions.
If there is anything I would like to see on POV it is a three or
four pass optimizing compiler against this single pass parser.
But then there are not enough gurus interested in this to do
that.
> I don't have any books on algorithms or programming theory. I don't have
> much money to buy them either... :-(
No library?
--
<A href="http://www.giwersworld.org">A free internet for a free
people.</a>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz <jon### [at] geocitiescom> wrote:
: and here is how the second one looks
: x = 2;
: foo(x);
: // what is x? 5
Java is not any better:
Complex x(2,0);
foo(x);
// Did x change?
: Regarding operator overloading, yes I think it has it's place in C++. But I have
seen
: it used in actual production code in ways that have actually caused real bugs and
: problems for maintenance. If everyone who ever works at a company is in that small
: percentage of programmers who are an order of mangnatude more productive, then good.
If
: not...
Again, if we remove everything dangerous, no matter how useful, what do
we have?
Nothing, I think. Everything can be used wrong.
: Another thing that Java does differently is that usually you can only get a single
: value returned from a method.
How do you get more than one value returned from a method in C++?
Of course you can get a class (or struct) instance, but it's still just one
value.
I'm not saying that Java is a bad language. It's safer and often more
pleasant to look at than C++. It's harder to make bad programming with it
(although possible).
I just don't like the limits it imposes. Sorry :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Giwer wrote:
> > One limitation of POV script is that it's not possible to
> > pass values into it without editing the source.
>
> I see this and the following but as a dumb question, why?
Hmmm... This is like saying that command line tools
should have no prompts.
Perhaps because it would be nice to call POV from
another app without going to the trouble of generating
POV script?
Howabout:
C:\> povray +w100 +h20 +Ibanner.pov +DTEXT="Click Here!"
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > The POV-Team has already officially announced that jpeg input support has
> > been added to POV-Ray v3.5. Jpeg out will not be added or supported.
Anyone know the reasoning for this?
Not even as a compile-time config option?
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hmmm... This is like saying that command line tools
> should have no prompts.
DOH! Let's try again...
Hmmm... This is like saying that command line tools
should have no command line options.
> Perhaps because it would be nice to call POV from
> another app without going to the trouble of generating
> POV script?
>
> Howabout:
> C:\> povray +w100 +h20 +Ibanner.pov +DTEXT="Click Here!"
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 16 Mar 2000 22:44:56 +1100, Nigel Stewart wrote:
>
>> > The POV-Team has already officially announced that jpeg input support has
>> > been added to POV-Ray v3.5. Jpeg out will not be added or supported.
>
> Anyone know the reasoning for this?
The main reasoning is, we didn't want the support nightmare that comes from
someone (tens of thousands of someones) discovering that a lossy format isn't
the best option for primary output.
> Not even as a compile-time config option?
No comment. :)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
