So, some 25 years after the advent of the "AI Revolution", in-the-trenches programmers are sitting around debugging J2EE stack traces that look like this insanely over-architected slop.
With programmer productivity advancements of such magnitude, can the Singularity be far behind?
Look, the reality is that CS theory (including AI) has been fairly stagnant for 20-30 years. Applied programming technology is higher-level than it was a few decades ago, but what about the theory?
Dumping 43 million layers of J2EE bloat (which is based on a mediocre implementation of decades-old OO techniques) on the programmer might give software architects stiffies, but it doesn't get us any closer to the Singularity.
My work environment is very flexible, so I'm pretty much free to structure my time, as long as I get the work done. But let's face it: a larger slice of programming than we'd like is friggin' boring drudge work. Here's the most effective strategy I've found for concentrating on work:
- Get enough sleep, and get up early (heresy for a geek, I know).
- Have some breakfast and then *dive right into work while you're still fresh*. Don't squander these precious hours on Slashdot and Reddit! Do 3-4 hours of work until your morning high is gone.
- Then stop and do some very intensive physical exercise for 45-75 minutes. By "very intensive", I'm talking about the frothin-at-the-mouth, panting, totally-drenched-in-sweat kind of stuff. My chosen exercise is to split firewood with a maul, at the fastest pace my body can handle.
- After going all out on the exercise, take a shower.
- Eat lunch and enjoy a bit of leisure (read Slashdot or whatever). At this point, the post-morning-high crash is long gone, but it should have been replaced by a feeling of relaxation (because of exercise -> shower -> lunch), but still with adequate energy because the exercise revved your body up. I find that if I don't do the (very intensive) exercise, I tend to be very sleepy from the time the morning high wears off until the end of the work day.
- Do another 3-4 hours of work. You'll probably find it easier to concentrate on boring work during this period of the day, since you'll be mellowed by the exercise -> shower -> meal.
- If 6-8 hours is enough, you're now done for the day. However, I sometimes find the very most boring work most tolerable between 8 p.m. and 10 p.m., when my body is winding down toward sleep. Just don't do anything so absorbing or intellectually taxing that it wakes you back up, or you'll be up really late.
I know these suggestions are not realistic for most people, but for those who work from home, they're feasible. That mid-day exercise provides a huge boost to my ability to concentrate.
PHP is an extremely flexible scripting lanuage, that really excells at what it does: powering the back-end of a web application and interfacing with databases and the file system. Trying to make PHP do other things is possible, but is almost always a nasty hack.
Help me out here: you're saying that PHP is extremely flexible, as long as the programmer only tries to write one type of program with it? Hmmmm?
I think we both recognize the truth: compared to Python, Ruby, or Lisp, PHP is not very flexible at all. It's a poorly designed, inflexible language that happens to have gained momentum at a critical era in the history of the WWW.
From my experience using C++ in the field, I basically agree. While type safety can be a headache, there are many errors that strong typing eliminates entirely, almost to the point that "if it compiles, it's correct".
If you were talking about ML, you might be right, but in the case of C++, that's unadulterated bullshit. C++ can never approach the "if it compiles, it's correct" ideal because it allows unsafe memory operations. I recently worked on a large C++ code base that "compiled" the day I arrived. Within a couple of months, I had fixed about 90 memory handling bugs, which type safety did absolutely nothing to guard against.
7-zip is the 16th most popular download on SourceForge (8544268 downloads so far), and it gets downloaded about 18000 times per day, so it must be going somewhere in terms of popularity.
Anyone who's tried to write a Java program that uses minimal hardware resources already knows that Sun views "the software as the razor; the servers as the blades."
Views are a nice feature, but most often used to support business and reporting. I don't like managers connecting to the database to run queries.
Yeah, what kind of crazy person would use a database engine to support managers in making business decisions. Wild, I tell you, just far out!
The truth is that since MySQL doesn't allow you to define constraints on how long queries launched by a specific user can run, you've concluded that allowing ad hoc queries is a bad practice. That's tunnel vision, not insight.
You're right, and it's fine for MySQL to be a Cessna.
But for many years, MySQL proponents have, in blatant defiance of the facts, claimed that their Cessna could seat 275 passengers and cross the Pacific in one hop. If MySQL lacked a feature, proponents claimed the feature was unnecessary fluff. As soon as the feature was added, they announced that "MySQL is ready to run with the big dogs." When the features in question were utterly fundamental to effectively exploiting the power of the relational database model, this tactic made MySQL proponents look like they were either ignorant or unabashedly dishonest.
That's why so many people today have a negative gut reaction to MySQL: the history of blatantly distortionary marketing, not the entirely justifiable choice of market segment.
You're correct that (non-graphical) pure Java code is much faster than pure Python code, although Java typically uses 2-5x as much memory.
But you say that, "Python is provable slower than Perl... [for] the Sieve of Eratosthenes algorithm". I don't think you could have picked a worse example to support your claim; in the Shootout's Sieve test, Python is friggin' four times faster than Perl.
Circa 2000, it was true that Perl was significantly faster than Python, but not anymore. While the Perl interpreter stagnated due to the Perl 6 fiasco, the Python interpreter has closed the gap, and then some. Except for regular expression-heavy code and I/O-heavy code (which are Perl's specialty), Python is now faster across the board. Check the shootout if you don't believe me.
Don't get me wrong. I'm not claiming that Python is a speed demon (in fact, it has serious performance problems). But Perl is not faster anymore.
Odd, then, that NetBeans and Eclipse are still slower than a sedated elephant on my Athlon 64 3200+ with 512 MB RAM. My computer must be living in a time warp.
Or maybe the truth is that Java is "effectively sluggish, though not technically slow" because its runtime optimization techniques require such huge amounts of RAM.
... "ominous" news for the millions of truckers and taxi drivers (in the US alone) who'll be quickly replaced over the next decade.
"Quickly replaced over the next decade"? You're nuts.
I expect it to be at least thirty years before automated vehicles are driving on ordinary public roads. In ultra-remote areas (think resource exploration in harsh environments), controlled areas (think forklifts within a freight terminal), and war zones: yes. Public roads (imagine a delivery truck threading through Dallas in rush hour): no time soon.
The software and hardware from which these vehicles are built is certain to fail occasionally, and consider the standards an automated "driver" would be held to: if the brakes failed and a human driver crashed into others, the event would be ascribed to "bad luck" or "poor maintenance", but wouldn't be noteworthy; if the same thing happened to an automated vehicle, it'd become a political carnival, a rally point for those concerned about what they perceive to be the dehumanizing impact of technology.
The solution is to put Richard Stallman in charge of the kernel development process. If he got hit by a bus, the only problem would be a pulverised bus.
Re:Screensavers, music, and Unicode?
on
State of the Onion 9
·
· Score: 3, Insightful
I want Perl 6 to be the community's rewrite of Perl and of the community.
And that's the chief reason why it's a directionless (or perhaps I should say omnidirectional) disaster that's not even close to production-ready after all these years. Programming language design by committee does not work.
Another thing to be careful of with KVM switches is whether the switch puts a governor on the keyboard repeat rate.
For personal use, I have a TrendNet TK-401R KVM switch, and although it's generally quite satisfactory for the price (~ $55), it locks the keyboard repeat rate at a low setting, which I've found no way to overcome at the software system level. It's maddening to try to use a command line shell with a sluggish keyboard repeat rate.
The Anandtech thread I linked to was about 24" wide-screen LCDs with a native res of 1900x1200. There were specific complaints about the nVidia 5200's DVI facilities not being up to that, and subsequent comments that reasonably priced ATI cards can handle it.
Low end nVidia cards such as the 5200 you mention do a poor job with high-res 2d, though, which was the focus of the parent poster's question. In the 2d arena, ATI's offerings do a better job, apparently because there are fewer OEMs who use more consistently high-quality parts.
On a practical level, Linus has said many times that he won't do this because it would require freezing the internal kernel api. While this might sound good for an outsider, you only have to consider how much say the USB structure has been reorganised to realise how bad an idea it would have been if this was all frozen.
Microsoft has managed to deliver a stable driver API in the NT kernel over the last 5 years (across Windows 2000, XP, 2003). Why can't Linux do the same? Sloppy engineers who can't create a design in which they have confidence?
While this might sound good for an outsider
You call them outsiders; I call them users. I say their concerns should be paramount; you say they're not discerning enough to know what they need. Your condescending attitude toward users is why Linux has gained such minimal traction on the desktop.
Borland has a history of contradictory and self-defeating behavior in many areas, but especially with regard to open source, and even in closed source support for the Linux platform.
First of all, renaming a large, long-established company (to Inprise), then reverting to Borland screams "our once-famous brand has become irrelevant, so we're launching ham-handed, ill-considered reinvention attempts".
In 2000, with about nine months of preparatory fanfare, they released the source to their database engine, Interbase, under a Mozilla-style license. Soon thereafter, they abandoned open source Interbase and closed the product again.
An independent open source offshoot from the Interbase source code (Firebird) is doing fairly well, but in the course of that whole debacle, Borland managed to look both mean-spirited and incompetent.
Then they released Kylix (essentially a Linux port of Delphi) after months of hype, subsequently decided that desktop Linux was irrelevant, and cast it adrift.
In the early days of the.NET platform, Borland even released a version of Delphi that lacked the ability to compile to native code, which they subsequently decided to restore.
Those of us who've been observing Borland throughout all this expect them to maintain about as steady a course as a carload of squabbling thirteen-year-olds who just stole a car and a case of beer. The opening of JBuilder will be no different.
1) Cost. Since there need only be half as many sockets, the motherboard can be smaller, less complicated, and therefore less expensive. This is especially true in the case of single-socket motherboards, which are usually 50-60% as expensive as their dual-socket brethren. AMD has sweetened the cost savings even further by arranging it so that most single-socket motherboards already in use with a single-core CPU can accomodate a dual-core CPU after just a BIOS flash.
2) More efficient interconnection between the cores. This advantage currently applies to AMD's design but not Intel's. As explained here, "As you can see, AMD didn't simply glue a pair of K8 cores together on a single piece of silicon. They've actually done some integration work at a very basic level, so that the two CPU cores can act together more effectively. Each of the K8 cores has its own, independent L2 cache onboard, but the two cores share a common system request queue. They also share a dual-channel DDR memory controller and a set of HyperTransport links to the outside world."
After reading the TechReport article I linked to above, it looks to me like AMD is way ahead in the dual core market in all of the areas that count: better backward-compatibility, better cache coherency, and lower heat.
Slashdot Mirror
So, some 25 years after the advent of the "AI Revolution", in-the-trenches programmers are sitting around debugging J2EE stack traces that look like this insanely over-architected slop.
With programmer productivity advancements of such magnitude, can the Singularity be far behind?
Look, the reality is that CS theory (including AI) has been fairly stagnant for 20-30 years. Applied programming technology is higher-level than it was a few decades ago, but what about the theory?
Dumping 43 million layers of J2EE bloat (which is based on a mediocre implementation of decades-old OO techniques) on the programmer might give software architects stiffies, but it doesn't get us any closer to the Singularity.
My work environment is very flexible, so I'm pretty much free to structure my time, as long as I get the work done. But let's face it: a larger slice of programming than we'd like is friggin' boring drudge work. Here's the most effective strategy I've found for concentrating on work:
- Get enough sleep, and get up early (heresy for a geek, I know).
- Have some breakfast and then *dive right into work while you're still fresh*. Don't squander these precious hours on Slashdot and Reddit! Do 3-4 hours of work until your morning high is gone.
- Then stop and do some very intensive physical exercise for 45-75 minutes. By "very intensive", I'm talking about the frothin-at-the-mouth, panting, totally-drenched-in-sweat kind of stuff. My chosen exercise is to split firewood with a maul, at the fastest pace my body can handle.
- After going all out on the exercise, take a shower.
- Eat lunch and enjoy a bit of leisure (read Slashdot or whatever). At this point, the post-morning-high crash is long gone, but it should have been replaced by a feeling of relaxation (because of exercise -> shower -> lunch), but still with adequate energy because the exercise revved your body up. I find that if I don't do the (very intensive) exercise, I tend to be very sleepy from the time the morning high wears off until the end of the work day.
- Do another 3-4 hours of work. You'll probably find it easier to concentrate on boring work during this period of the day, since you'll be mellowed by the exercise -> shower -> meal.
- If 6-8 hours is enough, you're now done for the day. However, I sometimes find the very most boring work most tolerable between 8 p.m. and 10 p.m., when my body is winding down toward sleep. Just don't do anything so absorbing or intellectually taxing that it wakes you back up, or you'll be up really late.
I know these suggestions are not realistic for most people, but for those who work from home, they're feasible. That mid-day exercise provides a huge boost to my ability to concentrate.
PHP is an extremely flexible scripting lanuage, that really excells at what it does: powering the back-end of a web application and interfacing with databases and the file system. Trying to make PHP do other things is possible, but is almost always a nasty hack.
Help me out here: you're saying that PHP is extremely flexible, as long as the programmer only tries to write one type of program with it? Hmmmm?
I think we both recognize the truth: compared to Python, Ruby, or Lisp, PHP is not very flexible at all. It's a poorly designed, inflexible language that happens to have gained momentum at a critical era in the history of the WWW.
Nah, Bill's bid to shore up the profitability of the perhipheral divisions of Microsoft consists of purchasing Herman Miller.
Steve goes through a few dozen chairs during the employee productivity review: profit.
Steve smashes a bookcase halfway through a product placement strategy meeting: profit.
Steve wipes out a patio set as the XBox branding summit heats up: profit.
They just can't lose.
If the Sun turns out to be binary, what the hell will the Gentoo guys do, CCFLAGS="-Odamnimcold -DALPHA_CENTAURI -funroll-solar-panels"?
From my experience using C++ in the field, I basically agree. While type safety can be a headache, there are many errors that strong typing eliminates entirely, almost to the point that "if it compiles, it's correct".
If you were talking about ML, you might be right, but in the case of C++, that's unadulterated bullshit. C++ can never approach the "if it compiles, it's correct" ideal because it allows unsafe memory operations. I recently worked on a large C++ code base that "compiled" the day I arrived. Within a couple of months, I had fixed about 90 memory handling bugs, which type safety did absolutely nothing to guard against.
7-zip is the 16th most popular download on SourceForge (8544268 downloads so far), and it gets downloaded about 18000 times per day, so it must be going somewhere in terms of popularity.
Anyone who's tried to write a Java program that uses minimal hardware resources already knows that Sun views "the software as the razor; the servers as the blades."
I guess they could try to patent ugliness...
No good; there's prior art.
(ducks)
Views are a nice feature, but most often used to support business and reporting. I don't like managers connecting to the database to run queries.
Yeah, what kind of crazy person would use a database engine to support managers in making business decisions. Wild, I tell you, just far out!
The truth is that since MySQL doesn't allow you to define constraints on how long queries launched by a specific user can run, you've concluded that allowing ad hoc queries is a bad practice. That's tunnel vision, not insight.
You're right, and it's fine for MySQL to be a Cessna.
But for many years, MySQL proponents have, in blatant defiance of the facts, claimed that their Cessna could seat 275 passengers and cross the Pacific in one hop. If MySQL lacked a feature, proponents claimed the feature was unnecessary fluff. As soon as the feature was added, they announced that "MySQL is ready to run with the big dogs." When the features in question were utterly fundamental to effectively exploiting the power of the relational database model, this tactic made MySQL proponents look like they were either ignorant or unabashedly dishonest.
That's why so many people today have a negative gut reaction to MySQL: the history of blatantly distortionary marketing, not the entirely justifiable choice of market segment.
You're correct that (non-graphical) pure Java code is much faster than pure Python code, although Java typically uses 2-5x as much memory.
But you say that, "Python is provable slower than Perl... [for] the Sieve of Eratosthenes algorithm". I don't think you could have picked a worse example to support your claim; in the Shootout's Sieve test, Python is friggin' four times faster than Perl .
Circa 2000, it was true that Perl was significantly faster than Python, but not anymore. While the Perl interpreter stagnated due to the Perl 6 fiasco, the Python interpreter has closed the gap, and then some. Except for regular expression-heavy code and I/O-heavy code (which are Perl's specialty), Python is now faster across the board. Check the shootout if you don't believe me.
Don't get me wrong. I'm not claiming that Python is a speed demon (in fact, it has serious performance problems). But Perl is not faster anymore.
Odd, then, that NetBeans and Eclipse are still slower than a sedated elephant on my Athlon 64 3200+ with 512 MB RAM. My computer must be living in a time warp.
Or maybe the truth is that Java is "effectively sluggish, though not technically slow" because its runtime optimization techniques require such huge amounts of RAM.
Although I'm well aware of the limitations of the Great Computer Language Shootout as a tool for measuring a language's overall utility, it does tell the naked truth about performance. When I see an easy-to-use language whose design makes it easier to write reusable code than Java using somewhat less CPU time and typically FOUR TIMES less memory , it makes me suspect that well-intentioned Java apologists like you have never really attempted an objective evaluation of the performance compromises inherent in Java's design.
"Quickly replaced over the next decade"? You're nuts.
I expect it to be at least thirty years before automated vehicles are driving on ordinary public roads. In ultra-remote areas (think resource exploration in harsh environments), controlled areas (think forklifts within a freight terminal), and war zones: yes. Public roads (imagine a delivery truck threading through Dallas in rush hour): no time soon.
The software and hardware from which these vehicles are built is certain to fail occasionally, and consider the standards an automated "driver" would be held to: if the brakes failed and a human driver crashed into others, the event would be ascribed to "bad luck" or "poor maintenance", but wouldn't be noteworthy; if the same thing happened to an automated vehicle, it'd become a political carnival, a rally point for those concerned about what they perceive to be the dehumanizing impact of technology.
The solution is to put Richard Stallman in charge of the kernel development process. If he got hit by a bus, the only problem would be a pulverised bus.
I want Perl 6 to be the community's rewrite of Perl and of the community.
And that's the chief reason why it's a directionless (or perhaps I should say omnidirectional) disaster that's not even close to production-ready after all these years. Programming language design by committee does not work.
Another thing to be careful of with KVM switches is whether the switch puts a governor on the keyboard repeat rate.
For personal use, I have a TrendNet TK-401R KVM switch, and although it's generally quite satisfactory for the price (~ $55), it locks the keyboard repeat rate at a low setting, which I've found no way to overcome at the software system level. It's maddening to try to use a command line shell with a sluggish keyboard repeat rate.
While SAS seems like a very cool company...
Looks that way to me too. They support open source, for example.
Quote from the game Freedom Fighters:
"That's what I love about Americans--one finger up your nose and the other on the remote control."
The Anandtech thread I linked to was about 24" wide-screen LCDs with a native res of 1900x1200. There were specific complaints about the nVidia 5200's DVI facilities not being up to that, and subsequent comments that reasonably priced ATI cards can handle it.
Low end nVidia cards such as the 5200 you mention do a poor job with high-res 2d, though, which was the focus of the parent poster's question. In the 2d arena, ATI's offerings do a better job, apparently because there are fewer OEMs who use more consistently high-quality parts.
On a practical level, Linus has said many times that he won't do this because it would require freezing the internal kernel api. While this might sound good for an outsider, you only have to consider how much say the USB structure has been reorganised to realise how bad an idea it would have been if this was all frozen.
Microsoft has managed to deliver a stable driver API in the NT kernel over the last 5 years (across Windows 2000, XP, 2003). Why can't Linux do the same? Sloppy engineers who can't create a design in which they have confidence?
While this might sound good for an outsider
You call them outsiders; I call them users. I say their concerns should be paramount; you say they're not discerning enough to know what they need. Your condescending attitude toward users is why Linux has gained such minimal traction on the desktop.
Borland has a history of contradictory and self-defeating behavior in many areas, but especially with regard to open source, and even in closed source support for the Linux platform.
First of all, renaming a large, long-established company (to Inprise), then reverting to Borland screams "our once-famous brand has become irrelevant, so we're launching ham-handed, ill-considered reinvention attempts".
In 2000, with about nine months of preparatory fanfare, they released the source to their database engine, Interbase, under a Mozilla-style license. Soon thereafter, they abandoned open source Interbase and closed the product again.
An independent open source offshoot from the Interbase source code (Firebird) is doing fairly well, but in the course of that whole debacle, Borland managed to look both mean-spirited and incompetent.
Then they released Kylix (essentially a Linux port of Delphi) after months of hype, subsequently decided that desktop Linux was irrelevant, and cast it adrift.
In the early days of the .NET platform, Borland even released a version of Delphi that lacked the ability to compile to native code, which they subsequently decided to restore.
Those of us who've been observing Borland throughout all this expect them to maintain about as steady a course as a carload of squabbling thirteen-year-olds who just stole a car and a case of beer. The opening of JBuilder will be no different.
1) Cost.
Since there need only be half as many sockets, the motherboard can be smaller, less complicated, and therefore less expensive. This is especially true in the case of single-socket motherboards, which are usually 50-60% as expensive as their dual-socket brethren. AMD has sweetened the cost savings even further by arranging it so that most single-socket motherboards already in use with a single-core CPU can accomodate a dual-core CPU after just a BIOS flash.
2) More efficient interconnection between the cores.
This advantage currently applies to AMD's design but not Intel's. As explained here, "As you can see, AMD didn't simply glue a pair of K8 cores together on a single piece of silicon. They've actually done some integration work at a very basic level, so that the two CPU cores can act together more effectively. Each of the K8 cores has its own, independent L2 cache onboard, but the two cores share a common system request queue. They also share a dual-channel DDR memory controller and a set of HyperTransport links to the outside world."
After reading the TechReport article I linked to above, it looks to me like AMD is way ahead in the dual core market in all of the areas that count: better backward-compatibility, better cache coherency, and lower heat.
Steam is the only direct-to-consumer internet-based game delivery service.
That's not true.