ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <christopher.d.schu...@comcast.net>
Subject Re: [OT] Seeking input from the comunity at large.
Date Fri, 14 Nov 2003 14:15:02 GMT
Donald,
> I have to agree with David on this one. I have considered doing something
> similar myself and dismissed it as probably a waste of time.

I have a friend that has been dreaming of a language he wants to write 
since we were in college. I always felt like if I were smart enough, I 
could make anything work in any language.

I'm very happy with Java and I've explained it to people why ask as "I 
can start thinking about my problem right away... I don't have to start 
by figuring out which parts of the language are going to get in my way. 
I feel like C/C++ projects start out with me trying to do something 
simple and getting tripped up by something small like references versus 
pointers". I guess that's just my dumb self and my lack of experience. I 
used to be a pretty good C guy. C++ was an abomination IMO, so I pretty 
much steered clear of it. It didn't help: I've since written a C++ 
plug-in for Winamp that also gets called (separately) by a JNI wrapper 
hooked-up to Java.

Anyhoo...

> I'm sorry my friend, you are posting to a list concerned with an application that
> runs on every commonly used OS.

Damned straight. Back in the day, everyone joked that it was "write 
once, test everywhere". Now, that's only the case on Solaris... which is 
too bad. It's a shame that Java seems more stable on win32 than Solaris, 
where it should feel right at home. I realize that part of the problem 
is the forest of patches required for every new version of Java, but 
still there are a lot of issues.

Note that those are not application issues, though. They are runtime 
issues, which can be fixed by the runtime authors. Your application is 
still very portable. That's no consolation for someone that wants to use 
a platform that's buggy, though: they either have to wait for a good 
version (d'oh) or switch to another platform (double d'oh!).

>>2) The byte code paradigm. Is it needed?
> 
> There are many ways, that is true. An interpreter combined with a JIT compiler
> is one of them.

I should point out that machine code is also interpreted, albeit at a 
lower-level. The microprocessor takes your "simplex" commands (like 
"load data into register 2") and breaks it down into several simpler 
operations to execute. Don't knock the interpreter :)

The only other alternative to "bytecode" is machine code. If you complie 
to "real" machine code, you make it harder to do the translation on 
other platforms. I'll admit that Java's bytecode (specifically) may not 
be the best example of high-performance bytecode, but it sure is 
portable. What would have happened if Java bytecode had not been 
stack-based? What would all those stack-based architectures have done 
with the bytecode? Probably nothing. However, a register-based 
architecture can use it just the same. (Does anyone actually know of a 
stack-based architecture for which a JVM has been written...?)

> It has allowed new
> ideas to be developed because it has taken a different approach. Such ideas
> as Applets, Reflection, Beans, JSPs are concepts that, even if they existed 
> prior to java, they were not main stream.

I think that the only thing Java has really allowed here is Applets; and 
that's basically due to its ability to run on the three major OS types 
in the market, today. Reflection (which is really called Run Time Type 
Info or RTTI) has been around in several languages in various forms... 
even C++ has it. If you mean arbitrary method invocation after lookup, 
then functions pointers have almost always been available. Beans are 
just a concept; they hold data. JSPs were beaten to the punch by PHP and 
ASP, and I'm sure there are others.

>>3) One problem many languages have gotten into is that thier keywords are
>>similar to their variable names. Java got smacked by this when they created a
>>new keyword assert() in JDK 1.4Now they are gunshy about creating another
>>keyword called foreach.

The whole assert thing was a major fumble in my eyes. There are 
currently some reserved words that don't mean anything in the Java 
language, but they are reserved for future use. They actually had rto 
remove assertions from the earlier versions because they had to ship the 
damned product. They could have *very easily* reserved that word.

With the "foreach" issue, I think that syntactic sugar sucks. It's one 
of the reasons that C/C++ irritate me. It's nice that things that act 
the same, look the same. When you introduce 5 different ways to do the 
same thing (syntactically, not methodologically), people get confused. 
And don't tell me that confused people will just starve themselves 
because they are too stupid to find and eat food, and that they deserve 
to die. Newbies deserve to understand what's going on, and it's easier 
to become a better programmer as you can recognize familiar patterns or 
paradigms. Foreach is just a compiler trick. It's completely 
unnecessary. (Actually, the benefit would be that lots of people would 
avoid OB1 errors, but let's just sweep that one nuder the rug for now :)

> "Gee, this langauge would be so much better if it only had <insert favourite language
> feature>."
> Everyone has their own version of this statement. Until languages can be extended at

> will by those who feel a feature is missing, people will continue to make this complaint.
> Such a language would need a fairly simple grammar that could be easily extended, I
> suspect that it would be difficult to read.

 > I think Lisp is a bit like that and there was
 > another language...

Yes, Lisp is very difficult to read (at least for me). And it's 
completely extensible. The only thing it's got are parens and lambda 
calculus. Oh, and a standard library, but that library it just an 
extension of the language, really.

That other language might have been Smalltalk? I know nothing about it 
other than I think it was the first OO-language. Maybe I'm lying out my 
arse.

> Good luck in whatever you decide to do.

That's what I'm saying. I have to admit (not hard, really), that I 
pretty much despise Microsoft. Yet, I still use their OS as my desktop 
and their friggin Office tools. My mantra is "the right tool for the 
right job". M$ Office is pretty much a requirement for dealing in the 
corporate world. Sorry, but OpenOffice.org just isn't going to cut it, 
at least not for me. So, I use the best tool.

Hey, if you think that Pascal is the only language that makes sense for 
your project, go for it (might I suggest Delphi?). If you want to use 
web services to implement everything in your app, go for it. Use Java. 
Use .NET. Use them both for all I care. Just make your decisions based 
upon information and requirements. If it's gotta run on win32 and UNIX, 
you basically have two choices: Java or C/C++. IF it's gotta be deployed 
on both without thinking about it, you're really down to one choice.

... unless you write your own language, compiler, and runtime for every 
platform you want to use ... :)

-chris


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message