Slashdot Mirror
Why is Java Considered Un-Cool?
jg21 writes "After the Slashdot discussion on Paul Graham's 'Great
Hackers' essay, it had to happen. Java developers have taken umbrage at
Graham's assertion that "Of all the great programmers I can think of, I know of
only one who would voluntarily program in Java. And of all the great programmers
I can think of who don't work for Sun, on Java, I know of zero." Now in JDJ Sachin Hejip pinpoints the Top
Reasons Why Java is Considered Un-Cool and to tries to debunk them. He levels some of the blame at the Java compiler for "too much
chaperoning" and speculates that Java fails the geek test precisely because
"it's such a language-for-the-masses." But isn't he missing the point? Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?"
people just concentrate on the best tool for the job instead of worrying about things like, "coolness".
These, "my programming language is better than the rest and here is a list why" arguments are BS. Every situation is different, every problem requires different tools/methodologies to solve. You wouldn't go into the carpentry business and claim your hammer is the best hammer for every single job would you? You would be laughed at and possibly hit in the head with said hammer. Same goes with programming languages.
Monstar L
This is news?
Java is the new COBOL. No, I mean that quite seriously. COBOL means "COmmon Business Oriented Language". Java is the language of choice for modern day corporate application development. In the corporate world - which probably accounts for more actual lines of code than anything else - applications fall into two categories, forms (inputting data into databases) and reports (getting data out of databases). The corporate world wants legions of cheap, interchangeable programmers to work on these applications. Kids are taught Java at college or learn it themselves. The language makes it very easy for one person to work on another person's code, and it makes it quite painless to document your work as you go. That's the reason "hackers" don't like Java - they've just transferred their traditional dislike of COBOL to it.
Some of the things in java are terribly verbose. especially when going to design GUIs.
Using the language you just "feel" as if there should be an easier way.
I'm no fan of microsofts products but I think C# is an excellent language to program in. It addresses alot of Java's shortcomings and it is a joy to program in.
From my employer's point of view, it makes me more productive than (most) other languages would, since I spend less time worrying about crap like header files, pointers, memory leaks, and so on.
So everyone wins. "Cool" stopped being important when I turned 18.
..on the laptop I use for work (a Pentium-2 ...) it's just like that. Don't understand me wrong: I have programmed in JAVA, I liked it.
But as corporations nowadays still have little budget left for buying their employees decent PC's, JAVA still has this practical limitation.
Slashdot: stuff for news, nerds that matter, matter for news, stuff that nerd
Most developers I know basically slam it for it's reputation for being slow, and frankly, because it's not C, the geek Gold Standard. Perl has the same difficulty and has it's own cultish crowd (Perl users are the Greatful Dead fans of computer science). Python is somewhat trendy as well.
But Java....Java was designed to be easily learned, and to especially be used in web-based apps. To Unix geeks, that makes it kind of the Visual Basic for the Slashdot crowd. Not something to brag on.
Fact is, it's a great language, and it's still growing. A friend of mine is a professional Java developer (mostly server side stuff), and he's one of the brighter bulbs in the lamp. He loves it, and still thinks Java's potential is largely untapped. Whereas we know what C can and can't do, Java is still growing. He thinks it'll be used (and used effectively) for things we can't even imagine yet.
Life is hard, and the world is cruel
It's just not that hard to understand this. For good or ill, programming has always been an ego-driven profession. You hear stories of punch cards and marathon hacking sessions, and how cool it was that some guy arranged all of his code so that memory accesses were precisely in alignment with the rotation of the memory drum. You do not hear about how cool the fact that someone's applet can't crash because of automated bounds checking and lack of explicit pointers.
Java is seen as uncool precisely because it protects you from your own mistakes -- it's an attempt to make programming approachable to the masses, and the fact that it's forgiving makes it look like programming with training wheels. And just like the 50 year old MBA will never fit in with the Harley crowd, Java programming will never be seen as cool as "real" hackers' languages like C.
In my career I've written more C then anything else. Followed by PERL for test automation. Recently I'm working a new program that is 100% Java. It has been a pleasure. I do not see any huge performance problems that people seem to complain about. I'm not just writing a database/forms program either but doing REAL work in image processing.
I have no idea what you mean about byte code making it harder. You compile things into a JAR, in most OS's you can double click the JAR and run it. How is that difficult?
Tons of production software is written in Java. Especially server side.
C/C++ are out there but the reality is that they are too hard to use for very large project. It can and will be done successfully but it costs a fortune. I can do so much more using Java with so much less budget that its amazing.
As far as being multiplatform. It comes close. I've never had any huge problems outside of cosmetic differences that might need to be tweaked, but that it easy. I was even doing 3d graphics on the mac and demoing them blindly on a windows PC without testing on Windows (I refuse to own one of those) and had no problems.
.plan!! what plan?
I had to use Java back in school and I won't touch it unless my superiors threaten the branding iron (again). Java loads too much overhead and it doesn't have the same responsiveness as C based apps, IMHO. I don't think Java is optimized enough, and it shows. All the cross-platform support comes at a price and that price is speed.
... for security. Java has all sorts of neat features built in like automatic bounds checking on arrays that simply don't exist in languages like C. This means that it may run slower, but in a computing environment where processor speed doubles every 18 months, would you rather have a little bit slow execution for now or a fundamentally flawed security paradigm? Programming in C leaves you wide open to buffer overflows and other attacks, and it takes a security-oriented programmer to overcome those problems. And guess what, once you get all of the code in there necessary to make it secure, it runs at about the same speed as Java. Java just puts all of the security stuff in by default, which I don't think is a bad decision in this age of computer worms and viruses.
Java is optimized
Cyde Weys Musings - Scrutinizing the inscrutable
Maybe it's because a whole lot of us are too busy working on multi-million dollar financial projects to stop and tell you how cool it is? Java is all about the server side, so if we're not coding desktop apps, its because there's more appropriate software out there for that. That doesn't make Java uncool - there's a lot to be said about enterprise Java. Whether it's cool or not, it works.
By the way, I frequently use a very cool Java desktop app - It's an Amp/Effect editor from Line 6 that controls their Guitar and Bass Amps - It's all Java, looks and runs fantastic. Check it out if you have a Podxt.
That's right, he used LISP.
First impressions for java weren't all that good. Back in the early days it wasn't just slow, it was painful. We'd ask "why does VB have a user interface that's so much quicker?" I still don't know. We also asked why every interface looked different. Java never did successful wrap the APIs provided by the OS and there's no reason not to.
By the time of the second impressions, Sun and Java zealots started to become annoying, promising silly things like it was faster than native code. Maybe in some cases it is, but certainly not where it counts: the GUI.
Oz
The problem with Java is that Sun really has managed it properly. We all thought it was cool when it came out, but the promises really weren't true. Write Once Run Anywhere mostly managed to work on different platforms, but the GUI is so god awful slow nobody really wants to bother. Its just easier to code native. I'm not exagerating here that even Visual Basic programmers could have come up with something better.
.Net products. Hate MS all you want but .Net actually is really easy to use.
Sun has let the technology stagnate while Microsoft has caught up (and IMHO surpassed) Java with their
Plus I don't know what's going on at Sun marketing, but they've descended Java into acronym hell. Plus the naming conventions don't really make sense now. The new version of Java is J2SE5 (I'm not even sure that it is this now).
I'm taking this from the perspective of desktop developers (rather than the server side as they seem to use Java fine). Java really does blow, and there are now better technologies to use. Sun has even ignored integrating other, better technologies (*cough* SWT) due to NIH syndrome.
If Sun went and fixed their mistakes rapidly (a bit late IMHO) then Java could still be cool. But everyone on the desktop who's used it considers it a steaming POS.
Anyone still concerned with whether or not their favoured language is cool or not is a 1) hack, 2) student, or 3) self-described 'geek' who's not nearly as good as he thinks he is.
Java works well in some environments and for some tasks, and poorly in others, and a lot of that depends on the programmer, not the platform.
Besides, success is its own argument. If you can't understand why Java is so big these days, maybe that's your fault, and not the world's.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
Except that Flash 6 is like ~500kb and a decent JRE is like 30MB.
Flash 6 can install on accident even on a dial-up modem. You won't be accidentally downloading a huge runtime to get Java installed.
I do not find java all that verbose. Terse or not the really key to getting real work done quickly is a large collection of libraries so you do not spend your life reinventing the wheel. Look at Perl it is not a pretty language but cpan makes it so useful that it has yet to be replaced by Python or Ruby.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Hey, I *like* java, but this kind of crap is definitely shooting yourself in the foot material.
You! Yes, YOU! Out of the gene pool!
In theory, all of hte above is correct.
But I am a JAVA developer using Borland JBuilder X (one of the leading JAVA IDEs, implemented in JAVA) on a 3Ghz machine. The UI is the slowest, most unresponsive thing on my system. If the maker of one of the leading JAVA IDEs can't package their system (w JDK of their choice, toolkit of their choice, etc) so that its responsive on a modern machine using XP Pro, then I think it's fair to say that JAVA is slow for GUIs. (Yes, XP pro sucks, but every other app on my machine, most of which are written in C/C++, work fine.) Try eclipse - even using SWT, my experience is that its about as unresponsive, compared to Microsoft's C++-coded IDE, and even compared to Emacs, which is largely written in bytecoded LISP (and not even a very fast LISP) and has been known as a hog for decades.
Also, while hotspot VMs in principle can grow to faster cpu performance than native compilation, the major cause of JAVA's slowness is space cost, not time, plus startup time (of the JVM, classloader, etc). I've never heard of any JVM which is reasonable in space terms. Most need a 10M resident set for hello world, and go up very fast with increasing complexity of app.
Starting BEA (_the_ leading JAVA app server) on my system takes 30 seconds. This is absurd. (And it's not even precompiling the JSPs needed, because as soon as I hit a page, it chokes again for multiple seconds.)
Plus, htere are things that native compilers are better at than hotspots, as they can make lower-level decisions than a bytecode compiler while they can still see the source tree. I don't think either type of compiler is clearly better than the other, but I don't think its fair to say that JIT is always faster. Try using a few JAVA apps, then using a few C++ apps, and see which one works better.
That said, JAVA has a huge security advantage over C/C++. Even experts screw up sometimes using those languages (look at the occasional security hole in carefully coded bits of core unices). _Any_ garbage collected, bounds-checked language has much of what JAVA has (excluding secure classloaders, sandbox, bytecode verification) for security, in fact. Some, such as OCaml and Common LISP, can potentially be far faster than JAVA, especially at compute-intensive tasks. If speed is no object, use Python or Perl (and I know, sometimes they're just as fast).
Tool choice depends on the task. And sometimes the task is "interface to these twelve hoary enterprise systems using the same language the standards committee decided the other twelve hundred programmers will use." Don't laugh. I think the analogy from JAVA to COBOL has some truth to it...and just think how much better of a COBOL JAVA is, in most ways. But that doesn't mean that Paul Graham should like JAVA. He made his career by seeking out the kind of problem that is NOT subject to the above constraints, but very different ones. (Did anyone actually _read_ his article? Or his other 30?)
That's exactly the problem of Perl, having more than one way to do one thing. It's fine when you're the only one who reads your code. People tend to learn a subset of Perl that does everything. But what if you're collaborating with other people who know a different subset, and generally a different coding style?
Of course style can be enforced, like the Linux or GNU guidelines for writing C. But at that point you could just as well make the language itself clear and consistent, which is just what Python does.
Escher was the first MC and Giger invented the HR department.
Some of his posts are grossly incorrect. Examples:
But the semantics for many programs would not be correct, since Java requires array bounds checking. Disabling it means that you're not compiling Java.
True, if youe xceed the bounds of an array in a Java app you will get an array out of bounds exception - but that is the worst that can happen, a nasty error message. However, this is a totally different can of worms in C/C++. If you don't check the bounds of every single array, you could be exposing buffer overlows in your application, which is a huge security hole. +1 for Java.
You've posted three examples of code that you claimed was as fast or faster in Java than in C++, and every one of them, when compiled properly, turned out to be faster in C++ than in Java.
Faster when run how many iterations under hotspot? 1? 10? 100?
In Java you have to write nine copies of the basic sort function: one for arrays of chars, one for arrays of doubles, one for arrays of Objects, etc.
For one, most people use the Collection or List interfaces for utility classes so that you can pass in any type of object, be it an ArrayList or a linked list, so in the Real World(tm) this is rarely an issue. Additionally, Java 1.5 has templates so it is a moot point.
I could go on and debunk more of his debunking, but I can tell from his posts that ihe is quite biased and is not being resonable. Just for reference, I am *not* a Java developer. I write a lot of C++ code and a lot of java code, both are ideal for certain situations. For example, desktop apps with need for a fast startup time will always be best written in C++ until Java Vms are built into the OS. But for long-running business applications, where startup time is not a huge requirement and ease of development, debugging, and security are a higher priority, Java wins hands down.
"the managers that choose Java"
Hey, waitaminute, who let the *managers* choose?
"Fred, here's a saw. Go pound some nails in."
Bingo. That's why I hate it. The whole "platform independence" is pretty much a load of crap in Java. Yes, in theory, it's there. In practice, all of the real Java apps I end up having to deal with require some specific runtime. Then I fight with CLASSPATH stuff.
I understand that truly cross-platform programs are a difficult problem. But that doesn't change the fact that Java is pretty bad at it. And don't even get me started on the fact it has multiple GUI API's.
Java is slow - This is a myth.
I honestly don't understand why people are still repeating this. It _is_ slower than either native C++ or
Java bytecode is not easy to optimize, having been originally intended for interpretation (my, how silly that seems now!). This is usually a minor issue compared to memory. I also suspect that, using the standard Java libs, IO is bound to be slower than a more direct approach unless the JVM takes some shortcuts and makes some methods into special cases. But actually, from the point of view of my actual work it doesn't matter what the reason is -- performance critical serious number crunching is done in C++, and that's pretty much a universal, because everyone relevant has made the same simple observations I have. This C++ can then be wrapped with a Java interface for the benefit of other systems that depend on Java and for people who only care about whether the system is Java or not (and so that it works with WebSphere now that the company is locked into WebSphere, heh heh).
So, _whyyyyyyy_ am I _stilllll_ told by posters on
Whence? Hence. Whither? Thither.
Just like the last article slashdot linked from this source. For one, it's a straw-man argument. He gets to set up the 10 greivances that he'll knock down. How about he ask Paul for a list of 10 greivances to knock down? Secondly, the greivances he picks and his arguments against them clearly show that he's incapable of thinking in the way that people who despise java think, which makes him a poor arbiter of such things. Would a great hacker really say "Java sucks because it doesn't have a cool IDE like MS Visual Studio?"
11*43+456^2
I'm amazed that how all of the current "state of the art" Languages/Frameworks still haven't caught up to Smalltalk yet.
Smalltalk is a Language/Library/ and integrated development environment all in one.
It's had for over twenty years:
Java/C#/.Net wish they had all of this "20 year old" tech. They are good Languages/tools that are slowly evolving into Smalltalk. Why don't you just save time and go to the top of the food chain?
It's amazing how one research lab, Xerox Parc, could have been SO far ahead of its time. Its like software has stood still for twenty years.
You can explore it via the open source squeak project. Understand it is written for coders by coders so it takes a little work to come up to speed on it, but in my option, well worth the effort. And Morphic just rocks. http://minnow.cc.gatech.edu/squeak/1
Martin Fowler of Refactoring does Java.
Erich Gamma of Design Patterns is a major player on the Eclipse project.
Besides why should people consider a language cool at all? Shouldn't it be, "What I can do with a language" is considered cool?
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
I could not agree more with your post. There was another quote that went something along the lines of: a cool language is one that teaches you something by learning it. I thought learning and using Haskell and Lisp were very useful for a different and complementary mindset that they help create. I think my C++ programs are higher quality because of my functional programming experience.
Languages like Java or Basic are not cool for me personally because they did not teach me anything. These languages are primarily designed to protect the computer from the programmer. I think the proliferation of buggy programs is due to languages like Java or Basic that make it easy for a person without the proper training to program. Engineers need to go through very rigerous tests to certify their expertise before they are allow to design and build a bridge. Why should programming be different?
SYS 49152
Well Java as I understand moves much of the optimization process down into the JVM whereas a compiled language like C++ does that optimization during compile time. Comparing the time I have spent waiting for C++ during the code, compile, run, code, compile run, I find I have wasted much more of my time. With the Caching of classes and dynamic inlining of code the JVM tunes up as you you go along.
... current and 1.5 (Tiger) coming in a few months are light years ahead of that old MS version and should be looked at seriously.
You are correct that this model has a start up delay which can be seen as a problem if you do a lot of startups, but like many applicatons say a web server that starts a JVM and keeps it running while the server is up it is a one time charge. I find that given the saftey of the language especially around automatic garbage collection compared with C++ my envirionment is rock stable and the online Web apps we have only come down with the hardware needs maintenance.
The folks compainign about MS Java have a good complaint as that was an old buggy version of Java that has not been in general use for years by people using Java from the Sun source. The new versions of Java 1.4
I write my code on NT and W2k platforms (java 1.4.2) and field the same code on WNT W2k Sun Solaris with out modification and no changes for envirionments. With C++ or C# and the java clone this is impossible at this time. I have in the past had to field C++ code on different platforms and that was not a very nice time.
How do you want to spend your time. Collecting your own Garbage, writting very very carefully so you can use your code in different environments, or do you want to just get the job done right and once and get on with it?
This is true, but that is not the whole picture. One of the things that was obvious right away is that minimizing the number of things the programmer can do wrong causes a significant jump in the effective productivity of the programmer.
Brooks talks about this in the Mythical Man Month as it related to assembly versus high level languages, but we do see the same effect when moving between a language like C and something like Smalltalk or Java. It has been my experience that a good programmer writes more and higher quality code in Java versus C or C++, largely due to three factors:
1. Mandatory exception handling forces error handling down into the code where it can best be dealt with. In other words, you have to work harder to not handle abnormal situations.
2. Garbage collection eliminates whole classes of memory mismanagement problems.
3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality).
All three of these affect both time to deliver and quality of delivered code. We're not talking about minimal changes in productivity, either. I've been watching and working with Java and C++ since ... well, pretty much since they made it out of the laboratory. The improvement in real world productivity seen with Java is a factor of two to four greater on average versus C/C++ (measured by "how long does it take to get this feature to work", which is not necessarily the same as "how much code did I have to write"). Often lower for GUI work (depending on which GUI toolkit/tools you're using) but much higher for network code. Moreover, bug counts in released code are dramatically lower, like one tenth as many, and they tend to be less serious (a feature may fail, but seldom does the entire application fail).
In any case I guess I would have to vehemently disagree with Graham's contention that great hackers don't use Java. I suspect that is more a matter of which circles you run in, as that certainly doesn't hold true in my experience. There are fewer using it today than three or four years ago, but I surmise that that is mostly a matter of language maturity; the best programmers tend to sit on the bleeding edge, and that's not Java anymore.
Your mileage may vary, contents may have settled during shipping, etc.
jim frost
jimf@frostbytes.com
Oh, god no! I just want it to behave more like 'libraries' under Linux/Unix. Let me edit /etc/java.conf to set which directories hold "libraries" (jar files). Java wants too much on the command line. One needs to be a good shell script writer (and/or batch script writer) as well as a Java developer as it is. Ever seen the weblogic startup scripts? *huge* shell script infrastructure just to setup all the correct params to java.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
It can, in theory, be faster. Sometimes you discover data that turns out to be constant in the end, but you don't know this until your program is running. A JITter can use this additional information to compile to machine code that is a lot simpler and therefore faster. If you then execute this piece of code lots of times, you can earn back the time spent compiling and then start to profit from it. I remember some work being done into some research which did this in C: it generated some C based on a template, fork()-exec()ed gcc to compile it to a shared library, dlopen()ed the shared library and then ran the code. Of course, you had to do this explicitly, but I think since the chances of actually having an algorithm that benefits from this is pretty rare, that's not going to be a problem.
That being said, Java has no way of hinting to the compiler "this is going to be constant for a long while now", or "I'm going to run this loop a couple of million times in a bit, you might want to JIT it real good". Without those, the compiler doesn't really have a hope.
Also, it's not a case of interpreted languages not being cool. Perl, Python and a myriad of other languages are all interpreted (or run as some kind of byte-code), and no-one complains. Then again, I've seen Java out-paced by many of these languages (most of which compile the program to byte-code at start-up faster than Java loads), which suggests to me that Java is just a poor interpreted language. If you've seen how JVMs work internally, I think you'll agree with me.
Real java apps are packaged in a Jar file with a manifest file that takes care of everything...
My dislike of Java has nothing to do with slowness. It has to do with control and succinctness. Trivial example:
// Must be stored in a file called "hello.java"
public class hello {
static public void main(String[] argv) {
System.out.println("Hello world!");
}
}
Since everyone likes readability, I'd like to ask what part of "static public void" helps you to understand the program. Let's compare this to, oh say Perl.
print "Hello World\n";
Which, as Perl's reputation precedes it, is obviously harder to understand.
Javs relies on vast ammounts of knowledge drilled into the heads of students. If the OO paradigm wasn't so popular, Java would be entirely obtuse. Anything not memorized must be looked up. You wanted to add that integer to the float? Too bad. Go look it up type converting. Additionally I'd like to conjecture that the human mind is better at remembering small things than large ones. Therefore, system.out.println() is more difficult to remember than print. I'd rather remember something like "-e" (Perl) to test for file existance, than the Java equivalent, which I have looked up and since forgotten (though I've used each the same number of times).
While C may be verbose, it allows you to have near complete control of the physical operations of the hardware (e.g. when you delete memory or use a pointer, this has a physical analogue).
Java is both verbose (lots of commands to do simple stuff), clunky (really long commands), and forces you to use the OO paradigm whether or not the problem demands it. It's these reasons why I dislike it.
-- Political fascism requires a Fuhrer.
here is the REAL reason hackers don't like java, and most of them don't even realize it.
the job of an organization developing a software product (whether it's a company, an open source team, whatever), is to get a product out. nobody outside the project cares about languages or anything else, as long as it all works in the end. but to get a product out, the manager eventually has to pick a strategy. they usually fall somewhere in between the two extremes:
A) use a few brilliant (possibly well paid) hackers and let them do the work. they're smart, and good enough to rely on to just do it. managing them is like herding cats, but why would you need to?
B) use an army of keyboard monkeys and manage the hell out of them. these guys can pound out mediocre code, but with enough software engineering from the top down, well defined specs, and massive testing and integration, their work is sieved into a release-quality product.
real hackers hate being marginalized, having their creativity stifled (yes, for those of us who actually write code, not just implement specs, creativity is involved), having to do the dumb solution just because everyone else is too weak to do their part of the smart solution.
java is not a bad language. i think many would agree that is it at least decent (i think it's pretty good, actually). but java is the language of the B coders. it is made to be easy and idiot proof, like visual basic. you cannot do "neat hacks" in java, because if you could, the B coders would screw it up and produce worse code. java is a great language for the B coders. but the choice of java for a project is often a leaning toward strategy B. it's the "we can get any code monkey off the street to do this". it's the grunt work software that real hackers don't want to do, and what B coders are hired for.
perl, a RAD (and rad) programming language, does not suffer this stigma. perl is accepted by hackers, precisely because it is not idiot proof. it's easy to confuse the B coders (and yourself) with some maliciously written ascii barf. you can do some crazy tricks in perl. it does not lend itself well to software engineering and the micromanagement of the B coders. perl is a hacker's language.
many real hackers i've seen instinctively feel resentment towards java and the like, because they see marginalization of the software industry. java is for the blue collar coders, part of the greater plan of "software factories", where reproducability, meeting deadlines and specs, and easy replacement of people is way more important than doing cool shit. those of us who wish to stay at the top of the game, to do the cool shit, to write the programs that interest us the right way are often drawn to the languages that keep out the idiots, that have a higher barrier of entry, and let us do the cool hacks.
i don't dislike java, and i don't dislike you B coders out there (you know who you are). i just don't want to be one of you.
thanks for reading my long-ass post,
p.
ava has no function pointers. If you want to include callbacks in your data structures, you need to do hideous things with interfaces and virtual functions.
No, you use the Command or Strategy patterns to solve the problem the function pointer "hack" is used for in C/C++.
Java doesn't have function pointers because it's not C. I am sorry if anything non-C frightens you, but it's time to move on. If language A doesn't have feature B of language C, it means you need to learn something new instead of just apply the knowledge of C to everything.
C is just assembly that has put on finer clothes, trying to look like a higher-level programming language.
I've mentioned this before, but the primary difference between a C/UNIX programmer and a C#/Java/Windows programmer is the perception of what constitutes a program.
In UNIX, a program is usually a tiny little thing which passes its output to other tiny little things, creating a network of programs controlled by a lightweight master program. Because of this, programs HAVE to have a small footprint and have to start up and close down quickly. A good UNIX program does only what it's supposed to, and then it quits.
In a Java/C#/Windows program, you generally start the program once per day/week/year. The program, once started, calls objects with functions that operate the same as individual programs in the UNIX paradigm. Because the program is doing all of the work and all of the flow control, it doesn't matter if the thing starts or stops quickly, doesn't matter if it uses a lot of memory, because you're not going to be using that memory for a whole lot else. A good Java program does so much, it's almost like its own windowing or operating system.
The essence of "I don't understand OOP, it's full of bloat" is the perception of what a program is and does. If you think a program should do one small thing and then pass its output or control to another program, you're essentially in the OOP mentality already...substituting processes for objects and programs for functions. On the other hand, if you believe as I do that programs should sit open and ready to use on a whim, even the fast startup time of the average UNIX utility is too much. You need the memory allocated, the commands loaded and ready to handle whatever you've got to do -- which is why OOP makes sense. You don't start your notebook every time you need to jot a note (I don't anyway)...you just pick it up and write.
Anyway, to get on topic: I always thought Java *WAS* cool. All the under-40 programmers I know LOVE Java, even if they don't use it. It's almost a spiritual thing (I plainly remember wearing a "Java is the Way" back when I was a Java coder) and it's even more mysterious because the older generation of C coders didn't like it. Not disposing of objects and relying on GC is the programmatic equivalent of not cleaning your room. And a good UML diagram reads like a map of a futuristic city.
Hey freaks: now you're ju
First you say: Yeah, and your point is? In case you didn't notice, passing functions as arguments does not make the worlds most legible / maintainable code. On the other hand, an explicit interface is both legible and maintainable, plus you have an explicit place for documenting the interface (Javadoc in the interface definition).
Then you go on to say:This is an implicit downcast:It compiles perfectly and works as expected.
The last line of this:Is an upcast. and I dare you to find a list implementation in any type-strong language that doesn't require an upcast in this situation. You need it to be able to store objects of an anonymous type on a list.
How such misinformed tripe ends up at +5, I'll never know...
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
This is an interesting example, because I think in the real navy, there's a straightforward answer: Sometimes your preparation fails.
In the example you gave, there are *two* points of failure. The first is that you can't find the directory you pointed at, and the second is that you can't get a listing of it. Making those things be separate forces you to consider the failure cases.
A large part of what Java is about is failsafe enterprise-level applications. When you write to that level of safety, you need to identify the different causes of issues.
In the same way, your day-sailer on a 12' boat doesn't shout to his crewmate "Prepare to tack!" because there isn't any reason to. If you're sailing an 80' schooner, however, you do shout to your crew of six "prepare to tack!" And then you wait in case someone shouts back, "Port side winch is jammed!".
-Zipwow
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
thanks for reading my long-ass post
you're welcome, thanks for posting it
However, I think you miss a few important concepts in your post.
1) Not all "A coders" are hackers.
- I've worked with the elite programmers that do believe that requirements and documentation are good and that a process produces better results. It seems that these are usually the elite and experienced, but not always.
2) Not all hackers are "A coders".
- "B coders" are hackers too. Seen it too many times. Just like anything else, there are more "B coders" and "C coders" that are hackers than there are "A coders". It is just a fact of life, that there is always an elite FEW, but and abudance of mediocrity. i.e., just because you are a hacker, doesn't mean you're good.
3) Managers are people too.
- There are many "B managers" and an elite few "A managers". And usually, an "A manager" is worth a team of "A coders" to a company.
4) Teams are usually a cross section of the population.
- Rarely are there teams full of code monkeys, or full of "A coders". Here is where a great manager is important. An "A manager" will allow enough room for each person to do what they need to, but ensure that each is able to work with the other. I've been lucky enough to have "A managers", and they make a world of difference to individuals and to projects.
5) Programming languages are just tools.
- Use the best tool for the job. Saying you choose a language based on your ability to do "neat hacks" is idiocracy. If I see someone putting nails into a wall with a screw driver, I think - "Damn, that guy is good with a screw driver", and "what a friggen' idiot".
Reading your post it is obvious that you are either an elitist with a lot of bad experiences, or someone with no experience. Either way, I hope your next manager is an "A manager", you really need some help.
I am living proof of the Peter Principle