Thanks. You make some excellent point. I admit, we spend a lot of time and effort (meaning, money) maintaining machines, connectivity, backups, and redundancy (RAID for data redundancy, in addition to backups, UPS and a generator for power redundancy, and separate ISPs for connection redundancy). It's a huge expense for a tiny company.
I'm just very nervous about entrusting the company meat and potatoes to an external business. If our stuff goes down because I screwed up - and it has happened - I can try to fix it immediately. If our power or internet connectivity goes down, I can work with the corresponding vendor to get it restored. If something goes wrong with my Cloud Computing setup, I am at the complete mercy of their technical staff. Instead of actively working to solve the problem, all I can do is stay on the phone with their tech support and hope they fix it. Naturally, I'd rather be working than waiting.
And of course, I'm at the mercy of the vendor. If they decide to shut down, I have to scramble to find replacement as quickly and painlessly as possible. If they decide to raise prices, I'm looking at an instant drop in operating income or else the expense of moving to another vendor.
I'm not saying the cloud is the wrong way to go. I'm just saying that I am nervous.
Your own servers don't necessarily cost much more. Check the pricing at Amazon http://aws.amazon.com/ec2/ for a 'Large Instance' with "7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform". A reserved instance costs $910 per year plus $0.12 per hour, or $1961 per year. I can assemble a nice rackmount 1U RAID server with better computing resources than that for the same price. Multiply that by a few servers and a few years, and your cost savings over your own hosting / racks / UPs isn't going to be that high. And of course, nothing stops Amazon from raising the prices.
Also, EC2 gives the user no recourse if the system goes down for any reason, or if your data is lost. http://aws.amazon.com/agreement/ You get a 10% discount if the system uptime is less than 99.95%, but that's the extent of your rights. If you screw up, it's your fault. If Amazon screws up, it's their fault but your problem.
Now, the nice thing about Cloud Computing is scaling. When your magic startup starts generating massive throughput, you can just add resources to your EC2 allotment as needed. But for small deployments that don't anticipate sudden rapid growth, I don't get the appeal.
Actually, a friend of mine who immigrated to the US from Denmark as an adult has a very different belief. Her children are given far more after school work than she was as a child, and the homework kills their enthusiasm for learning. She transferred her son from a school which gave him three hours of homework per night at age ten to one that gives him less than one hour of homework per night. His academic performance has increased dramatically. If her six year old daughter starts to perform poorly in the public school, she plans to transfer her to the same private school.
Read the article. Species with an easy time digesting their food have more resources for thinking. Cows get plenty of food, but their extra stomach and time spent chewing cud indicate that they expend tons of their body's space and resources digesting food.
I think archaeology has established that farming is only about 10,000 years old. Before that, humans were hunter-gatherers and most vegetables, fruits, nuts, and other non-meats we ate were just picked and eaten.
I suspect he's speaking almost entirely of meat roasting on sticks over a fire. If hunted or scavenged meat was the vast majority of the primitive human diet, then cooking meat on sticks over a fire might be enough to cause the evolutionary changes required.
Now when my wife complains, "Not another barbecue!" I can just claim it's for research purposes.
The badly implemented regulations didn't mess up the industry, they just failed to prevent the mess. The government didn't fuck Wall Street, it just let Wall Street fuck itself.
That's okay, if the libertarians had their way all roads would be privately owned, and the tolls we would have to pay to leave our own property would put us all into debt slavery. My owner can bitch about proprietary protocols on his car while I'm out in the fields picking cotton. Yay for unfettered capitalism!
Yes this problem is partly caused by government regulation. What's the alternative, more pollutants in the air? I don't really care about global warming, but I have a strong affection for breathing. Ever drive behind a classic car for a long period of time? The odor will make you sick, and after a while you really do feel yourself laboring harder just to breathe. I realize pollution controls and emissions tests are irritating an expensive, but it's a burden I'm quite willing to endure and also willing to vote as policy for all car owners.
In the late 1990s and early 2000s the Japanese automakers had an unofficial policy of not producing sports cars with more than 300 horsepower. The Subaru model you're describing, probably the WRX STi, was probably from that period. Since then, the gloves have come off.
Except that unlike U.S. private insurers, the government won't deny you insurance because of pre-existing conditions or deny payment because you gave inaccurate information on your application form. No caps on lifetime expenditure, no loopholes to drop you if they think you're costing them too much.
You missed my favorite: unlike US private insurers, if you get too sick to work and lose your income, and then can no longer afford your insurance premiums precisely when you need them the most, you don't lose your coverage.
Are the assertions about the Powell engine pretty well documented? Because every few months Popular Science features some amazing breakthrough in some scientific field that later turns out to be a bunch of nonsense.
For example, for a few years I followed with interest the press releases from the Coates Engine company in New Jersey. They claimed to have developed a spherical valve replacement for typical internal combustion engine valves that allowed for far higher compression and far less engine power losses from friction. The head of the company was later arrested for mail fraud. http://www.nytimes.com/1994/07/23/business/engine-inventor-accused-of-fraud.html?sec=&spon=... so are you sure Powell was the real deal?
This is a student project at Southampton university using a technology that hasn't been in widespread use in well over 50 years. I realize steam turbines are in wide use in ships and power plants, but I assume the engineering challenges are significantly different when you're trying to build a fast steam-driven automobile. It seems like a nice achievement to me.
Now if BMW or Honda made a steam car run on the Bonneville Salt Flats and only got 140 mph, then it would be embarrassing.
1. Steam cars did not emit dirty smoke. Unlike steam trains, steam ships, and very early steam cars, the later steam cars only used liquid fuels. It burns fuel like a propane stove, and burns very clean. Internal combustion engines burned their fuel far less efficiently until the last few decades, because the burn has to occur inside the cylinder within a few milliseconds of time. The steam engine combustion is like a torch or stove burner, it burns every bit of fuel for heat.
2. In terms of engine size, steam engines in steam cars just weren't that big. The boiler in a Stanley Steamer was smaller than a mini-fridge, and the engine was only 2 cylinders. Because the steam is created outside the engine cylinder, it has nearly full engine torque right from launch. Steam cars also did not use transmissions, which saved on complexity and weight. Remember too, the internal combustion engines of the steam car era produced ridiculously low power output per unit of engine displacement by modern standards. I don't have comparison figures, but I assume that at the time steam engines were equal or smaller for an equivalent power output.
3. The original steam cars just released the steam from each cylinder motion as exhaust gas, and went through water quickly. From the page I linked, the original Stanley Steamers worked the same way and required about 1 gallon of water per mile in addition to the kerosene they burned to heat the steam. But later Stanley Steamers and other steam cars used condensers to recapture most of the steam after each cylinder motion, and used 1 gallon of water per 10 miles, or less.
4. From the page I linked, the boiler was wrapped in piano wire and designed with exhaust valves so that there would be no catastrophic boiler explosions. None are documented.
Now obviously, a century old Stanley Steamer can't match a modern car. It offered 40 horsepower, required one fuel tank for kerosene and one for water, and gets lower fuel economy. But imagine if the technology was updated with 100 years of technical know-how by more than a bright but small and group of students at Southampton University with limited funding. I don't know if it could be made as good as modern cars, but I bet the gap would narrow tremendously.
A Pinto is relatively small and light, just about 2400 pounds, with plenty of room under the hood, and rear wheel drive. Its styling is the polar opposite of the Enzo's "sex on wheels", but even ignoring electric conversions many tuners would swap the stock engine with a big V8 and deliver tremendous straight line acceleration.
I agree that the skid-pad 1G mark is reserved for particularly sporty vehicles, whether you're discussing a Ferrari, BMW M-series model, Chevrolet Corvette, or Dodge Viper.
But I think you're singling out American sedans for poor handling unfairly. A Toyota Camry handles like a boat, too, and Toyota doesn't invest the money in a better suspension because 400,000 Americans each year clearly don't mind its wallowy driving characteristics very much. Volkswagens sold in America tend to drive better than equivalent domestic or Asian vehicles, but you pay at least a $3,000 premium for the improvement and very clearly most of us don't care enough or can't afford to spend the extra money.
As others have said, it's probably just a lack of investment in steam technology. The instant-start convenience of the internal combustion engine quickly drove the entire steam car industry out of business in the early 20th century. I'm sure if steam cars remained in general use throughout the century, the record would be far higher.
Of course. That's what insurance is for: the big, catastrophic stuff.
Except that many people with the big problems either can't afford insurance, can't get insurance due to pre-existing conditions, or hit their lifetime maximum benefits cap and get dropped.
I had a friend who developed stomach cancer and was unable to continue working. He lost his job and his insurance coverage and died a few months later. One of my cousins developed complications early in her pregnancy that put her on bed rest for the remainder of the pregnancy. She lost her job and her insurance coverage too. In both cases, they ended up covered by Medicaid - the government - because commercial insurance failed them. Another cousin develops kidney stones frequently and has accrued a lifetime's worth of medical debt getting care for it. He can't get insurance that will cover his kidney stones because they're a pre-existing condition, so he has to pay out of pocket for everything - like $12,000 for one day in the hospital.
I'm sorry for your father's suffering, and your loss.
No, it's not the same problem. Congenital birth defects, accidents, car accidents, Breast Cancer, Colon Cancer, Leukemia, Prostate Cancer, Lou Gehrig's Disease, Alzheimers, Asthma, Muscular Dystrophy, Post Traumatic Stress Disorder, Meningitis, physical assaults, Hepatitis, Influenza, Pneumonia, etc... etc...
There are millions of people with billions of dollars in health care expenses that didn't do anything wrong, and many of them are too young, too old, or too sick to work. Many others are able to work, but they can't get private health insurance because of their pre-existing conditions. There are legitimate reasons to criticize the current health plans under consideration, but you're a fool if you think lifestyle, rather than luck, is "insurance" against most expensive ailments.
I understand your point, but Bell could afford to sink mega-bucks into its research because it was reaping the financial rewards of a complete monopoly. Look at all of the phone and phone-related innovations since Bell was broken - now instead of one company using a portion of immense profits for research, you have dozens of competing companies spending resources on research to stay competitive.
Competition forces investment in research. It's as true when you're competing with business competition as it is when the US was competing against the USSR in the Cold War.
The failing public schools are mostly plagued by kids that don't give a damn and parents that don't give a damn, and they ruin things for everyone else. Private schools do far better because they can very easily eject problematic kids - and most parents that don't care about school won't even bother to send their kids to a private school anyway.
There are plenty of things the US government does more poorly than private industry that are clearly the government's own fault. This isn't one of them, this is a case where the biggest problem facing the public schools does not exist for the private schools because the private schools are not legally required to accept all students in the area. And if we don't try to educate the kids that cause problems, we're adding to the population of people who turn to welfare or crime because they're not educated enough to qualify for a real job. (e.g. 30% of the people in US prisons are illiterate.) I don't know what the solution is, but please pick some other government failure to harpoon.
I've read that, aside from startup times, the JVM is extremely fast these days. But I thought most well-written Java (and by extension, Scala) applications are still 2-10 times slower than equivalent C.
Hey, I'd love to program for fun. But I have to put food on the table. The honeymoon I had with Java is long over, but since I'm making twice as much as I did as a C developer, I'm going to stay with it.
If I could find a company local that would pay me as much, or nearly as much, to work on Scala or Haskell, I would jump ship in a hurry. Until then, I'm not going anywhere.
Your experience with Java is hugely different than mine, then. In no particular order, these features of Java irritate me:
- Embedding a large String in a source file. I shouldn't have to use a named String in an XML file every time I want a String more than 60 characters long. Scala (for example) allows triple-quoted Strings, starting and ending with """, so I can do
"""select user.first_name || user.last_name as "full_name"
from user where id = 2983573;"""
And that will compile just fine. Now obviously, if I have huge SQL queries or other fragments, using a separate properties or XML file makes sense.
-Information passing. Our code is littered with Java classes like this:
class TransactionData { private Date date; private Long transactionId; public Date getDate() { return this.date } public Long getTransactionId () { return transactionId; } public void setDate(Date date) { this.date = date; } public void setTransactionId(Long transactionId) { this.transactionId = transactionId; } }
In some cases, especially with lots of different data in one place, those Java objects make sense. But in many cases, it's a useless data holder class created for the sole purpose of passing information back and forth between two different Java classes. Now, you could use an Object array to do the same thing - but then you have to cast everything to the appropriate type when you pull it out of the array. Scala Tuples solve this problem, and would eliminate literally thousands of lines of code from our codebase. Scala also has a shortcut for class definitions that automatically generates getters and setters for you, and lets you easily override the defaults if you need non-standard getter or setter code.
-Null checks. Our Java code is just full of code like this: SomeType x; SomeOtherType y; SomeThirdType z; x = doSomeCalculation(); if (x != null) { y = x.getY(); if (y != null) { z = y.getZ(); }/* else log some error about not finding y */ }/* else log some error about not finding x */ if (z != null) { doSomethingWithZ(z); }/* else log an error about not finding z */
Scala has Options which shortcut the whole procedure and let you write the exact same logic in a much simpler way.
-Inheritance. We have a number of interfaces and abstract parent classes that are used left and right in the Java code. Every time a method changes in one of the interfaces, we have to re-write the class hierarchy or insert an intermediate parent class. The "Java Design Patterns" solution is to use the Strategy Design Pattern and compose simple implementations of the interfaces with the classes. It works, but it results in lots of code. Enter Scala traits, which are an interface WITH its implementation. Each Scala class can be composed with a trait by adding the trait name to the class declaration. *Poof*, you get your Strategy Design Pattern in far fewer lines of code. (Scala traits give Java multiple inheritance without the multiple inheritance headaches of C++.)
-Cases. Java has a nice switch construct... for numbers. Most of our comparisons in web code is with Strings, so instead of nice, easy to read switch (variable) {... } in our code, we have tons of if (variable.equals("...") else if (variable.equals("....")....)
Scala gives you a case statement that's tremendously flexible, and can handle Strings, Exceptions, Lists, it doesn't matter. You can't believe how much this simplifies your code until you see it in action.
-Exceptions. In Java, you have to explicitly catch all of your checked exceptions or declare them to be thrown. In Scala, all exceptions are unchecked. You only put the "try / catch" blocks where you want them to exist, and you don't have to do "throws this, that, theotherthing, andsoforth, andsoon" on your method signatures.
-XML. Java uses XML like crazy, and the APIs for reading and writing it are
If C++ was well suited to web application development, it would be a very common choice for websites. Instead, Google, Ebay, and Yahoo need the performance it offers for their high volume websites. Most smaller volume websites and many of the competing high volume websites are willing to skip the performance of C++ for the faster development time and easier maintenance from using other languages.
For server side applications, the ability to move applications from Windows to Linux to BSD is nice. Scala gives you that while C++ requires a recompile for each platform with a mess of #ifdef and Make options.
Scala has tuples, traits (similar to Ruby mixins, and a very nice solution to Java's lack of multiple inheritance and C++'s multiple inheritance headaches), cases classes that are far more powerful than the C++ switch or other similar C++ constructs (or at least, all of the ones I've encountered), functional language constructs (which in many cases use compile-time tail call optimization to keep run time performance acceptable), and the ability to easily import and use existing Java APIs and libraries and run on existing Java servlet containers. Check out the Scala web development platform lift ( http://liftweb.net/ ) - the example website has a staggering number of features for such a tiny codebase.
I think we'll see some mutual benefit in terms of technology. But in terms of public image, I think most of the general public will still not transfer any of their views of Google to Linux at large.
Slashdot Mirror
Thanks. You make some excellent point. I admit, we spend a lot of time and effort (meaning, money) maintaining machines, connectivity, backups, and redundancy (RAID for data redundancy, in addition to backups, UPS and a generator for power redundancy, and separate ISPs for connection redundancy). It's a huge expense for a tiny company.
I'm just very nervous about entrusting the company meat and potatoes to an external business. If our stuff goes down because I screwed up - and it has happened - I can try to fix it immediately. If our power or internet connectivity goes down, I can work with the corresponding vendor to get it restored. If something goes wrong with my Cloud Computing setup, I am at the complete mercy of their technical staff. Instead of actively working to solve the problem, all I can do is stay on the phone with their tech support and hope they fix it. Naturally, I'd rather be working than waiting.
And of course, I'm at the mercy of the vendor. If they decide to shut down, I have to scramble to find replacement as quickly and painlessly as possible. If they decide to raise prices, I'm looking at an instant drop in operating income or else the expense of moving to another vendor.
I'm not saying the cloud is the wrong way to go. I'm just saying that I am nervous.
Your own servers don't necessarily cost much more. Check the pricing at Amazon http://aws.amazon.com/ec2/ for a 'Large Instance' with "7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform". A reserved instance costs $910 per year plus $0.12 per hour, or $1961 per year. I can assemble a nice rackmount 1U RAID server with better computing resources than that for the same price. Multiply that by a few servers and a few years, and your cost savings over your own hosting / racks / UPs isn't going to be that high. And of course, nothing stops Amazon from raising the prices.
Also, EC2 gives the user no recourse if the system goes down for any reason, or if your data is lost. http://aws.amazon.com/agreement/ You get a 10% discount if the system uptime is less than 99.95%, but that's the extent of your rights. If you screw up, it's your fault. If Amazon screws up, it's their fault but your problem.
Now, the nice thing about Cloud Computing is scaling. When your magic startup starts generating massive throughput, you can just add resources to your EC2 allotment as needed. But for small deployments that don't anticipate sudden rapid growth, I don't get the appeal.
Actually, a friend of mine who immigrated to the US from Denmark as an adult has a very different belief. Her children are given far more after school work than she was as a child, and the homework kills their enthusiasm for learning. She transferred her son from a school which gave him three hours of homework per night at age ten to one that gives him less than one hour of homework per night. His academic performance has increased dramatically. If her six year old daughter starts to perform poorly in the public school, she plans to transfer her to the same private school.
Here's a pretty good and reasonably balanced discussion of the topic: http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2006/10/08/ING0FLHNM21.DTL
Read the article. Species with an easy time digesting their food have more resources for thinking. Cows get plenty of food, but their extra stomach and time spent chewing cud indicate that they expend tons of their body's space and resources digesting food.
I think archaeology has established that farming is only about 10,000 years old. Before that, humans were hunter-gatherers and most vegetables, fruits, nuts, and other non-meats we ate were just picked and eaten.
I suspect he's speaking almost entirely of meat roasting on sticks over a fire. If hunted or scavenged meat was the vast majority of the primitive human diet, then cooking meat on sticks over a fire might be enough to cause the evolutionary changes required.
Now when my wife complains, "Not another barbecue!" I can just claim it's for research purposes.
The badly implemented regulations didn't mess up the industry, they just failed to prevent the mess. The government didn't fuck Wall Street, it just let Wall Street fuck itself.
That's okay, if the libertarians had their way all roads would be privately owned, and the tolls we would have to pay to leave our own property would put us all into debt slavery. My owner can bitch about proprietary protocols on his car while I'm out in the fields picking cotton. Yay for unfettered capitalism!
Yes this problem is partly caused by government regulation. What's the alternative, more pollutants in the air? I don't really care about global warming, but I have a strong affection for breathing. Ever drive behind a classic car for a long period of time? The odor will make you sick, and after a while you really do feel yourself laboring harder just to breathe. I realize pollution controls and emissions tests are irritating an expensive, but it's a burden I'm quite willing to endure and also willing to vote as policy for all car owners.
In the late 1990s and early 2000s the Japanese automakers had an unofficial policy of not producing sports cars with more than 300 horsepower. The Subaru model you're describing, probably the WRX STi, was probably from that period. Since then, the gloves have come off.
Except that unlike U.S. private insurers, the government won't deny you insurance because of pre-existing conditions or deny payment because you gave inaccurate information on your application form. No caps on lifetime expenditure, no loopholes to drop you if they think you're costing them too much.
You missed my favorite: unlike US private insurers, if you get too sick to work and lose your income, and then can no longer afford your insurance premiums precisely when you need them the most, you don't lose your coverage.
Are the assertions about the Powell engine pretty well documented? Because every few months Popular Science features some amazing breakthrough in some scientific field that later turns out to be a bunch of nonsense.
... so are you sure Powell was the real deal?
For example, for a few years I followed with interest the press releases from the Coates Engine company in New Jersey. They claimed to have developed a spherical valve replacement for typical internal combustion engine valves that allowed for far higher compression and far less engine power losses from friction. The head of the company was later arrested for mail fraud. http://www.nytimes.com/1994/07/23/business/engine-inventor-accused-of-fraud.html?sec=&spon=
This is a student project at Southampton university using a technology that hasn't been in widespread use in well over 50 years. I realize steam turbines are in wide use in ships and power plants, but I assume the engineering challenges are significantly different when you're trying to build a fast steam-driven automobile. It seems like a nice achievement to me.
Now if BMW or Honda made a steam car run on the Bonneville Salt Flats and only got 140 mph, then it would be embarrassing.
You're thinking of the very first steam cars, where solid fuels were used and someone on the vehicle had to stoke the fire by hand. The last steam cars were dramatically superior to that. Check http://www.stanleymotorcarriage.com/GeneralTechnical/GeneralTechnical.htm
1. Steam cars did not emit dirty smoke. Unlike steam trains, steam ships, and very early steam cars, the later steam cars only used liquid fuels. It burns fuel like a propane stove, and burns very clean. Internal combustion engines burned their fuel far less efficiently until the last few decades, because the burn has to occur inside the cylinder within a few milliseconds of time. The steam engine combustion is like a torch or stove burner, it burns every bit of fuel for heat.
2. In terms of engine size, steam engines in steam cars just weren't that big. The boiler in a Stanley Steamer was smaller than a mini-fridge, and the engine was only 2 cylinders. Because the steam is created outside the engine cylinder, it has nearly full engine torque right from launch. Steam cars also did not use transmissions, which saved on complexity and weight. Remember too, the internal combustion engines of the steam car era produced ridiculously low power output per unit of engine displacement by modern standards. I don't have comparison figures, but I assume that at the time steam engines were equal or smaller for an equivalent power output.
3. The original steam cars just released the steam from each cylinder motion as exhaust gas, and went through water quickly. From the page I linked, the original Stanley Steamers worked the same way and required about 1 gallon of water per mile in addition to the kerosene they burned to heat the steam. But later Stanley Steamers and other steam cars used condensers to recapture most of the steam after each cylinder motion, and used 1 gallon of water per 10 miles, or less.
4. From the page I linked, the boiler was wrapped in piano wire and designed with exhaust valves so that there would be no catastrophic boiler explosions. None are documented.
Now obviously, a century old Stanley Steamer can't match a modern car. It offered 40 horsepower, required one fuel tank for kerosene and one for water, and gets lower fuel economy. But imagine if the technology was updated with 100 years of technical know-how by more than a bright but small and group of students at Southampton University with limited funding. I don't know if it could be made as good as modern cars, but I bet the gap would narrow tremendously.
A Pinto is relatively small and light, just about 2400 pounds, with plenty of room under the hood, and rear wheel drive. Its styling is the polar opposite of the Enzo's "sex on wheels", but even ignoring electric conversions many tuners would swap the stock engine with a big V8 and deliver tremendous straight line acceleration.
I agree that the skid-pad 1G mark is reserved for particularly sporty vehicles, whether you're discussing a Ferrari, BMW M-series model, Chevrolet Corvette, or Dodge Viper.
But I think you're singling out American sedans for poor handling unfairly. A Toyota Camry handles like a boat, too, and Toyota doesn't invest the money in a better suspension because 400,000 Americans each year clearly don't mind its wallowy driving characteristics very much. Volkswagens sold in America tend to drive better than equivalent domestic or Asian vehicles, but you pay at least a $3,000 premium for the improvement and very clearly most of us don't care enough or can't afford to spend the extra money.
As others have said, it's probably just a lack of investment in steam technology. The instant-start convenience of the internal combustion engine quickly drove the entire steam car industry out of business in the early 20th century. I'm sure if steam cars remained in general use throughout the century, the record would be far higher.
Of course. That's what insurance is for: the big, catastrophic stuff.
Except that many people with the big problems either can't afford insurance, can't get insurance due to pre-existing conditions, or hit their lifetime maximum benefits cap and get dropped.
I had a friend who developed stomach cancer and was unable to continue working. He lost his job and his insurance coverage and died a few months later. One of my cousins developed complications early in her pregnancy that put her on bed rest for the remainder of the pregnancy. She lost her job and her insurance coverage too. In both cases, they ended up covered by Medicaid - the government - because commercial insurance failed them. Another cousin develops kidney stones frequently and has accrued a lifetime's worth of medical debt getting care for it. He can't get insurance that will cover his kidney stones because they're a pre-existing condition, so he has to pay out of pocket for everything - like $12,000 for one day in the hospital.
I'm sorry for your father's suffering, and your loss.
No, it's not the same problem. Congenital birth defects, accidents, car accidents, Breast Cancer, Colon Cancer, Leukemia, Prostate Cancer, Lou Gehrig's Disease, Alzheimers, Asthma, Muscular Dystrophy, Post Traumatic Stress Disorder, Meningitis, physical assaults, Hepatitis, Influenza, Pneumonia, etc... etc...
There are millions of people with billions of dollars in health care expenses that didn't do anything wrong, and many of them are too young, too old, or too sick to work. Many others are able to work, but they can't get private health insurance because of their pre-existing conditions. There are legitimate reasons to criticize the current health plans under consideration, but you're a fool if you think lifestyle, rather than luck, is "insurance" against most expensive ailments.
I understand your point, but Bell could afford to sink mega-bucks into its research because it was reaping the financial rewards of a complete monopoly. Look at all of the phone and phone-related innovations since Bell was broken - now instead of one company using a portion of immense profits for research, you have dozens of competing companies spending resources on research to stay competitive.
Competition forces investment in research. It's as true when you're competing with business competition as it is when the US was competing against the USSR in the Cold War.
The failing public schools are mostly plagued by kids that don't give a damn and parents that don't give a damn, and they ruin things for everyone else. Private schools do far better because they can very easily eject problematic kids - and most parents that don't care about school won't even bother to send their kids to a private school anyway.
There are plenty of things the US government does more poorly than private industry that are clearly the government's own fault. This isn't one of them, this is a case where the biggest problem facing the public schools does not exist for the private schools because the private schools are not legally required to accept all students in the area. And if we don't try to educate the kids that cause problems, we're adding to the population of people who turn to welfare or crime because they're not educated enough to qualify for a real job. (e.g. 30% of the people in US prisons are illiterate.) I don't know what the solution is, but please pick some other government failure to harpoon.
I've read that, aside from startup times, the JVM is extremely fast these days. But I thought most well-written Java (and by extension, Scala) applications are still 2-10 times slower than equivalent C.
Hey, I'd love to program for fun. But I have to put food on the table. The honeymoon I had with Java is long over, but since I'm making twice as much as I did as a C developer, I'm going to stay with it.
If I could find a company local that would pay me as much, or nearly as much, to work on Scala or Haskell, I would jump ship in a hurry. Until then, I'm not going anywhere.
Can't you do weak type casts in C++?
Your experience with Java is hugely different than mine, then. In no particular order, these features of Java irritate me:
/* else log some error about not finding y */ } /* else log some error about not finding x */ if (z != null) { doSomethingWithZ(z); } /* else log an error about not finding z */
... } in our code, we have tons of if (variable.equals("...") else if (variable.equals("....") ....)
- Embedding a large String in a source file. I shouldn't have to use a named String in an XML file every time I want a String more than 60 characters long. Scala (for example) allows triple-quoted Strings, starting and ending with """, so I can do
"""select user.first_name || user.last_name as "full_name"
from user where id = 2983573;"""
And that will compile just fine. Now obviously, if I have huge SQL queries or other fragments, using a separate properties or XML file makes sense.
-Information passing. Our code is littered with Java classes like this:
class TransactionData { private Date date; private Long transactionId; public Date getDate() { return this.date } public Long getTransactionId () { return transactionId; } public void setDate(Date date) { this.date = date; } public void setTransactionId(Long transactionId) { this.transactionId = transactionId; } }
In some cases, especially with lots of different data in one place, those Java objects make sense. But in many cases, it's a useless data holder class created for the sole purpose of passing information back and forth between two different Java classes. Now, you could use an Object array to do the same thing - but then you have to cast everything to the appropriate type when you pull it out of the array. Scala Tuples solve this problem, and would eliminate literally thousands of lines of code from our codebase. Scala also has a shortcut for class definitions that automatically generates getters and setters for you, and lets you easily override the defaults if you need non-standard getter or setter code.
-Null checks. Our Java code is just full of code like this:
SomeType x; SomeOtherType y; SomeThirdType z; x = doSomeCalculation(); if (x != null) { y = x.getY(); if (y != null) { z = y.getZ(); }
Scala has Options which shortcut the whole procedure and let you write the exact same logic in a much simpler way.
-Inheritance. We have a number of interfaces and abstract parent classes that are used left and right in the Java code. Every time a method changes in one of the interfaces, we have to re-write the class hierarchy or insert an intermediate parent class. The "Java Design Patterns" solution is to use the Strategy Design Pattern and compose simple implementations of the interfaces with the classes. It works, but it results in lots of code. Enter Scala traits, which are an interface WITH its implementation. Each Scala class can be composed with a trait by adding the trait name to the class declaration. *Poof*, you get your Strategy Design Pattern in far fewer lines of code. (Scala traits give Java multiple inheritance without the multiple inheritance headaches of C++.)
-Cases. Java has a nice switch construct... for numbers. Most of our comparisons in web code is with Strings, so instead of nice, easy to read switch (variable) {
Scala gives you a case statement that's tremendously flexible, and can handle Strings, Exceptions, Lists, it doesn't matter. You can't believe how much this simplifies your code until you see it in action.
-Exceptions. In Java, you have to explicitly catch all of your checked exceptions or declare them to be thrown. In Scala, all exceptions are unchecked. You only put the "try / catch" blocks where you want them to exist, and you don't have to do "throws this, that, theotherthing, andsoforth, andsoon" on your method signatures.
-XML. Java uses XML like crazy, and the APIs for reading and writing it are
If C++ was well suited to web application development, it would be a very common choice for websites. Instead, Google, Ebay, and Yahoo need the performance it offers for their high volume websites. Most smaller volume websites and many of the competing high volume websites are willing to skip the performance of C++ for the faster development time and easier maintenance from using other languages.
For server side applications, the ability to move applications from Windows to Linux to BSD is nice. Scala gives you that while C++ requires a recompile for each platform with a mess of #ifdef and Make options.
Scala has tuples, traits (similar to Ruby mixins, and a very nice solution to Java's lack of multiple inheritance and C++'s multiple inheritance headaches), cases classes that are far more powerful than the C++ switch or other similar C++ constructs (or at least, all of the ones I've encountered), functional language constructs (which in many cases use compile-time tail call optimization to keep run time performance acceptable), and the ability to easily import and use existing Java APIs and libraries and run on existing Java servlet containers. Check out the Scala web development platform lift ( http://liftweb.net/ ) - the example website has a staggering number of features for such a tiny codebase.
I think we'll see some mutual benefit in terms of technology. But in terms of public image, I think most of the general public will still not transfer any of their views of Google to Linux at large.