I've not done much perl and no I've not heard of perldoc and POD. If I ever do Perl, I'm sure they will be helpful:)
They certainly will; they're more-or-less directly equivalent to the Java tools you mentioned.:-)
Also, the system.out.println() vs print argument is silly.
As an isolated case, a specific example, yes, I agree with you. My point was more the general approach I read into your previous post: that having good documentation was an adequate substitute for knowing even the basics of your language's standard library. If you're working with console apps, the print example is directly relevant; if you're a GUI kind of guy, I guess not knowing the basic classes of your windows/dialogs framework of choice would be equivalent.
I wont comment on whether Java is more productive than C++, I don't know about that, but the gain of the garbage collector cannot be reduced to you not having to write delete p; or whatever your language of choice wants you to write.
Of course it makes a difference to the performance characteristics of software written in Java as well; I'm certainly not disagreeing with that. However, in terms of developer productivity -- specifically, how long it takes a team to develop the equivalent code in Java vs. a non-GC language with otherwise similar characteristics -- I'm pretty sure that the missing delete (or whatever) is exactly what it boils down to...
Copyright simply ensures that your employee agreement is all the legal buffer necessary for a large corporation to take everything you produce and pay you the minimum necessary to keep you from going postal. I don't particularly enjoy living on a shoestring held by an exec whose worried more about his stock price than my intellectual property.
I'm sorry, but you don't seem to understand either the spirit of copyright or even how it works in practice. If your work is of a good standard and you don't want to give up that work to an employer (and receive the fringe benefits that come from that employment in exchange) then you are quite at liberty to go self-employed and start your own business. That has nothing to do with copyright.
I don't see any usefulness in using big government legislation to subsidize people who produce a mediocre product.
Remember that the next time you use a commodity electrical product -- like your car, or the microwave in your kitchen, or your television set, or your PC, or...
Without the artificial protections set up by copyright (and patents, too) these industries simply wouldn't be where they are today.
You seem to be of the opinion that we need to maintain the number of creative professionals we have now. I disagree.
I don't necessarily agree with maintaining the overall number, and I do agree that no-one is entitled to a job if they don't provide a produce or service of value. However, if you're going to trim the industry, you want to lose the deadweight; it is in society's interests to keep the good people in the industry producing good products and providing good services.
Unfortunately, as with anything in a capitalist society, if the job doesn't guarantee to pay well, the good people are the first to walk. Look at top executives and what they get paid. Even with all the sleaze and kickbacks and so on, the big corps wouldn't even offer the kind of salaries they do unless they believed it was necessary to attract the calibre of staff they require. The same goes for software development, or creative writing, or music making: if you trimmed the industry by removing copyright, the better people would be the first to go, and society would lose the benefits of their now-unfinished work as a result.
Also, if you're driving your car, nobody else can drive it at the same time. In contrast, information is impossible to steal; once you have it you always have it, unless you try to forget it.
That's the standard (and, I'm afraid, rather naive) argument at this point, so here's my standard counter: while what you say is true physically, it is not true economically. If you copy a work without compensating its creator, you have dimished the value of that work to a creator. Taken to an extreme, if you could copy a CD as often as you wanted at no cost to you, and you chose to give a copy to everyone in the world, then that would be a great cost to the CD's creator, as you have destroyed his market.
A long-running Java app running under HotSpot will over time grow to be faster than nearly any simmilar C or C++ app. Why? Because the Vm can over time learn how the codepath actually is executing and optimize it at the assembly level. The only way you could consistantly achive performance as good would be to hand-code the whole app in assembly, and thati s assuming you already know in advance exactly how the program will be used so you know what paths to optimize.
I've already debunked this particular fallacy elsewhere in this thread. I don't know when the popular spin on Java's JIT technology went from "it could theoretically catch up with C++" (true, to a reasonable degree) to "it should theoretically go faster than C++" (not true, to a reasonable degree) but I wish those claiming the latter would go back and think about it for a minute. You can fairly easily see the flaws in the latter, even without knowing exactly how HotSpot works (and therefore that a lot of the claims made about its effects by enthusiasts in this thread are simply wrong, even in theory).
Many programmers make a living by providing software as a service, not a product.
And many more make a living by providing software as a product. I work for a company that gets income from both sources, for example, and the latter dwarfs the former.
The vast majority of musicians make their living by performance, not recording
The vast majority of musicians don't make a living from music. Of those who do, a significant part of that income usually comes from selling CDs at larger gigs these days. Coincidentally, I work in an office full of semi-pro musicians, BTW.
Most art considered valuable by collectors is original
I was using the term "artist" in a general sense, to mean someone who creates an original work in some form. That would include the specific groups I mentioned, and numerous others.
No, somebody doesn't. In most cases, there is no need to specify the type twice to identify the desired behaviour, and indeed in most OO languages you can instantiate type T without doing so. The only time it's necessary to specify two types is when you need a base class reference to identify an object of a derived type, which isn't a very common thing to do.
Polymorphism. It has the advantage of being far more readable than your code.
I think that's missing the point slightly. The C code to do this is horrible. Something like Perl would do it with a hash and function references in a much more concise form. Obviously functional programming languages offer considerably more powerful features than simple function pointers. The fact that Java's equivalent would be more readable than the C is not something to be proud of -- and looking at the AC's suggestion a bit further down this thread, I'm not sure I even agree with that!
function objects? Ever heard of classes or interfaces?
Do you know what a function object is?
[...] for almost everything else, using interfaces and classes is far more elegant.
No, it really isn't. Take a look at a language that supports closures some time, or just at something like Perl's sort function or C++'s STL algorithms. Function objects live in that world, and while they are not the most powerful concept it has to offer, in comparison the elementary support for interfaces and classes in Java falls a long way short.
Layout managers! A UI that looks good regardless of users resizing the window, different-sized widgets (themes[*]), different fonts/sizes (accessibility), different lengths of words (i18n).
Cocoa can't do this. MFC can't do this. Qt and Gtk don't, do they?
Actually, I wrote a typical MFC dialog-based tool at work recently, and having decided I wanted resizing on the Window, it took me about five minutes to find, install and integrate a free-as-in-you-can-have-it resizing class from one of the usual MFC web sites.
I've also worked with plenty of cross-platform and internationalised apps, and I'm still waiting for someone to tell me how any of Java's standard layout managers helps with getting a Windows-like interface on Windows, a Mac-like interface on OS X, and a KDE-style interface on Linux; there is a lot more to the styles of each OS than the alignment of dialog buttons!
Layout managers go some way to helping with these problems, and just about every major GUI library either has one itself or has several a download away. What else does Swing have to offer?
The Sun Javadocs are vastly helpful, plus you can generate your own javadoc for your own code very easily. Does perl do that?
Without wishing to fuel a pointless language flamewar, you did know about perldoc and POD, right?
You don't have to remember system.out.println(), you only have to remember how to navigate to sun.com's javadocs.
Sorry, but that's taking a reasonable argument (it suffices to know the simple things off by heart and know where to find the rest) to an absurd extreme (it's not important to know anything as long as you can remember where the reference docs are). It doesn't matter how easy to use the reference materials are, if I have to go on-line several times for each line of code I write, I'm not going to be terribly productive.
And it's just as easy to look up print in Perl, BTW.
Java seems to becoming popular for a lot of OO and software engineering research. A lot of the originator of ideas such as design patterns (Erick gamma), refactoring (Martin fowler), XP and test-driven development (Kent Beck, Ward cunningham) are Java people.
I agree with a lot of your points about bias, but this one irritated the hell out of me, I'm afraid. Although the people you mention may have popularised the terms you mention, the actual ideas behind them have been around for far longer, and used in many languages before Java. The latter simply makes a convenient buzzword to which other convenient buzzwords (like, say, "patterns" or "extreme programming") can be attached for the purposes of impressing PHBs and students.
Y'see, the thing about good geeks -- the ones who can discuss the relative merits of data structures, pointer math, and so on in an informed way -- is that they tend to understand programming. If you appreciated that, then you'd realise that any of those good geeks could easily maintain the trivial weather code written by that SNK, whether it was written in Perl, Java or VisualHappyHappy. Of course, if the SNK was himself a geek-in-training, he'd equally well have been able to write the trivial code you describe in whatever language/toolkit you were using anyway.
BTW, for future reference good geeks also hate PHBs who strangely assume that because said geeks know their stuff technically they do not also appreciate the business side of things. (Compounding this error by attempting to lecture the geeks in technical buzzwords that they understand and the PHB does not will not improve said PHB's credibility.) There are a lot of very successful senior developers/constractors/consultants reading this board who'd pretty much laugh in your face at your idea of business sense, and some of us are probably earning more than you, too. But go ahead and eye up your porn/secretary/games instead if it makes you happy; it'll keep you out of our way...:-)
I'd mod your post Interesting, but I'd rather reply...
It's true that many people miss the point of JIT in Java and make poorly justified claims that C and/or C++ will always be faster. However, it's equally true that many Java fans make a similar mistake, in assuming JIT to be a silver bullet.
I'll begin, if I may, with a selection of excerpts from your post that I believe capture your argument.
Java HotSpot JVM, is a not only an interpreter, its also a compiler; a JIT compiler. [...] The JIT compiler usually uses a cache on the disk, so when it has run your program once or twice, it has already compiled the stuff that needs it. Thus, your programs gets faster by use. [...] The compiler is a "JIT" (Just In Time) compiler, which means the code is compiled while its running, and further more, only code that the VM assumes is worth it, will be compiled. What is really interesting here, is that the compiler at this point will have runtime knowledge of the program, something a common C compiler wont have. This enables the compiler to optimise better, utilising the runtime info. (Which loops are heavy-duty, and should be unrolled, which loops are merely used, etc.).
The first problem with this is limited potential. As we all remember from the first time we coded a bad algorithm, the little adjustments really don't make that much difference to performance once you've reached "good enough"; algorithmic complexity is usually what matters in the grand scheme of things, and while micro-optimisations help, you get diminishing returns.
Now, C compilers have 20+ years of experience with things like loop unrolling, eliminating common subexpressions, yada yada. C++ compilers have a somewhat harder job because the language is more complicated, but are rapidly catching up. Java's been way behind the pace for years, and JIT allows it to level the playing field somewhat, since it's finally running as a compiled rather than an interpreted language. It's important to realise that it doesn't do much more than that, however; it hasn't invented a dozen magic new optimisations that were unknown to the C compiler community before. Which brings me to the other flaw in the usual "JIT will be faster" argument...
That other flaw is that all this run-time optimisation is not free. Sure, you could just use a straightforward compile-on-load process, optimised for the particular platform in use, and you'd get similar performance to a C application compiled to target that platform once you were past that oh-so-annoying start-up lag (at least the first time). But to do the clever run-time stuff, the stuff you describe, requires actively monitoring the running code, and doing that is expensive.
To get an idea of just how expensive, consider the type of instrumented executable often used for profiling with C or C++. These can run an order of magnitude or more slower than a fully optimised version. If you want the kind of run-time customised optimisation you're talking about, you're going to take a huge hit in the monitoring code. Moreover, if you turn the monitoring code off after you've done the optimisation, you're going to be screwed if the data within your application changes significantly, so you'd have to leave some basic monitoring on even in the optimised version.
Now, if you're talking about an application that runs the same few subroutines thousands of times on similar data, it might be worth the overhead, but for most code, that simply isn't the case. The impact of the monitoring and recompiling/optimisation overheads will always limit the effectiveness of any JIT optimisation process, and since we're talking about diminishing returns micro-optimisations anyway, you're simply never likely to beat AOT-compiled C or C++ code of a similar quality just because of a JIT optimiser.
So, the bottom line(s):
JIT compilation/optimisation has the theoretical potential to level the playing field a lot compared to interpreted by
Java's most important fundamental improvement over C++ is memory management. [...] My experience is that this roughly doubles the productivity of a Java team over a C++ team.
I never understand claims like this. The advantage of Java's GC boils down to not having to write delete p; when you're done with something allocated dynamically. Since most variables in C++ aren't allocated with new anyway, and even in the occasional code where they are you usually use RAII to avoid the overhead of deleting them manually, how on earth does productivity double in Java?
Well, what I'm trying to say is that copyright is an artificial construct. [...] Thus, "information wants to be free."
Indeed; that much is undeniable. Consider, however, that any sort of possession is to some extent an artificial construct. You do not keep all your belongings with you all the time, and the only thing that keeps them yours when you are away is the social understanding of possession, embodied in our laws. My car "wants to be free", in the sense that if I left a shiny new sports car unattended and easy to steal, it would probably be gone when I returned.;-)
I'm not arguing that natural monopolies (i.e. markets with high barriers of entry) are bad, but the market of ideas has very low barriers of entry, and so is pretty darn close to perfectly competitive.
This is true. I guess my position on the monopoly issue is that monopolies are only bad when they're abused, for example when the monopoly status is allowed to adversely affect other markets. This is what I mean when I say the counterbalances have failed; we have laws against such abuse. It is the lack of enforcement of those laws, not the dominance of the market by a few key players, that leads to the sort of high prices people so often complain about for music and movies. The correct solution to those problems, IMHO, is not to get rid of copyright (and with it, all the benefits it does bring to other markets) but to enforce the rules against the **AA and their friends as convincingly as they like doing to other people.
Considering that copyright is an artificial construct, the onus is on proving its usefulness, not proving that it's not.
That's true, but I think the simple fact that being a professional author, programmer, musician or artist would be near impossible otherwise is a fairly compelling argument! Sure, as is often pointed out, there would always be such people surviving by other means -- concert income, bespoke software developments, and so on. However, there would be far, far fewer of them, as without copyright to level out the playing fields, the number of creative jobs available that would pay a living wage would be much lower. Copyright is there to restore that balance, and when used appropriately, does so very well.
"Information wants to be free" and "monopolies are bad" would be those general arguments you're looking for, I think
Well, that depends on your point of view. Neither of those statements is necessarily true, and both are pretty meaningless without context.
As for copyright being a necessary evil... Much of the world you live in today wouldn't exist without that "evil", and much of the world you're going to live in tomorrow wouldn't either. Whether this is a good or a bad thing is left as an exercise for the reader, but personally, I think this subthread has it backwards: the principle of copyright is a good one; it's the practical applications in a few specific areas, and the failure of the counterbalances, that are currently messing things up.
Of course the other things you mention are tragic as well, and in some sense those who died on the planes are "nothing special". I don't laugh at the expense of the others who die, or who live with their own problems, either.
But it's all a matter of taste. My original post has been modded both up and down several times now -- though it's strange how the down-mods on "controversial" posts always seem to consist mostly of the M2-proof (-1, Overrated)...
I'm sorry, but I've never understood how people get upset when people make light of a situation like this.
The same reason they got upset on 9/11, and all the other times a tragedy has unnaturally ended lives, and for that matter when the life of someone they love has ended naturally: death is not funny, and making jokes out of it is likely to cause suffering to people who have already suffered enough. Is humanity really such a terribly old-fashioned virtue these days?
A GUI is, in most cases today, operating at a higher level of abstraction than a CLI. As with all such distinctions, the higher level conceals some of the details, in exchange for providing a simplified picture. As with all such distinctions, for tasks that require an understanding of those details, you must revert to the lower level tools, or choose a different higher level tool. And as with all such distinctions, for most other things Joe User will be much more productive using a suitable higher level tool. The trick is to build a good higher level tool, or range of higher level tools, which minimise the information loss while maximising the usability, and which get in the way as little as possible when you really do need to go lower.
An example close to the subject at hand is LaTeX. For most people, it's faster to produce a nicely formatted document with LaTeX by using a standard document class than it would be by using plain TeX, or by writing their own LaTeX class. OTOH, customising those documents is a bitch, so if you need to follow a house publication style, you're probably going to want to dive into LaTeX's innards and produce a custom class. For a document that doesn't fit any of the classic LaTeX formats, you might be better off developing your own macro set in plain TeX in the first place. It works for Knuth... In any case, you could have produced a quick letter faster using MS Word and a template, but the kind of person who uses a typesetting system instead of a WP finds that today's WPs give up too much control by going to that high a level.
as far as I remember "Reveal Formatting" option in Word reveals only icons and symbols for limited formatting options (i.e. hard returns).
No, that's the non-printing characters (which you can display or hide using the Tools|Options|View dialog page, or the Ctrl+Shift+8 shortcut, on most recent versions of Word).
What the original poster is talking about is a feature available via Format|Reveal Formatting...; IIRC this first appeared in Word 2002. That feature does indeed do something similar to WordPerfect's Reveal codes command, displaying the exact formatting of a particular piece of text.
Please consider yourself modded (-1, Just Plain Wrong)...:-)
The VAST majority of software being written is high-level business applications; hence there are at least an order of magnitude more JOBS available for application programmers than systems programmers.
I'm sorry, but that simply isn't true. Take a quick on any jobs board, or ask around in any hi-tech area, and you'll find far more jobs in areas like embedded software (particularly telecomms), scientific/engineering apps, and instrument control. The bubble on everything being a web-enabled database burst a couple of weeks ago, in case you missed it.;-)
In fact, looking at some respectable local IT job boards, Java appears to be a skill very much in decline, as is VB. C and C++ are as strong as ever, as is SQL. Then there's a surprisingly strong showing for Perl and also Python, considering their relative obscurity. Sure, there are also quite a few Java and.Net/C#/VB things, but an order of magnitude more jobs for applications programmers? Not unless you're counting all those high-performance, low-level jobs and everybody's system admin scripts as applications.
Slashdot Mirror
They certainly will; they're more-or-less directly equivalent to the Java tools you mentioned. :-)
As an isolated case, a specific example, yes, I agree with you. My point was more the general approach I read into your previous post: that having good documentation was an adequate substitute for knowing even the basics of your language's standard library. If you're working with console apps, the print example is directly relevant; if you're a GUI kind of guy, I guess not knowing the basic classes of your windows/dialogs framework of choice would be equivalent.
Of course it makes a difference to the performance characteristics of software written in Java as well; I'm certainly not disagreeing with that. However, in terms of developer productivity -- specifically, how long it takes a team to develop the equivalent code in Java vs. a non-GC language with otherwise similar characteristics -- I'm pretty sure that the missing delete (or whatever) is exactly what it boils down to...
I'm sorry, but you don't seem to understand either the spirit of copyright or even how it works in practice. If your work is of a good standard and you don't want to give up that work to an employer (and receive the fringe benefits that come from that employment in exchange) then you are quite at liberty to go self-employed and start your own business. That has nothing to do with copyright.
Remember that the next time you use a commodity electrical product -- like your car, or the microwave in your kitchen, or your television set, or your PC, or...
Without the artificial protections set up by copyright (and patents, too) these industries simply wouldn't be where they are today.
I don't necessarily agree with maintaining the overall number, and I do agree that no-one is entitled to a job if they don't provide a produce or service of value. However, if you're going to trim the industry, you want to lose the deadweight; it is in society's interests to keep the good people in the industry producing good products and providing good services.
Unfortunately, as with anything in a capitalist society, if the job doesn't guarantee to pay well, the good people are the first to walk. Look at top executives and what they get paid. Even with all the sleaze and kickbacks and so on, the big corps wouldn't even offer the kind of salaries they do unless they believed it was necessary to attract the calibre of staff they require. The same goes for software development, or creative writing, or music making: if you trimmed the industry by removing copyright, the better people would be the first to go, and society would lose the benefits of their now-unfinished work as a result.
That's the standard (and, I'm afraid, rather naive) argument at this point, so here's my standard counter: while what you say is true physically, it is not true economically. If you copy a work without compensating its creator, you have dimished the value of that work to a creator. Taken to an extreme, if you could copy a CD as often as you wanted at no cost to you, and you chose to give a copy to everyone in the world, then that would be a great cost to the CD's creator, as you have destroyed his market.
I've already debunked this particular fallacy elsewhere in this thread. I don't know when the popular spin on Java's JIT technology went from "it could theoretically catch up with C++" (true, to a reasonable degree) to "it should theoretically go faster than C++" (not true, to a reasonable degree) but I wish those claiming the latter would go back and think about it for a minute. You can fairly easily see the flaws in the latter, even without knowing exactly how HotSpot works (and therefore that a lot of the claims made about its effects by enthusiasts in this thread are simply wrong, even in theory).
And many more make a living by providing software as a product. I work for a company that gets income from both sources, for example, and the latter dwarfs the former.
The vast majority of musicians don't make a living from music. Of those who do, a significant part of that income usually comes from selling CDs at larger gigs these days. Coincidentally, I work in an office full of semi-pro musicians, BTW.
I was using the term "artist" in a general sense, to mean someone who creates an original work in some form. That would include the specific groups I mentioned, and numerous others.
No, somebody doesn't. In most cases, there is no need to specify the type twice to identify the desired behaviour, and indeed in most OO languages you can instantiate type T without doing so. The only time it's necessary to specify two types is when you need a base class reference to identify an object of a derived type, which isn't a very common thing to do.
I think that's missing the point slightly. The C code to do this is horrible. Something like Perl would do it with a hash and function references in a much more concise form. Obviously functional programming languages offer considerably more powerful features than simple function pointers. The fact that Java's equivalent would be more readable than the C is not something to be proud of -- and looking at the AC's suggestion a bit further down this thread, I'm not sure I even agree with that!
Do you know what a function object is?
No, it really isn't. Take a look at a language that supports closures some time, or just at something like Perl's sort function or C++'s STL algorithms. Function objects live in that world, and while they are not the most powerful concept it has to offer, in comparison the elementary support for interfaces and classes in Java falls a long way short.
Actually, I wrote a typical MFC dialog-based tool at work recently, and having decided I wanted resizing on the Window, it took me about five minutes to find, install and integrate a free-as-in-you-can-have-it resizing class from one of the usual MFC web sites.
I've also worked with plenty of cross-platform and internationalised apps, and I'm still waiting for someone to tell me how any of Java's standard layout managers helps with getting a Windows-like interface on Windows, a Mac-like interface on OS X, and a KDE-style interface on Linux; there is a lot more to the styles of each OS than the alignment of dialog buttons!
Layout managers go some way to helping with these problems, and just about every major GUI library either has one itself or has several a download away. What else does Swing have to offer?
Without wishing to fuel a pointless language flamewar, you did know about perldoc and POD, right?
Sorry, but that's taking a reasonable argument (it suffices to know the simple things off by heart and know where to find the rest) to an absurd extreme (it's not important to know anything as long as you can remember where the reference docs are). It doesn't matter how easy to use the reference materials are, if I have to go on-line several times for each line of code I write, I'm not going to be terribly productive.
And it's just as easy to look up print in Perl, BTW.
I agree with a lot of your points about bias, but this one irritated the hell out of me, I'm afraid. Although the people you mention may have popularised the terms you mention, the actual ideas behind them have been around for far longer, and used in many languages before Java. The latter simply makes a convenient buzzword to which other convenient buzzwords (like, say, "patterns" or "extreme programming") can be attached for the purposes of impressing PHBs and students.
Y'see, the thing about good geeks -- the ones who can discuss the relative merits of data structures, pointer math, and so on in an informed way -- is that they tend to understand programming. If you appreciated that, then you'd realise that any of those good geeks could easily maintain the trivial weather code written by that SNK, whether it was written in Perl, Java or VisualHappyHappy. Of course, if the SNK was himself a geek-in-training, he'd equally well have been able to write the trivial code you describe in whatever language/toolkit you were using anyway.
BTW, for future reference good geeks also hate PHBs who strangely assume that because said geeks know their stuff technically they do not also appreciate the business side of things. (Compounding this error by attempting to lecture the geeks in technical buzzwords that they understand and the PHB does not will not improve said PHB's credibility.) There are a lot of very successful senior developers/constractors/consultants reading this board who'd pretty much laugh in your face at your idea of business sense, and some of us are probably earning more than you, too. But go ahead and eye up your porn/secretary/games instead if it makes you happy; it'll keep you out of our way... :-)
I'd mod your post Interesting, but I'd rather reply...
It's true that many people miss the point of JIT in Java and make poorly justified claims that C and/or C++ will always be faster. However, it's equally true that many Java fans make a similar mistake, in assuming JIT to be a silver bullet.
I'll begin, if I may, with a selection of excerpts from your post that I believe capture your argument.
The first problem with this is limited potential. As we all remember from the first time we coded a bad algorithm, the little adjustments really don't make that much difference to performance once you've reached "good enough"; algorithmic complexity is usually what matters in the grand scheme of things, and while micro-optimisations help, you get diminishing returns.
Now, C compilers have 20+ years of experience with things like loop unrolling, eliminating common subexpressions, yada yada. C++ compilers have a somewhat harder job because the language is more complicated, but are rapidly catching up. Java's been way behind the pace for years, and JIT allows it to level the playing field somewhat, since it's finally running as a compiled rather than an interpreted language. It's important to realise that it doesn't do much more than that, however; it hasn't invented a dozen magic new optimisations that were unknown to the C compiler community before. Which brings me to the other flaw in the usual "JIT will be faster" argument...
That other flaw is that all this run-time optimisation is not free. Sure, you could just use a straightforward compile-on-load process, optimised for the particular platform in use, and you'd get similar performance to a C application compiled to target that platform once you were past that oh-so-annoying start-up lag (at least the first time). But to do the clever run-time stuff, the stuff you describe, requires actively monitoring the running code, and doing that is expensive.
To get an idea of just how expensive, consider the type of instrumented executable often used for profiling with C or C++. These can run an order of magnitude or more slower than a fully optimised version. If you want the kind of run-time customised optimisation you're talking about, you're going to take a huge hit in the monitoring code. Moreover, if you turn the monitoring code off after you've done the optimisation, you're going to be screwed if the data within your application changes significantly, so you'd have to leave some basic monitoring on even in the optimised version.
Now, if you're talking about an application that runs the same few subroutines thousands of times on similar data, it might be worth the overhead, but for most code, that simply isn't the case. The impact of the monitoring and recompiling/optimisation overheads will always limit the effectiveness of any JIT optimisation process, and since we're talking about diminishing returns micro-optimisations anyway, you're simply never likely to beat AOT-compiled C or C++ code of a similar quality just because of a JIT optimiser.
So, the bottom line(s):
I never understand claims like this. The advantage of Java's GC boils down to not having to write delete p; when you're done with something allocated dynamically. Since most variables in C++ aren't allocated with new anyway, and even in the occasional code where they are you usually use RAII to avoid the overhead of deleting them manually, how on earth does productivity double in Java?
Indeed; that much is undeniable. Consider, however, that any sort of possession is to some extent an artificial construct. You do not keep all your belongings with you all the time, and the only thing that keeps them yours when you are away is the social understanding of possession, embodied in our laws. My car "wants to be free", in the sense that if I left a shiny new sports car unattended and easy to steal, it would probably be gone when I returned. ;-)
This is true. I guess my position on the monopoly issue is that monopolies are only bad when they're abused, for example when the monopoly status is allowed to adversely affect other markets. This is what I mean when I say the counterbalances have failed; we have laws against such abuse. It is the lack of enforcement of those laws, not the dominance of the market by a few key players, that leads to the sort of high prices people so often complain about for music and movies. The correct solution to those problems, IMHO, is not to get rid of copyright (and with it, all the benefits it does bring to other markets) but to enforce the rules against the **AA and their friends as convincingly as they like doing to other people.
That's true, but I think the simple fact that being a professional author, programmer, musician or artist would be near impossible otherwise is a fairly compelling argument! Sure, as is often pointed out, there would always be such people surviving by other means -- concert income, bespoke software developments, and so on. However, there would be far, far fewer of them, as without copyright to level out the playing fields, the number of creative jobs available that would pay a living wage would be much lower. Copyright is there to restore that balance, and when used appropriately, does so very well.
Well, that depends on your point of view. Neither of those statements is necessarily true, and both are pretty meaningless without context.
As for copyright being a necessary evil... Much of the world you live in today wouldn't exist without that "evil", and much of the world you're going to live in tomorrow wouldn't either. Whether this is a good or a bad thing is left as an exercise for the reader, but personally, I think this subthread has it backwards: the principle of copyright is a good one; it's the practical applications in a few specific areas, and the failure of the counterbalances, that are currently messing things up.
Of course the other things you mention are tragic as well, and in some sense those who died on the planes are "nothing special". I don't laugh at the expense of the others who die, or who live with their own problems, either.
But it's all a matter of taste. My original post has been modded both up and down several times now -- though it's strange how the down-mods on "controversial" posts always seem to consist mostly of the M2-proof (-1, Overrated)...
The same reason they got upset on 9/11, and all the other times a tragedy has unnaturally ended lives, and for that matter when the life of someone they love has ended naturally: death is not funny, and making jokes out of it is likely to cause suffering to people who have already suffered enough. Is humanity really such a terribly old-fashioned virtue these days?
89 people died today. Was it really necessary to make a joke at their expense (and, rather sickeningly, to mod it up to +5 as well)?
I agree entirely.
A GUI is, in most cases today, operating at a higher level of abstraction than a CLI. As with all such distinctions, the higher level conceals some of the details, in exchange for providing a simplified picture. As with all such distinctions, for tasks that require an understanding of those details, you must revert to the lower level tools, or choose a different higher level tool. And as with all such distinctions, for most other things Joe User will be much more productive using a suitable higher level tool. The trick is to build a good higher level tool, or range of higher level tools, which minimise the information loss while maximising the usability, and which get in the way as little as possible when you really do need to go lower.
An example close to the subject at hand is LaTeX. For most people, it's faster to produce a nicely formatted document with LaTeX by using a standard document class than it would be by using plain TeX, or by writing their own LaTeX class. OTOH, customising those documents is a bitch, so if you need to follow a house publication style, you're probably going to want to dive into LaTeX's innards and produce a custom class. For a document that doesn't fit any of the classic LaTeX formats, you might be better off developing your own macro set in plain TeX in the first place. It works for Knuth... In any case, you could have produced a quick letter faster using MS Word and a template, but the kind of person who uses a typesetting system instead of a WP finds that today's WPs give up too much control by going to that high a level.
No, that's the non-printing characters (which you can display or hide using the Tools|Options|View dialog page, or the Ctrl+Shift+8 shortcut, on most recent versions of Word).
What the original poster is talking about is a feature available via Format|Reveal Formatting...; IIRC this first appeared in Word 2002. That feature does indeed do something similar to WordPerfect's Reveal codes command, displaying the exact formatting of a particular piece of text.
Please consider yourself modded (-1, Just Plain Wrong)... :-)
I'm sorry, but that simply isn't true. Take a quick on any jobs board, or ask around in any hi-tech area, and you'll find far more jobs in areas like embedded software (particularly telecomms), scientific/engineering apps, and instrument control. The bubble on everything being a web-enabled database burst a couple of weeks ago, in case you missed it. ;-)
In fact, looking at some respectable local IT job boards, Java appears to be a skill very much in decline, as is VB. C and C++ are as strong as ever, as is SQL. Then there's a surprisingly strong showing for Perl and also Python, considering their relative obscurity. Sure, there are also quite a few Java and .Net/C#/VB things, but an order of magnitude more jobs for applications programmers? Not unless you're counting all those high-performance, low-level jobs and everybody's system admin scripts as applications.
When did the standards committee ratify the Plum Hall tests? I never saw anything about that.