Re: [Tapioca-devel] Thoughts on languages, toolkits, etc.

[Richard F. <rj...@fi...>]

On Tue, 31 Jul 2001, The Unknown Hacker wrote:

> I'd like to make the server side be in a high level language (which C++ isn't).
> Java is a possibility -- but it takes forever and a half to start up a Java
> program. That's what happens from carrying around 40mb of bloated runtime
> environment.

I agree about the run-time start-up problem for Java.  I've been playing
around a bit with Forte, and I can't believe how long it takes to start
the damn thing on my dual-PIII RAID box.

However, I have grave concerns about switching languages here.  Call me
blasphemous, but I would rather do the whole thing in C++ than a
less-capable scripting language.  Let me explain:

Granted, Python saved us a lot of time in developing BRU-Pro, due to being
less verbose, and having a rich set of data management classes.  But it
also cost us some time, due to a lack of a decent debugging environment
(which is now resolved), dynamic names (how many times did the program
fail at run-time due to a name error? or because we forgot an import), and
dynamic types (1 != "1", anybody?).

To me, Java is a bit more verbose than Python, but brings with it static
types, compiler checks, and excellent development and debugging tools.
This is a very good thing!

I am really concerned about integrating a large portion of this thing in a
language that doesn't have a large user base, static types, and a solid
debugging environment.  Ruby seems to fail on all 3 points.

So, if we can't live with Java's startup time, I think our only real
alternative is to do it in pure C++.  But that doesn't mean we need to
abandon Java however.

The other benefit of Java is that the syntax is close enough to C++ that
we can prototype things in Java to get them running, and let others who
come later convert modules into C++.  This would be good way to let new
developers get their feet wet in the project.  I can see a time where
there are a lot of Java modules, but not a Java bytecode to be found.

On the wxWindows side, I would be willing to do our entire interface
(i.e., the client) in C++ with wxWindows.  It is missing a couple of
useful controls, but that will probably be resolved by the wxUniversal
project.  Note that C++ RPC from Windows to Unix does work, with the
correct library.  QuincyStreet has a working RPC implementation from
Windows to Solaris, that I'm certain we could use.  And if we need more
than just RPC, we could always use CORBA.

In other news, I am close to getting my TCString class done, and a
document about internationalization.  There really isn't much to the
document, just saying here are the interfaces and defines for i18n, and
the actual implementation will be put off until later.

An interesting note is that the current GNU (as of gcc 3.0) stdc++ library
doesn't support wstring, wcout, wcerr, wfstream, etc.  It's a part of the
C++ spec, but they haven't gotten that far yet.  Would be a good project
for me to get involved in, if I had time!!

I should have these things ready to upload by Saturday.

-- 
Richard Fish, Unix/Linux Software Engineer, rj...@fi...