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

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.

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.

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

> '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.'  Strong programmers will learn on their own;
weak programmers rarely see that option, honestly.

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

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.

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.

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.

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

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

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

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.

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

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

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

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

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



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

Other related posts: