Problems like these should be solved by technology. The time and energy of talented hackers is wasted on vigilanteism. The digital world has new rules and new capabilities.
Sorry, I know good engineering work is harder, much less exciting, and much less satisfying than hacking the enemy directly, but why play whack-a-mole when you can make them obsolete? Ok, enough ranting. I hope y'all had fun.
After Safari Books online, I bought more books. After iTunes music store, I bought more CDs. Not out of charity, but additional interest.
The texts are available search-only. It's a f'in product catalog for God's sake! You can't read the entire journal online, just find the one that you need to buy!! How much do you want to bet that the publishers heard "digital copy" and panicked before reading (or thinking) any further?
Don't worry about being off topic, once the/. post leaves the front page, nobody else but us cares:-)
The Desktop App example is actually really straightforward: the delays in using Java are immediately visible to the user, and immediately comparable to C/C++ desktop apps. Delays imposed by java on the server side are less visible; as they can only be seen indirectly by a client app (and web browsers are C/C++!), and there aren't many comparable C/C++ apps on the server side.
And, btw, the document you linked to before was all scientific number-crunching. Something that wouldn't run as a server app. And I did read through the source of that, they're reasonably close implementations with each other, in a sec I'll describe why C/C++ is still going to be faster in a production environment (even with the same number-crunching code!). See next paragraph.
As for the intuition claims, what happens when you feed some profiling data back into the compiler (which the better ones accept) ? Any (good) C/C++ app development house will have automated tests running, which provide gobs of good profiling data. And again, a compiler back-end can optimize more aggressively than a JVM can, as it has high-level knowledge of the system (e.g. the source code) vs only the low-level knowledge a JVM has (bytecode only). Not to mention that the low-level implementation of the intermediate representation can be made highly compatible with the target's architecture, vs having one imposed from Sun (which, btw, was made for interpretation, not recompilation, compare with.Net's CLR which was).
And I was being nice about GC, and I'll be nice again. I'll save the debugging arguments for another day -- java programmers tend to fear problems solved in C++ quite easily. Btw, the arguments for JIT are usually similar for GC: in the "big picture" (e.g. a fantasy land where I can claim whatever I want), the overhead is nothing compared to code that we don't actually talk about.
And some more niceness: it's easier to tweak out Java code's performance: the JVM does most of the heavy lifting for you. Java's often easier to develop for (unless you use the libraries too heavily, they're mostly shit), and there are many areas where the dev effort/speed trade off favors java over C/C++. Java has a richer runtime with some nice parts in there (reflection comes to mind).
However, the claim that Java can be faster than C/C++, when good people are put on both side, is false. A C/C++ compiler simply has more knowledge of the system being compiled (the source text vs java bytecode), essentially unlimited time to optimize it (for an extreme case, check out http://www.cs.utk.edu/~rwhaley/papers/icpp05_8.ps ), and full freedom for transformations (a C/C++ compiler, knowing what you originally asked for in the source code, can generate anything it wants that fills your request; a JVM's JIT can only guess at what your source wanted from the bytecode it has to work with, limited to the strict letter of the law given by the bytecode). The paper you listed was an honest attempt at comparison, but GCC isn't optimal on many platforms, most notably intel or ppc.
This is a fair set of tradeoffs; don't let the marketing people and the kool-aide drinkers tell you different.
There are always booth babes. The number (entire booths set up as playpens for the babes to sit in, with no product??) and prevalence (I'm hearing more about them than anything else (XBox 360 and PS3 included!)) are the indicators.
1. "but three days of snapping Poloroids with sweaty game geeks leads these girls to swear off Guild Wars forever." -- How many were considering Guild Wars before?
2. How much of the motivation for these women's presence came from the marketing dept trying to convince their own developers to come to the show?
3. Usually frills like these are a good indicator of an oversaturated, undergrowing market. And again, the indicator is proven true.
Ah yes the denial sits in. Some things to ponder: 1. If it's not the JVMs, then why are all java desktop apps of size slow? Oh sure, blame the programmer, I dare you.
2. The C/C++ argument is fallacious in its very nature. Comparing well-written java code to crap C code doesn't count (O(n) algorithms vs O(n^2) on string ops, please!).
Here's some intuition why it's fallacious: C/C++ can always express everything that a java app can, only it doesnt have the overhead of a JVM. The runtime translation will always take time during execution, while a C/C++ app had all that done at compile time. As the JVM is itself a C/C++ app, it can only add overhead to a java app in comparison to a C/C++ app.
The "Java is faster than C/C++" argument argues this: interpretation + JVM + C < C (speaking in overheads).
While I'd disagree to the characterization of OS X as little more than eye candy and color, the general idea that GUI development has flattened out is about right. But there are some good reasons for it:
Increasing cost of change - Both users and vendors have lots invested in their current systems, in training, software, and installed base. Both have more to lose in case of failure. In the older days, if it didn't work, each box was a new platform, and you could trash that box if it failed.
Reasonably Good - For what people expect out of computers, the current generation of GUIs are decent at providing just that. People can often learn in a few days what they need to know to use what they want out of a computer.
Increasing difficulty for innovation - Major shifts in the way a GUI is done is going to require some strong cognative leaps (e.g. 3D UIs, if they're going to be more than a cute gimmick, will need lots of R&D before they get as straighforward, efficient, and easy to use as 2D GUIs). The next generation of user interfaces will be a significant jump forward, and until someone can make that leap, the rest of the industry will just evolve the status quo. Not a bad thing, just a normal part of a technology's evolution.
So yeah, we'll have lots of evolution until the next revolution. Looking to Tiger or Longhorn for anything more is a waste of effort.
It looks like the checkpoints have a real culture clash problem -- prior Iraqi government wanted citizens to speed by as fast as possible (or else face possible arrest), while the US forces want people nice & slow. So lots of Iraqis tend to speed by, just trying to follow the last commands they've heard on the topic.
I'm pretty anal about this, but my own policy is this: tabs for indents, spaces for everything else. So, I end up with lines like this: void foo () { (tab)line 1; (tab)line that ( (tab)____continues onwards (tab)____for a few lines); }
The _s are spaces here. That way, the text looks good no matter what the indent level is (unless it's ridiculously small, like 1 space).
Which only really works when your editor lets you see tab characters and easily manipulate them (e.g. BBEdit).
Slashdot Mirror
Problems like these should be solved by technology. The time and energy of talented hackers is wasted on vigilanteism. The digital world has new rules and new capabilities.
Sorry, I know good engineering work is harder, much less exciting, and much less satisfying than hacking the enemy directly, but why play whack-a-mole when you can make them obsolete? Ok, enough ranting. I hope y'all had fun.
The flame level here's getting higher than my tastes. Have a nice day and enjoy Java.
.. but I'm too lazy to read all the posts.
After Safari Books online, I bought more books. After iTunes music store, I bought more CDs. Not out of charity, but additional interest.
The texts are available search-only. It's a f'in product catalog for God's sake! You can't read the entire journal online, just find the one that you need to buy!! How much do you want to bet that the publishers heard "digital copy" and panicked before reading (or thinking) any further?
Don't worry about being off topic, once the /. post leaves the front page, nobody else but us cares :-)
.Net's CLR which was).
The Desktop App example is actually really straightforward: the delays in using Java are immediately visible to the user, and immediately comparable to C/C++ desktop apps. Delays imposed by java on the server side are less visible; as they can only be seen indirectly by a client app (and web browsers are C/C++!), and there aren't many comparable C/C++ apps on the server side.
And, btw, the document you linked to before was all scientific number-crunching. Something that wouldn't run as a server app. And I did read through the source of that, they're reasonably close implementations with each other, in a sec I'll describe why C/C++ is still going to be faster in a production environment (even with the same number-crunching code!). See next paragraph.
As for the intuition claims, what happens when you feed some profiling data back into the compiler (which the better ones accept) ? Any (good) C/C++ app development house will have automated tests running, which provide gobs of good profiling data. And again, a compiler back-end can optimize more aggressively than a JVM can, as it has high-level knowledge of the system (e.g. the source code) vs only the low-level knowledge a JVM has (bytecode only). Not to mention that the low-level implementation of the intermediate representation can be made highly compatible with the target's architecture, vs having one imposed from Sun (which, btw, was made for interpretation, not recompilation, compare with
And I was being nice about GC, and I'll be nice again. I'll save the debugging arguments for another day -- java programmers tend to fear problems solved in C++ quite easily. Btw, the arguments for JIT are usually similar for GC: in the "big picture" (e.g. a fantasy land where I can claim whatever I want), the overhead is nothing compared to code that we don't actually talk about.
And some more niceness: it's easier to tweak out Java code's performance: the JVM does most of the heavy lifting for you. Java's often easier to develop for (unless you use the libraries too heavily, they're mostly shit), and there are many areas where the dev effort/speed trade off favors java over C/C++. Java has a richer runtime with some nice parts in there (reflection comes to mind).
However, the claim that Java can be faster than C/C++, when good people are put on both side, is false. A C/C++ compiler simply has more knowledge of the system being compiled (the source text vs java bytecode), essentially unlimited time to optimize it (for an extreme case, check out http://www.cs.utk.edu/~rwhaley/papers/icpp05_8.ps ), and full freedom for transformations (a C/C++ compiler, knowing what you originally asked for in the source code, can generate anything it wants that fills your request; a JVM's JIT can only guess at what your source wanted from the bytecode it has to work with, limited to the strict letter of the law given by the bytecode). The paper you listed was an honest attempt at comparison, but GCC isn't optimal on many platforms, most notably intel or ppc.
This is a fair set of tradeoffs; don't let the marketing people and the kool-aide drinkers tell you different.
There are always booth babes. The number (entire booths set up as playpens for the babes to sit in, with no product??) and prevalence (I'm hearing more about them than anything else (XBox 360 and PS3 included!)) are the indicators.
1. "but three days of snapping Poloroids with sweaty game geeks leads these girls to swear off Guild Wars forever." -- How many were considering Guild Wars before?
2. How much of the motivation for these women's presence came from the marketing dept trying to convince their own developers to come to the show?
3. Usually frills like these are a good indicator of an oversaturated, undergrowing market. And again, the indicator is proven true.
Ah yes the denial sits in. Some things to ponder:
1. If it's not the JVMs, then why are all java desktop apps of size slow? Oh sure, blame the programmer, I dare you.
2. The C/C++ argument is fallacious in its very nature. Comparing well-written java code to crap C code doesn't count (O(n) algorithms vs O(n^2) on string ops, please!).
Here's some intuition why it's fallacious: C/C++ can always express everything that a java app can, only it doesnt have the overhead of a JVM. The runtime translation will always take time during execution, while a C/C++ app had all that done at compile time. As the JVM is itself a C/C++ app, it can only add overhead to a java app in comparison to a C/C++ app.
The "Java is faster than C/C++" argument argues this:
interpretation + JVM + C < C
(speaking in overheads).
I call that false.
(And JVMs are still ass-slow).
Remember that the most pirated products are also at monopoly pricing levels. How many really would buy?
This is somehow surprising to you? From MS?
But I think it looks like complete ass.
- Increasing cost of change - Both users and vendors have lots invested in their current systems, in training, software, and installed base. Both have more to lose in case of failure. In the older days, if it didn't work, each box was a new platform, and you could trash that box if it failed.
- Reasonably Good - For what people expect out of computers, the current generation of GUIs are decent at providing just that. People can often learn in a few days what they need to know to use what they want out of a computer.
- Increasing difficulty for innovation - Major shifts in the way a GUI is done is going to require some strong cognative leaps (e.g. 3D UIs, if they're going to be more than a cute gimmick, will need lots of R&D before they get as straighforward, efficient, and easy to use as 2D GUIs). The next generation of user interfaces will be a significant jump forward, and until someone can make that leap, the rest of the industry will just evolve the status quo. Not a bad thing, just a normal part of a technology's evolution.
So yeah, we'll have lots of evolution until the next revolution. Looking to Tiger or Longhorn for anything more is a waste of effort.Actually you'd have to find a top-tier OEM to make it fair. You're not building the mac from parts, you're getting a fully assembled unit.
If you're coming in from fvwm2 and get on a mac, for the love of God, don't try to make the mac more like fvwm2.
From the CS Monitor: http://blogs.csmonitor.com/notebook_iraq/2005/03/i ndex.html#a0003873189
It looks like the checkpoints have a real culture clash problem -- prior Iraqi government wanted citizens to speed by as fast as possible (or else face possible arrest), while the US forces want people nice & slow. So lots of Iraqis tend to speed by, just trying to follow the last commands they've heard on the topic.
It's too straightforward. Makes people nervous.
Are dead tailgaters really counted as a loss?
Us faithful aren't. This is f'in weak.
I'm pretty anal about this, but my own policy is this: tabs for indents, spaces for everything else. So, I end up with lines like this:
void foo () {
(tab)line 1;
(tab)line that (
(tab)____continues onwards
(tab)____for a few lines);
}
The _s are spaces here. That way, the text looks good no matter what the indent level is (unless it's ridiculously small, like 1 space).
Which only really works when your editor lets you see tab characters and easily manipulate them (e.g. BBEdit).
More proof that DS users are dumb.
try OpenSecrets.
Plus one for racism?
Primarily, no. It's designed for adults, 18-35.
It's an actual C++ feature. 90% of the people on this site that say they know C++ know C with classes.
please do us a favor and try some timing tests for user-relevant tasks on your current system and the new build.