It's nice to see some people defending the right to have a useful e-mail account--maybe one day (far in the future) we can reclaim USENET and the web too...
Syntax is entirely a matter of opinion, and anyone who gets hung up on it is being shallow; (or can't figure out how to write a pre-processor...) this was the one thing that completely baffled me in the old C/Pascal debates. Even at the time, there were translators available to convert Pascal to C, and they did an ok job, so quibbling about the syntax (and not the language features) seemed completely useless and absurd to me...
Even though perl can *look* quite ugly, it's actually a very powerful and fully-featured language, with all (most?) of the features of the classic functional languages, except that they're optional. Anyone who objects to perl based on the syntax alone is just being shallow, and should probably spend some time writing a pre-processor for perl in perl so they can make it look "pretty" (whatever they think is pretty, that is--I think Java is pretty ugly).
I've been spending a lot of time programming in PHP lately, and although my code might be more readable, (especially to someone with just a C programming background) I spend a lot more time working around quirks in PHP (either version issues, library functions, or design flaws... sometimes all three!) than I ever would in Perl.
However, the repositories do make all the difference. Although there isn't quite as much out there for PHP as there is for Perl, there's still a substantial amount, and that helps make it all bearable.
I did this for a while when I had my P133 as my old system. And I agree with you in principle--there should be some *testing* done on multiple hardware platforms.
However, your application should be OPTIMIZED for whatever people are likely to have. And if you just code your app on one machine and never try it out on anything else, it might be an order of magnitude slower than it should be because you unwittingly optimized it for the machine you were on. (trust me, I've seen this happen, for example when the bottleneck was the cache on the K6's vs. on the P]['s.)
And, as someone else said, P133's make a sucky development platform these days. Just as I wouldn't expect you to do graphics work on one, (although I did do a lot of work on one in The GIMP back in the day...) you shouldn't expect us to do our compiling on one... just some testing.:)
My numeric example wasn't meant to say that you should use Java to do high-performance arbitrary precision number manipulation, but rather to mention that this is an area where operator overloading makes the interface much more natural. I already that the + operator has its shortcomings in concatenation, but it is nice to see that this is (still) common knowledge.
I haven't seen that particular code beautifier--when I was searching for one, I found one that understood and formatted many different languages (at least somewhat), primarily for printing. And it did an ok job with Java, except when it couldn't manage to decently break a line of code up in the first place--this is primarily due to the godAwfullyLongIdentifiers that are commonly used in Java.
You're right that my example could be broken up through the judicious use of temporary variables, as I've already mentioned. But I know of no code beautifier that actually modifies your source code so as to change its meaning, and if I found one, I probably wouldn't want to use it in the first place.
I actually wasn't referring to any particular Java method in that example by the way, but attempting to emulate the sort of identifiers commonly found in a Java program. I think that writing code like that (all on one line, and accessing the results of functions as objects, etc., etc.) is a particularly ugly way to write Java code, but it's common enough, and IMHO it makes the code harder to read, indent, and understand.
I don't think that 80 columns is necessarily some magic number that *has* to be enforced, but I think it's a nice rule of thumb, especially for printing. I'd go as far as perhaps 120 columns, but with 80 columns as a strong preference. Still, even 120 columns isn't wide enough for some code...
I often use console-based editors, sometimes on actual consoles. And I wouldn't ask anyone to change their preferred editor, yea, even for Java programming, unless I had some awesome development environment to suggest. Usually I use nano or pico, actually, due to an old preference for simple console editors, probably a hold-over from my DOS programming days. For an IDE, I'd have to recommend RHIDE, again due to my days using TurboVision-based IDEs. But of course this is entirely my personal preference.
The automatic documentation generators in the style of JavaDoc did get quite popular, and started springing up on every language, almost overnight. I think that's one great contribution Java has made to the community, intentionally or not. I guess you need good documentation when you can't decently indent, format, and print your code...;)
First, to get "private protected" semantics, you can't just use an anonymous package, you have to create another package to encapsulate the class in the first place.
Re: assigning System.out to an object, sure that works, but you have an extra temporary variable; not horrible, but a bit ugly.
I don't mind reading documentation; I'm merely pointing out that when you have as many container implementations, it'll take a while to figure out which one is best for the task at hand, and what the pros and cons of each one are. I personally don't have a problem with this, but it's easy for a programmer to pick the wrong one--in fact, it happens all the time. By using completely different algorithms under the hood but maintaining the same interface, Java makes it easy for programmers to use the wrong algorithm and never know it.
There's nothing wrong with Strings being UNICODE provided the only thing you're storing in them is text that's written in some human-readable language. A char* or char[] in C often contains data as opposed to Chinese. I see nothing wrong with promoting data to UNICODE as needed, but I don't see why I should double my storage requirements otherwise.
In that link you oh-so-cleverly pointed out, do you see any way to DRAW it? No? Well, that's because you found a class that REPRESENTS the idea of a pixel, but isn't ACTUALLY a "picture element". Yes, Java has a lot of classes, so it's confusing when you're searching for the right one. Try again and get back to me when you find something that can draw to a computer screen. (hint: it can also draw lines, squares, circles, etc., etc., as I said before)
OO Programming in Perl is some bizarre hack they added on later. I don't entirely understand what they're doing, but then, I don't have to use it either. By "bizarre semantics", I'm not talking about syntax here--you can get rid of that with a tokenizer. The problems I have with Java go far deeper than that.
I agree with you about the networking--networking in C can get pretty nasty. I haven't done any database access in Java, but I know that a lot of work has been done in that area. My take on Java is that it's sort of a modern-day cross between Pascal and Visual Basic. It imposes bizarre restrictions on the programmer (in the sense that people used to complain about Pascal's strong typing, but far worse) and it tries to have tons of ready-made algorithms and classes built-in to make life easier, apparently to make up for deficiencies in the language that make it a pain to do these things yourself.
There probably are some things in the API that would make my life easier (but what are the odds that I would find them:), or more likely some third-party system library-like classes that hide some of the nastiness. But fortunately I don't have to program in Java for a living, and I don't plan on doing too much more dabbling with it if I can help it. However, I'll leave you to it.:)
Yes, it's obvious that they had some leanings towards operator overloading simply due to the way they also use + for string concatenation. (never mind that anyone who knows what + actually does there will tell you not to use it anyhow because it's slow...) But naturally this is, again, one of those features that is handy enough that they don't mind doing it themselves, because they know what they're doing, but they wouldn't dare unleash it upon the world.
Think of the consequences--someone might write an arbitrary precision number library that allows for code that looks like "2 * 3 + 4 / 5" -- no, that must never be, it would be too useful and obvious!
As far as the 80 columns difficulties, quit blaming the language and get a better editor -- you know, the kind that can fit more than 80 columns per row or intelligently wrap the lines. Why anyone codes with console-based vi or emacs these days, I will never understand.
This explains so much--thank you. I have often wondered why Java programmers can't seem to indent their code properly. I've even had trouble finding a good program to (re-)indent Java code. The main reason why I'd like to see programmers stick to 80 columns (or 120 even? please??) is because sometimes I might want to PRINT SOMETHING OUT.
However I realize that when you have code that looks like
it might be difficult to indent without introducing awkward spaces or unnecessary temporary variables, and you wouldn't want to disrupt the straightforward purity of the Java code itself! Actually, if you write all of your classes correctly, and your iterator functions and whatnot, maybe you can get your main program to one big long line that does everything you need. Say, 10,000 characters long.
But while we're enforcing semantics on the programmers, let's enforce specific editors or IDEs too! Do you have any suggestions, or an approved list of allowable console text editors? Does the editor have to be written in Java?
As always, with Java or C, YMMV--sometimes it just depends on what you're trying to do with the language in the first place, and if you haven't run into problems, well, congratulations. I admit I have little experience programming in Java, perhaps because I object to its particular variety of brain damage, but I'd be happy to go into a few of my pet peeves, just so you understand where I'm coming from.
Scope issues--have you ever used protected variables in C++? I think they're remarkably handy for both keeping a level of OO encapsulation and allowing descendants to get real work done later on. Let's say you want the same functionality in Java. I'll call the different kinds of scope here public (anyone can access a variable), private (only the class itself can access its own variable), package (one of the things Java added--anything in the package can access the variable) and class (that class and its descendants can access the variable).
Now, in C++ (since there are no packages) public variables have public scope, private variables have private scope, and protected variables have class scope. That is to say, to get a variable that only has class scope, all you have to do is make it protected. But in Java, protected variables have class AND package scope. Therefore, to make a class have protected variables, you have to give each class (and its descendants) its own unique package, which you'd have to keep track of manually.
But wait, it gets better... remember what I was saying about Java enforcing its own conventions on the programmer? Well, to create a package, you have to create a directory for that package. So, whereas before you could have one file that contained, say, your class with the protected variable and your main() routine and whatnot, now you have an extra package and directory to worry about... just for that variable! Want another class with protected variables? Make another package, create another directory, etc., etc., etc....
To reply to your questions about why Java would need macro preprocessing, I'd like to go into some of the philosophy that (to me, at least) seems to underly a lot of Java's design. You said it yourself--"Why does Java need...". Well, the answer is that for a particular feature, maybe Java doesn't need it at all for 99% of the time. And all of the features that the developers thought did more harm than good were purposely left out of Java. With prejudice. Macros are a good example of this. Because Java has such silly, long and inane naming conventions, I'd love to #define them all away and use something short and easy to remember. Even iostreams in C++ are better here--you can just use cin and cout for I/O; convenient, isn't it? I agree with you that using #define for inlining is of limited use today--most of the time the compiler does a pretty good job with that now.
A better example of this philosophy is goto. Even Dijkstra never advocated eliminating goto entirely from the language--he acknowledged that it has its uses. This is another case where 99% of the time you really shouldn't use it at all, but the other 1% of the time you'll miss it enough to switch to C++ or C. But the Java people didn't just not implement a goto statement and leave it at that. Oh no. They actually RESERVED THE KEYWORD AND LEFT IT UNIMPLEMENTED. To me, that just seems completely gratuitous, unnecessary, and unprofessional.
I agree with you that choosing the right algorithm can make far more difference than which language you choose, because the orders of magnitude difference in performance can make up for much sloppy programming in a higher-level language. And this is one of those reasons why Java is so confusing and dangerous. It has a lot of implementations of different, handy algorithms, that can all do the same tasks. And this has a high learning curve associated with it, I'd say even higher than learning the STL in C++. Since you didn't actually write this code yourself, you have to know (i.e., read the documentation or benchmark the implementation or both) how fast each operation is for a given task in each implementation to pick the right one. Also, it helps if you know what it does to your data along the way. For instance, the fact that Strings are UNICODE in Java might explain why a simple change can double your memory requirements.
Ok, how about graphics. Graphics are fun--Java has some built-in facilities for drawing primitives to the screen, something C doesn't have built into the language. Sure, you could use X, or SDL, or whatnot, but that's a whole 'nother kettle of fish. Well, you can draw lines, and boxes and circles in Java... but not pixels. There's no drawing primitive for a pixel. I think you could convert from one type of graphics object to another (that has pixels and nothing else) but only at a hefty penalty in speed and memory usage, and obviously if you wanted both, converting between the two would be highly silly. So the usual work-around is to draw a degenerate line or square or something, surely at great expense, since there is no pixel primitive, and no good way to add one. So much for OOP.
I like Perl quite a bit; it has a lot of higher-level language features, but it doesn't impose any bizarre semantics on me, or hide any features from me. It's a great tool for a C programmer to gain a lot of higher-level language features without losing the power and flexibility of C. Perl has something for everyone, even proper closures and lexically scoped variables, if you want them!
But yes, I agree that using the right tool at the right time is very important. My experience with Java has been far more trouble than it could ever possibly be worth, but perhaps I wasn't designing a networked GUI interface or something. I admit that there are many things that Java can do for you that are handy, and would require much work to implement in C. But there seem to be just as many things that it does that I would rather not have it do, and can find no easy way to make it stop.
Also, my foot shooting example wasn't meant to be taken literally, but rather in the spirit of the classic list of getting your feet shot in various different languages. If that wasn't clear, I apologize.
I agree with you that it's possible to speed up programs written in higher-level languages immensely by finding the bottlenecks and rewriting them in a lower level language, (profiling your code, the old fashioned way) but I find much of the rest of your bashing to be quite excessive.
I find that in higher-level languages, I spend less time debugging my code and more time debugging the system libraries and the language. In any complicated and changing system, there will be bugs, and there's far more code behind your average higher-level programming language, especially when it's new, not extensively tested, and not well-understood. i.e., your average C compiler will behave much more predictably than your average Java compiler, and if you screw something up in Assembler, rest assured, it's probably your fault.
How are iostreams more portable than stdio.h? Do you mean portable in that it hides more implementation details, or portable in that it runs on more platforms? I'll agree with you on the former, although that isn't always a good thing, but never on the latter.:)
As for C's #ifdef facility, I like it a lot. In fact, I sincerely wish Java had some form of macro preprocessing, because occasionally, I need it. I'm sick of Java programmers whining about how "macros are confusing"--if they lack the intelligence to run the source through the preprocessor in the first place, then... it might explain a lot about their Java coding.
But this goes right back to using the right tool for the job, and not reinventing the wheel--if I needed to implement some sort of portable, network-aware program in C, I'd probably look for some sort of portable, network-aware LIBRARY that's already ported to the intended platforms.
There's nothing wrong with quickly testing out an implementation in a higher-level language, but depending on what you're doing, you still might want to re-code all or parts of it in C. And all languages have their warts, especially depending on what you're used to doing or having. I wish C compilers had a standard facility for hashes and did proper tail-recursion optimizations--but then I also wish Java wasn't so crippled, bloated, and slow (to say nothing about typecasting, scope problems, enforcing its own naming conventions, etc., etc.), OOP in C++ wasn't so whacky, and I wouldn't mind if Perl's type system were a bit cleaner, or if PHP implementations could be more consistent between versions, etc., etc., etc.:)
So, yes, use the right tool for the job. But don't kid yourself--you'll be banging your head against that higher-level language a lot anyhow, and likely for different reasons, sometimes completely unrelated to your program. After doing that for a while, I'd much rather know I'm shooting my own foot in C or Assembler instead of having my shot foot anonymously instantiated by some cryptic and unnecessary higher-level language 'feature'.
Actually, Anonymous Coward is pretty accurate here; Rusty *does* have donated hardware and servers, and he doesn't have a real job, which is why he asked the people at Kuro5hin to pay him.
But you're right that Rusty is the soul of courtesy; I didn't mind giving him my $4 at all (for 4 months of "membership) and obviously other people didn't mind donating quite a bit more.
Ok, so where's the troll here? Is it the fact that I can run the NWN Client in Wine, the fact that you need the nocd crack, or the fact that the NWN Client crashes sometimes?
Oh, it's the $3 crack; I'm sorry... can I have some?
I can run the NWN Client under Linux *right now* in Wine. The only thing you need to make it work is the nocd crack, because Wine doesn't like the direct CD-ROM access that the copy protection uses.
But other than that it works decently; it crashes occasionally, but so does the real thing, right? At least this doesn't bring your whole system down...
What this says is that if Einstein had this idea floating around in his head for decades, and then got a job with a company (in this modern world), and mentioned his pet theory to someone at work and they were interested, he could get HIS idea sued out of him and patented by the company, and they can proceed to patent and use his idea (and make him pay for it!) while they leave their competition in the dust, and leave the rest of their field in The Dark Ages.
Don't we have any laws to protect THE RESEARCHER who actually comes up with his own ideas anymore? You know, like it says in that Constitution document that everyone ignores? And for that matter, what about enriching the scientific community instead of the corporations? Did we all just forget about that in our mad dash to acquire the Holy and All-Powerful Dollar?
Anyone who could perform or support an act like this has no sense of ethics in the first place, which includes at least one major corporation, a bunch of lawyers, and a judge; I'm not surprised at all. So call the thought police on me already, I'm guilty.
Here's a sure-fire way to confound junk faxers and spammers alike:
1) Harvest phone numbers from spam e-mails and e-mails from junk faxes. (you can find these online)
2) Figure out where spammers and faxers get their information from and flood these locations with the e-mails and phone numbers you find; USENET and message boards (like slashdot!) are good for this.
3) Wait for the faxers to start faxing the spammers, and for the spammers to start e-mailing the faxers.
I should probably warn you that RHIDE works *much* better under DOS; I didn't like the Linux port very much, although I think there are some patches out there to make it more stable.
I haven't really tried SetEdit, but it looks good--I can only hope it's more stable...
Then definitely check out RHIDE and SetEdit; all should know about the glory of Borland-style IDEs!
I used the Control-K commands up through Turbo Pascal 5.5 or so; I'm sure that lives on, or something like it... And originally I was stuck with "edlin" and whatever built-in editors were in my programming tools (Turbo BASIC, Turbo Pascal, and later QBASIC and DOS Edit), and used "Leading Edge Word Processing" to write papers. I don't think I really had a stand-alone editor on my C64, but I did have a cheesy publishing program... And yeah I used COPY CON for batch files; didn't everyone?
My absolute favorite programming IDE ever was Borland Turbo Pascal 7.0; therefore, I'm a sucker for any editor written in TurboVision, like RHIDE or SetEdit.
DOS Edit is still pretty decent in the console; on the GUI side, NoteTab is a notepad replacement on steroids (the "Light" version is free).
If you download Cygwin, you can compile almost any UNIX-y text editor you want, including my favorite--nano.
In general this wouldn't be necessary because journals have an obligation to present the facts and correct themselves as needed. Slashdot rarely reflects these practices, however, and many other online equivalents of pen-and-paper journals are sorely lacking in their journalism.
However, people and organizations can still be sued for slander and libel, even under the First Amendment. I think that organizations that purport to report the News have an obligation to report the facts accurately, and should be held to a higher standard than are individuals.
I'm arguing that the headline is negligent and misleading, and should be corrected. Every minute that goes by when it isn't misleads and confuses another person who might have expected news or accurate reporting. Many people have come to expect this sort of inaccurate reporting from slashdot, but that doesn't excuse it.
Perhaps they could have an "editor" on duty whose job it is to "edit"?
He was convicted of selling 413 pirated video games and Playstation mod-chips. How do I know this? Well, first, I read the article; second, I know that there aren't 413 GAMES available for the Playstation 2!
Also, the PS/2 is a computer from IBM, and does not require mod chips to play pirated games. Sony doesn't call their Playstation 2 the PS/2, perhaps because they don't want to get sued. Does slashdot want to get sued? Well, it'd be nice to have some penalties for irresponsible journalism... Finally, considering the facts of the case, it is disingenuous for the writers of this article to call it a conviction for selling mod-chips, since that wasn't all it was.
In conclusion, all you journalists are lazy, illiterate, and incompetent. If you don't agree with me, prove me wrong by writing something accurate, intelligent, or interesting.
Slashdot Mirror
Just like the good old days...
It's nice to see some people defending the right to have a useful e-mail account--maybe one day (far in the future) we can reclaim USENET and the web too...
Syntax is entirely a matter of opinion, and anyone who gets hung up on it is being shallow; (or can't figure out how to write a pre-processor...) this was the one thing that completely baffled me in the old C/Pascal debates. Even at the time, there were translators available to convert Pascal to C, and they did an ok job, so quibbling about the syntax (and not the language features) seemed completely useless and absurd to me...
Even though perl can *look* quite ugly, it's actually a very powerful and fully-featured language, with all (most?) of the features of the classic functional languages, except that they're optional. Anyone who objects to perl based on the syntax alone is just being shallow, and should probably spend some time writing a pre-processor for perl in perl so they can make it look "pretty" (whatever they think is pretty, that is--I think Java is pretty ugly).
I've been spending a lot of time programming in PHP lately, and although my code might be more readable, (especially to someone with just a C programming background) I spend a lot more time working around quirks in PHP (either version issues, library functions, or design flaws... sometimes all three!) than I ever would in Perl.
However, the repositories do make all the difference. Although there isn't quite as much out there for PHP as there is for Perl, there's still a substantial amount, and that helps make it all bearable.
I did this for a while when I had my P133 as my old system. And I agree with you in principle--there should be some *testing* done on multiple hardware platforms.
:)
However, your application should be OPTIMIZED for whatever people are likely to have. And if you just code your app on one machine and never try it out on anything else, it might be an order of magnitude slower than it should be because you unwittingly optimized it for the machine you were on. (trust me, I've seen this happen, for example when the bottleneck was the cache on the K6's vs. on the P]['s.)
And, as someone else said, P133's make a sucky development platform these days. Just as I wouldn't expect you to do graphics work on one, (although I did do a lot of work on one in The GIMP back in the day...) you shouldn't expect us to do our compiling on one... just some testing.
Sounds powerful, like C++'s templates, or closures.
Of course, Java doesn't have any of the above, so even C's macro system would be an improvement, let alone LISP's macro system.
Many Lisp implementations are now written in C--Film at 11!
Believe it or not, we've gone a long way from car and cdr being register mnemonics.
My numeric example wasn't meant to say that you should use Java to do high-performance arbitrary precision number manipulation, but rather to mention that this is an area where operator overloading makes the interface much more natural. I already that the + operator has its shortcomings in concatenation, but it is nice to see that this is (still) common knowledge.
;)
I haven't seen that particular code beautifier--when I was searching for one, I found one that understood and formatted many different languages (at least somewhat), primarily for printing. And it did an ok job with Java, except when it couldn't manage to decently break a line of code up in the first place--this is primarily due to the godAwfullyLongIdentifiers that are commonly used in Java.
You're right that my example could be broken up through the judicious use of temporary variables, as I've already mentioned. But I know of no code beautifier that actually modifies your source code so as to change its meaning, and if I found one, I probably wouldn't want to use it in the first place.
I actually wasn't referring to any particular Java method in that example by the way, but attempting to emulate the sort of identifiers commonly found in a Java program. I think that writing code like that (all on one line, and accessing the results of functions as objects, etc., etc.) is a particularly ugly way to write Java code, but it's common enough, and IMHO it makes the code harder to read, indent, and understand.
I don't think that 80 columns is necessarily some magic number that *has* to be enforced, but I think it's a nice rule of thumb, especially for printing. I'd go as far as perhaps 120 columns, but with 80 columns as a strong preference. Still, even 120 columns isn't wide enough for some code...
I often use console-based editors, sometimes on actual consoles. And I wouldn't ask anyone to change their preferred editor, yea, even for Java programming, unless I had some awesome development environment to suggest. Usually I use nano or pico, actually, due to an old preference for simple console editors, probably a hold-over from my DOS programming days. For an IDE, I'd have to recommend RHIDE, again due to my days using TurboVision-based IDEs. But of course this is entirely my personal preference.
The automatic documentation generators in the style of JavaDoc did get quite popular, and started springing up on every language, almost overnight. I think that's one great contribution Java has made to the community, intentionally or not. I guess you need good documentation when you can't decently indent, format, and print your code...
First, to get "private protected" semantics, you can't just use an anonymous package, you have to create another package to encapsulate the class in the first place.
:), or more likely some third-party system library-like classes that hide some of the nastiness. But fortunately I don't have to program in Java for a living, and I don't plan on doing too much more dabbling with it if I can help it. However, I'll leave you to it. :)
Re: assigning System.out to an object, sure that works, but you have an extra temporary variable; not horrible, but a bit ugly.
I don't mind reading documentation; I'm merely pointing out that when you have as many container implementations, it'll take a while to figure out which one is best for the task at hand, and what the pros and cons of each one are. I personally don't have a problem with this, but it's easy for a programmer to pick the wrong one--in fact, it happens all the time. By using completely different algorithms under the hood but maintaining the same interface, Java makes it easy for programmers to use the wrong algorithm and never know it.
There's nothing wrong with Strings being UNICODE provided the only thing you're storing in them is text that's written in some human-readable language. A char* or char[] in C often contains data as opposed to Chinese. I see nothing wrong with promoting data to UNICODE as needed, but I don't see why I should double my storage requirements otherwise.
In that link you oh-so-cleverly pointed out, do you see any way to DRAW it? No? Well, that's because you found a class that REPRESENTS the idea of a pixel, but isn't ACTUALLY a "picture element". Yes, Java has a lot of classes, so it's confusing when you're searching for the right one. Try again and get back to me when you find something that can draw to a computer screen. (hint: it can also draw lines, squares, circles, etc., etc., as I said before)
OO Programming in Perl is some bizarre hack they added on later. I don't entirely understand what they're doing, but then, I don't have to use it either. By "bizarre semantics", I'm not talking about syntax here--you can get rid of that with a tokenizer. The problems I have with Java go far deeper than that.
I agree with you about the networking--networking in C can get pretty nasty. I haven't done any database access in Java, but I know that a lot of work has been done in that area. My take on Java is that it's sort of a modern-day cross between Pascal and Visual Basic. It imposes bizarre restrictions on the programmer (in the sense that people used to complain about Pascal's strong typing, but far worse) and it tries to have tons of ready-made algorithms and classes built-in to make life easier, apparently to make up for deficiencies in the language that make it a pain to do these things yourself.
There probably are some things in the API that would make my life easier (but what are the odds that I would find them
Think of the consequences--someone might write an arbitrary precision number library that allows for code that looks like "2 * 3 + 4 / 5" -- no, that must never be, it would be too useful and obvious!
This explains so much--thank you. I have often wondered why Java programmers can't seem to indent their code properly. I've even had trouble finding a good program to (re-)indent Java code. The main reason why I'd like to see programmers stick to 80 columns (or 120 even? please??) is because sometimes I might want to PRINT SOMETHING OUT.
However I realize that when you have code that looks likeit might be difficult to indent without introducing awkward spaces or unnecessary temporary variables, and you wouldn't want to disrupt the straightforward purity of the Java code itself! Actually, if you write all of your classes correctly, and your iterator functions and whatnot, maybe you can get your main program to one big long line that does everything you need. Say, 10,000 characters long.
But while we're enforcing semantics on the programmers, let's enforce specific editors or IDEs too! Do you have any suggestions, or an approved list of allowable console text editors? Does the editor have to be written in Java?
As always, with Java or C, YMMV--sometimes it just depends on what you're trying to do with the language in the first place, and if you haven't run into problems, well, congratulations. I admit I have little experience programming in Java, perhaps because I object to its particular variety of brain damage, but I'd be happy to go into a few of my pet peeves, just so you understand where I'm coming from.
Scope issues--have you ever used protected variables in C++? I think they're remarkably handy for both keeping a level of OO encapsulation and allowing descendants to get real work done later on. Let's say you want the same functionality in Java. I'll call the different kinds of scope here public (anyone can access a variable), private (only the class itself can access its own variable), package (one of the things Java added--anything in the package can access the variable) and class (that class and its descendants can access the variable).
Now, in C++ (since there are no packages) public variables have public scope, private variables have private scope, and protected variables have class scope. That is to say, to get a variable that only has class scope, all you have to do is make it protected. But in Java, protected variables have class AND package scope. Therefore, to make a class have protected variables, you have to give each class (and its descendants) its own unique package, which you'd have to keep track of manually.
But wait, it gets better... remember what I was saying about Java enforcing its own conventions on the programmer? Well, to create a package, you have to create a directory for that package. So, whereas before you could have one file that contained, say, your class with the protected variable and your main() routine and whatnot, now you have an extra package and directory to worry about... just for that variable! Want another class with protected variables? Make another package, create another directory, etc., etc., etc....
To reply to your questions about why Java would need macro preprocessing, I'd like to go into some of the philosophy that (to me, at least) seems to underly a lot of Java's design. You said it yourself--"Why does Java need...". Well, the answer is that for a particular feature, maybe Java doesn't need it at all for 99% of the time. And all of the features that the developers thought did more harm than good were purposely left out of Java. With prejudice. Macros are a good example of this. Because Java has such silly, long and inane naming conventions, I'd love to #define them all away and use something short and easy to remember. Even iostreams in C++ are better here--you can just use cin and cout for I/O; convenient, isn't it? I agree with you that using #define for inlining is of limited use today--most of the time the compiler does a pretty good job with that now.
A better example of this philosophy is goto. Even Dijkstra never advocated eliminating goto entirely from the language--he acknowledged that it has its uses. This is another case where 99% of the time you really shouldn't use it at all, but the other 1% of the time you'll miss it enough to switch to C++ or C. But the Java people didn't just not implement a goto statement and leave it at that. Oh no. They actually RESERVED THE KEYWORD AND LEFT IT UNIMPLEMENTED. To me, that just seems completely gratuitous, unnecessary, and unprofessional.
I agree with you that choosing the right algorithm can make far more difference than which language you choose, because the orders of magnitude difference in performance can make up for much sloppy programming in a higher-level language. And this is one of those reasons why Java is so confusing and dangerous. It has a lot of implementations of different, handy algorithms, that can all do the same tasks. And this has a high learning curve associated with it, I'd say even higher than learning the STL in C++. Since you didn't actually write this code yourself, you have to know (i.e., read the documentation or benchmark the implementation or both) how fast each operation is for a given task in each implementation to pick the right one. Also, it helps if you know what it does to your data along the way. For instance, the fact that Strings are UNICODE in Java might explain why a simple change can double your memory requirements.
Ok, how about graphics. Graphics are fun--Java has some built-in facilities for drawing primitives to the screen, something C doesn't have built into the language. Sure, you could use X, or SDL, or whatnot, but that's a whole 'nother kettle of fish. Well, you can draw lines, and boxes and circles in Java... but not pixels. There's no drawing primitive for a pixel. I think you could convert from one type of graphics object to another (that has pixels and nothing else) but only at a hefty penalty in speed and memory usage, and obviously if you wanted both, converting between the two would be highly silly. So the usual work-around is to draw a degenerate line or square or something, surely at great expense, since there is no pixel primitive, and no good way to add one. So much for OOP.
I like Perl quite a bit; it has a lot of higher-level language features, but it doesn't impose any bizarre semantics on me, or hide any features from me. It's a great tool for a C programmer to gain a lot of higher-level language features without losing the power and flexibility of C. Perl has something for everyone, even proper closures and lexically scoped variables, if you want them!
But yes, I agree that using the right tool at the right time is very important. My experience with Java has been far more trouble than it could ever possibly be worth, but perhaps I wasn't designing a networked GUI interface or something. I admit that there are many things that Java can do for you that are handy, and would require much work to implement in C. But there seem to be just as many things that it does that I would rather not have it do, and can find no easy way to make it stop.
Also, my foot shooting example wasn't meant to be taken literally, but rather in the spirit of the classic list of getting your feet shot in various different languages. If that wasn't clear, I apologize.
I agree with you that it's possible to speed up programs written in higher-level languages immensely by finding the bottlenecks and rewriting them in a lower level language, (profiling your code, the old fashioned way) but I find much of the rest of your bashing to be quite excessive.
:)
:)
I find that in higher-level languages, I spend less time debugging my code and more time debugging the system libraries and the language. In any complicated and changing system, there will be bugs, and there's far more code behind your average higher-level programming language, especially when it's new, not extensively tested, and not well-understood. i.e., your average C compiler will behave much more predictably than your average Java compiler, and if you screw something up in Assembler, rest assured, it's probably your fault.
How are iostreams more portable than stdio.h? Do you mean portable in that it hides more implementation details, or portable in that it runs on more platforms? I'll agree with you on the former, although that isn't always a good thing, but never on the latter.
As for C's #ifdef facility, I like it a lot. In fact, I sincerely wish Java had some form of macro preprocessing, because occasionally, I need it. I'm sick of Java programmers whining about how "macros are confusing"--if they lack the intelligence to run the source through the preprocessor in the first place, then... it might explain a lot about their Java coding.
But this goes right back to using the right tool for the job, and not reinventing the wheel--if I needed to implement some sort of portable, network-aware program in C, I'd probably look for some sort of portable, network-aware LIBRARY that's already ported to the intended platforms.
There's nothing wrong with quickly testing out an implementation in a higher-level language, but depending on what you're doing, you still might want to re-code all or parts of it in C. And all languages have their warts, especially depending on what you're used to doing or having. I wish C compilers had a standard facility for hashes and did proper tail-recursion optimizations--but then I also wish Java wasn't so crippled, bloated, and slow (to say nothing about typecasting, scope problems, enforcing its own naming conventions, etc., etc.), OOP in C++ wasn't so whacky, and I wouldn't mind if Perl's type system were a bit cleaner, or if PHP implementations could be more consistent between versions, etc., etc., etc.
So, yes, use the right tool for the job. But don't kid yourself--you'll be banging your head against that higher-level language a lot anyhow, and likely for different reasons, sometimes completely unrelated to your program. After doing that for a while, I'd much rather know I'm shooting my own foot in C or Assembler instead of having my shot foot anonymously instantiated by some cryptic and unnecessary higher-level language 'feature'.
Actually, Anonymous Coward is pretty accurate here; Rusty *does* have donated hardware and servers, and he doesn't have a real job, which is why he asked the people at Kuro5hin to pay him.
But you're right that Rusty is the soul of courtesy; I didn't mind giving him my $4 at all (for 4 months of "membership) and obviously other people didn't mind donating quite a bit more.
Ok, so where's the troll here? Is it the fact that I can run the NWN Client in Wine, the fact that you need the nocd crack, or the fact that the NWN Client crashes sometimes?
Oh, it's the $3 crack; I'm sorry... can I have some?
I can run the NWN Client under Linux *right now* in Wine. The only thing you need to make it work is the nocd crack, because Wine doesn't like the direct CD-ROM access that the copy protection uses.
But other than that it works decently; it crashes occasionally, but so does the real thing, right? At least this doesn't bring your whole system down...
What this says is that if Einstein had this idea floating around in his head for decades, and then got a job with a company (in this modern world), and mentioned his pet theory to someone at work and they were interested, he could get HIS idea sued out of him and patented by the company, and they can proceed to patent and use his idea (and make him pay for it!) while they leave their competition in the dust, and leave the rest of their field in The Dark Ages.
Don't we have any laws to protect THE RESEARCHER who actually comes up with his own ideas anymore? You know, like it says in that Constitution document that everyone ignores? And for that matter, what about enriching the scientific community instead of the corporations? Did we all just forget about that in our mad dash to acquire the Holy and All-Powerful Dollar?
Anyone who could perform or support an act like this has no sense of ethics in the first place, which includes at least one major corporation, a bunch of lawyers, and a judge; I'm not surprised at all. So call the thought police on me already, I'm guilty.
Here's a sure-fire way to confound junk faxers and spammers alike:
1) Harvest phone numbers from spam e-mails and e-mails from junk faxes. (you can find these online)
2) Figure out where spammers and faxers get their information from and flood these locations with the e-mails and phone numbers you find; USENET and message boards (like slashdot!) are good for this.
3) Wait for the faxers to start faxing the spammers, and for the spammers to start e-mailing the faxers.
Problem solved.
So compile it with Cygwin, and then just distribute the binary along with CYGWIN1.DLL; this generally works...
I should probably warn you that RHIDE works *much* better under DOS; I didn't like the Linux port very much, although I think there are some patches out there to make it more stable.
I haven't really tried SetEdit, but it looks good--I can only hope it's more stable...
Then definitely check out RHIDE and SetEdit; all should know about the glory of Borland-style IDEs!
I used the Control-K commands up through Turbo Pascal 5.5 or so; I'm sure that lives on, or something like it...
And originally I was stuck with "edlin" and whatever built-in editors were in my programming tools (Turbo BASIC, Turbo Pascal, and later QBASIC and DOS Edit), and used "Leading Edge Word Processing" to write papers. I don't think I really had a stand-alone editor on my C64, but I did have a cheesy publishing program...
And yeah I used COPY CON for batch files; didn't everyone?
My absolute favorite programming IDE ever was Borland Turbo Pascal 7.0; therefore, I'm a sucker for any editor written in TurboVision, like RHIDE or SetEdit.
DOS Edit is still pretty decent in the console; on the GUI side, NoteTab is a notepad replacement on steroids (the "Light" version is free).
If you download Cygwin, you can compile almost any UNIX-y text editor you want, including my favorite--nano.
And if all else fails, Ask Google!
Dewey Wins!
:)
It may not be a crime, but it's criminal...
No; I was going for any or all of the above, but more importantly, better than this article. :)
In general this wouldn't be necessary because journals have an obligation to present the facts and correct themselves as needed. Slashdot rarely reflects these practices, however, and many other online equivalents of pen-and-paper journals are sorely lacking in their journalism.
However, people and organizations can still be sued for slander and libel, even under the First Amendment. I think that organizations that purport to report the News have an obligation to report the facts accurately, and should be held to a higher standard than are individuals.
I'm arguing that the headline is negligent and misleading, and should be corrected. Every minute that goes by when it isn't misleads and confuses another person who might have expected news or accurate reporting. Many people have come to expect this sort of inaccurate reporting from slashdot, but that doesn't excuse it.
Perhaps they could have an "editor" on duty whose job it is to "edit"?
He was convicted of selling 413 pirated video games and Playstation mod-chips.
How do I know this? Well, first, I read the article; second, I know that there aren't 413 GAMES available for the Playstation 2!
Also, the PS/2 is a computer from IBM, and does not require mod chips to play pirated games. Sony doesn't call their Playstation 2 the PS/2, perhaps because they don't want to get sued. Does slashdot want to get sued? Well, it'd be nice to have some penalties for irresponsible journalism...
Finally, considering the facts of the case, it is disingenuous for the writers of this article to call it a conviction for selling mod-chips, since that wasn't all it was.
In conclusion, all you journalists are lazy, illiterate, and incompetent. If you don't agree with me, prove me wrong by writing something accurate, intelligent, or interesting.