> And the point still stands that Java as a language isn't > in any way a step forward, and in many ways is a step > backwards.
If you compare Java with Lisp, then yes it is. If you're a C++ programmer, then you may see things differently. It could be that more programmers see Java as an alternative to C++ than as an alternative to anything else.
This thread is considering Java as a threat to Lisp, by being an alternative, but how realistic is that? If you're using Lisp, why change to Java? I suspect that more C++ programmers will have reasons to move to Java than Lisp programmers. In that sense, Java is a step _forward_, not backward. (Memetic lanscape, etc.)
There are some C++ programmers who won't use anything but C++. They appear to be looking at Java - and everything else - as a "poor person's C++". It looks to me like this is not that different to how some Lisp people look at other languages, as a "poor person's Lisp".
Was Java designed to replace Lisp? I don't think so. So why should we care about Java? Take care to avoid falling into the Peaceman trap. If you're doing something very different in Lisp to what most people are doing in Java, then where is the competition? Well, there's the competition of memes, but as I've said, I don't think that Java memes will hurt Lisp memes as much as they'll hurt C++ memes, or as much as C++ memes have (and may continue to) hurt Lisp.
Java is alreadty reshaping the memetic landscape, which could be why some C++ are trying so hard to trash Java. Curiously, they're using exactly the same arguments that they've used against Lisp, and those arguments failed to kill Lisp. We're _winning_!
So, I don't think that this is the time to behave like religious zealots and slag off Java just for not being Lisp. We can afford to be a little more pragmatic than that. 10 years from now, this may change, but by then there should be less BS spouted by C++ programmers. If we instead find that there's BS posted by _Java_ programmers, then we may have still moved forward. They'll have to use rather different tactics to their C++ cousins, to avoid shooting themselves.
Or perhaps I'm completely wrong, _everybody_ is a religious zealot, and the only rule is to fight, fight, fight? -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough "As you read this: Am I dead yet?" - Rudy Rucker Please note: my email address is gubbish
Mike Coffin <m...@Eng.Sun.COM> wrote in article <8p6iuwq0znn....@Eng.Sun.COM>...
>[snip an interesting observation re: Java not fitting pidgeon holes]
> - it allows completely statically typed programs > - it allows "mostly" statically typed programs that occassionally > cast objects to subtypes > - it allows "mostly" dynamically typed programs, where most data > structures contain Object and are dynamically cast into useful > types > - it allows "wildly dynamic" typing, where introspection is used to > figure out at run time which methods an object provides and call > them.
But does Java allow actual objects to change type, or allow new types to be invented at runtime?
On the dynamic typing scale, perhaps these items are good indicators of a language with full-blown dynamic typing, as opposed to those with some type flexibility features.
> > Per Bothner <both...@cygnus.com> wrote in article > > <5u2213$fm...@rtl.cygnus.com>...
> > >[snip]
> > > Well, Java is a statically-typed language, and it does not have > > > procedure types, so the type of (the instances of) the inner class > > > needs to be something useful. Using an interface is one way; using > > > inheritance is another.
> > You know, I earlier made the converse claim (i.e., that Lisp had dynamic > > typing) in reply to the message that originally started this incarnation of the > > "Will Java Kill Lisp?" thread. I cited said dynamism as a good reason to use > > Lisp over Java. Yet, I noticed that in a later message, a reply to my > > assertion was lumped into a group retort by our friend from NASA, to whit:
> > "Java has dynamic typing"
> > I realize that Java has an object reference type that can refer to an object of > > any type, but I didn't think that this exactly qualified it as > > dynamically-typed language. Is this some mixup on our friend's part between the > > meanings of strongly-typed vs statically-typed, or am I just losing whatever > > clarity I may have once possessed?
> I think Java if pretty flexible about typing: it doesn't really fall > neatly into the usual pigeon holes:
> - it allows completely statically typed programs > - it allows "mostly" statically typed programs that occassionally > cast objects to subtypes > - it allows "mostly" dynamically typed programs, where most data > structures contain Object and are dynamically cast into useful > types > - it allows "wildly dynamic" typing, where introspection is used to > figure out at run time which methods an object provides and call > them.
> About the only pigeon hole it really fits in is "strongly typed".
> But does Java allow actual objects to change type,
No.
> or allow new types to be invented at runtime?
Yes, but they don't make it easy.
See java.lang.ClassLoader#defineClass(java.lang.String, byte[], int, int).
> On the dynamic typing scale, perhaps these items are good indicators of a > language with full-blown dynamic typing, as opposed to those with some type > flexibility features.
> > > Java has the equivalent of closures, but in an object-oriented > > > form. They seems to be as powerful as closures, though one > > > could argue the pragmatics (syntax etc) are more cumbersome.
I always have to laugh when somebody says that putting wrapper classes around functions is more "object-oriented" than passing the function itself. In a real OO language, functions are objects, just like everything else.
* Mike Coffin | Now, Scheme is one of my favorite languages. And I don't claim any | universal significance to any of the reasons stated above: it's just one | project. But the practical arguments for Java in this project are pretty | overwhelming.
how tolerant would Sun Microsystems, Inc, be of a project that elected _not_ to use Java at this time? how tolerant would Sun be of excellent reasons not to use Java presented by its own people?
#\Erik -- 404 You're better off without that file. Trust me.
> Now, Scheme is one of my favorite languages. And I don't claim any > universal significance to any of the reasons stated above: it's just > one project. But the practical arguments for Java in this project are > pretty overwhelming.
I regret that this sounds painfully familiar. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough "As you read this: Am I dead yet?" - Rudy Rucker Please note: my email address is gubbish
e> How tolerant would Sun be of excellent reasons not to use Java e> presented by its own people?
Given that the practical alternatives to Java for real projects are C and C++, the number of excellent reasons not to use Java is already small for many purposes, and shrinking fairly rapidly.
People don't have religion about Java at Sun, though; I have seen a few successful instances where a case was made for Java being an inappropriate language in which to implement a project.
I used to be the lead on the project Mike Coffin now leads. About 18 months ago, I gave some serious thought to reimplementing the entire project in either Scheme or Common Lisp and sold the appropriate managers on this idea. When Java 1.1 came out and it became clear that it would suffice for our needs, I ditched the Lisp idea pretty quickly, for all the reasons Mike mentions.
Of those reasons, by far the most significant in my book are that it is very difficult to find talented Lisp programmers, and it is also difficult to find good commercial Lisp implementations that look like they'll still be alive and supported a few years from now.
Bryan O'Sullivan <b...@serpentine.com> writes: > m> - We'd like to avoiding type errors in the extension code. Scheme > m> is dynamically typed, so most errors don't show up until run > m> time.
> Unfortunately, the absence of parameterised classes in Java makes this > non-trivial. I have some enthusiasm for the work Phil Wadler and > Martin Odersky have done on Pizza, but the syntactic decisions they > made and the sugar they added are pretty heinous.
I definitely agree that it would be far better if Java had parameterized classes (assuming they were done right). Still, some compile-time type checking is far better than none.
Erik Naggum <cle...@naggum.no> writes: > * Mike Coffin > | Now, Scheme is one of my favorite languages. And I don't claim any > | universal significance to any of the reasons stated above: it's just one > | project. But the practical arguments for Java in this project are pretty > | overwhelming.
> how tolerant would Sun Microsystems, Inc, be of a project that elected > _not_ to use Java at this time? how tolerant would Sun be of excellent > reasons not to use Java presented by its own people?
I couldn't say; we didn't try. I can't speak for others, but *I* didn't sense any pressure to use any particular language.
Bryan O'Sullivan wrote: > Unfortunately, the absence of parameterised classes in Java > makes this non-trivial. I have some enthusiasm for the work > Phil Wadler and Martin Odersky have done on Pizza, but the > syntactic decisions they made and the sugar they added are > pretty heinous.
In article <34077FBB.4...@infinet.com>, Bruce Tobin <bto...@infinet.com> wrote:
>Somebody [i.e. me, Per Bothner] wrote: > > Java has the equivalent of closures, but in an object-oriented > > form. They seems to be as powerful as closures, though one > > could argue the pragmatics (syntax etc) are more cumbersome. >I always have to laugh
"Laugh while you can, monkey-boy."
>when somebody says that putting wrapper classes >around functions is more "object-oriented" than passing the function >itself.
Who says that? I certainly didn't.
> In a real OO language, functions are objects, just like everything else.
Wrong. In *some* real OO languages, functions are objects. -- --Per Bothner Cygnus Solutions both...@cygnus.com http://www.cygnus.com/~bothner
In article <87lo1jy4cq....@serpentine.com> Bryan O'Sullivan <b...@serpentine.com> writes: > Given that the practical alternatives to Java for real projects are C > and C++,
I don't see this as factual, though it does seem to be the typical perception. Certainly Ada95 is a completely viable and practical alternative (even with full support for JVM, RMI, CORBA, etc.) IMO (and more to the point, IME) it is cleary preferable to the three listed, though I can see how you might claim that "even so - it is not 'good enough'" (if coming from a Lisp perspective).
> Of those reasons, by far the most significant in my book are that it > is very difficult to find talented Lisp programmers, and it is also > difficult to find good commercial Lisp implementations that look like > they'll still be alive and supported a few years from now.
The problem with this (admittedly very widespread view) is that it is simply self fulfilling prophesy. Just think if a reasonable percentage of these people just decided that they _were_ going to use CL. That very action would begin to eliminate in principle this perceived problem.
/Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari
Far from it; it's a grab bag of weird and inconsistent giblets, ears, and toes from other languages. Some of the giblets represent reasonable choices, and work well enough; others are not, and don't work.
- The syntax Pizza uses for declaring parameterised interfaces and classes leads to ambiguous parses. Consider:
interface Foo<Bar<T>> { // is that a right shift above? public interface Baz<Blat<Bong<Z>>> { // what about the sign-extended shift here? } }
- The use of the word "fun" for anonymous functions comes straight from ML.
- The use of "->" to denote the return type of a function comes from any number of functional languages, and doesn't fit with any of Java's syntax. What's wrong with the usual notation? Regardless of whether you use the standard Java notation or this icky special casing, the compiler has to do a lot of lookahead to figure out what is going on.
It's also worth noting that the current syntax is misleading unless you are more likely to be coming from an ML or Haskell background than one of C or C++ (which is entirely unlikely for most of the world), while at least the rest of Java's syntax is not going to surprise C or C++ programmers.
- Pizza overloads the "case" keyword so that it no longer indicates simply a particular choice in a switch statement, but also a declaration of a symbolic atom. Oh, and you get to stick it in front of a constructor declaration in one special case, too.
- The language permits casts between primitive types and the classes that represent them. This is implicit magic that you don't see much of in the rest of the Java language.
- Special-cased syntactic sugar for algebraic classes with a single constructor is ugly and inconsistent with the usual Java thinking, because Java provides very few redundant language-level mechanisms for getting things done, and those that exist are well-chosen.
From where I'm sitting, it looks like the Pizza authors took the features they wanted from other languages with the syntax they already had, and simply grafted them straight onto Java without much thought as to whether the notation fitted cleanly.
I particularly object to the syntactic choices that will confuse C and C++ programmers, and also to the one-time special syntactic cases and the shoehorning of new meanings into old keywords.
I thought C++ and Perl already gave us some pretty clear indications that throwing random syntactic crud at a language in the hope that some of it will stick is, shall we say, not quite the best way to produce something that people will find either particularly easy to learn in the short term, or memorable over a longer period of time.
b> Given that the practical alternatives to Java for real projects are b> C and C++, [...]
j> I don't see this as factual, though it does seem to be the typical j> perception.
Sure it's factual. If I had my druthers, I'd write my code in Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple of considerations I have to deal with that prevent me from doing this:
- I don't want to restrict the set of engineers I can hire who can start working on my project without having to learn a new language, along with possibly a new way of thinking. It's already quite hard enough to hire smart people.
- I don't want to have to worry about whether there's a compiler and runtime environment available for some random platform I'll need to worry about two years from now, and I don't want to worry about whether the compiler vendor is going to disappear because nobody cares about their products.
If these don't seem like significant problems, that's great. I'm very happy for you.
j> Certainly Ada95 is a completely viable and practical alternative
The only thing I much care for about Ada is that its metastasis has now been outpaced by that of C++.
<b...@serpentine.com> wrote: > b> Given that the practical alternatives to Java for real projects are > b> C and C++, [...]
> j> I don't see this as factual, though it does seem to be the typical > j> perception.
> Sure it's factual. If I had my druthers, I'd write my code in > Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple > of considerations I have to deal with that prevent me from doing this:
> - I don't want to restrict the set of engineers I can hire who can ...deleted
> - I don't want to have to worry about whether there's a compiler and > runtime environment available for some random platform I'll need to
...deleted
Let us not forget what Shaw said about resonable and unresonable people. By beeing resonable one will never get what one wants.
In article <87d8mtx8s3....@serpentine.com>, Bryan O'Sullivan
<b...@serpentine.com> wrote: >- I don't want to restrict the set of engineers I can hire who can > start working on my project without having to learn a new language, > along with possibly a new way of thinking. It's already quite hard > enough to hire smart people.
I agree that it is getting ridiculously hard to hire good software people. BTW, rest of the world, the US, especially silicon valley, has a severe shortage of good software people, and it looks to be getting worse, much worse, over the next decade. (According to a recent report, the number of cs grads is going down! What are those students thinking?)
However, if there really is a productivity advantage to Lisp, Modula-3, ML, etc, why not hire people and train them in the language? Good people are always willing to learn new skills, especially when they are getting paid for it. This might not work for a short term project, where the start up costs would eat up your savings, but in a longer project...
Sam
-- Necessity is the Mother of Improvisation. | Samuel S. Paik Laziness and Greed are the Parents of Innovation| p...@webnexus.com Speak only for self
Bryan O'Sullivan <b...@serpentine.com> writes: > w> I think Pizzas syntax is rather canonical.
> Far from it; it's a grab bag of weird and inconsistent giblets, ears, > and toes from other languages. Some of the giblets represent > reasonable choices, and work well enough; others are not, and don't > work.
> - The syntax Pizza uses for declaring parameterised interfaces and > classes leads to ambiguous parses. Consider:
> interface Foo<Bar<T>> { > // is that a right shift above? > public interface Baz<Blat<Bong<Z>>> { > // what about the sign-extended shift here? > } > }
This seems to me an LALR problem. Even Suns own Java parser generator, JavaCC, provides better techniques which can resolve such ambiguoities.
> - The use of the word "fun" for anonymous functions comes straight > from ML.
This is not bad by definition. "method" cannot be used, since this would surely lead to confusion. "static method" is to long.
> - The use of "->" to denote the return type of a function comes from > any number of functional languages, and doesn't fit with any of > Java's syntax. What's wrong with the usual notation?
C's syntax for higher oder types is horrible. Do you believe that "(int ()(int))foo(int(x)(int))" is a better alternative then "int -> int foo(int -> int x)"? (Don't take me for sure for the correctness of the C'ish version ...)
> Regardless of whether you use the standard Java notation or this > icky special casing, the compiler has to do a lot of lookahead to > figure out what is going on.
Its the parser, and not the compiler, and this additional work most probably amounts to 1 promille of the overall compilation task.
> - Pizza overloads the "case" keyword so that it no longer indicates > simply a particular choice in a switch statement, but also a > declaration of a symbolic atom. Oh, and you get to stick it in > front of a constructor declaration in one special case, too.
I found this consistent, since the "case" for the class case is related to using the "case" for matching a class term in a switch. And the best of it: it doesn't reserves a further keyword. (Java already steels far to much lower-case identifiers).
BTW, Java 1.1 does overload keywords as well, namely "class".
> - The language permits casts between primitive types and the classes > that represent them. This is implicit magic that you don't see much > of in the rest of the Java language.
Discussable. Though the absence of implicit casts from primtives to their wrappers can be considered as a to less magic in Java as well.
> - Special-cased syntactic sugar for algebraic classes with a single > constructor is ugly and inconsistent with the usual Java thinking, > because Java provides very few redundant language-level mechanisms > for getting things done, and those that exist are well-chosen.
If you view class cases as a sum of product types, this decision is consistent; if you view them as syntactic sugar for introducing subclasses, not. Anyway, it is a convenient feature in practice.
> From where I'm sitting, it looks like the Pizza authors took the > features they wanted from other languages with the syntax they already > had, and simply grafted them straight onto Java without much thought > as to whether the notation fitted cleanly.
The examples you have given for this judgment are not convincing. Actually, Pizza adds only a few new syntax constructs, and these are, in my opinion, realtive cleanly designed.
Wolfgang
PS. For those following this discussion, and became interested in Pizza, here is the URL:
* Samuel S. Paik | (According to a recent report, the number of cs grads is going down! | What are those students thinking?)
they look around and see that any uneducated fool can get hired to write "cool" software and make a lot of money from age 16 onwards. they look around and see that if they take a serious CS education, they will have spent the years they could have made a lot of money _paying_ a lot of money, instead, and few will pay them more to recover their losses.
instead of assembly languages, we have assembly-line languages, where programmers are as interchangeable as the PC's. some (managers) actually think this is a *great* development.
the students aren't the problem -- they think rationally in today's market. the managers are the problem. not only do they buy Microsoft products because Microsoft targets their marketing at untechnological managers, they buy into Microsoft's ideas about programming, as well. nearly everybody else in the software or hardware industries have talked to technologically savvy people, selling products, not "feeling good, feeling safe".
unfortunately, it's not exactly considered positive for a manager to be technologically savvy in today's business climate. my impression is that computers have become a blue-collar thing, and that all that really counts is the user interface. these managers will begin to pay attention only after they have run the whole industry into the ground and they can no longer solve all their problems with "more cheap manpower", lawsuits begin to blame bad software, and they actually lose money on their uneducated staff. for this to set in, another decade at today's speed will suffice, and I believe we are still accelerating. it would take an extremely insightful 16-year-old to consider the long view instead of the several hundred thousand dollars he can reap while the managers destroy everything.
#\Erik -- 404 You're better off without that file. Trust me.
>However, if there really is a productivity advantage to Lisp, Modula-3, >ML, etc, why not hire people and train them in the language?
We've done exactly this, with good success retraining skilled C++ programmers. One disadvantage: Once they've become Lisp programmers, there's no going back...
> b> Given that the practical alternatives to Java for real projects are > b> C and C++, [...]
> j> I don't see this as factual, though it does seem to be the typical > j> perception.
> Sure it's factual. If I had my druthers, I'd write my code in > Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple > of considerations I have to deal with that prevent me from doing this:
> - I don't want to restrict the set of engineers I can hire who can > start working on my project without having to learn a new language, > along with possibly a new way of thinking. It's already quite hard > enough to hire smart people.
I have heard this circular argument before!
If you hire smart programmers, then they won't have any problems picking up a new language. Unless, you are the type that hires people and expects results in the first two weeks. (I will be happy to quote published experiences of good C programmers picking up Modula-3 in a week or so.)
> - I don't want to have to worry about whether there's a compiler and > runtime environment available for some random platform I'll need to > worry about two years from now, and I don't want to worry about > whether the compiler vendor is going to disappear because nobody > cares about their products.
I have heard this statement before, also.
While the C++ or Java "ideals" fit the bill, that is, you'd *think* you can find implementations for "random" platforms, the reality is far from the ideal. I have seen far too many projects which took the bait on this for even popular platforms (e.g., thinking their complex Java programs will work across Windows/Solaris and/or multiple browser implementations), and ended up shipping only on a single platform.
Speaking of which, where can I get a supported Java implementation for SunOS 4.1 running on SPARC--which is far from "random"? The only supported implementation of JavaVM that I know of for that platform is the Critical Mass JVM, which incidently was entirely written in Modula-3.
[Followups directed to comp.lang.misc. Please don't both mail and post followups to this article.]
f> If you hire smart programmers, then they won't have any problems f> picking up a new language.
This is true, but I don't want to lock myself into having to find some way to hire top-notch engineers in perpetuity.
f> While the C++ or Java "ideals" fit the bill, that is, you'd *think* f> you can find implementations for "random" platforms, the reality is f> far from the ideal.
No argument here. Java is the most prominent member of a small set of languages that have a realistic chance of this ever being true, though.
I might also note that, for most purposes, the advantages of Modula-3 and Eiffel over Java are incremental. Java gets it mostly right and has several orders of magnitude more momentum than Modula-3 and Eiffel combined, and so the 70% solution wins again.
Bryan O'Sullivan wrote: > Sure it's factual. If I had my druthers, I'd write my code in > Modula-3, Scheme, or Eiffel as the fit took me, but there are a couple > of considerations I have to deal with that prevent me from doing this: > - I don't want to restrict the set of engineers I can hire who can > start working on my project without having to learn a new language, > along with possibly a new way of thinking. It's already quite hard > enough to hire smart people.
I can offer some suggestions as to how you might go about hiring smart people. Number one, do a better job of interviewing some of Matthias's students. Some Silicon Valley companies are really dumb in their interview policies, in terms of picking just a few schools to interview at, and no others. Number two, your employer (who is, to be fair, expanding their Boston-area operations, but Boston only looks cheap to someone from Silicon Valley) lacks geographic diversity. That is, it's hard to hire someone who is CS-smart, yet stupid enough not to wonder about Silicon Valley's 0.5% rental vacancy rate and sky-high property values. Learning a new language ought not be hard; I've learned many over the years, and the only ones that I found hard were TeX and C++, and most of the people I've worked with seemed to have little or no trouble learning new languages, again with the exception of C++.
> - I don't want to have to worry about whether there's a compiler and > runtime environment available for some random platform I'll need to > worry about two years from now, and I don't want to worry about > whether the compiler vendor is going to disappear because nobody > cares about their products.
> If these don't seem like significant problems, that's great. I'm very > happy for you.
These are not significant problems for a sufficiently well-designed language. Modula-3 has been ported to quite a few platforms on a shoestring -- working for Olivetti, a team of not more than five (Me, Trevor, Mick, Steve, Marion) implemented the whole damn language, quite a few tools, and ported it to Sun-68k, Sun-Sparc, Mach-386, plus a couple of others that I no longer recall, and we did it in not more than 3 years, including a substantial part of the language design and one major language revision. We did not work weekends, we had lives outside our jobs, and for a decent part of the time the team was split geographically (once, from California to England).
Scheme is similarly simple. Java is also relatively simple, though the library and its interactions with the compiler (*) are a little annoying. (* The compiler from byte codes to native, that is.)
For a company as large as Sun, or IBM, or Apple, or Microsoft, if they needed a language supported on multiple platforms, they could have it for less than the yearly cost of a typical corporate vice president. If Sun, Microsoft, IBM, or Apple decided to use Modula-3 and sent money to the company supporting it, that company would be there as long as Sun wanted. Same for Scheme, also same for Java.
Near as I can tell, the failure to use good languages is a management failure, in that the people in charge of making these choices cannot tell the difference between appropriate technology and inappropriate technology, between competent people and charlatans, and instead simply choose to follow the herd. Sun's major win with Java is not that it is especially good compared to Scheme or Modula-3, but that it is head and shoulders above the former choice of the herd, namely C++.
>Years ago, I decided that programmers should not design user >interfaces, as we have a very different point of view from users. >Ideally, we'd have some kind of design tool that let's specialists >design the user interface, while us programmers get on with the more >interesting side of development.
Actually, a mediator is still needed. Most users, when they sit down to "design" a UI come up with a big bag o'undifferentiated and misbe- gotten functions from hell, tied together via a disorganized menu structure with lots of special modal behavior that makes learning the system a nightmare. In addition, the UI is generally only fit for their VERY specific use. If you need an example, look at most non-professional web pages (which are, in fact, a UI into an information repository).
And, BTW, most "programmers" and "software engineers" (or whatever you want to call the techno-grunts who grind code) do just as poor of a job at UI design as the users they believe they serve (take it from one who has been there and has learned to acknowledge his limitations).
All-in-all, the need for formal UI designers is still there. -- Frank A. Adrian First DataBank
In article <87d8mtx8s3....@serpentine.com> Bryan O'Sullivan <b...@serpentine.com> writes: > b> Given that the practical alternatives to Java for real projects are > b> C and C++, [...]
> j> I don't see this as factual, though it does seem to be the typical > j> perception.
> Sure it's factual. If I had my druthers, I'd write my code in
Well, since we use alternatives here and they work for us, I don't see this as factual. It is just the typical opinion from those who have not really tried something else.
> - I don't want to restrict the set of engineers I can hire who can
Well, you get what you pay for. Having a pool of thousands of C,C++,Java one week wonder hacks (learn C,C++,J in a week!, C,C++,J for dummies, etc.) doesn't mean you are going to get anything worth much fishing in that barrel.
> - I don't want to have to worry about whether there's a compiler and > runtime environment available for some random platform I'll need to
Again - I think this is _way_ overly exaggerated for several viable alternatives, including Ada95 and Eiffel.
> If these don't seem like significant problems, that's great. I'm very > happy for you.
Thanks! It _is_ great.
> j> Certainly Ada95 is a completely viable and practical alternative
> The only thing I much care for about Ada is that its metastasis has > now been outpaced by that of C++.
Whatever floats your boat!, ;-)
/Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari
