As far as I'm concerned, there is absolutely no sane reason to use a system like Java with the overhead of a VM when you already know what architecture the binaries will be running on when you build them.
As for being as slick as OS X, well, spoken like somebody who obviously doesn't own a Mac.
I'm typing this on my home Mac. It's nice and all, but I look forward to being back on my Kubuntu machine at the office where everything works the way I think it should.
Personal preference? Certainly! But no more so then claiming that OS X is inherently more polished than Ubuntu.
You're completely wrong on this one. A design problem is something like "give the console user root access if they click in the top-right corner of the screen". A non-design problem is something like a buffer overflow that wasn't designed into the system, but added inadvertently.
It's tolerable, but I just hate the idea of "designers" trying to force the web to act exactly like print media. I can't stand fixed width pages because I don't want to have to find an acceptable zoom level, and I don't like when a webmonkey assumes they know more about what looks good on my screen than I do.
Yes, long lines are ugly. That's why I don't typically have browser windows maximized. Still, I want the text to flow to my preferences, which will always look better to me than what a fixed layout can manage.
Most of the designers I know prefer, these days, to create fixed width designs because most sites look like crap when the browser is maximized on a monitor with 1900x1280 resolution. The line lengths are far too long.
...in their not-so-humble opinion. Screw 'em. Fixed widths look like crap when I'm standing a few feet away from my monitor with the font sized increased, unless
you think this
looks better than
letting the user
decide how long
theirs lines
should be.
For school, I used IntelliJ 6.x as the IDE to develop in Java. A couple years later I had to upgrade to IntelliJ 7.x. The program became much slower, in part because the new version demanded more RAM than I had on my laptop. The teacher explained that this is because it can do more. Okay, it can do more, but if I'm not using these extra features, why does it have to bog down all the rest?
Counter: if you aren't using at least some of those extra features, then you shouldn't have upgraded.
Yes. In my house, the defining point was our purchase of a Flip video camera. It's a little $150 flash-based unit meant for people like us who want grandma to see movies of the kids with minimal hassle. You shoot your video, plug it into a Mac or PC's USB port, double-click the runnable software that's stored on the camera itself, and watch your movies. If you want to upload them to YouTube, select the desired clips and click the "upload" button - the software handles the rest.
It's a slick little camera and we love it, but the transcoding takes ages on my wife's older iMac. She's the furthest thing from a power user, but she gets impatient waiting for the process to finish so she can call her mom to let her know the movies are online. I have a suspicion that we'll be upgrading her computer soon so that she can use our camera more easily.
I think this will be the next CPU-eating activity. Almost every portable electronic device seems to have a video camera these days, and people are going to want to start actually using them.
The problem with languages with like python/Java/.NET is that it's not in the users interest. Why do users care about making the developers life easier?
Because easier development means more features and more robust software. I'm capable of writing big apps in several flavors of assembler, but the cost is much slower development that keeps customers from getting the features they want on a schedule they're happy with.
They just want fast apps the use as little memory as possible.
No they don't. A tiny subset of geeks with a RAM optimization fetish wants that, but no one else cares as long as the requirements aren't absolutely insane. I have never, ever heard a graphic designer bitch that Photoshop uses too much RAM. Instead, they'll bitch that their machine needs more RAM so that Photoshop runs better. In their opinion, the fact that it sucks down bytes like a crackhead locked into an evidence room is evidence that it's doing difficult stuff and that they need a good computer to support it.
There are big python apps that don't suck, and that's because the bottle necks have been moved into C.
I've never written a Python program that didn't address all of the bottlenecks in C, which is the language my Python interpreter is written in. It's all about the algorithms. I'll take an O(1) function in "slow" Python over an O(n!) function in hand-rolled multi-threaded assembler any day of the week.
It really annoys me when programmers complain they have done all they can for the app in the language it's in, THEN DAMN WELL LEARN A LOWER LANGUAGE AND MOVE PROBLEM PARTS!
That might be true for toy desktop applications. On the server side, it's almost always false. It's far more cost effective to throw more hardware at the problem (assuming that the program's written well with good algorithms and simply can't be made faster in its current language) then paying staff to learn and maintain a multi-language implementation.
.NET programmers I find are the worse for this, but from what I read there is the same problem with Java programmers coming out of some universities.
Algorithms. Algorithms. Algorithms. I don't like Java and have zero interest in.NET, but I guarantee that you can write tight, efficient code in either of them. I also guarantee that the same universities could crank out crappy assembler programmers if they decided to shift focus.
If we hadn't let the programmers run amok and force them to write efficient code, what we had back then was 'good enough' for most people.
OK, so give me an example of inefficient code and your explanation for why it's inefficient. As a professional programmer, I get tired of bearing the blame for "bloat". Sure, I write in high-level languages instead of assembler these days. I write database-backed web applications, and while I'm capable of implementing them on bare hardware, my boss would much rather just buy a faster server and let me code in Python than wait 4 years while I hammer out a prototype in assembler. The end result is that I can add new features in a timeframe that our customers will tolerate.
If we were stuck on the hardware of 1999, we'd be writing software the same way we did in 1999. Having been there, it sucked compared to what we can do today and I would never voluntarily go back. Do carpenters build "bloated" homes because they use general-purpose fasteners to bind pieces of standardized wood together, or are you willing to tolerate a little deviation from the ideal because you don't want to wait while they grow a tree in the exact shape of your blueprints? Well, I want to do the same for software. If you consider that "bloat", then you don't understand modern software development and what it delivers to end users.
So putting a bunch of charging stations in Chicago (to kickstart the market) makes sense, but anybody who drives to Northern Wisconsin better see the electric as costing a lot less than a gasoline car (or they won't participate).
I think that the short-term idea is for it to function as an intra-city vehicle. I'd happily replace my fuel-thirsty (but fun to drive!) V6 with an electric for driving to work, the store, and picking up the kids from school if this infrastructure was available locally, especially considering the tax breaks that are being offered to get the ball rolling.
happily, there is a very good solution. ultracapacitors, sometimes known as ultracaps.
Step one: get the infrastructure built out with proven, well-tested technology - batteries.
Step two: when better technologies come readily available, replace the guts of the electric modules that you're renting out on a schedule that's convenient to your company. One time, customers get a battery. Next time, they get a capacitor. They'll go back and forth as one is phased out in favor of the other.
Then there is the weird liability issue of possession of stolen property, if somebodys car gets stolen, and after passing thru the hands of 20 innocent people, you get the stolen battery. Now, how long is the jail term for receiving stolen property?
All of your points were goofy, but this was the goofiest. You'd only get "caught" with the stolen property when in the act of returning it to its rightful owners: the filling station owners (that had previously rented it to you after receiving it from the prior renters). Are you in some kind of a contest to invent the most ridiculous straw men?
Which is nothing compared to the 2,000,000 miles some diesel powered taxis have
It'll take a lot longer to rack up that many miles than hybrids have been around, so that's still an open question. I don't particularly like hybrids, but you can't really rule on their longevity yet.
his proposal doesn't seem to lend itself to incremental change
How so? You could hypothetically add a battery replacement center to existing gas stations, much like many have added car washes to bring in new customers.
You have to have leased batteries for this to make sense. But then leasing costs for the battery would end up being more than Gas and remind people how uneconomical BEVs really are.
That's the plan: to lease the batteries. They contend that they can sell you power cheaper per mile driven than you can buy gasoline, and they're probably right. Among other things, consider that they can charge the batteries at night when electric demand (and costs) are lower, and potentially sell back excess during peak times. The charging plant could very likely be a profit center even if they never rented a single battery to end users.
This sounds like a great way to use the hell out of my batteries, and then swap them for a brand new set.
Since you're only renting the batteries short-term in this plan, there's no financial reason for you to abuse them and then swap them out.
The next item is battery theft.
Who would a thief sell them to? The vendor who owns them? I can't imagine the electric company will pay top dollar to buy back its own property, as opposed to just siccing the cops on the thief dumb enough to try.
Who picks up the tab for a dead battery? The owner or the 'fuel' vendor?
In Agassi's plan, the "vendor" owns the batteries. Whenever you "fill up" your car by swapping them out, you're basically renting the batteries for the duration.
Shai's plan for electric cars was featured in Wired last year. The idea only sounds crazy until you learn more about it, and then starts to take on the air of inevitability. It makes so much sense and is so practical (and profitable!) that someone is bound to do it. Israel and San Francisco signed on to the plan, anyway.
They called 'Recording Industry vs. The People' an 'anti-recording industry web site' and stated that NYCL 'is currently subject to a pending sanctions motion for his conduct in representing a defendant' (without disclosing that plaintiffs' lawyers were 'subject to a pending motion for Rule 11 sanctions for their conduct in representing plaintiffs' in that very case).
So, is Ray "subject to a pending sanctions motion", and if so, what does that mean anyway? NYCL, as much as I respect you and wholeheartedly support and appreciate what you're doing, I'm not a fan of the "they did it too!" defense.
Slashdot Mirror
As far as I'm concerned, there is absolutely no sane reason to use a system like Java with the overhead of a VM when you already know what architecture the binaries will be running on when you build them.
LLVM is going to blow your mind, then.
As for being as slick as OS X, well, spoken like somebody who obviously doesn't own a Mac.
I'm typing this on my home Mac. It's nice and all, but I look forward to being back on my Kubuntu machine at the office where everything works the way I think it should.
Personal preference? Certainly! But no more so then claiming that OS X is inherently more polished than Ubuntu.
Every vulnerability is a "design problem".
You're completely wrong on this one. A design problem is something like "give the console user root access if they click in the top-right corner of the screen". A non-design problem is something like a buffer overflow that wasn't designed into the system, but added inadvertently.
It's tolerable, but I just hate the idea of "designers" trying to force the web to act exactly like print media. I can't stand fixed width pages because I don't want to have to find an acceptable zoom level, and I don't like when a webmonkey assumes they know more about what looks good on my screen than I do.
Yes, long lines are ugly. That's why I don't typically have browser windows maximized. Still, I want the text to flow to my preferences, which will always look better to me than what a fixed layout can manage.
Most of the designers I know prefer, these days, to create fixed width designs because most sites look like crap when the browser is maximized on a monitor with 1900x1280 resolution. The line lengths are far too long.
...in their not-so-humble opinion. Screw 'em. Fixed widths look like crap when I'm standing a few feet away from my monitor with the font sized increased, unless
you think this
looks better than
letting the user
decide how long
theirs lines
should be.
Hers is an 800MHz single G4. Other than for CPU-intensive stuff, it's still a great machine for all the reasons you mentioned.
Who'd want to piss off a library?
I wish the framers allowed the president and congress critters to be recalled if they pissed off the public.
That was a large part of the motivation behind the second amendment.
For school, I used IntelliJ 6.x as the IDE to develop in Java. A couple years later I had to upgrade to IntelliJ 7.x. The program became much slower, in part because the new version demanded more RAM than I had on my laptop. The teacher explained that this is because it can do more. Okay, it can do more, but if I'm not using these extra features, why does it have to bog down all the rest?
Counter: if you aren't using at least some of those extra features, then you shouldn't have upgraded.
Yes, but have they gone up recently?
Yes. In my house, the defining point was our purchase of a Flip video camera. It's a little $150 flash-based unit meant for people like us who want grandma to see movies of the kids with minimal hassle. You shoot your video, plug it into a Mac or PC's USB port, double-click the runnable software that's stored on the camera itself, and watch your movies. If you want to upload them to YouTube, select the desired clips and click the "upload" button - the software handles the rest.
It's a slick little camera and we love it, but the transcoding takes ages on my wife's older iMac. She's the furthest thing from a power user, but she gets impatient waiting for the process to finish so she can call her mom to let her know the movies are online. I have a suspicion that we'll be upgrading her computer soon so that she can use our camera more easily.
I think this will be the next CPU-eating activity. Almost every portable electronic device seems to have a video camera these days, and people are going to want to start actually using them.
The problem with languages with like python/Java/.NET is that it's not in the users interest. Why do users care about making the developers life easier?
Because easier development means more features and more robust software. I'm capable of writing big apps in several flavors of assembler, but the cost is much slower development that keeps customers from getting the features they want on a schedule they're happy with.
They just want fast apps the use as little memory as possible.
No they don't. A tiny subset of geeks with a RAM optimization fetish wants that, but no one else cares as long as the requirements aren't absolutely insane. I have never, ever heard a graphic designer bitch that Photoshop uses too much RAM. Instead, they'll bitch that their machine needs more RAM so that Photoshop runs better. In their opinion, the fact that it sucks down bytes like a crackhead locked into an evidence room is evidence that it's doing difficult stuff and that they need a good computer to support it.
There are big python apps that don't suck, and that's because the bottle necks have been moved into C.
I've never written a Python program that didn't address all of the bottlenecks in C, which is the language my Python interpreter is written in. It's all about the algorithms. I'll take an O(1) function in "slow" Python over an O(n!) function in hand-rolled multi-threaded assembler any day of the week.
It really annoys me when programmers complain they have done all they can for the app in the language it's in, THEN DAMN WELL LEARN A LOWER LANGUAGE AND MOVE PROBLEM PARTS!
That might be true for toy desktop applications. On the server side, it's almost always false. It's far more cost effective to throw more hardware at the problem (assuming that the program's written well with good algorithms and simply can't be made faster in its current language) then paying staff to learn and maintain a multi-language implementation.
.NET programmers I find are the worse for this, but from what I read there is the same problem with Java programmers coming out of some universities.
Algorithms. Algorithms. Algorithms. I don't like Java and have zero interest in .NET, but I guarantee that you can write tight, efficient code in either of them. I also guarantee that the same universities could crank out crappy assembler programmers if they decided to shift focus.
If we hadn't let the programmers run amok and force them to write efficient code, what we had back then was 'good enough' for most people.
OK, so give me an example of inefficient code and your explanation for why it's inefficient. As a professional programmer, I get tired of bearing the blame for "bloat". Sure, I write in high-level languages instead of assembler these days. I write database-backed web applications, and while I'm capable of implementing them on bare hardware, my boss would much rather just buy a faster server and let me code in Python than wait 4 years while I hammer out a prototype in assembler. The end result is that I can add new features in a timeframe that our customers will tolerate.
If we were stuck on the hardware of 1999, we'd be writing software the same way we did in 1999. Having been there, it sucked compared to what we can do today and I would never voluntarily go back. Do carpenters build "bloated" homes because they use general-purpose fasteners to bind pieces of standardized wood together, or are you willing to tolerate a little deviation from the ideal because you don't want to wait while they grow a tree in the exact shape of your blueprints? Well, I want to do the same for software. If you consider that "bloat", then you don't understand modern software development and what it delivers to end users.
So putting a bunch of charging stations in Chicago (to kickstart the market) makes sense, but anybody who drives to Northern Wisconsin better see the electric as costing a lot less than a gasoline car (or they won't participate).
I think that the short-term idea is for it to function as an intra-city vehicle. I'd happily replace my fuel-thirsty (but fun to drive!) V6 with an electric for driving to work, the store, and picking up the kids from school if this infrastructure was available locally, especially considering the tax breaks that are being offered to get the ball rolling.
happily, there is a very good solution. ultracapacitors, sometimes known as ultracaps.
Step one: get the infrastructure built out with proven, well-tested technology - batteries.
Step two: when better technologies come readily available, replace the guts of the electric modules that you're renting out on a schedule that's convenient to your company. One time, customers get a battery. Next time, they get a capacitor. They'll go back and forth as one is phased out in favor of the other.
Then there is the weird liability issue of possession of stolen property, if somebodys car gets stolen, and after passing thru the hands of 20 innocent people, you get the stolen battery. Now, how long is the jail term for receiving stolen property?
All of your points were goofy, but this was the goofiest. You'd only get "caught" with the stolen property when in the act of returning it to its rightful owners: the filling station owners (that had previously rented it to you after receiving it from the prior renters). Are you in some kind of a contest to invent the most ridiculous straw men?
Which is nothing compared to the 2,000,000 miles some diesel powered taxis have
It'll take a lot longer to rack up that many miles than hybrids have been around, so that's still an open question. I don't particularly like hybrids, but you can't really rule on their longevity yet.
his proposal doesn't seem to lend itself to incremental change
How so? You could hypothetically add a battery replacement center to existing gas stations, much like many have added car washes to bring in new customers.
You are again neglecting the economics of battery life.
Considering that people are investing real money in it, even in today's economy, I'd say you're the one who's not doing the math.
Take for starters that they're buying the batteries wholesale and can get good deals on reconditioning or repairing units.
You have to have leased batteries for this to make sense. But then leasing costs for the battery would end up being more than Gas and remind people how uneconomical BEVs really are.
That's the plan: to lease the batteries. They contend that they can sell you power cheaper per mile driven than you can buy gasoline, and they're probably right. Among other things, consider that they can charge the batteries at night when electric demand (and costs) are lower, and potentially sell back excess during peak times. The charging plant could very likely be a profit center even if they never rented a single battery to end users.
This sounds like a great way to use the hell out of my batteries, and then swap them for a brand new set.
Since you're only renting the batteries short-term in this plan, there's no financial reason for you to abuse them and then swap them out.
The next item is battery theft.
Who would a thief sell them to? The vendor who owns them? I can't imagine the electric company will pay top dollar to buy back its own property, as opposed to just siccing the cops on the thief dumb enough to try.
Who picks up the tab for a dead battery? The owner or the 'fuel' vendor?
In Agassi's plan, the "vendor" owns the batteries. Whenever you "fill up" your car by swapping them out, you're basically renting the batteries for the duration.
Shai's plan for electric cars was featured in Wired last year. The idea only sounds crazy until you learn more about it, and then starts to take on the air of inevitability. It makes so much sense and is so practical (and profitable!) that someone is bound to do it. Israel and San Francisco signed on to the plan, anyway.
Ah, OK. Thanks to both of you for the explanations.
But you just got it burned in! You don't want the new cable jitter and muddiness, do you?
They called 'Recording Industry vs. The People' an 'anti-recording industry web site' and stated that NYCL 'is currently subject to a pending sanctions motion for his conduct in representing a defendant' (without disclosing that plaintiffs' lawyers were 'subject to a pending motion for Rule 11 sanctions for their conduct in representing plaintiffs' in that very case).
So, is Ray "subject to a pending sanctions motion", and if so, what does that mean anyway? NYCL, as much as I respect you and wholeheartedly support and appreciate what you're doing, I'm not a fan of the "they did it too!" defense.