Cross-Platform Languages [Archive] - ForumsHQ
-
erek[NOT BANNED]
- Posts: 204
- Joined: Wed May 18, 2005 5:00 am
Cross-Platform Languages [Archive] - ForumsHQ
sigh... C#? man it'd be cool if this was portable to nearly ever OS/arch ...
Re: Cross-Platform Languages [Archive] - ForumsHQ
']sigh... C#? man it'd be cool if this was portable to nearly ever OS/arch ...
I felt the same way. Originally I set out to do it in C++, but guess what? You run into the exact same problems with inconsistency in libraries between different OSes and architectures. .NET is viable with Linux (actually I think prety much all flavors of *nix?) via the Mono project. I'm not sure how far they've gotten with sockets, but if it's anywhere near complete, the code *should* port right over.
I felt the same way. Originally I set out to do it in C++, but guess what? You run into the exact same problems with inconsistency in libraries between different OSes and architectures. .NET is viable with Linux (actually I think prety much all flavors of *nix?) via the Mono project. I'm not sure how far they've gotten with sockets, but if it's anywhere near complete, the code *should* port right over.
Re: Cross-Platform Languages [Archive] - ForumsHQ
mono isnt terribly popular though (ie, the installed base isn't great compared to other languages)... unix users are wary of Microsoft-designed APIs because honestly they make simple things way too complicated. (example: the function to create a new process in Windows takes 8 parameters, vs taking 0 parameters in Unix)
I guess .net is a sane choice tho if you want to stick with a mostly-MS-base of sysops, which is consistent with WorldGroup.
Personally I'd go for more of a unix approach, since I think that as years pass, the kinds of people who play/run text games (ie MUDs) and the kinds of people who use text-heavy OS's (ie Unix) will continue to overlap more and more.
I actually started writing a mud in Perl + MySQL a few months back, Perl is way faster to code in than C-style languages like C#. The rlogin server was only like 50 lines of code for example, Perl is really nice. I ran out of free time and dropped it though (as usual! sigh), maybe will pick it back up some day, maybe not. There's already a lot of other Unix MUDs out there anyway :)
I guess .net is a sane choice tho if you want to stick with a mostly-MS-base of sysops, which is consistent with WorldGroup.
Personally I'd go for more of a unix approach, since I think that as years pass, the kinds of people who play/run text games (ie MUDs) and the kinds of people who use text-heavy OS's (ie Unix) will continue to overlap more and more.
I actually started writing a mud in Perl + MySQL a few months back, Perl is way faster to code in than C-style languages like C#. The rlogin server was only like 50 lines of code for example, Perl is really nice. I ran out of free time and dropped it though (as usual! sigh), maybe will pick it back up some day, maybe not. There's already a lot of other Unix MUDs out there anyway :)
-
abc123
Re: Cross-Platform Languages [Archive] - ForumsHQ
Evan, seriously, writing it in c# is a great idea; the only better language might be java, that's truly cross-platform, but really - who gives a crap.
WG currently only runs on windows, megamud runs on windows, most of us use windows, so why should he go out of his way to write something so cross-platform, when it clearly doesn't need to be?
It's a SERVER anyway, not a client app, so the requirement for cross-platformness isn't as important.
Anyway, nice work vitoc! And have you guys been following this topic: http://www.metrobbs.com/cgi-bin/yabb/YaBB.cgi?board=111k;action=display;num=1130602220; start=50#50
Try and hit this guy up for some money for your efforts :)
WG currently only runs on windows, megamud runs on windows, most of us use windows, so why should he go out of his way to write something so cross-platform, when it clearly doesn't need to be?
It's a SERVER anyway, not a client app, so the requirement for cross-platformness isn't as important.
Anyway, nice work vitoc! And have you guys been following this topic: http://www.metrobbs.com/cgi-bin/yabb/YaBB.cgi?board=111k;action=display;num=1130602220; start=50#50
Try and hit this guy up for some money for your efforts :)
Re: Cross-Platform Languages [Archive] - ForumsHQ
Evan, seriously, writing it in c# is a great idea; the only better language might be java, that's truly cross-platform, but really - who gives a crap.
WG currently only runs on windows, megamud runs on windows, most of us use windows, so why should he go out of his way to write something so cross-platform, when it clearly doesn't need to be?
Because you can get a dedicated, remote-hosted 100mbps Linux/BSD server for only $30 to $60/month, whereas Windows servers cost twice that.
Running internet servers on personal machines via home broadband is a waste of a machine and a waste of the sysop's bandwidth. Usually when an edited board goes down for good, it's because the sysop no longer had a spare computer. Remote hosting solves all that, and Unix is the way to go with remote hosting.
Cross-platform means more people can run it, why the hell would that be a bad thing? (Then again, since you're advocating that festering crap-pile known as Java, I doubt we're going to agree on much here. :wallbang: Java isn't any more or less cross-platform than Perl, Python, Ruby, PHP, or any number of other languages which are much better designed and take a tenth the amount of code to do simple tasks.)
WG currently only runs on windows, megamud runs on windows, most of us use windows, so why should he go out of his way to write something so cross-platform, when it clearly doesn't need to be?
Because you can get a dedicated, remote-hosted 100mbps Linux/BSD server for only $30 to $60/month, whereas Windows servers cost twice that.
Running internet servers on personal machines via home broadband is a waste of a machine and a waste of the sysop's bandwidth. Usually when an edited board goes down for good, it's because the sysop no longer had a spare computer. Remote hosting solves all that, and Unix is the way to go with remote hosting.
Cross-platform means more people can run it, why the hell would that be a bad thing? (Then again, since you're advocating that festering crap-pile known as Java, I doubt we're going to agree on much here. :wallbang: Java isn't any more or less cross-platform than Perl, Python, Ruby, PHP, or any number of other languages which are much better designed and take a tenth the amount of code to do simple tasks.)
Re: Cross-Platform Languages [Archive] - ForumsHQ
okok what are your issues with java. i happen to prefer it.
the design goal of a compiled language (or at least one that is EVENTUALLY compiled) is different from an interpretted language. you really can't compare them because the taskset you can accomplish in an interpretted language is a subset of that which you can accomplish in a compiled language.
the design goal of a compiled language (or at least one that is EVENTUALLY compiled) is different from an interpretted language. you really can't compare them because the taskset you can accomplish in an interpretted language is a subset of that which you can accomplish in a compiled language.
Re: Cross-Platform Languages [Archive] - ForumsHQ
okok what are your issues with java. i happen to prefer it.
Java is only good "in theory", kind of like communism. It's all clean and pretty and well-designed in theory, but in practical use it's crap.
Now that you got me going :) , here's a ton of major problems with Java:
1. It FORCES all programs to be object-oriented, even when an object-oriented approach makes no sense whatsoever. Many software-design-theorists are now admitted that the all-OO approach that was heavily advocated in the 90s is a bad one; they now say OO only works well in a small set of application domains. Most other languages are more flexible than this, not *forcing* coders into a single design paradigm.
2. It takes far more lines of code to do certain tasks in Java than it does in others. To do a simple, regular task such as a grep -- opening a file, readline'ing from it, picking certain lines by a regular expression and printing them -- is literally ONE HUNDRED TIMES the amount of typing in Java vs Perl or PHP.
3. The Java API went overboard with function naming. Sure, it's slightly clearer, but it's a hell of a lot more typing. I'd much rather type $_GET['name'] than type myForm.getFormProperty("name") a million times.
4. Dynamicly-resizing arrays and hash tables are both missing from Java's built-in syntax, which means that you need to do much longer method calls to do these basic tasks. If you've ever written code in a language which has good, native array and hash support you'll wonder how you ever lived without it.
5. Java doesn't support operator overloading or multiple inheritance. For a pure-OO language, those are glaring omissions. Java tries to force you to write clean code by assuming all coders are idiots who can't use advanced OO features cleanly, which is a bizarre design rule to enforce.
6. In its quest to be completely cross-platform and have absolutely no platform-specific functions at all anywhere, it loses the ability to perform platform-specific tasks. For instance, there's no way to do Unix signal handling in Java because Windows doesn't support Unix-style complex signal handling. This makes Java completely unusable for certain tasks.
7. Java is a Sun Microsystems product, and Sun Microsystems has fallen on really hard times in terms of loss of upper management, profitability, and other factors. They were mainly a hardware company, and large IT depts are switching off of Sun hardware like it has the plague. That doesn't bode well for the company's software either, long-term.
8. The JVM's instruction set makes about as little sense as the Pentium's; that is to say, Java bytecodes are a nonsensical mess.
9. The JVM's set of base libraries is far too large, making it a bloated download.
The above is the result of my opinion having written thousands of lines of Java for about 2 years. End result is that I dislike Java about equally with C++, and I'd much rather use any of the other languages that I know for nearly any task.
the design goal of a compiled language (or at least one that is EVENTUALLY compiled) is different from an interpretted language.
But Java *IS* almost always used an interpretted language, not a compiled one. Unless you're spitting out native executables, it's an interpretted language. Java VM interprets non-native bytecodes, exactly the same as Perl, PHP, Python, .NET CRL, Ruby, JavaScript, etc...
you really can't compare them because the taskset you can accomplish in an interpretted language is a subset of that which you can accomplish in a compiled language.
From a theoretical standpoint, that's categorically untrue (google: "turing-complete language"). From a practical standpoint, that's only true in the sense of, like, you must use C to write operating systems and device-drivers... otherwise, the task-sets aren't so different.
Java is only good "in theory", kind of like communism. It's all clean and pretty and well-designed in theory, but in practical use it's crap.
Now that you got me going :) , here's a ton of major problems with Java:
1. It FORCES all programs to be object-oriented, even when an object-oriented approach makes no sense whatsoever. Many software-design-theorists are now admitted that the all-OO approach that was heavily advocated in the 90s is a bad one; they now say OO only works well in a small set of application domains. Most other languages are more flexible than this, not *forcing* coders into a single design paradigm.
2. It takes far more lines of code to do certain tasks in Java than it does in others. To do a simple, regular task such as a grep -- opening a file, readline'ing from it, picking certain lines by a regular expression and printing them -- is literally ONE HUNDRED TIMES the amount of typing in Java vs Perl or PHP.
3. The Java API went overboard with function naming. Sure, it's slightly clearer, but it's a hell of a lot more typing. I'd much rather type $_GET['name'] than type myForm.getFormProperty("name") a million times.
4. Dynamicly-resizing arrays and hash tables are both missing from Java's built-in syntax, which means that you need to do much longer method calls to do these basic tasks. If you've ever written code in a language which has good, native array and hash support you'll wonder how you ever lived without it.
5. Java doesn't support operator overloading or multiple inheritance. For a pure-OO language, those are glaring omissions. Java tries to force you to write clean code by assuming all coders are idiots who can't use advanced OO features cleanly, which is a bizarre design rule to enforce.
6. In its quest to be completely cross-platform and have absolutely no platform-specific functions at all anywhere, it loses the ability to perform platform-specific tasks. For instance, there's no way to do Unix signal handling in Java because Windows doesn't support Unix-style complex signal handling. This makes Java completely unusable for certain tasks.
7. Java is a Sun Microsystems product, and Sun Microsystems has fallen on really hard times in terms of loss of upper management, profitability, and other factors. They were mainly a hardware company, and large IT depts are switching off of Sun hardware like it has the plague. That doesn't bode well for the company's software either, long-term.
8. The JVM's instruction set makes about as little sense as the Pentium's; that is to say, Java bytecodes are a nonsensical mess.
9. The JVM's set of base libraries is far too large, making it a bloated download.
The above is the result of my opinion having written thousands of lines of Java for about 2 years. End result is that I dislike Java about equally with C++, and I'd much rather use any of the other languages that I know for nearly any task.
the design goal of a compiled language (or at least one that is EVENTUALLY compiled) is different from an interpretted language.
But Java *IS* almost always used an interpretted language, not a compiled one. Unless you're spitting out native executables, it's an interpretted language. Java VM interprets non-native bytecodes, exactly the same as Perl, PHP, Python, .NET CRL, Ruby, JavaScript, etc...
you really can't compare them because the taskset you can accomplish in an interpretted language is a subset of that which you can accomplish in a compiled language.
From a theoretical standpoint, that's categorically untrue (google: "turing-complete language"). From a practical standpoint, that's only true in the sense of, like, you must use C to write operating systems and device-drivers... otherwise, the task-sets aren't so different.
-
abc123
Re: Cross-Platform Languages [Archive] - ForumsHQ
Java is only good "in theory", kind of like communism. It's all clean and pretty and well-designed in theory, but in practical use it's crap.
That is just not true at all. Java is used EVERYWHERE in the enterprise environment.
1. It FORCES all programs to be object-oriented, even when an object-oriented approach makes no sense whatsoever. Many software-design-theorists are now admitted that the all-OO approach that was heavily advocated in the 90s is a bad one; they now say OO only works well in a small set of application domains. Most other languages are more flexible than this, not *forcing* coders into a single design paradigm.
You can program non-OO in java if you like; I'm sorry to say but you are demonstrating a very basic knowledge of programming here.
Java has Objects, sure, but procedural is just a layout. Nothing technially stops you. (Even though it's bad).
2. It takes far more lines of code to do certain tasks in Java than it does in others. To do a simple, regular task such as a grep -- opening a file, readline'ing from it, picking certain lines by a regular expression and printing them -- is literally ONE HUNDRED TIMES the amount of typing in Java vs Perl or PHP.
One hundred? ::)
Welcome to the world of compiled vs interpreated. Type-safety, compile-time safety, is what you get.
3. The Java API went overboard with function naming. Sure, it's slightly clearer, but it's a hell of a lot more typing. I'd much rather type $_GET['name'] than type myForm.getFormProperty("name") a million times.
See above.
4. Dynamicly-resizing arrays and hash tables are both missing from Java's built-in syntax, which means that you need to do much longer method calls to do these basic tasks. If you've ever written code in a language which has good, native array and hash support you'll wonder how you ever lived without it.
See above. Welcome to type-safety.
5. Java doesn't support operator overloading or multiple inheritance. For a pure-OO language, those are glaring omissions. Java tries to force you to write clean code by assuming all coders are idiots who can't use advanced OO features cleanly, which is a bizarre design rule to enforce.
No, it isn't. Again you are being naive and don't consider real-world problems. Do some reading and you will be enlightened.
[qipte]6. In its quest to be completely cross-platform and have absolutely no platform-specific functions at all anywhere, it loses the ability to perform platform-specific tasks. For instance, there's no way to do Unix signal handling in Java because Windows doesn't support Unix-style complex signal handling. This makes Java completely unusable for certain tasks.
[/quote]
Have you met JNI? You should discover it.
Java was designed to be cross-platform, but you can integrate it into the OS if you wish.
7. Java is a Sun Microsystems product, and Sun Microsystems has fallen on really hard times in terms of loss of upper management, profitability, and other factors. They were mainly a hardware company, and large IT depts are switching off of Sun hardware like it has the plague. That doesn't bode well for the company's software either, long-term.
Sure, Sun sucks, but java is operated under a community that loves it.
8. The JVM's instruction set makes about as little sense as the Pentium's; that is to say, Java bytecodes are a nonsensical mess.
What the FUCK? How do you come to this judgement?
9. The JVM's set of base libraries is far too large, making it a bloated download.
That'st the JDK, not JRE. And deal with it - you need a large runtime to do all the tasks java provides.
The above is the result of my opinion having written thousands of lines of Java for about 2 years. End result is that I dislike Java about equally with C++, and I'd much rather use any of the other languages that I know for nearly any task.
I've written java for 5, assembly, c, c++, c#, php, perl, and many more. Seriously, do some research.
But Java *IS* almost always used an interpretted language, not a compiled one. Unless you're spitting out native executables, it's an interpretted language. Java VM interprets non-native bytecodes, exactly the same as Perl, PHP, Python, .NET CRL, Ruby, JavaScript, etc...
HAHAHAHAHA.
Oh my lord, please, (sorry for getting so rude) but ffs, you have no clue at all. I've wasted my time with this post, you won't even understand it if that's your opinion.
"A compiled language must produce a native executable?" *rofl*.
That is just not true at all. Java is used EVERYWHERE in the enterprise environment.
1. It FORCES all programs to be object-oriented, even when an object-oriented approach makes no sense whatsoever. Many software-design-theorists are now admitted that the all-OO approach that was heavily advocated in the 90s is a bad one; they now say OO only works well in a small set of application domains. Most other languages are more flexible than this, not *forcing* coders into a single design paradigm.
You can program non-OO in java if you like; I'm sorry to say but you are demonstrating a very basic knowledge of programming here.
Java has Objects, sure, but procedural is just a layout. Nothing technially stops you. (Even though it's bad).
2. It takes far more lines of code to do certain tasks in Java than it does in others. To do a simple, regular task such as a grep -- opening a file, readline'ing from it, picking certain lines by a regular expression and printing them -- is literally ONE HUNDRED TIMES the amount of typing in Java vs Perl or PHP.
One hundred? ::)
Welcome to the world of compiled vs interpreated. Type-safety, compile-time safety, is what you get.
3. The Java API went overboard with function naming. Sure, it's slightly clearer, but it's a hell of a lot more typing. I'd much rather type $_GET['name'] than type myForm.getFormProperty("name") a million times.
See above.
4. Dynamicly-resizing arrays and hash tables are both missing from Java's built-in syntax, which means that you need to do much longer method calls to do these basic tasks. If you've ever written code in a language which has good, native array and hash support you'll wonder how you ever lived without it.
See above. Welcome to type-safety.
5. Java doesn't support operator overloading or multiple inheritance. For a pure-OO language, those are glaring omissions. Java tries to force you to write clean code by assuming all coders are idiots who can't use advanced OO features cleanly, which is a bizarre design rule to enforce.
No, it isn't. Again you are being naive and don't consider real-world problems. Do some reading and you will be enlightened.
[qipte]6. In its quest to be completely cross-platform and have absolutely no platform-specific functions at all anywhere, it loses the ability to perform platform-specific tasks. For instance, there's no way to do Unix signal handling in Java because Windows doesn't support Unix-style complex signal handling. This makes Java completely unusable for certain tasks.
[/quote]
Have you met JNI? You should discover it.
Java was designed to be cross-platform, but you can integrate it into the OS if you wish.
7. Java is a Sun Microsystems product, and Sun Microsystems has fallen on really hard times in terms of loss of upper management, profitability, and other factors. They were mainly a hardware company, and large IT depts are switching off of Sun hardware like it has the plague. That doesn't bode well for the company's software either, long-term.
Sure, Sun sucks, but java is operated under a community that loves it.
8. The JVM's instruction set makes about as little sense as the Pentium's; that is to say, Java bytecodes are a nonsensical mess.
What the FUCK? How do you come to this judgement?
9. The JVM's set of base libraries is far too large, making it a bloated download.
That'st the JDK, not JRE. And deal with it - you need a large runtime to do all the tasks java provides.
The above is the result of my opinion having written thousands of lines of Java for about 2 years. End result is that I dislike Java about equally with C++, and I'd much rather use any of the other languages that I know for nearly any task.
I've written java for 5, assembly, c, c++, c#, php, perl, and many more. Seriously, do some research.
But Java *IS* almost always used an interpretted language, not a compiled one. Unless you're spitting out native executables, it's an interpretted language. Java VM interprets non-native bytecodes, exactly the same as Perl, PHP, Python, .NET CRL, Ruby, JavaScript, etc...
HAHAHAHAHA.
Oh my lord, please, (sorry for getting so rude) but ffs, you have no clue at all. I've wasted my time with this post, you won't even understand it if that's your opinion.
"A compiled language must produce a native executable?" *rofl*.
Re: Cross-Platform Languages [Archive] - ForumsHQ
That is just not true at all. Java is used EVERYWHERE in the enterprise environment.
I never said that it wasn't. But just because it's used everywhere doesn't mean it's even remotely a good product. How many tens of thousands of clueless vice presidents are there out there making enterprise language choices without knowing a thing about programming?
You can program non-OO in java if you like; I'm sorry to say but you are demonstrating a very basic knowledge of programming here.
Java has Objects, sure, but procedural is just a layout. Nothing technially stops you. (Even though it's bad).
This is categorically incorrect. All Java code must be wrapped in classes, and is object-oriented.
Java is what's known as a "pure OO" language; you MUST put all functions and variables into a class. This differs greatly from C, C++, Perl, etc where you can do true procedural programming: writing functions that are not associated with classes and have nothing to do with object-oriented code. Read Bjarne Stroustrup's comments on "multi-paradigm programming", this is a good start to clear you up.
Java isn't quite as object-oriented as, say, Ruby -- where even literal numbers are objects, and you can call methods on them, like 4.times({codeblock...}) -- but it's far more object-oriented than C++, Objective C, Perl, PHP, et al, in that Java forces all code to belong to a class.
And if you think procedural programming is uniformly "bad"... you haven't read many design books beyond the OO community obviously. BTW, the majority of software that you're running at this very instant is NOT object-oriented. And if you're running Linux, change that to a LARGE majority. Experienced coders know that there is no "silver bullet" to programming, no single design pattern that solves all problems. Object-oriented design should only be used in domains where it makes sense, and that is now known to be a rather small subset of programming applications.
And what's up with the flame attitude? Saying I have a "very basic knowledge of programming", what on earth are you talking about? FYI, I'm a professional programmer with a BS in computer science from a top university, and 11 years coding experience in over a dozen programming languages.
I'm also probably the only person in this forum who's ever written a complete MUD from scratch, let alone one that has been run on hundreds of servers in at least 5 countries. So quit your nonsensical flames already, your attitude is unnecessary and you're just making yourself look bad.
One hundred? ::)
Yes, one hundred. Implementing a grep program in Perl is literally 3 lines of code. Compare this to Java where you need to wrap the code in a class, where you need to make 3 method calls across 3 classes just to open a freakin' file, and where you can't use a compact syntax to loop and perform complex operations in the same line of code.
Welcome to the world of compiled vs interpreated. Type-safety, compile-time safety, is what you get.
That's an untrue statement. For instance, C is a compiled language which is "semi" type-safe, but it doesn't *guarantee* type safety. You can take a pointer to anything and cast it to anything else unsafely. Type safety is a concept unrelated to compiled languages.
No, it isn't. Again you are being naive and don't consider real-world problems. Do some reading and you will be enlightened.
You really crack me up. Get a real programming job and then try talking to me when you have some idea what the heck you're talking about.
Have you met JNI? You should discover it.
I'm well aware of JNI and have used it before and let me tell you, it's pretty messy. If you wanna add dozens of lines of code just to do a Unix signal handler -- something that would be a 1-liner in C or Perl -- then you're making some pretty stupid design decisions.
It's not the *worst* of Java's APIs though; that would go to RMI, quite possibly the most poorly designed remote-object strategy ever written. Or maybe the old AWT graphics classes which were so bad that Sun had to redesign the API from scratch. Or maybe the Threading libraries which are a complete unholy terror. There's so many poorly-designed Java libs that I don't even know where to start.
> 8. The JVM's instruction set makes about as little sense as the Pentium's;
What the F---? How do you come to this judgement?
What's with the profanity? Chill out. I come to this judgement from books and classes on compiler design, processor design, and programming language implementation. I've actually written code that manipulates Java binary bytecodes, and have worked with the JVM's instruction set directly; have you? No? Then why are you even trying to talk about it?
That'st the JDK, not JRE.
No, that's the JRE. The runtime environment provides the full set of Java class files, a bloated mess of which 90% of which aren't used in the vast majority of Java programs; so why are the bundled in?
And deal with it - you need a large runtime to do all the tasks java provides.
Perl, PHP, etc provide 95% equivalent functionality in a smaller download. The other 5% is moved into separate NON-CORE libraries, which is where they should be if they're not used often. Go figure.
I've written java for 5, assembly, c, c++, c#, php, perl, and many more. Seriously, do some research.
If you want to have a pissing contest, I can code in C, C++, Java, Objective C, Perl, PHP, 8086 assembly, MIPS assembly, Pl/SQL, ML, Basic, and several others.
"A compiled language must produce a native executable?" *rofl*.
Despite the quotes you put there, that is most decidedly NOT what I said. My statement was, "Unless you're spitting out native executables, it's an interpretted language." This statement is 100% factual, and if you disagree, you've been miseducated. The DEFINITION of an interpretted language is one that requires an INTERPRETTER, aka a Virtual Machine. Perl, PHP, Ruby, ML, .NET CLR, and many others fall into this category -- AND SO DOES JAVA.
Java is BOTH a compiled language and an interpretted language. The two are not mutually exclusive. And also in this regard, really EVERY language is a "compiled" language. I don't know of a single interpretter that directly interprets code in stirng form, without first parsing the code and compiling into bytecode. Just because some languages do this straight-to-memory (ie Perl, PHP) instead of writing a compiled form to disk (ie Java's .class files) doesn't mean that one language is "compiled" and the other isn't.
Seriously abc, get a degree, some job experience, and a clue and then we'll talk!
BTW, nice job at not replying to half of the points in my previous post!
I never said that it wasn't. But just because it's used everywhere doesn't mean it's even remotely a good product. How many tens of thousands of clueless vice presidents are there out there making enterprise language choices without knowing a thing about programming?
You can program non-OO in java if you like; I'm sorry to say but you are demonstrating a very basic knowledge of programming here.
Java has Objects, sure, but procedural is just a layout. Nothing technially stops you. (Even though it's bad).
This is categorically incorrect. All Java code must be wrapped in classes, and is object-oriented.
Java is what's known as a "pure OO" language; you MUST put all functions and variables into a class. This differs greatly from C, C++, Perl, etc where you can do true procedural programming: writing functions that are not associated with classes and have nothing to do with object-oriented code. Read Bjarne Stroustrup's comments on "multi-paradigm programming", this is a good start to clear you up.
Java isn't quite as object-oriented as, say, Ruby -- where even literal numbers are objects, and you can call methods on them, like 4.times({codeblock...}) -- but it's far more object-oriented than C++, Objective C, Perl, PHP, et al, in that Java forces all code to belong to a class.
And if you think procedural programming is uniformly "bad"... you haven't read many design books beyond the OO community obviously. BTW, the majority of software that you're running at this very instant is NOT object-oriented. And if you're running Linux, change that to a LARGE majority. Experienced coders know that there is no "silver bullet" to programming, no single design pattern that solves all problems. Object-oriented design should only be used in domains where it makes sense, and that is now known to be a rather small subset of programming applications.
And what's up with the flame attitude? Saying I have a "very basic knowledge of programming", what on earth are you talking about? FYI, I'm a professional programmer with a BS in computer science from a top university, and 11 years coding experience in over a dozen programming languages.
I'm also probably the only person in this forum who's ever written a complete MUD from scratch, let alone one that has been run on hundreds of servers in at least 5 countries. So quit your nonsensical flames already, your attitude is unnecessary and you're just making yourself look bad.
One hundred? ::)
Yes, one hundred. Implementing a grep program in Perl is literally 3 lines of code. Compare this to Java where you need to wrap the code in a class, where you need to make 3 method calls across 3 classes just to open a freakin' file, and where you can't use a compact syntax to loop and perform complex operations in the same line of code.
Welcome to the world of compiled vs interpreated. Type-safety, compile-time safety, is what you get.
That's an untrue statement. For instance, C is a compiled language which is "semi" type-safe, but it doesn't *guarantee* type safety. You can take a pointer to anything and cast it to anything else unsafely. Type safety is a concept unrelated to compiled languages.
No, it isn't. Again you are being naive and don't consider real-world problems. Do some reading and you will be enlightened.
You really crack me up. Get a real programming job and then try talking to me when you have some idea what the heck you're talking about.
Have you met JNI? You should discover it.
I'm well aware of JNI and have used it before and let me tell you, it's pretty messy. If you wanna add dozens of lines of code just to do a Unix signal handler -- something that would be a 1-liner in C or Perl -- then you're making some pretty stupid design decisions.
It's not the *worst* of Java's APIs though; that would go to RMI, quite possibly the most poorly designed remote-object strategy ever written. Or maybe the old AWT graphics classes which were so bad that Sun had to redesign the API from scratch. Or maybe the Threading libraries which are a complete unholy terror. There's so many poorly-designed Java libs that I don't even know where to start.
> 8. The JVM's instruction set makes about as little sense as the Pentium's;
What the F---? How do you come to this judgement?
What's with the profanity? Chill out. I come to this judgement from books and classes on compiler design, processor design, and programming language implementation. I've actually written code that manipulates Java binary bytecodes, and have worked with the JVM's instruction set directly; have you? No? Then why are you even trying to talk about it?
That'st the JDK, not JRE.
No, that's the JRE. The runtime environment provides the full set of Java class files, a bloated mess of which 90% of which aren't used in the vast majority of Java programs; so why are the bundled in?
And deal with it - you need a large runtime to do all the tasks java provides.
Perl, PHP, etc provide 95% equivalent functionality in a smaller download. The other 5% is moved into separate NON-CORE libraries, which is where they should be if they're not used often. Go figure.
I've written java for 5, assembly, c, c++, c#, php, perl, and many more. Seriously, do some research.
If you want to have a pissing contest, I can code in C, C++, Java, Objective C, Perl, PHP, 8086 assembly, MIPS assembly, Pl/SQL, ML, Basic, and several others.
"A compiled language must produce a native executable?" *rofl*.
Despite the quotes you put there, that is most decidedly NOT what I said. My statement was, "Unless you're spitting out native executables, it's an interpretted language." This statement is 100% factual, and if you disagree, you've been miseducated. The DEFINITION of an interpretted language is one that requires an INTERPRETTER, aka a Virtual Machine. Perl, PHP, Ruby, ML, .NET CLR, and many others fall into this category -- AND SO DOES JAVA.
Java is BOTH a compiled language and an interpretted language. The two are not mutually exclusive. And also in this regard, really EVERY language is a "compiled" language. I don't know of a single interpretter that directly interprets code in stirng form, without first parsing the code and compiling into bytecode. Just because some languages do this straight-to-memory (ie Perl, PHP) instead of writing a compiled form to disk (ie Java's .class files) doesn't mean that one language is "compiled" and the other isn't.
Seriously abc, get a degree, some job experience, and a clue and then we'll talk!
BTW, nice job at not replying to half of the points in my previous post!
Re: Cross-Platform Languages [Archive] - ForumsHQ
I agree with your points, Evan. I thought you were going to go down the "Java is slow" road, which is no longer true so much. Now it can be slow or it can be fast, depending on implementation (like any language)
I've done programming in C++, Java, Perl, PHP and Python. I agree it's missing some conveniences, and it definitely is missing optimizability. I find Java the most readable language I've dealth with. The IDE eclipse is just awesome. I prefer it to VS.net for C++... haven't seen it matched by any other IDE, actually.
I've done programming in C++, Java, Perl, PHP and Python. I agree it's missing some conveniences, and it definitely is missing optimizability. I find Java the most readable language I've dealth with. The IDE eclipse is just awesome. I prefer it to VS.net for C++... haven't seen it matched by any other IDE, actually.