[gameprogrammer] Re: What do I need to download develop a client/server java applet?

On Fri, 22 Jul 2005 12:32:12 -0500, "Fernando Arturo Gómez Flores"
<fernando.gomez@xxxxxxxxxxxxxxx> said:
> Yes, exception handling is a cool feature in Java, as I said. And I 
> think that unless you don't know how to fully use exceptions in C++, 
> they're not that bad. Consider the following example in C++:
> 
> class SomeException;
> class AnotherException;
> 
> void foo() throw(SomeException)
> {
>     throw AnotherException();
> }
> 
> This will cause a compile-time error if the compiler follows the
> standard.

Ah.  No, it won't.  The standard doesn't say how this should work.  You
need to read this page:

http://www.gotw.ca/publications/mill22.htm

The conclusion that (the highly respected) Herb Sutter comes to in this
article is 'Never write an exception specification'.  In general
exception specifications may not be checked at compile-time; which
reduces them to 'glorified comments' and makes them nearly useless.

> You can specify if a method or function will throw an exception. Of
> course, Java's support is stronger, but it is not a 'nightmare'. 

Well, Java guarantees that exceptions are checked at compile time, which
makes them much nicer.

> Indeed Java also has runtime exceptions and those are not checked by 
> the compiler...

Well, yeah, just like array bounds are not checked by the compiler in
C/C++.  You can shoot yourself in the foot if you must.

> > You can say what you like about the quality of Swing or JavaBeans or
> > whatever, but they're standard with the language, so it's far more
> > likely that people know how they work.
> >
> > **********
> > Yet you are restricted and cannot use the full OS capabilities and
> > they are slow.
> 
> Which OS are you talking about?  Windows?  Linux?  Solaris?  Mac?  A
> browser?
> ***************
> Both Windows and Linux. I haven tested it my self neither with Solaris
> nor Mac.

I'm not so much talking about which capabilities you can use on which
platform, but the fact that you'd rather not have to know about the
'full capabilities' and corner cases of each platform.

> The cross-platform goal of Java, while not 100% successful,
> does hold pretty well for a large class of programs.  I really, _really_
> don't want to have to implement my app four times, once for our Windows
> customers, once for our Linux customers, once for our Solaris customers
> and once for our Mac customers.  That's just _not_ an option; not to
> mention the ongoing maintenance costs.  If we write it in Java, and have
> automated tests that run every night on each OS, we're just about four
> times as productive as we would be in C++.
> ***************
> Alright, cross platform development is nice (at what cost however?).

Let me tell you, it's a _far_ bigger cost for us to _not_ have cross
platform applications, than the cost of programming in a possibly
inferior language.

> Still, you also can do C++ cross platform development by following the
> standard. The only differences are when trying to use a GUI, in which 
> case you'll need specific libraries or APIs. Yet there are many GUI 
> libraries --wxWidgets, GTK or Qt-- that allow cross platform GUI 
> development. If someone has to rewrite the entire program to port from
> Linux to Windows, is because a bad design.

Oh, yeah, of course.  But it's more likely that that will happen in C++
than in Java, in my experience, even using a cross-platform widget
library.  Not only may the GUI stuff differ, but threading models may
differ.  Filesystem access may differ.  These are essentially bypassed
when using Java.

> I work usually to Windows. However, my programs I like to port them to
> Linux. I create DLLs /SharedObjects with the program's logic. With 
> some templates and policies I created a database-independent data 
> access engine. And in the executable I implement the GUI things. Since
> I don't actually need to port my apps to Linux, I work with WTL in 
> Windows and GTK in Linux. I personally rewrite that part (mostly 
> because I'm still learning GTK/GNOME under Linux).

Well, if that works for you, that's good.  Sounds pretty inefficient to
me, though.  If I'm being paid by the business to develop the GUI,
they'd rather not pay me again to completely rewrite the thing for each
new platform.

(Let me also note that 'database-independent data access engine' is
essentially an impossible goal, I'm told by our DB guys.  Differences in
SQL dialects and data access efficiency across different databases mean
that, if you want acceptable performance for a big app, you have to
specialise for the database you're using.  There's just no other
option.)
> No it doesn't.  It makes them less productive.  'Why doesn't this 
> work? I'm sure that's the way to do it?  Oh, that's right, that's Tk, 
> not Qt. Oh well, there goes a day.'
> ***************
> The programmer in your example is then an idiot. Who will confuse 
> APIs? Imagine: "Uh, why CreateFile does not work on Linux? Ah! Because
> that's Windows' API". That's absurd. If such a programmer exists, s/he
> deserves to be expelled from the computer science community.

Confuse APIs?  That's a fairly obvious mistake which takes about 3
seconds to catch.  What I'm talking about is similar APIs (as GUI
libraries are wont to be) with slightly different semantics.  Like 'why
is this so slow?  Oh, that's right, this library calls recalculateBounds
every time it calls redraw, while I thought we were using the other one
which doesn't'.  You can't tell me you've never run into this sort of
problem; usually affecting performance rather than correctness.

> > It's really a shame that Java programmers don't know what happens
> > between the JVM level and OS level.
> 
> Yes, it is.  But it's not a shame that they don't _need_ to know it.
> ***************
> Yes they need! Say there's a new database whose API has been wrote in 
> C. You wan't to make a Java library implementation to access such data
> engine through JDBC. You need to use "native", right? And native code 
> is C/C++. Then you're doomed if you don't know how does the OS 
> works...

I imagine if you're writing your app in Java, you use a database that
supports JDBC, which yours obviously doesn't.  Or you get someone who
knows this stuff to write the JDBC driver.

> Taking that argument further, it's a shame that C++ programmers don't
> know what happens between the OS level and the CPU level.  Why aren't 
> we all just using assembly?  The whole point of moving to higher level
> languages is that we _can_ abstract away details.
> ***************
> Of course there is a difference, because Java and C++ are at the same
> language level, whereas Assembly and C++ are from different levels.

This is probably a definition problem, then.  I don't think Java and C++
_are_ at quite the same 'level'.  Java provides more high-level
abstractions than C++ - therefore it's a higher-level language, for
mine.

> Despite, assembly can be embedded within C/C++ code with no problemo, 
> whereas Java uses a restrictive version of C/C++.

Well, it's a higher level language.  And you can only use assembly in
C/C++ if you know a fair bit about the memory layout and control flow.

> I don't need to know shader programming to throw a dialog up on the
> screen.  Why should I have to?  I just tell the GUI kit that I want a
> dialog, and other people take care of drawing the pixels.
> ***************
> For such simple things, in C++ you don't. Use WTL or MFC, and they all
> wrap the functionality for you.

Um.  Yeah.  That was my point, I think.  Why should you need to have
in-depth knowledge of the system to do easy stuff?

> Hang on, surely a policy class is just a compile-time version of a
> Strategy?  The only difference between the two is that the
> compile-time version will have larger code size and (possibly) more 
> effective execution.  There's absolutely _no_ reason that you can't 
> implement this in Java.
> ***************
> Indeed. Yet in Java you would have to code more.

I don't agree with this.

> Whereas in Java, the easiest style to use, for a beginner, is the
> clearest one.  So people are taught to write clean code.  So code 
> tends to be easier to understand.
> ***************
> A begginer for sure is not going to use templates. Without templates, 
> C++ is as clean as Java, that's up to the programmer's coding style.

Yeah, I don't agree with this either.  If _only_ because of having to do
memory management all yourself, C++ is less clean that Java.

> Yep. Imagine a class that needs to have a a variable number of 
> template parameters. Then with some imagination, you can create a 
> template whose template parameter is a list of template parameters. 

OK, sorry, I know what a 'template parameter list' is.  But I don't see
how that's a design pattern.  Isn't it just a particular way of solving
a problem?  Though I've never used a template parameter list, so can't
think of a problem in which it comes in handy.

> This is really useful when creating functors (another design patter 
> Java can't follow because operator overloading is not allowed).

There are plenty of arguments that operator overloading causes more
problems than it solves.  A function named operator() is _exactly_
equivalent to a function with any other name, say Execute().  Why is
this a problem?

> Finally, I think this is a useless discussion. In the end, you'll be
> programming with Java and I'll do it with C++. So there's no point I
> think.

Well, that's not quite true.  I'll be programming in C, in C++, in Java,
in Python, in Perl, in Lisp, in shell scripts, etc.  I tend to use the
language that seems right for the job at hand.  I don't think it's
useful to use one language for every problem; how much more effort is it
to write a parser in C++ than in Lisp?

But, as you say, each to their own.

Dave.
-- 
  Dave Slutzkin
  Melbourne, Australia
  daveslutzkin@xxxxxxxxxxx



---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: