I get Dish network in Seattle, where the weather is frequently lousy. Rain does NOT affect it. Snow will if it accumulates on the dish, but that's easy to dislodge with a broom. The only real problem is wind -- a south wind gust of 30+ MPH can cause the receiver to lose the signal, and reacquiring it takes a few seconds. Watching a program when that happens every few minutes is no fun at all. We give up when that happens, maybe 3 or 4 times a year.
Cable here (Comcast) is much more expensive, unless you get the stripped-down version (I've heard there is a tier BELOW "basic" cable that only costs something like $25 a month).
We are quite satisfied with Dish, but then we don't watch much TV...the only reason we pay anybody for TV service is to get Dish's optional Russian channels, which are the best of any service I'm aware of.
There's an interesting (if long-winded) book called "The Support Economy" (find it at Amazon or wherever),
which argues that in the current transaction-oriented economy of the western world, the adversarial relationship between corporations and consumers is inevitable, and will get worse.
Boiling their argument down to one sentence, the authors reason that corporations seek to extract maximum profit from every transaction, and this means that the customer's feelings are of no consequence whatever.
If they're right, then:
a) it's going to get worse
b) whoever figures out how to derive value from a real RELATIONSHIP with the customer, and can effectively address each customer's concerns instead of working around them, will win big.
Sometime in the 80's, manufacturers found that the American consumer would pay for cheaper products that don't last as long. There are still some people who would rather pay more for a product that lasts longer, but a company can't build two separate products for the same niche...so the "extended warranty" was created for the latter group, who wanted some assurance of a longer product life.
Unfortunately, the presence of an extended warranty has no effect on the quality of the product itself. It's just a way for a manufacturer or a retailer to use one product to appeal to both audiences.
This is somewhat related to product enhancement...in the 80's and 90's, people saw their computers becoming "obsolete" so fast that the working lifespan of the physical product wasn't an issue.
In the last few years, many people have started realizing that what they have is good enough. But America is in love with cheap consumer electronics, and the manufacturers have adjusted accordingly.
slightly o.t.: I remember an experiment Sears did with screwdrivers -- they carried USA-made ones that they'd been selling for years, at several dollars each. Alongside, they sold similar screwdrivers, made in China, for $1 each. Both carried the famous Sears lifetime replacement guarantee. I'm sure the rate of return on the latter was higher, but not enough to impact profits -- because they're still selling them.
> ignoring the cost of the coder is wrong.
Ignoring the SKILL of the coder is also wrong.
In my professional experience, the compiler/runtime environment is chosen for reasons other than performance: upfront cost, installed base, pro/anti-Microsoft sentiment, many others.
More importantly, performance and scalability problems of the applications have always resulted from a poor choice of methods and algorithms, not by poor raw numeric performance.
Using C to double your performance cannot save you when you should be storing your data in binary instead of XML, or when you store your JPEG images in the database instead of the filesystem.
I'm not saying XML or database BLOBs are the wrong choice for any particular application, instead these are
real-world cases I've observed where performance problems could not have been headed off by choosing a different language.
In fact I've NEVER seen a case where the language caused a performance problem, except in cases of sheer ignorance. Skill is worth more than either the "right" language or more MIPS.
Others are saying that laptops are designed for lower power consumption, which is true. But further, laptops use DC, not AC, so if you're going to use solar power or some other homebrew power generation you won't have to include an inverter (with its attendant expense and power losses) in the setup.
Solar only works in the daytime but you could charge several laptop batteries in parallel and switch them in as needed after sundown. Depending on your laptop, you may not even need to shut down to do so.
And in the worst case you can power a laptop off your car's cigarette lighter. Terrible conversion efficiency, but in a pinch, it works and is easy to do.
I have never had the opportunity to do what you're doing, but have often imagined it -- haven't we all?
Agreed, the K-1000 is incredibly robust. I've fallen on mine while taking pictures skiing, dropped it on the sidewalk, every kind of abuse you can think of short of dunking it in salt water (though it did live on a boat with me for 5 years). It continued to work, dents and all, flawlessly. I finally had to take it in for repair after over 20 years of use, because one of the light-sensor wires came loose. I will never give up this camera.
That said, though, my next camera will be digital. Darkroom or no, you'll spend money developing pictures if you take a lot of them, and you SHOULD take a lot of pictures. And although an all-manual camera is great for learning the fundamentals, you will find that you just can't get some pictures if your camera lacks automatic features. The best camera would make it easy to gain full control WHEN YOU WANT IT, and do a good job of exposing and/or focusing for you when you don't.
I would trust that Diebold vote-counting machine if (a) it was open-source, (b) the software wasn't updated after certification, and (c) it isn't attached to any network (write CD's or something to get the tallies out midstream). The counting task is simple, and very amenable to computerization. The shipping of a verifiable paper trail for purposes of a recount is what the suggested method adds. Actually, I think recounts should be standard procedure: send the tallies from the precincts to satisfy the news hounds, then re-do the entire tally AGAIN the next day and verify that the results are identical.
> revising the "official" records to expunge subjects A tangent: in the 90's I worked in the former USSR in a Christian mission. We published a lot of printed materials, and worked closely with the big local publishers. Once, we had a book printed and bound, and discovered an error just before they were scheduled to go to distributors. The error was serious enough to rectify, but we had little hope until we talked to the printing house. The representative showed how they could slice a page out of each book and replace it with a different one, then said "in Soviet times, we used to do it quite often!" And that's how we solved that problem.
Two more requirements: allow disabled (e.g. blind) people to vote, and verify the results as standard operating procedure. If I can't read, I should be able to still work the device (using voice prompts and a pair of headphones), and verify that the output was as I desired it (using a reader that works on the printed ballot). Then, after the machines have reported in and the results tallied and sent to the media, the next day a sample of precincts (or maybe ALL precincts) should be recounted and compared to the preliminary results. In a properly designed system, there should be NO DIFFERENCE. Any difference means the election was not valid.
I second this. I once had a Mac IIx to which I was able to attach two Radius 21" monitors (a princely luxury, just one of them was considered huge at the time). Why? Because other team members had abandoned their Macs to work on other, faster architectures (and just single 17" monitors). I felt I was more productive with more screen space and less available CPU power. I still miss those two huge heads (and the team environment that allowed me to choose my setup from the available options, instead of being forced into following the crowd).
No, I realize they aren't made any more.
But any hybrid you buy now should do way better than 50MPG.
My 1988 Honda CRX-HF has given me 50+MPG over 15 years and 160K miles, and is still doing well.
Not to put you off buying a new Honda -- they're a great company -- but for overall economy, you may do just as well to find a used HF.
Whatever else they do, I hope they make a way for
me to select a group of icons visually (i.e. with the mouse)
and then operate on them with a series of shell commands,
and use globbing in GUI tools (like selecting multiple files in a file-selection dialog).
As one who drives Seattle's roads every day, I can tell you this is par for the course for our state government.
They can't decide how to solve the problem (because they're too busy siphoning off transportation money to fill someone's pockets), so they look for hair-brained "solutions" to make it look like they're doing their job.
There is no interest in emissions -- first and foremost, the carpool lanes here are designed to reduce congestion by reducing the number of cars on the road.
By selling exemptions, they are reducing the incentive to get a modest increase in tax dollars, at a time when everyone is screaming about the budget deficit. (Mostly it's the politicians screaming, saying "how can we keep spending up when income is going down? How? How?")
By using eBay, they're looking for a way to set the price, but it doesn't really matter. They could sell enough stickers to clog the carpool lane at $1000 a pop, and still make no dent at all in what it costs to build a single offramp (about $300 million dollars in Seattle!)
Language structure is determined by two things: 1. the target machine architecture 2. the range of expression required by the programmer and/or workgroup
Java is "successful" but it really looks a lot like Algol and Pascal, as does C++. The range of expression is greater in the newer languages (object-orientation in Java and C++) but the forte is still that of expressing algorithms in written form to be used on a stored-program digital computer.
WILL WE STILL BE PROGRAMMING? Take one example -- genetic programming. If you had a programming system where the basic algorithm could learn, and all you had to do is set up the learning environment, then you'd be teaching rather than programming. In fact I believe THIS is what most "programmers" will be doing in 100 years. The challenge will be defining the problem domain, the inputs, the desired outputs; the algorithm and the architecture won't change, or won't change much, and the vast majority of people won't fiddle with it.
But if HAL doesn't appear and we aren't all retrained as Dr. Chandra, I believe we'll still be handling a lot of text on flat screens. I don't think we'll be using sound, and I don't think we'll be using pictures. (see below)
So predicting what languages will be like in 100 years is predicated on knowing what computers and peripherals will be like. I think progress will be slow, for the most part -- that is, I don't think it will be all that much different from how it is now.
HOW WILL OUR RANGE OF EXPRESSION CHANGE? If we relied primarily on voice input, languages would be a lot more like spoken natural languages; there would be far less ambiguity than most natural languages (so they'd be more like Russian than like English, for example) but there wouldn't be nearly as much punctuation as there is in Java and C++.
If we rely primarily on thought-transfer, they'll be something else entirely. But I don't think this will come in 100 years.
How is a 24x80 IDE window different from punched cards and printers? Much more efficient but remarkably similar, really. It would not surprise me if we still use a lot of TEXT in the future. Speech is slow -- a program body stored as audio would be hard to scan through quickly. Eyes are faster than ears so the program body will always be stored as either text or pictures.
Pictures - well, pictorial languages assume too much of the work has already been done underneath. "Programming isn't hard because of all the typing; programming is hard because of all the thinking." (Who wrote that in Byte a couple of decades ago?). I don't think we'll be using pictures. When we get to the point that we can use hand-waving to describe to the computer what we want it to do, again we'll be teaching, not programming.
HOW WILL THE ARCHITECTURE CHANGE? If the target architecture isn't Von Neumann, but something else, then we may not be describing "algorithms" as we know them today. Not being up to speed about quantum computing, I can speak to that example...but there are lots of other variations. Analog computers? Decimal instead of Binary digital machines? Hardware-implemented neural networks? Again, I don't see much progress away from binary digital stored-program machine in 40 years, and I think (barring a magical breakthrough) this may continue to be the cheapest, most available hardware for the next 50-100 years.
SO WHAT DO I THINK? I think IDE's and runtime libraries will evolve tremendously, but I don't think basic language design will change much. As long as we continue to use physical devices at all, I think the low-level programming languages will be very similar to present day ones: Based on lines of text with regular grammars and punctuation, describing algorithms. I predict COBOL will be gone, FORTRAN will still be a dinosaur, and Java and C/C++ will also be dinosaurs. But compilers for all 4 wi
Slashdot Mirror
Snow will if it accumulates on the dish, but that's easy to dislodge with a broom.
The only real problem is wind -- a south wind gust of 30+ MPH can cause the receiver to lose the signal,
and reacquiring it takes a few seconds. Watching a program when that happens every few minutes is no fun at all.
We give up when that happens, maybe 3 or 4 times a year.
Cable here (Comcast) is much more expensive, unless you get the stripped-down version
(I've heard there is a tier BELOW "basic" cable that only costs something like $25 a month).
We are quite satisfied with Dish, but then we don't watch much TV...the only reason we pay anybody for TV service is to get Dish's optional Russian channels, which are the best of any service I'm aware of.
If they're right, then:
a) it's going to get worse
b) whoever figures out how to derive value from a real RELATIONSHIP with the customer, and can effectively address each customer's concerns instead of working around them, will win big.
Sometime in the 80's, manufacturers found that the American consumer would pay for cheaper products that don't last as long. There are still some people who would rather pay more for a product that lasts longer, but a company can't build two separate products for the same niche...so the "extended warranty" was created for the latter group, who wanted some assurance of a longer product life.
Unfortunately, the presence of an extended warranty has no effect on the quality of the product itself. It's just a way for a manufacturer or a retailer to use one product to appeal to both audiences.
This is somewhat related to product enhancement...in the 80's and 90's, people saw their computers becoming "obsolete" so fast that the working lifespan of the physical product wasn't an issue. In the last few years, many people have started realizing that what they have is good enough. But America is in love with cheap consumer electronics, and the manufacturers have adjusted accordingly.
slightly o.t.: I remember an experiment Sears did with screwdrivers -- they carried USA-made ones that they'd been selling for years, at several dollars each. Alongside, they sold similar screwdrivers, made in China, for $1 each. Both carried the famous Sears lifetime replacement guarantee. I'm sure the rate of return on the latter was higher, but not enough to impact profits -- because they're still selling them.
Ignoring the SKILL of the coder is also wrong. In my professional experience, the compiler/runtime environment is chosen for reasons other than performance: upfront cost, installed base, pro/anti-Microsoft sentiment, many others.
More importantly, performance and scalability problems of the applications have always resulted from a poor choice of methods and algorithms, not by poor raw numeric performance. Using C to double your performance cannot save you when you should be storing your data in binary instead of XML, or when you store your JPEG images in the database instead of the filesystem.
I'm not saying XML or database BLOBs are the wrong choice for any particular application, instead these are real-world cases I've observed where performance problems could not have been headed off by choosing a different language. In fact I've NEVER seen a case where the language caused a performance problem, except in cases of sheer ignorance. Skill is worth more than either the "right" language or more MIPS.
Others are saying that laptops are designed for lower power consumption, which is true. But further, laptops use DC, not AC, so if you're going to use solar power or some other homebrew power generation you won't have to include an inverter (with its attendant expense and power losses) in the setup.
Solar only works in the daytime but you could charge several laptop batteries in parallel and switch them in as needed after sundown. Depending on your laptop, you may not even need to shut down to do so.
And in the worst case you can power a laptop off your car's cigarette lighter. Terrible conversion efficiency, but in a pinch, it works and is easy to do.
I have never had the opportunity to do what you're doing, but have often imagined it -- haven't we all?
Agreed, the K-1000 is incredibly robust. I've fallen on mine while taking pictures skiing, dropped it on the sidewalk,
every kind of abuse you can think of short of dunking it in salt water (though it did live on a boat with me for 5 years). It continued to work, dents and all, flawlessly.
I finally had to take it in for repair after over 20 years of use, because one of the light-sensor wires came loose. I will never give up this camera.
That said, though, my next camera will be digital. Darkroom or no, you'll spend money developing pictures if you take a lot of them, and you SHOULD take a lot of pictures.
And although an all-manual camera is great for learning the fundamentals, you will find that you just can't get some pictures if your camera lacks automatic features.
The best camera would make it easy to gain full control WHEN YOU WANT IT, and do a good job of exposing and/or focusing for you when you don't.
I would trust that Diebold vote-counting machine
if (a) it was open-source, (b) the software wasn't updated after certification,
and (c) it isn't attached to any network (write CD's or something to get the tallies out midstream).
The counting task is simple, and very amenable to computerization.
The shipping of a verifiable paper trail for purposes of a recount is what the suggested method adds.
Actually, I think recounts should be standard procedure: send the tallies from the precincts to satisfy the news hounds, then re-do the entire tally AGAIN the next day and verify that the results are identical.
> revising the "official" records to expunge subjects
A tangent: in the 90's I worked in the former USSR in a Christian mission.
We published a lot of printed materials, and worked closely with the big local publishers.
Once, we had a book printed and bound, and discovered an error just before they were scheduled to go to distributors.
The error was serious enough to rectify, but we had little hope until we talked to the printing house.
The representative showed how they could slice a page out of each book and replace it with a different one,
then said "in Soviet times, we used to do it quite often!"
And that's how we solved that problem.
Two more requirements: allow disabled (e.g. blind) people to vote,
and verify the results as standard operating procedure.
If I can't read, I should be able to still work the device (using voice prompts and a pair of headphones), and verify that the output was as I desired it (using a reader that works on the printed ballot).
Then, after the machines have reported in and the results tallied and sent to the media,
the next day a sample of precincts (or maybe ALL precincts) should be recounted and compared to the preliminary results.
In a properly designed system, there should be NO DIFFERENCE. Any difference means the election was not valid.
I second this. I once had a Mac IIx to which I was able to
attach two Radius 21" monitors (a princely luxury, just one of them was considered huge at the time).
Why? Because other team members had abandoned their Macs to work on other, faster architectures (and just single 17" monitors).
I felt I was more productive with more screen space and less available CPU power.
I still miss those two huge heads (and the team environment that allowed me to choose my setup from the available options, instead of being forced into following the crowd).
Not to put you off buying a new Honda -- they're a great company -- but for overall economy, you may do just as well to find a used HF.
Whatever else they do, I hope they make a way for me to select a group of icons visually (i.e. with the mouse) and then operate on them with a series of shell commands, and use globbing in GUI tools (like selecting multiple files in a file-selection dialog).
As one who drives Seattle's roads every day, I can tell you this is par for the course for our state government. They can't decide how to solve the problem (because they're too busy siphoning off transportation money to fill someone's pockets), so they look for hair-brained "solutions" to make it look like they're doing their job. There is no interest in emissions -- first and foremost, the carpool lanes here are designed to reduce congestion by reducing the number of cars on the road. By selling exemptions, they are reducing the incentive to get a modest increase in tax dollars, at a time when everyone is screaming about the budget deficit. (Mostly it's the politicians screaming, saying "how can we keep spending up when income is going down? How? How?") By using eBay, they're looking for a way to set the price, but it doesn't really matter. They could sell enough stickers to clog the carpool lane at $1000 a pop, and still make no dent at all in what it costs to build a single offramp (about $300 million dollars in Seattle!)
Language structure is determined by two things:
1. the target machine architecture
2. the range of expression required by the programmer and/or workgroup
Java is "successful" but it really looks a lot like Algol and Pascal,
as does C++. The range of expression is greater in the newer languages
(object-orientation in Java and C++) but the forte is still that of
expressing algorithms in written form to be used on a stored-program
digital computer.
WILL WE STILL BE PROGRAMMING?
Take one example -- genetic programming. If you had a programming system
where the basic algorithm could learn, and all you had to do is set up
the learning environment, then you'd be teaching rather than programming.
In fact I believe THIS is what most "programmers" will be doing in 100 years. The challenge
will be defining the problem domain, the inputs, the desired outputs; the
algorithm and the architecture won't change, or won't change much, and the
vast majority of people won't fiddle with it.
But if HAL doesn't appear and we aren't all retrained as Dr. Chandra,
I believe we'll still be handling a lot of text on flat screens.
I don't think we'll be using sound, and I don't think we'll be using pictures.
(see below)
So predicting what languages will be like in 100 years is predicated
on knowing what computers and peripherals will be like. I think progress
will be slow, for the most part -- that is, I don't think it will be all
that much different from how it is now.
HOW WILL OUR RANGE OF EXPRESSION CHANGE?
If we relied primarily on voice input, languages would be a lot more
like spoken natural languages; there would be far less ambiguity than
most natural languages (so they'd be more like Russian than like English,
for example) but there wouldn't be nearly as much punctuation as there
is in Java and C++.
If we rely primarily on thought-transfer, they'll be something else
entirely. But I don't think this will come in 100 years.
How is a 24x80 IDE window different from punched cards and printers?
Much more efficient but remarkably similar, really. It would not surprise
me if we still use a lot of TEXT in the future. Speech is slow --
a program body stored as audio would be hard to scan through quickly.
Eyes are faster than ears so the program body will always be stored as
either text or pictures.
Pictures - well, pictorial languages assume too much of the work has
already been done underneath. "Programming isn't hard because of all
the typing; programming is hard because of all the thinking." (Who
wrote that in Byte a couple of decades ago?). I don't think we'll be
using pictures. When we get to the point that we can use hand-waving
to describe to the computer what we want it to do, again we'll be
teaching, not programming.
HOW WILL THE ARCHITECTURE CHANGE?
If the target architecture isn't Von Neumann, but something else,
then we may not be describing "algorithms" as we know them today.
Not being up to speed about quantum computing, I can speak to that
example...but there are lots of other variations. Analog computers?
Decimal instead of Binary digital machines? Hardware-implemented
neural networks? Again, I don't see much progress away from binary
digital stored-program machine in 40 years, and I think (barring
a magical breakthrough) this may continue to be the cheapest, most
available hardware for the next 50-100 years.
SO WHAT DO I THINK?
I think IDE's and runtime libraries will evolve tremendously, but
I don't think basic language design will change much. As long as
we continue to use physical devices at all, I think the low-level
programming languages will be very similar to present day ones:
Based on lines of text with regular grammars and punctuation,
describing algorithms. I predict COBOL will be gone, FORTRAN will
still be a dinosaur, and Java and C/C++ will also be dinosaurs.
But compilers for all 4 wi