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

[Eric L. G. <er...@ba...>]

On Wed, 1 Aug 2001, Richard Fish wrote:
> 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:

"less-capable"? Are we talking Python? or Ruby? (The two are virtually
the same language, aside from strings and integers being objects in
Ruby and built-in classes being subclassable in Ruby, and some syntax
differences that aren't particularly difficult to learn).

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

My concern is with getting something working in a reasonable amount of
time. I write about the same amount of code per day whether I'm
working in C++, Python, or Java. The C++ code, on the other hand,
takes far more lines of code -- about 90 lines in the case of that
block accept thingy to do something that can be done in a dozen lines
of Python/Ruby or in two dozen lines of Java. In addition, C++ is
prone to problems like memory leaks that are irritating.

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

You have obviously not debugged Java Server Pages :-).

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

Large user base: Ruby has one, but most of them don't speak English
:-).  Really, Ruby is so easy to learn (especially for Python
programmers -- have I mentioned how similar the two languages are?)
that it's not a problem.

Static types: We have a difference of opinion here. In my opinion,
strict static typing is the main reason C++ is so complex. I'll point
out that while Java variables do have a static type, this does not
apply to the contents of container objects. This is one reason why
using Java's container classes is so much simpler than C++'s. For
example, a Vector can hold a string for its first element, a class
instance for its second element, and an integer for its third
element. And yes, I've already run into a problem where I accidentally
stuck an integer into my Vector when I meant to put the string value
instead! Java doesn't have "templates" like C++, and my reaction to
that is "Thank God!". Java defines things like Vectors in terms of
references to things of type Object (the base type of all Java
classes), and you have to cast your data reference to/from type Object
to put it into/take it out of one of the Java container classes
(though in most cases that's done automatically for you). Like with
Python, data in Java lives as objects on the Heap, all that is in your
variables is a reference to the actual object (just like Python).
Have I mentioned that I like Java a whole lot better than I like C++?
:-).

As for solid debugging environment, you have to pay for one that works
for Java Server Pages. I frankly don't have any inclination to do so.
Debugging Java Server Pages is frankly almost identical to debugging
Python -- same problem with runtime errors when you try to compare 0 with
"0", for example (easy to do if you're pulling something out of a Hash or
Vector and you put it in there without first doing a string->int conversion
or vice-versa!).

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

Uhm, the problem was that certain things that would be better done in
Java cannot be done there because of the startup time. This does not
mean that the whole thing should (or *could*, for that matter) be written
in C++. In particular, C++ has the following problems that Java (and
high level languages in general) do not have:

1. Memory leaks.
2. Buffer overflows.
3. Machine dependence (Java, Ruby, etc. are pretty close to 'write once
 run anywhere', c++ is lots of use of GNU Autoconf on Unix platforms, and
 god only knows what on Windows),
4. Lack of an extensive class library (e.g. setting up a TCP server in
 Ruby or Python is a matter of instantiating a TCP server instance,
 in Java it's a few dozen lines of code instantiating a service
 object, whereas in C++, it's hundreds of lines of custom coding).

#2 is especially irritating, because it basically means that all C++
programs are security risks.

> 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

I have no problem with wxWindows if we choose not to use Java for the
server. If we do use Java for the server, it makes sense to use Java
for the interface too, using the SWING classes. These are widely
derided as being slow, but they do provide most modern functionality
(unlike the older AWT classes).

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

The problem with RPC/CORBA is that they were designed prior to the relaxing
of crypto exports, and thus are not as secure as they could/should be.
Java's built-in CORBA-like mechanism can be told to use SSL, and Java does
have an SSL implementation. Or Java is fast enough nowdays, with the JIT
runtimes that are now extant, that we could roll our own, but there should
be little need for that. We'll find out as we get closer to implementation
time there.

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

For internationalization, Java does internationalization naturally
(via doing everything as Unicode internally). I suggest that all C++
modules emit key/substitution value tuples rather than user-readable
messages, and let Java do the actual conversion to English (or
Japanese, or ...).

For example:

com.key_error:com.key_error.expired_key:34812a5|05|12|2001|15|35\n

could expand to:

Communications Key Error: Key 34812a5 expired on 05/12/2001.

And the

com.en.US.properties file has the following in it:

com.key_error=Communications Key Error
com.key_error.expired_key=Key ${0} expired on ${1}/${2}/${3}

And the

com.en.UK.properties file has the following in it:

com.key_error=Communications Key Error
com.key_error.expired_key=Key ${0} expired on ${2}/${1}/${3}

(Note different date format!).

The C++ programs thus don't need to know anything about how to emit
Japanese or Russian or whatever, they just emit the keys and parameters
that will be substituted using the Java localization features.

In any event: My frustration is with C++. The language is a bear. I
would not want to go down to C though, the STL classes are just too
darned useful. But I also would not want to be writing more C++ than
absolutely necessary. Hell, I would write the whole thing as shell
scripts calling 'awk', 'sed', 'md5sum', 'dd' and 'od' if I could get
away with it :-). (Laugh all you want, but did I tell you about the
guy I knew who wrote a compiler using shell, awk, and sed? Took forever
to compile anything, but it worked!).

Ruby is better than resorting to shell scripting, and is more readable
and maintainable than Perl. That was why I was interested in Ruby.
Especially when virtually the whole agent side could be implemented in
a couple hundred lines of Ruby, and I'm already past that in lines of
C++ without having a completed packet class yet :-}. But frustration with
C++ is certainly no reason to decide to do the whole project in C++!

-- 
Eric Lee Green         Web: http://www.badtux.org
  GnuPG public key at http://badtux.org/eric/eric.gpg
    Free Dmitry Sklyarov! [ http://www.eff.org ]