This is a list of reasons why I personally hate Java. They're not all rational, but hatred seldom is... Three points I would like to make up front. 1. I *know* Java is the best choice for certain things. 2. Please don't bother telling me all the drawbacks of C++ in reply. Believe me, I am aware of many glaring flaws with C++, it's just that I've learned to live with these flaws. If I had learned java before C++ I'm sure I would find those flaws less tolerable. 3. I'm not a Java newbie. I learned it 5 years ago, and I used it nearly full time commercially for the last 2 years, (recently returned to C++ with a huge sigh of relief)
Firstly, the IRRATIONAL REASONS (that I'm aware of):
It took me years to learn all the pitfalls in C++, and then some bastard comes out with a lanaguage in which many of those pitfalls are removed. This makes that time more likely to have been wasted and makes my skills less valuable. Don't bother telling me that this mentality is selfish, stupid and short-sited, I'm well aware of this. ------------------------------------------------ ------------------
I've gotten burnt too many times with Java to trust anything I'm told without trying it myself (eg - bug fixed, performance improved, memory leaks). I started learning about Java as soon as it came out, before books were available etc. I was terribly excited by the chance of something to break MS hedgemony, so I was initially enthusiastic. That enthusiasm has worn off, and then some, which is why I now sound so bitter about the whole thing.
Java 1.0 was God awful, and the time spent learning how to overcome it's shortcomings was a total waste of time. Other equally important libraries have changed so much to require any old (2years+) java code to need total rewriting. Yeah, yeah, I know, what do you expect with bleeding edge technology, but it was managed badly, and Sun flat lied about these issues from the beginning.
------------------------------------------------ ------------------ I don't like the default style of the code:
public ZipEntry getNextEntry() throws IOException { if (entry != null) { closeEntry(); } ... }
I prefer matched brackets, (the extra lines are worth the additional clarity methinks) and I prefer this_style to thisStyle as a purely arbitrary preference.
public ZipEntry get_next_entry() throws IOException { if (entry != null) { close_entry(); } ... }
------------------------------------------------ ------------------ Sun's behaviour with Java
has been pretty disgusting at times. For instance they delayed providing a Linux version of the JDK for as long as possible. They spread vast amounts of disinformation and pro Java FUD. They made thousands of misleading statements wrt performance and stability and seem to have effectively brainwashed a whole generation of students as to the benefits of Java compared to other languages. The number of clueless little student wankers I've heard regurgitating Sun's propoganda...
For some reason people give more credence to what Sun says about Java compared to other langauges than they give to what Microsoft says about Windows compared to other OS'es, but the same level of objectivity and accuracy has been used.
Sun has done plenty of other boneheaded things with Java, but the misinformation thing is the one that irritates me most.
The other obvious mistake is that Sun never tried to use Java to obtain a level playing field. It wanted to keep control and replace MS. If they had completely opened up Java initially then it would be a different story by now.
Java isn't a bad language, but it's not "all that" either. IMO ML and Eiffel are preferable aesthetically while C/C++ is preferable for practical engineering today. I think Java is an excellent training langauge, an OO equivalent of Pascal.
I can understand the motivation for declaring the exceptions thrown in method declarations, but I'm not convinced it's a good idea. The whole point of exceptions is to localize the pain of dealing with weird occurences rather than pass the pain up the call stack in the form of checking return values everywhere.
With java, you constantly have to work your way up the call stack adding extra exception declarations to methods. It's very tempting to either not bother throwing the exception or just trap it inappropriately rather than editing half a dozen files up the call stack. It's almost as much work as the old C paradigm of checking return values everywhere.
This argument is kinda weak, I know you don't need to declare Error exceptions in method declarations, and in some ways it's a good thing that it makes you think about the fact that an exception could be thrown, I guess it depends on what you're used to. ------------------------------------------------ ------------------ ------------------------------------------------ ------------------ RATIONAL REASONS for disliking Java. (I mean reasons that I don't already know are irrational) ------------------------------------------------ ------------------ Java is slow.
I don't care how many benchmarks Sun comes out with claiming the latest JIT has "C++ level performance". It's just not fucking true. While we're on that subject, these benchmarks always show considerable difference between C++ and C level performance. You only see a significant difference in performance between C and C++ for a given task if either (a) the C++ programmer didn't care about performance or (b) the C++ programmer was stupid, in which case all bets are off. You can write hand crafted assembly that's slower than Java if you're stupid enough.
A uncontrived comparison is at http://sprout.stanford.edu/uli/java_cpp.html In summary, with HotSpot 1.3 beta, (a JIT that Sun touted as being faster than C++ !!) Java was roughly 5 times slower than C++.
The performance hit from Java comes more from it's crappy libraries (Swing anybody) than the JIT aspects. Bounds checking, garbage collection, and inherent overhead of OO techniques all cause a performance hit, but the real trouble comes from crappy libraries that put 10 levels of indirection between a request and it's implementation.
For instance the String class being written with 16 bit characters to make it unicode friendly when 98% of the java code written never uses this feature but it still requires twice the time and space for every operation. Also Strings are not alterable so to alter a character you create a new StringBuffer object, copy everything, make an adjustment, then replace the old reference with the new so the old object eventually gets passed to garbage collection... all compared to buf[i]= 'a'; (C or C++). It's crap like this that really makes Java seem so slow, not the JIT hit.
Basically Java is slow for the same reason that Windows sys admin is slower than Linux sys admin. You don't trust the user with the rm command or trust the programmer with pointers - show him an idiot box if he tries to delete a file or bounds check that array access for him. It's one way of doing things, but it sure isn't efficient.
------------------------------------------------ ------------------ Missing language features (compared to C++)
* templates No, just because everything is derived from Object, does not mean you don't need them. Writing container classes for Object is equivalent to writing container classes for void * in C++. You can do it, but it's not ideal. Besides templates are useful for more than just container classes. See http://oonumerics.org/blitz/ for an advanced example.
* enum Java is meant to have stricter type checking than C++. It seems like the kinds of mistakes an experienced engineer hardly ever makes are guarded against, but the kinds of mistakes that people are likely to make are more likely in Java because of the lack of enums or templates. The only reason for their absence is the added complication - that only makes sense in a training language.
* multiple inheritance Interfaces are pretty good, but MI is more powerful and abstract virtual inheritance if equivalent to interface, so interfaces are subset of MI.
* preprocessor "not needed because Java is platform independent" - hahaha. No it fucking isn't, but a more common need for the preprocessor would be to ease the pain of version changes. You either end up with duplicated code bases or you hack your own preprocessor on to javac, or you deal with a minor headache for every minor version change or a huge headache for major version changes (1.1 -> 1.2 or 2.0 as it's now called).
It's even more striking if you're working with matrices and vectors etc, but I've thankfully managed to avoid the pain of doing that in java.
Now we get into the "these language features can be abused" argument. It's easy to show examples of the dangers of misusing MI or operators. I think this is pure packer mentality. You cannot make programming idiot proof and it's a mistake to try. This mentality pervades java and is probably the single thing that really makes me hate it. The notion that you prevent everyone from doing something because "some people abuse it" drives me crazy. ------------------------------------------------ ------------------ Verbosity
Java code just tends to be longer than the equivalent in C, C++, perl or ML (unless of course you're implementing something that is nicely covered in the libaries)
There are several reasons for this.
Insistence on using OO paradigm all the time. Missing language features (especially operator overloading) choice: boolean Concept.Conventions.StyleGuide.LongFunctionNamesDe sirable() { returns true; }
This relates to something I've never fully understood. Several people who's opinion I respect insist that they can develop stuff faster with Java than with C++. If they really know C++ I just don't understand this, unless they are comparing old (pre-STL) C++ with modern (post-collections)java. The other possibility is that they have been using MFC, a piece of code so vile, that I can barely speak it's name.
I can see that if you're working on a project where (2 or more apply): threads are important; has to work on multiple platforms; requires functionality that JDK library classes cover well; is deployed over the internet; speed is not an issue; memory useage is not an issue; very precise control is not important; some team members are inexperienced;
then Java may well be the best choice.
However for implementing arbitrary fresh functionality I can develop far faster in C++ than java. For instance a fragment of a C++ program that reads in a file and gets a list of the starting positions for every word in the file:
Writing the equivalent in Java would take 20+ lines.
Now, I admit this is a contrived example, but do it the other way round - give me a nice piece of algorithmic code in Java, that is not dependent on some database/graphics/network library and I believe the equivalent C++ will almost always be smaller.
I don't like the JDK libraries much. This is mostly a maturity issue, but also it's a kind of OO at all costs mentality. For instance using NumberFormat & PrintWriter to create precisely formatted scientific output is immensly painful compared to using printf() (iostream's suck for this too).
"simple stuff should be easy and difficult stuff should be possible" Java libraries lose points on the first half, but are generally OK on second.
Using stuff like Dictionary is unpleasant compared to STL - there's no way to avoid this due to the lack of templates (BTW I am aware of Pizza, and this is definitely a step in the right direction, but unless Sun adopts Pizza it's not really worth bothering with).
I started on my last project before I knew about FLTK, and portability was an issue which was why I chose Java for the interface part of the project. Swing has quite a good design, but a shitty implementation. It's buggy as fuck, and seriously inefficient. Learning how to work around it's shortcomings is a right royal pain in the ass. It has gradually improved, but is still slow, leaky, bloated, buggy, and perverse in places. Stick a breakpoint in at any point in the code - the callstack will be at least 15 levels deep. It's still preferable to MFC though, which has shitty implementation coupled with *appalling* design.
Swing is wonderful compared to AWT, but I wish they had worked harder on stability and performance and less on features. Visual Basic based applications feel much faster than Swing even with the latest JIT.
------------------------------------------------ ------------------ Printing Why did they hardcode the output to 72dpi ??? It's just typical Java. You get the performance of 5 years ago on the latest hardware. Not a good use of Moore's law IMO. (There is a workaround to this using drawImage() but that has serious problems too...) ------------------------------------------------ ------------------ Tools
javac versus egcs/make, gdb v jdb, VisualC++ v. Jbuilder3 DDD v...er... DDD purify v JProbe quantify v JProbe
The C++ tools just have a greater polish.
This is an unfair comparison, since it's not really Java's fault and is just a matter of time. (Actually, the problems with JBuilder3 *are* java's fault. JBuilder3 is mostly written in Java and it shows. It's virtually unusable with less than 128Meg of RAM, 256M is recommended.)
Yes, Java is better for some things, that's why I sometimes use it. Your reply seemed to have tenuous relevence to what I was asking. If JOVE really is that fast, I want it.
The performance numbers came from my own testing, but a similar conclusion is available online: http://sprout.stanford.edu/uli/java_cpp.html
Why on earth do you think Java is closer to VB than C++ ? That's hardly a complement, and not really fair on Java. You can compile Java as C++ after minor mechanical translations (although you can't link it or run it that easily, since recreating JRE would take some work...). If you mean for RAD capabilities, it's the tool that matters - the language is not really the issue.
As for development time, it depends what you're doing . Some tasks can be done faster in Java, some faster in perl, some faster in C++. If you really want to get me ranting about Java, email me.
Have you actually used this puppy, or do you just believe the marketing gunk ?
Its hard to believe this - there are a *lot* of reasons why java is much slower than C/C++ let alone fortran - I've been using java off and on for 5 years. The fastest I've seen is jit for ibm jdk1.1.8 on NT which is about 5x slower than C++ equivalent.
The possibility that quantum effects pay a part in consciousness cannot be discounted so easily. Neurons are amplifiers, they fire above a certain threshold, so input just below the threshold and input just above the threshold result in different outcomes. This makes brains subject to quantum effects (unlike computers incidentally). Whether those quantum effects are important is unknown.
Given nature's tendancy to make the most out of whatever resources it has, I would say it is far more likely that quantum computation possibilities are exploited rather than ignored. Given two organisms, one that exploits quantum effects to improve it's processing power, and one that doesn't - the determinstic one would have an evolutionary disadvantage and die out.
Dennet's book is good, but he doesn't delve beyond a certain level. This may sound arrogant, but I don't give a fuck: I had already figured out the truth of what Dennett says before he published that book (with help from stuff I read by Susan Blackmoore). If you truly felt that he fulfilled the promise of the title, then you need to re-read it, it must have left you in a state of confusion.
Dennet avoids the more troubling implications of consciousness by deftly censoring the lines of reasoning that he allows himself to follow. His muliple minds model is correct - there is no cartesian theatre - but this still begs the question: what kinds of physical processes give rise to the thoughts one perceives ?
Following that path leads to surprising results, http://www.melloworld.com/Reciprocality/r4/addma t.html which I'm sure you'll find ridiculous. If you dislike my conclusions then tell me what's wrong with my reasoning rather than just telling me I'm wrong because you dislike the conclusion.
You think you're scientific, but I suspect you're just anti-spiritual. The difference is: science is interested in truth, and takes nothing for granted. Anti-spiritualists are those who take the abscence of any form of spiritual reality as a matter of faith which cannot be questioned. Any evidence disputing this faith is assumed wrong, since it leads to a conclusion they have already discarded. The anti-spiritualist mentality comes from the mistaken belief that you already has a basic understanding of everything.
Some laptops have a voltage switch for AC power. Make sure you're using the right one or you can screw up your power unit.
Get yourself a fuzz buster (radar detector) unless 55mph is acceptable to you, some small towns finance their sherrif departments by fining speeding motorists who are passing by.
Do you REALLY want to go to LA ? San Francisco is much nicer and the moron density is *far* lower.
Why not leave the computer at home !!! Try it for a month, it'll seem weird at first, but you'll see the world in more detail.
> This is jumbo metaphysics, there's absolutely zero science behind it.
How the *fuck* do you know. You haven't read the book, you know nothing about the author (who almost certainly knows a damn site more about quantum mechanics than you do). Yet you feel qualified to make assertions about the value of what he says because "it sounds ridiculous to me".
That doesn't sound very "scientific" to me. So I suppose that anything that "sounds ridiculous" must be rubbish and can be ridiculed without even reading it first . Somehow these comments strike a cord with the new slashdot and this gets moderated up to a 5.
This is *exactly* the attitude that holds humanity back. Every single advance in understanding goes through a period of ridicule while people who know nothing about anything heap scorn on the idea. It is the most cherished notion of the truly ignorant that they already understand everything. Any idea that is at odds with the orthodox opinion must be wrong.
The earth is round - ridiculous, everybody knows its flat. The earth revolves around the sun - ridiculous, just look at it. Mass is energy - ridiculous pseudo science coming from someone who "is no expert" in the field, just a patent clerk for heaven's sake.
PS, I haven't read this yet either, but I'm going to.
As another seasoned Swing developer I offer one right here. Forget about swing, use FLTK instead (http://www.fltk.org/ ) Shit, write it in COBOL, Visual Basic, assembly, anything but use Swing (er, except MFC which is even worse).
I've been using Swing for the last 2 years (since it first came out). It's slow, buggy, leaky, and did I mention slow. Check out the call stack at any point in a Swing program - it's about 15 levels deep.
Doubtless I'll be called a troll for this. Fine, fuck you too, but I do know what I'm talking about. I admit I'm kindof bitter about this, but if people had been honest about Swing before I got into it I would have been saved a ton of grief.
Where the hell did you get these figures ? What compiler, what OS, what architecture. They look *completely* out of line with every other test I've seen. Check out the JGL against STL comparison above for some real numbers.
For a start, what the hell is the difference between integer division in C or C++ - no compiler that I've heard of written in the last 5 years produces different code in these two cases.
Secondly - who remembers to turn on optimization: anybody who cares about performance and isn't completely stupid.
> it's particularly nice in large and sophisticated object models where you almost always lose track of who has a reference to what
Does this make anyone else nervous as heck. If you can't even keep track of when your objects should be deleted, how the hell do you keep track of anything. Increasing complexity requires more clarity of thought and design, not less. It's not the overhead of GC that bothers me, it's the sloppiness of thought it seems to encourage (try using JBuilder with less than 256Meg if you want to see what I mean).
In some languages (eg ML), you really are working at a different level of abstraction and then GC makes perfect sense, but it's not GC explicity that makes life easier.
The difference between theory and practice is that in theory there is no difference whilst in practice there is.
First off JIT is not java specific. Transmetas chip does a form of JIT on everything - even x86 assembly code. Your basic argument that JIT can be efficient is correct (not more efficient than humans, but I'll come to that).
The performance hit from Java comes far more from it's crappy libraries (Swing anybody) than the JIT aspects. Bounds checking, garbage collection, and inherent overhead of OO techniques all cause a performance hit, but the real trouble comes from crappy libraries written by crappy programmers who put 10 levels of indirection between a request and it's implementation.
For instance the String class being written with 16 bit characters to make it unicode friendly when 98% of the java code written never uses this feature but still requires twice the time and space for every operation. Also Strings are not alterable so to alter a character you create a new StringBuffer object, copy everything, make an adjustment, then replace the old reference with the new so the old object eventually gets passed to garbage collection... all compared to buf[i] = 'a'; (C or C++). It's crap like this that makes Java seem so slow, not the JIT hit.
Your argument about how JIT can outperform programmers because it has more information is flawed - any decent programmer will know where the spikes are and optimize accordingly. He will know what he can and can't do with the data, whilst the compiler has to take the strictest possible interpretation. Advanced optimization is too slow to do on the fly (although you can optimize the byte code to some extent with a decent javac, then optimize the translation with a JIT)
Garbage collection argument is silly too. In C/C++ or assembly, the programmer has a choice as to whether he uses the stack or the heap. It makes his life more complicated, but as long as he knows what he's doing it's inherently more efficient. If he doesn't know what he's doing then he's useless in any langauge. If you want to, you can use a garbage collector in assembly or C++, but it's not the only technique available to you.
Basically Java is slow for the same reason that Windows sys admin is slower than Linux sys admin. You don't trust the user with the rm command or trust the programmer with pointers - show him an idiot box if he tries to delete a file or bounds check that array access for him. It's one way of doing things, but it sure isn't efficient.
Of course, there's a difference between their OpenGL sample implementation and the private SGI OpenGL implementation (and the difference is... speed). Still, this is cool, although SGI could have saved themselves the grief of Microsoft's DirectX crap taking off if they had Open sourced this years ago. ( Amazing how generously giving stuff away just makes people like me whine.)
Now we just need OpenInventor open sourced, and there will be a real chance of DirectX biting the dust. (Novices find it far easier to put together interactive 3D apps with a decent scene graph implementation).
They don't crank out a few million lines. They crank out a few thousand that make the million obsolete.
OK, so nobody is going to rewrite SAP on their own, but SABRE I'm not so sure about. Almost all significant new developements comes from individuals or pairs of programmers. It happens all the time.
Unix - written by Ken Thompson and Dennis Ritchie, while 100s of programmers worked on Multics, and 1000s worked on MVCS.
dbx - the best debugger of it's time written by 1 guy, while 100s of people worked on xdb. It was not only more powerful, it had more functions.
Borland, Lotus, Linux, even fucking microsoft. Later on large organisations grow around the original innovation, but the *significant* software does NOT come from large teams.
Would I trust my life to a doctor who didn't know what they were doing ?
I would prefer not to. Unfortunately, I don't have any choice, since once the guy has qualified as a doctor, he can get away with gross incompetence for decades. The "ethics" of his "profession" mean that the worst thing a doctor can do is point out that another doctor is incompetent.
> Would you want the poor who can't afford the likes of Johnny Cochran to try their luck with public attourneys who might well not know the law well enough to see an obvious and powerful defense for their clients?
Exactly my point. Profession qualifications don't make you competent, they make you complacent. They take away the power of ordinary people to challenge the priesthood. You have no right to an opinion without the professional acreditation. Watch "Lorenzo's oil" sometime.
The law is just the worst example of this. As an example, you are incapable *by definition* of determining whether you are infringing on a patent unless you are a qualified patent attorney. You could be the worlds leading expert on something, but your firm won't let you look at the patents in your field because this ruling means that there is no possible upside in doing so.
I have a degree in CS, 10 years professional experience, and I think this is misguided. Try as hard as you like, software just isn't like other "professions". Of course experience counts, but trying to become like other professions with certificates and other bullshit is the worst thing we could do. Professional bodies exist to monopolise fields of study and provide a bar to entry. Organisations like the American medical association and the Bar council are just protection rackets. There only purpose is to raise the salaries of those in the club, not "protect the consumer". We should irradicate them, not copy them.
Writing great software has more in common with writing poetry than law, medicine or even civil engineering. You can stuff huge organisations with "professionals" following "best practice engineering" and they'll still get trampled into the dust by a couple of smart kids working in a garage somewhere. I'm not saying you should hire any old moron to write software, but the trick is to have clueful (developer) managers and they can make up their own mind as to who to hire. Organisations *should* have the right to hire the neighbourhood children to write software, just like they have the right to go bankcrupt.
If you want to see something sensible on programming check out the programmers stone at http://www.melloworld.com/reciprocality
The light bulb was invented by Swan. Read up on Edison a little. He was "responsible" for a whole bunch of stuff (records, movies, etc ) but he invented almost none of it. He abused his staff, and took every ounce of credit for himself, vindictively destroying the lives of former employees who dared point out their own roles in inventions. He truly was the Gates of his day, but this is unfair on Bill, who isn't quite as unfair as Edison was.
Tesla was a poor business man for sure, but you would probably object if someone told you Gates invented the computer.
Guiness is one of those very rare items: a complete food. It contains, in trace amounts, all the minerals, vitamins, protein and carbohydrate that you need.
However, in order to get enough of everything, a man of average size would need to drink 47 pints a day. But here's the catch: somehow I doubt you would stay an at an average size on this diet.
The reason today's software sucks is quite simple.
Programmers are becoming more stupid: Today a lot of software is written in VisualBasic. 10 years ago - C was dominant. 20 years ago assembly was dominant. When you lower the barriers to entry, you get more stupid participants.
Users are becoming more stupid: 20 years ago a computer user would have to be pretty smart. Now, any old moron uses a computer, so the software is mostly designed for morons (not necessary, but true).
People are becoming more stupid: This is more complicated, and only applies to 1st world. It's caused by automation making it possible for people to think less, along with the physical addictiveness of mindless ritual (iso9000 etc) leading to reduced cognitive capacity (or morons, to use the correct scientific term).
You don't *suffer* from ADD, you *suffer* from living in a world full of zombies.
ADD is caused by low levels of the neuro-inhibitor dopamine. Dopamine reduces neuron activity enabling people to focus on dull repetitive tasks such as ploughing fields, accountancy, or schoolwork. The dopamine prevents the neurons from getting excited by other trains of thought, thus helping you 'concentrate'. However, it also prevents creative thought and blocks out higher brain functions. It gets worse, dopamine is addictive, so normal people become resentful when you do something unexpected - you're denying them their fix.
Healthy, active brains, have low dopamine levels and find it virtually impossible to concentrate on these pointless activities. Why should we be able to concentrate on that crap ? it's not what we evolved for.
However, given something interesting you can concentrate better than 'normal' people.
I strongly recommend "ADD, a different perspective" by Thom Hartmann.
Sure, you *can* write stupid code in C++. You can write stupid code in any language.
1) No pointers - This is good. People abuse pointers.
Oh, I guess MacOS is better than Linux, because you have no command line in MacOS and people can abuse the command line. Linux is so crap, all you have to do is type # rm -rf / and you'll screw up your entire system.
If you believe in disempowering people because they *can* abuse something your argument makes perfect sense.
To me this summarises the entire java/C++ debate. The whole philosophy behind java is you can't trust the programmer,
- no pointers, you might abuse them,
- no operator overloading because some people abuse it, too bad if code is twice as long and hard to read, we must protect people from themselves.
- we'll take care of the memory management because stupid programmers can't handle it. But we'll do a half assed job of it so JBuilder grinds to a halt with less than 128M RAM. You better make sure you've taken care of all those dangling references though. If you can't even take care of whether you've deleted your objects or not, stay away from programming altogether.
- no templates, they're too complicated - we'll just force people to cast all over the place or write thousands of little utility classes.
- no multiple enheritance, its too complicated to use properly. We'll just give you a cut down version in interfaces (although I kindof agree with this one;-))
2) #includes - this has been covered, but just copying the code into one big lump file is not all that great of an idea.
WTF are you talking about #include files are meant to define interfaces
3) Strings are a class - I think deep down they aren't, but this relates to
if (you == "bozo") cout "I'll stick to C++ thanks\n";
if (!you.equals("bozo")) System.out.println("but server side java works nicely\n");
4) Everything is treated like an object - great! now you can prove things about your program.
You can't prove anything useful about non-trivial programs. When you're ready to write some non-trivial programs, you might want to try C++. Just kidding, Java is not a bad langauge, C++ does have flaws, but this argument about protecting people from writing bad code just drives me crazy. A bad programmer is useless in any language. Designing interfaces for beginners only is bad enough, but designing programming languages for beginners only is too much.
I never said that a deep call stack is necessarily a sign of poor implementation. It just USUALLY is. Recursion is an obvious exception (although with a bit more experience you'll realize that recursion does not deserve nearly as much emphasis as it receives in college). Swing isn't using recursion here anyway, it's purely indicative of bloat. Also, the deep call stack wasn't the only reason why I think Swing implementation is bad - I've read a fair amount of the source code and it seems to have been implemented without any consideration for efficiency.
I've read this online, and I would have to say you would be out of your mind to buy this book on Swing.
Why - well, it's written by Sun. They aren't allowed to say things like "this method is all fucked up, it fails mysteriously sometimes and when it does work, it's perversely slow, here is the workaround..."
Buy any other book, at least they are allowed to tell you the truth. There are a couple of good ones out there - "The complete guide to swing" (I think - it's at work)
But better yet, forget about Swing altogether. The design is good, implementation is terrible. Stick a break point in a callback and check out the call stack - 20 deep, WTF were they thinking.
Save yourselves endless grief and use the only decent LGPL cross-platform toolkit available: FLTK, it even comes with its own powerful GUI design tool (fluid). You will end up with 1/4 of the code required by a Swing based implementation and it will be 10x faster.
> Faster languages than C++ (at least, those I'm familiar enough with to say): C, Occam, LISP, FORTH, Fortran, Algol, Smalltalk, Perl.
You may well be familiar with all those langauges, but I doubt you're very familiar with modern C++.
C is NOT faster than C++. If you use a bunch of objects inappropriately, then yes, it will be slower than the pure C version but if you need to achieve the same level of flexibility and encapsulation and you have a decent optimizing compiler then the C version will be roughly the same speed.
Fortran - generally is faster than C++, especially for numerical work. However check out http://oonumerics.org/blitz/ for C++ based numerical code that is as fast as fortran
Perl - is being re-written in C++, and somehow I suspect that perl's authors have a better understanding of perl's strengths and weaknesses than you do.
Occam - was effectively the assembly language for transputers, I too have programmed transputer arrays, and yes, they did kick ass, but it's pretty fucking useless for anything except low level programming on massively parrallel computers. Also, using indentation to control block termination is a BAD idea.
Smalltalk - if you have an implementation that runs faster than sensible C++, please tell me where I can get it.
Damn, that's funny. WTF are you talking about ? Last I checked their were no "functional" processors either. Also "C++...seems to still be inefficient, compared to other languages." What other langauges are you talking about ? OK, it's slower than Fortran or assembly and C++ does tempt people to do wasteful things especially when they don't know the pitfalls, but it's pretty efficient when done right.
Slashdot Mirror
Each to his own.
- ------------------
- ------------------
... }
...
- ------------------
- ------------------
- ------------------ - ------------------ - ------------------
- ------------------
- ------------------
e sirable() { returns true; }
- ------------------
- ------------------ - ------------------
...er... DDD
- ------------------
This is a list of reasons why I personally hate Java. They're not all rational, but hatred seldom is...
Three points I would like to make up front.
1. I *know* Java is the best choice for certain things.
2. Please don't bother telling me all the drawbacks of C++ in reply.
Believe me, I am aware of many glaring flaws with C++,
it's just that I've learned to live with these flaws. If I had
learned java before C++ I'm sure I would find those flaws less
tolerable.
3. I'm not a Java newbie. I learned it 5 years ago, and I used it
nearly full time commercially for the last 2 years, (recently returned
to C++ with a huge sigh of relief)
Firstly, the IRRATIONAL REASONS (that I'm aware of):
It took me years to learn all the pitfalls in C++, and then some
bastard comes out with a lanaguage in which many of those pitfalls are
removed. This makes that time more likely to have been wasted and
makes my skills less valuable. Don't bother telling me that this
mentality is selfish, stupid and short-sited, I'm well aware of this.
-----------------------------------------------
I've gotten burnt too many times with Java to trust anything I'm told
without trying it myself (eg - bug fixed, performance improved,
memory leaks). I started learning about Java as soon as it came out,
before books were available etc. I was terribly excited by the chance
of something to break MS hedgemony, so I was initially enthusiastic.
That enthusiasm has worn off, and then some, which is why
I now sound so bitter about the whole thing.
Java 1.0 was God awful, and the time spent learning how to overcome
it's shortcomings was a total waste of time. Other equally important
libraries have changed so much to require any old (2years+) java code
to need total rewriting. Yeah, yeah, I know, what do you expect with
bleeding edge technology, but it was managed badly, and Sun flat
lied about these issues from the beginning.
-----------------------------------------------
I don't like the default style of the code:
public ZipEntry getNextEntry() throws IOException {
if (entry != null) {
closeEntry();
}
I prefer matched brackets, (the extra lines are worth the additional
clarity methinks) and I prefer this_style to thisStyle as a purely
arbitrary preference.
public ZipEntry get_next_entry() throws IOException
{
if (entry != null)
{
close_entry();
}
}
-----------------------------------------------
Sun's behaviour with Java
has been pretty disgusting at times. For instance they delayed
providing a Linux version of the JDK for as long as possible. They
spread vast amounts of disinformation and pro Java FUD. They made
thousands of misleading statements wrt performance and stability and
seem to have effectively brainwashed a whole generation of students as
to the benefits of Java compared to other languages. The number
of clueless little student wankers I've heard regurgitating Sun's
propoganda...
For some reason people give more credence to what Sun says about
Java compared to other langauges than they give to what Microsoft
says about Windows compared to other OS'es, but the same level
of objectivity and accuracy has been used.
Sun has done plenty of other boneheaded things with Java, but the
misinformation thing is the one that irritates me most.
The other obvious mistake is that Sun never tried to use
Java to obtain a level playing field. It wanted to keep control
and replace MS. If they had completely opened up Java initially then it
would be a different story by now.
Java isn't a bad language, but it's not "all that" either. IMO ML and
Eiffel are preferable aesthetically while C/C++ is preferable for
practical engineering today. I think Java is an excellent training
langauge, an OO equivalent of Pascal.
-----------------------------------------------
Exceptions
I can understand the motivation for declaring the exceptions thrown
in method declarations, but I'm not convinced it's a good idea.
The whole point of exceptions is to localize the pain of
dealing with weird occurences rather than pass the pain up the
call stack in the form of checking return values everywhere.
With java, you constantly have to work your way up the call stack
adding extra exception declarations to methods. It's very
tempting to either not bother throwing the exception or just
trap it inappropriately rather than editing half a dozen
files up the call stack. It's almost as much work as the old C paradigm of
checking return values everywhere.
This argument is kinda weak, I know you don't need to declare Error
exceptions in method declarations, and in some ways it's a good
thing that it makes you think about the fact that an exception
could be thrown, I guess it depends on what you're used to.
-----------------------------------------------
-----------------------------------------------
RATIONAL REASONS for disliking Java.
(I mean reasons that I don't already know are irrational)
-----------------------------------------------
Java is slow.
I don't care how many benchmarks Sun comes out with
claiming the latest JIT has "C++ level performance". It's just not
fucking true. While we're on that subject, these benchmarks always
show considerable difference between C++ and C level performance. You
only see a significant difference in performance between C and C++ for
a given task if either (a) the C++ programmer didn't care about
performance or (b) the C++ programmer was stupid, in which case all
bets are off. You can write hand crafted assembly that's slower than
Java if you're stupid enough.
A uncontrived comparison is at http://sprout.stanford.edu/uli/java_cpp.html
In summary, with HotSpot 1.3 beta, (a JIT that Sun touted as being
faster than C++ !!) Java was roughly 5 times slower than C++.
The performance hit from Java comes more from it's crappy libraries
(Swing anybody) than the JIT aspects. Bounds checking, garbage
collection, and inherent overhead of OO techniques all cause a
performance hit, but the real trouble comes from crappy libraries
that put 10 levels of indirection between a request and it's
implementation.
For instance the String class being written with 16 bit characters to
make it unicode friendly when 98% of the java code written never uses
this feature but it still requires twice the time and space for every
operation. Also Strings are not alterable so to alter a character you
create a new StringBuffer object, copy everything, make an adjustment,
then replace the old reference with the new so the old object
eventually gets passed to garbage collection... all compared to
buf[i]= 'a'; (C or C++). It's crap like this that really makes Java seem
so slow, not the JIT hit.
Basically Java is slow for the same reason that Windows sys admin is
slower than Linux sys admin. You don't trust the user with the rm
command or trust the programmer with pointers - show him an idiot box
if he tries to delete a file or bounds check that array access for
him. It's one way of doing things, but it sure isn't efficient.
-----------------------------------------------
Missing language features (compared to C++)
* templates
No, just because everything is derived from Object, does
not mean you don't need them. Writing container classes for Object is
equivalent to writing container classes for void * in C++. You can do
it, but it's not ideal. Besides templates are useful for more than
just container classes. See http://oonumerics.org/blitz/ for an
advanced example.
* enum
Java is meant to have stricter type checking than C++. It seems like
the kinds of mistakes an experienced engineer
hardly ever makes are guarded against, but the kinds of mistakes
that people are likely to make are more likely in Java because of
the lack of enums or templates. The only reason for their absence
is the added complication - that only makes sense in a training language.
* multiple inheritance
Interfaces are pretty good, but MI is more powerful and abstract virtual
inheritance if equivalent to interface, so interfaces are subset of MI.
* preprocessor
"not needed because Java is platform independent" -
hahaha. No it fucking isn't, but a more common need for the
preprocessor would be to ease the pain of version changes. You either
end up with duplicated code bases or you hack your own preprocessor on
to javac, or you deal with a minor headache for every minor version
change or a huge headache for major version changes (1.1 -> 1.2 or 2.0
as it's now called).
* operator overloading
String str = (String)vec.elementAt(i);
versus
string str = vec[i];
It's even more striking if you're working with matrices and vectors
etc, but I've thankfully managed to avoid the pain of doing that in
java.
Now we get into the "these language features can be abused" argument.
It's easy to show examples of the dangers of misusing MI or operators.
I think this is pure packer mentality. You cannot make programming
idiot proof and it's a mistake to try. This mentality pervades java
and is probably the single thing that really makes me hate it. The
notion that you prevent everyone from doing something because
"some people abuse it" drives me crazy.
-----------------------------------------------
Verbosity
Java code just tends to be longer than the equivalent in C, C++, perl
or ML (unless of course you're implementing something that is nicely
covered in the libaries)
There are several reasons for this.
Insistence on using OO paradigm all the time.
Missing language features (especially operator overloading)
choice: boolean Concept.Conventions.StyleGuide.LongFunctionNamesD
This relates to something I've never fully understood. Several people
who's opinion I respect insist that they can develop stuff faster
with Java than with C++. If they really know C++ I just
don't understand this, unless they are comparing old
(pre-STL) C++ with modern (post-collections)java.
The other possibility is that they have been using MFC, a
piece of code so vile, that I can barely speak it's name.
I can see that if you're working on a project where (2 or more apply):
threads are important;
has to work on multiple platforms;
requires functionality that JDK library classes cover well;
is deployed over the internet;
speed is not an issue;
memory useage is not an issue;
very precise control is not important;
some team members are inexperienced;
then Java may well be the best choice.
However for implementing arbitrary fresh functionality I can develop
far faster in C++ than java. For instance a fragment of a C++ program
that reads in a file and gets a list of the starting positions for
every word in the file:
map > word_positions;
string word;
while (cin)
{
cin >> word;
word_positions[word].push_back((int)cin.tellg() - word.size());
}
Writing the equivalent in Java would take 20+ lines.
Now, I admit this is a contrived example, but do it the other
way round - give me a nice piece of algorithmic code in Java,
that is not dependent on some database/graphics/network library
and I believe the equivalent C++ will almost always be smaller.
-----------------------------------------------
Libraries
I don't like the JDK libraries much. This is mostly a maturity
issue, but also it's a kind of OO at all costs mentality.
For instance using NumberFormat & PrintWriter to create
precisely formatted scientific output is immensly painful
compared to using printf() (iostream's suck for this too).
"simple stuff should be easy and difficult stuff should be possible"
Java libraries lose points on the first half, but are generally OK
on second.
Using stuff like Dictionary is unpleasant compared to STL
- there's no way to avoid this due to the lack of templates
(BTW I am aware of Pizza, and this is definitely a step in
the right direction, but unless Sun adopts Pizza it's
not really worth bothering with).
I started on my last project before I knew about FLTK, and
portability was an issue which was why I chose Java for the
interface part of the project. Swing has quite a good design,
but a shitty implementation. It's buggy as fuck, and seriously
inefficient. Learning how to work around it's shortcomings is a
right royal pain in the ass. It has gradually improved, but
is still slow, leaky, bloated, buggy, and perverse in places.
Stick a breakpoint in at any point in the code - the callstack
will be at least 15 levels deep. It's still preferable to MFC
though, which has shitty implementation coupled with *appalling*
design.
Swing is wonderful compared to AWT, but I wish they
had worked harder on stability and performance and less
on features. Visual Basic based applications feel much
faster than Swing even with the latest JIT.
-----------------------------------------------
Printing
Why did they hardcode the output to 72dpi ???
It's just typical Java. You get the performance of 5 years
ago on the latest hardware. Not a good use of Moore's law IMO.
(There is a workaround to this using drawImage() but that has serious
problems too...)
-----------------------------------------------
Tools
javac versus egcs/make,
gdb v jdb,
VisualC++ v. Jbuilder3
DDD v
purify v JProbe
quantify v JProbe
The C++ tools just have a greater polish.
This is an unfair comparison, since it's not really Java's fault
and is just a matter of time.
(Actually, the problems with JBuilder3 *are* java's fault.
JBuilder3 is mostly written in Java and it shows. It's virtually unusable
with less than 128Meg of RAM, 256M is recommended.)
-----------------------------------------------
And that's enough ranting for today...
Yes, Java is better for some things, that's why I sometimes use it. Your reply seemed to have tenuous relevence to what I was asking. If JOVE really is that fast, I want it.
The performance numbers came from my own testing, but a similar conclusion is available online:
http://sprout.stanford.edu/uli/java_cpp.html
Why on earth do you think Java is closer to VB than C++ ? That's hardly a complement, and not really fair on Java. You can compile Java as C++ after minor mechanical translations (although you can't link it or run it that easily, since recreating JRE would take some work...). If you mean for RAD capabilities, it's the tool that matters - the language is not really the issue.
As for development time, it depends what you're doing . Some tasks can be done faster in Java, some faster in perl, some faster in C++. If you really want to get me ranting about Java, email me.
Have you actually used this puppy, or do you
just believe the marketing gunk ?
Its hard to believe this - there are a *lot* of reasons why java is much slower than C/C++ let alone fortran - I've been using java off and on for 5 years. The fastest I've seen is jit for ibm jdk1.1.8 on NT which is about 5x slower than C++ equivalent.
The possibility that quantum effects pay a part in consciousness cannot be discounted so easily.
Neurons are amplifiers, they fire above a certain threshold, so input just below the threshold and input just above the threshold result in different outcomes. This makes brains subject to quantum effects (unlike computers incidentally).
Whether those quantum effects are important is unknown.
Given nature's tendancy to make the most out of whatever resources it has, I would say it is far more likely that quantum computation possibilities are exploited rather than ignored. Given two organisms, one that exploits quantum effects to improve it's processing power, and one that doesn't - the determinstic one would have an evolutionary disadvantage and die out.
Dennet's book is good, but he doesn't delve beyond a certain level. This may sound arrogant, but I don't give a fuck: I had already figured out the truth of what Dennett says before he published that book (with help from stuff I read by Susan Blackmoore). If you truly felt that he fulfilled the promise of the title, then you need to re-read it, it must have left you in a state of confusion.
a t.html
Dennet avoids the more troubling implications of consciousness by deftly censoring the lines of reasoning that he allows himself to follow. His muliple minds model is correct - there is no cartesian theatre - but this still begs the question: what kinds of physical processes give rise to the thoughts one perceives ?
Following that path leads to surprising results,
http://www.melloworld.com/Reciprocality/r4/addm
which I'm sure you'll find ridiculous. If you dislike my conclusions then tell me what's wrong with my reasoning rather than just telling me I'm wrong because you dislike the conclusion.
You think you're scientific, but I suspect you're just anti-spiritual. The difference is: science is interested in truth, and takes nothing for granted. Anti-spiritualists are those who take the abscence of any form of spiritual reality as a matter of faith which cannot be questioned.
Any evidence disputing this faith is assumed wrong, since it leads to a conclusion they have already discarded. The anti-spiritualist mentality comes from the mistaken belief that you already has a basic understanding of everything.
Use AOL for ISP, free for a month...
Some laptops have a voltage switch for AC
power. Make sure you're using the right one
or you can screw up your power unit.
Get yourself a fuzz buster (radar detector) unless 55mph is acceptable to you, some small towns finance their sherrif departments by fining speeding motorists who are passing by.
Do you REALLY want to go to LA ? San Francisco is much nicer and the moron density is *far* lower.
Why not leave the computer at home !!! Try it for a month, it'll seem weird at first, but you'll see the world in more detail.
> This is jumbo metaphysics, there's absolutely zero science behind it.
How the *fuck* do you know. You haven't read the book, you know nothing about the author (who almost certainly knows a damn site more about quantum mechanics than you do). Yet you feel qualified to make assertions about the value of what he says because "it sounds ridiculous to me".
That doesn't sound very "scientific" to me. So I suppose that anything that "sounds ridiculous" must be rubbish and can be ridiculed without even reading it first . Somehow these comments strike a cord with the new slashdot and this gets moderated up to a 5.
This is *exactly* the attitude that holds humanity back. Every single advance in understanding goes through a period of ridicule while people who know nothing about anything heap scorn on the idea. It is the most cherished notion of the truly ignorant that they already understand everything. Any idea that is at odds with the orthodox opinion must be wrong.
The earth is round - ridiculous, everybody knows its flat. The earth revolves around the sun - ridiculous, just look at it. Mass is energy - ridiculous pseudo science coming from someone who "is no expert" in the field, just a patent clerk for heaven's sake.
PS, I haven't read this yet either, but I'm going to.
As another seasoned Swing developer I offer
one right here. Forget about swing, use FLTK instead (http://www.fltk.org/ ) Shit, write
it in COBOL, Visual Basic, assembly, anything but use Swing (er, except MFC which is even worse).
I've been using Swing for the last 2 years
(since it first came out). It's slow, buggy,
leaky, and did I mention slow. Check out the call stack at any point in a Swing program - it's
about 15 levels deep.
Doubtless I'll be called a troll for this. Fine, fuck you too, but I do know what I'm talking about. I admit I'm kindof bitter about this, but if people had been honest about Swing before I got into it I would have been saved a ton of grief.
Where the hell did you get these figures ?
What compiler, what OS, what architecture.
They look *completely* out of line with every
other test I've seen. Check out the JGL against STL comparison above for some real numbers.
For a start, what the hell is the difference between integer division in C or C++ - no compiler that I've heard of written in the last 5 years produces different code in these two cases.
Secondly - who remembers to turn on optimization: anybody who cares about performance and isn't completely stupid.
> it's particularly nice in large and sophisticated object models where you almost always lose track of who has a reference to what
Does this make anyone else nervous as heck. If you can't even keep track of when your objects should be deleted, how the hell do you keep track of anything. Increasing complexity requires more clarity of thought and design, not less. It's not the overhead of GC that bothers me, it's the sloppiness of thought it seems to encourage (try using JBuilder with less than 256Meg if you want to see what I mean).
In some languages (eg ML), you really are working at a different level of abstraction and then GC makes perfect sense, but it's not GC explicity that makes life easier.
The difference between theory and practice is that in theory there is no difference whilst in practice there is.
First off JIT is not java specific. Transmetas chip does a form of JIT on everything - even x86 assembly code. Your basic argument that JIT can be efficient is correct (not more efficient than humans, but I'll come to that).
The performance hit from Java comes far more from it's crappy libraries (Swing anybody) than the JIT aspects. Bounds checking, garbage collection, and inherent overhead of OO techniques all cause a performance hit, but the real trouble comes from crappy libraries written by crappy programmers who put 10 levels of indirection between a request and it's implementation.
For instance the String class being written with 16 bit characters to make it unicode friendly when 98% of the java code written never uses this feature but still requires twice the time and space for every operation. Also Strings are not alterable so to alter a character you create a new StringBuffer object, copy everything, make an adjustment, then replace the old reference with the new so the old object eventually gets passed to garbage collection... all compared to
buf[i] = 'a'; (C or C++). It's crap like this that makes Java seem so slow, not the JIT hit.
Your argument about how JIT can outperform programmers because it has more information is flawed - any decent programmer will know where the spikes are and optimize accordingly. He will know what he can and can't do with the data, whilst the compiler has to take the strictest possible interpretation. Advanced optimization is too slow to do on the fly (although you can optimize the byte code to some extent with a decent javac, then optimize the translation with a JIT)
Garbage collection argument is silly too. In C/C++ or assembly, the programmer has a choice as to whether he uses the stack or the heap. It makes his life more complicated, but as long as he knows what he's doing it's inherently more efficient. If he doesn't know what he's doing then he's useless in any langauge. If you want to, you can use a garbage collector in assembly or C++, but it's not the only technique available to you.
Basically Java is slow for the same reason that Windows sys admin is slower than Linux sys admin.
You don't trust the user with the rm command or trust the programmer with pointers - show him an idiot box if he tries to delete a file or bounds check that array access for him. It's one way of doing things, but it sure isn't efficient.
Of course, there's a difference between their OpenGL sample implementation and the private SGI OpenGL implementation (and the difference is... speed). Still, this is cool, although SGI could have saved themselves the grief of Microsoft's DirectX crap taking off if they had Open sourced this years ago. ( Amazing how generously giving stuff away just makes people like me whine.)
Now we just need OpenInventor open sourced, and there will be a real chance of DirectX biting the dust. (Novices find it far easier to put together interactive 3D apps with a decent scene graph implementation).
They don't crank out a few million lines. They crank out a few thousand that make the million obsolete.
OK, so nobody is going to rewrite SAP on their own, but SABRE I'm not so sure about. Almost all significant new developements comes from individuals or pairs of programmers. It happens all the time.
Unix - written by Ken Thompson and Dennis Ritchie, while 100s of programmers worked on Multics, and 1000s worked on MVCS.
dbx - the best debugger of it's time written by 1 guy, while 100s of people worked on xdb. It was not only more powerful, it had more functions.
Borland, Lotus, Linux, even fucking microsoft. Later on large organisations grow around the original innovation, but the *significant* software does NOT come from large teams.
Would I trust my life to a doctor who didn't know what they were doing ?
I would prefer not to. Unfortunately, I don't have any choice, since once the guy has qualified as a doctor, he can get away with gross incompetence for decades. The "ethics" of his "profession" mean that the worst thing a doctor can do is point out that another doctor is incompetent.
> Would you want the poor who can't afford the likes of Johnny Cochran to try their luck with public attourneys who might well not know the law well enough to see an obvious and powerful defense for their clients?
Exactly my point. Profession qualifications don't make you competent, they make you complacent. They take away the power of ordinary people to challenge the priesthood. You have no right to an opinion without the professional acreditation. Watch "Lorenzo's oil" sometime.
The law is just the worst example of this. As an example, you are incapable *by definition* of determining whether you are infringing on a patent unless you are a qualified patent attorney. You could be the worlds leading expert on something, but your firm won't let you look at the patents in your field because this ruling means that there is no possible upside in doing so.
I have a degree in CS, 10 years professional experience, and I think this is misguided. Try as hard as you like, software just isn't like other "professions". Of course experience counts, but trying to become like other professions with certificates and other bullshit is the worst thing we could do. Professional bodies exist to monopolise fields of study and provide a bar to entry. Organisations like the American medical association and the Bar council are just protection rackets. There only purpose is to raise the salaries of those in the club, not "protect the consumer". We should irradicate them, not copy them.
Writing great software has more in common with writing poetry than law, medicine or even civil engineering. You can stuff huge organisations with "professionals" following "best practice engineering" and they'll still get trampled into the dust by a couple of smart kids working in a garage somewhere. I'm not saying you should hire any old moron to write software, but the trick is to have clueful (developer) managers and they can make up their own mind as to who to hire. Organisations *should* have the right to hire the neighbourhood children to write software, just like they have the right to go bankcrupt.
If you want to see something sensible on programming check out the programmers stone at http://www.melloworld.com/reciprocality
The light bulb was invented by Swan. Read up on
Edison a little. He was "responsible" for a whole
bunch of stuff (records, movies, etc ) but he invented almost none of it. He abused his staff, and took every ounce of credit for himself, vindictively destroying the lives of former employees who dared point out their own roles in inventions. He truly was the Gates of his day, but this is unfair on Bill, who isn't quite as unfair as Edison was.
Tesla was a poor business man for sure, but you would probably object if someone told you Gates invented the computer.
Guiness is one of those very rare items:
a complete food. It contains, in trace amounts, all the minerals, vitamins, protein and carbohydrate that you need.
However, in order to get enough of everything, a man of average size would need to drink 47 pints a day. But here's the catch: somehow I doubt you would stay an at an average size on this diet.
The reason today's software sucks is quite simple.
Programmers are becoming more stupid:
Today a lot of software is written in VisualBasic. 10 years ago - C was dominant. 20 years ago assembly was dominant. When you lower the barriers to entry, you get more stupid participants.
Users are becoming more stupid:
20 years ago a computer user would have to be pretty smart. Now, any old moron uses a computer, so the software is mostly designed for morons
(not necessary, but true).
People are becoming more stupid:
This is more complicated, and only applies to 1st world. It's caused by automation making it possible for people to think less, along with the physical addictiveness of mindless ritual (iso9000 etc) leading to reduced cognitive capacity (or morons, to use the correct scientific term).
http://oonumerics.org/blitz/
is a superb library, and free too.
Actually, real world physics in game engines
is extremely CPU-time sensitive. Assembly is
still necessary for bits and bobs.
Now if you've got lots of legacy code and stuff,
then you're right - stick with Fortran.
(Yo Dud3, use Java hahahahaha).
Sorry friend, you've been duped.
You don't *suffer* from ADD, you *suffer* from
living in a world full of zombies.
ADD is caused by low levels of the neuro-inhibitor
dopamine. Dopamine reduces neuron activity enabling
people to focus on dull repetitive tasks such
as ploughing fields, accountancy, or schoolwork.
The dopamine prevents the neurons from getting excited
by other trains of thought, thus helping you 'concentrate'.
However, it also prevents creative thought and
blocks out higher brain functions. It gets worse,
dopamine is addictive, so normal people become resentful
when you do something unexpected - you're denying them
their fix.
Healthy, active brains, have low dopamine levels
and find it virtually impossible to concentrate
on these pointless activities. Why should we be able
to concentrate on that crap ? it's not what we evolved
for.
However, given something interesting you can concentrate
better than 'normal' people.
I strongly recommend "ADD, a different perspective" by
Thom Hartmann.
Sure, you *can* write stupid code in C++.
;-))
You can write stupid code in any language.
1) No pointers - This is good. People abuse pointers.
Oh, I guess MacOS is better than Linux, because
you have no command line in MacOS and people
can abuse the command line. Linux is so crap,
all you have to do is type
# rm -rf /
and you'll screw up your entire system.
If you believe in disempowering people because
they *can* abuse something your argument makes
perfect sense.
To me this summarises the entire java/C++ debate. The whole philosophy behind java is you can't trust the programmer,
- no pointers, you might abuse them,
- no operator overloading because some people abuse it, too bad if code is twice as long and hard to read, we must protect people from themselves.
- we'll take care of the memory management because
stupid programmers can't handle it. But we'll do a half assed job of it so JBuilder grinds to a halt with less than 128M RAM. You better make sure you've taken care of all those dangling references though. If you can't even take care of whether you've deleted your objects or not, stay away from programming altogether.
- no templates, they're too complicated - we'll
just force people to cast all over the place or
write thousands of little utility classes.
- no multiple enheritance, its too complicated to use properly. We'll just give you a cut down version in interfaces (although I kindof agree
with this one
2) #includes - this has been covered, but just copying the code into one big lump file is not all that great of an idea.
WTF are you talking about
#include files are meant to define interfaces
3) Strings are a class - I think deep down they aren't, but this relates to
if (you == "bozo")
cout "I'll stick to C++ thanks\n";
if (!you.equals("bozo"))
System.out.println("but server side java works nicely\n");
4) Everything is treated like an object - great! now you can prove things about your program.
You can't prove anything useful about non-trivial programs. When you're ready to write some non-trivial programs, you might want to try C++. Just kidding, Java is not a bad langauge, C++ does have flaws, but this argument about protecting people from writing bad code just drives me crazy. A bad programmer is useless in any language. Designing interfaces for beginners only is bad enough, but designing programming languages for beginners only is too much.
I never said that a deep call stack is necessarily a sign of poor implementation. It just USUALLY is. Recursion is an obvious exception (although with a bit more experience you'll realize that recursion does not deserve nearly as much emphasis as it receives in college). Swing isn't using recursion here anyway, it's purely indicative of bloat. Also, the deep call stack wasn't the only reason why I think Swing implementation is bad - I've read a fair amount of the source code and it seems to have been implemented without any consideration for efficiency.
I've read this online, and I would have to say you would be out of your mind to buy this book on Swing.
Why - well, it's written by Sun. They aren't allowed to say things like "this method is all fucked up, it fails mysteriously sometimes and when it does work, it's perversely slow, here is the workaround..."
Buy any other book, at least they are allowed to tell you the truth. There are a couple of good ones out there - "The complete guide to swing" (I think - it's at work)
But better yet, forget about Swing altogether.
The design is good, implementation is terrible.
Stick a break point in a callback and check out the call stack - 20 deep, WTF were they thinking.
Save yourselves endless grief and use the only decent LGPL cross-platform toolkit available:
FLTK, it even comes with its own powerful GUI design tool (fluid). You will end up with 1/4 of
the code required by a Swing based implementation and it will be 10x faster.
http://fltk.easysw.com
> Faster languages than C++ (at least, those I'm familiar enough with to say): C, Occam, LISP, FORTH, Fortran, Algol, Smalltalk, Perl.
You may well be familiar with all those langauges, but I doubt you're very
familiar with modern C++.
C is NOT faster than C++.
If you use a bunch of objects inappropriately, then yes, it will
be slower than the pure C version but if you need to achieve the
same level of flexibility and encapsulation and you have a decent
optimizing compiler then the C version will be roughly the same speed.
Fortran - generally is faster than C++, especially for numerical
work. However check out http://oonumerics.org/blitz/
for C++ based numerical code that is as fast as fortran
Perl - is being re-written in C++, and somehow I suspect
that perl's authors have a better understanding of perl's strengths
and weaknesses than you do.
Occam - was effectively the assembly language for transputers, I too have programmed transputer
arrays, and yes, they did kick ass, but it's pretty fucking useless for anything except low level programming on
massively parrallel computers. Also, using indentation to control block
termination is a BAD idea.
Smalltalk - if you have an implementation that runs faster than sensible C++,
please tell me where I can get it.
Damn, that's funny. WTF are you talking about ?
Last I checked their were no "functional" processors either.
Also "C++...seems to still be inefficient, compared to other languages."
What other langauges are you talking about ?
OK, it's slower than Fortran or assembly and C++ does tempt
people to do wasteful things especially when they don't
know the pitfalls, but it's pretty efficient when done right.