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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
