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

Hi,

On Thu, 21 Jul 2005 18:56:14 -0500, "Fernando Arturo Gómez Flores"
<fernando.gomez@xxxxxxxxxxxxxxx> said:
> It's much easier to get decent Java programs than it is to get decent
> C++ programs, because, in my experience, decent C++ programmers are
> rare while decent Java programmers are less rare.  C++ is undoubtedly
> a harder language, and so it's less likely that your average
> programmer's going to be good at it.
>
> **********
> Of course, that's the problemo IMHO. Rather than making good
> programmers, Colleges and Universities nowadays teaches weak
> languages with weak techniques.

<snip>

> My point is simple. A weak programming language ("weak" understood as
> explained above) make weak programmers.

I'm not sure that's true.  I think that if someone's going to be a good
programmer, they'll be good no matter what language they're using.  I've
taught a bit of programming, and the majority of people just don't
appear to have the aptitude for 'good' programming.  They're OK at
following instructions and keeping with conventions, but they don't have
the innate sense of style or 'niceness' that causes a good programmer to
write good programs; regardless of the language.
***************
Try to make a VB programmer a good programmer... you shall fail, you cannot
explain a VB student OOP since VB itself does not implement OOP concepts.
***************

These people (and a lot of people I've worked with are like this) can do
a lot less damage in Java than in C++.

> Personally, I really don't like Java, because its features are
> unvaluable compared to the lack of C++ features. I admire some things
> of Java, like its security (you know, that "throws" keyword or
> try/catch/finally block; or the synchronization among methods), but
> programming strong programs can be a headache, specially if
> you try to introduce modern techniques.

I would argue that exceptions are modern techniques.  Exceptions in C++
are effectively useless, because exception specifications have horrible,
horrible semantics.  This means that no compile-time checking of
exceptions can be done, so every exception is effectively a run-time
exception.  This, in my experience, is a maintenance nightmare.  In
Java, however, you get nice compile-time checking and exceptions just
_work_.  And you can see the benefits in Java code.
***************
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.
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'. Indeed Java also
has runtime exceptions and those are not checked by the compiler...

***************

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

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

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

> 'I know MFC, Qt, wxWidgets, Gnome, KDE, Motif and Tk.'
> 'Oh, that's a shame, we're using gtk+.  Seeya.'
>
> **********
> As I said, it makes programmers stronger.

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

Strong programmers will learn on their own;
weak programmers rarely see that option, honestly.
***************
I agree.
***************


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

Everyone should know as much as possible about the system (or systems)
they're writing for.  But if you're writing a GUI for a piece of
bookkeeping software, why do you need to know much about how the
concurrency is actually implemented?  You just need to know enough so
that you can make your abstraction work.
***************
The problem is not when you do trivial or simple progams. The problem comes
when medium or big programs are needed.
***************

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. Despite,
assembly can be embedded within C/C++ code with no problemo, whereas Java
uses a restrictive version of C/C++.
***************

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

> Design patterns are all very well, but they're not very clear in C++
> **********
> I wouldn't see a problem in, for example, singleton classes in C++...

A singleton is the simplest design pattern.  But my argument wasn't
great; design patterns can be obfuscated in any language if the writer
doesn't realise what they're actually doing.
***************
Alright, I agree.
***************

> Furthermore, you can have, say, a SingletonHolder template class that
> can be employed with different policies and with every "client".
> Policies is something that you cannot have,

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

> since it involves generic programming and Java does not support
> generic programming (and don't say that Java does generic programming
> through that 'object' thing since this is not true).

I'm a big fan of generic programming, and no, Java doesn't support it.

But generic programming is a good example of C++ programmers sacrificing
code clarity for the sake of efficiency.  This is how C++ programmers
are usually taught to think.  I believe that code shouldn't need
comments, usually, because it should be self-explanatory.  Well,
hard-core template usage is about as far from that as it gets.  Not that
it doesn't have its place.
***************
Yes, I must agree that template syntax is horrible (perhaps C#'s generics on
C# 2.0 is better?). And this lack of code clarity makes students or even
more experienced programmers to have head aches.
***************

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

> Most design patters were made thinking in C++, and even it they
> weren't, they can be easily ported to C++.

Well, most design patterns were made thinking in objects.  The language
most commonly used was Smalltalk.  But I agree that they can be easily
ported to C++.

> Viceversa is impossible (try to create a template parameter list...).

I'm not sure I understand what you're saying, but is that a design
pattern?
***************
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. This is really useful
when creating functors (another design patter Java can't follow because
operator overloading is not allowed). See Andrei Alexandrescu's "Modern C++
Design" or check out www.moderncppdesign.com for more information.
***************

> Whereas there are less options in Java, so it's easier to start
> writing code in someone else's project.
> **********
> The problemo is that those "less options" truly are needed for
> implementing powerful and modern applications with less coding.

Nah, that's bullshit.  I don't agree with 'powerful' or 'modern' or
'less coding'.  The only place where (in the hands of a skilled
programmer) C++ has a true advantage over Java is in efficiency.  Java
is more modern (better support for exceptions and concurrency, for a
start), takes less code (more wide-ranging libraries mean on average
each line of code can do more), and is as powerful for a very large
subset of applications.  The only applications for which C++ is more
'powerful' (whatever our definition of that word is) is for hard-core
performance sensitive things.
***************
Well, C++ has richer semanthics --which OOP is all about--. By having richer
semanthics, design becomes more complete and with more options, which causes
a project to have less failures. I don't think that's bullshit, in the end
OOP was created to solve this problems.
***************

> I know it's cool to hate Java, but all I'm saying is don't dismiss it
> simply for that reason.
>
> **********
> Indeed it is not cool, rather it is a shame. Java lost the opportunity
> to become the most powerful, modern and complete programming
> environment. 10 years later C++ is the most used OOP language
> (according to the OMG's statistics). C# on the other hand will
> probably bury Java. Simpler than Java, yet almost as powerful as C++,
> with a modern platform, it won't take more than three or four years
> to end with Java's life. Pity.

Haven't used C#, so I can't comment, but I don't believe that yet.
***************
Well, perhaps you should give it a try. I'm sure you'll like it. It has most
of the features of Java, some with the same name (i.e. finally clause), some
with different names (i.e. use base rather than super). And they implemented
must of the C++ features that Java didn't (i.e. you can inherit a class and
make the public inherited methods public, protected or private whereas in
Java all are public). You can even use pointers with the so-called unsafe
code. The only thing that perhaps you'll find unconfortable is that the
throws thing is implemented as in C++, not as in Java, and thus is not as
powerful as in Java. But it is a very fancy and complete language.
***************

> Still, you know what Java is good for? Smartphone games. I've created
> a couple of games for my cell phone, it was really funny and easy to
> do.

Why didn't you do that in C++?  Didn't you want to know what was going
on between the JVM level and the OS level?
***************
Of course, and that's why I'm studyin my Nokia smartphone behaviour at
assembly level. The problem is that I haven't found yet a compiler for C or
C++ and an OpenGL-like library.
***************

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.

Regards,
Fernando.




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

Other related posts: