A standard electric meter is a true integrating wattmeter. It sums the instantaneous product of voltage and current over time. That's the correct measurement of energy consumed.
The design is quite clever. There are two electromagnets in a single-phase electric meter. The magnetic flux from one is proportional to the voltage, and the flux from the other is proportional to the current. The effect is that the torque on the aluminum meter disc is proportional to the product of the magnetic fluxes. The disc is retarded by a permanent magnet drag brake, which applies a braking torque proportional to speed. So total rotation is the sum of the torque applied by the coils over time. It's one of those neat little results from electromagnetics.
This invention was made by Shallenberger, in 1893. By 1903, General Electric had introduced their Type I meter, which worked like today's mechanical meters. Some were still in use as late as 1960. Progress since then included temperature compensation, better magnets, etc., but the basic concept hasn't changed in a century.
All-electronic versions emulate the electromagnetic design, and are also true integrating wattmeters.
I wrote a piece on Craigslist's Increasingly Complicated Battle Against Spammers last year. They've tried everything known and it hasn't worked. They've tried capchas, email confirmation, phone confirmation, and IP address checking. It hasn't helped. There's a whole industry providing tools to help spam Craigslist.
Craigslist is now leaning hard on some of the companies helping others spam Craigslist, with modest success. At least Craigslist spamming tools are no longer available via Google Checkout. (With that, Google was close to being an active participant in illegal activity.) "www.adsoncraigs.com", the source of Craigslist Auto Poster, has been shut down. Some of the Craigslist posting tools use a program to break captchas, and some outsource the job to a service in a low-wage country.
The going price for oursourced manual captcha solving is around $0.60/1000 captchas.
Forty years on, and they're still flogging this thing. Hollywood has a major idea shortage.
I'd like to see any of David Weber's space operas turned into a series. Or Bujold's. We need some new thinking. Not rehashes of dead TV shows and old comic books.
There are, in fact, industrial PCs designed for long life and support over long periods. It's not at all unusual to expect industrial electronics to last 15 years.
Welcome to the world of underclocking. In the industrial world, everything is oversized and derated.
I have an occasional problem with photo sites copying this image. It gets quite a few links, to which I don't object, but outright copies I have to bug people about. The worst case was a site which used it as a "smiley" in their forum system. It took them a while to untangle that. They were very unhappy about having to take it down, because removing it messed up old forum posts, but eventually they did. Right now, I'm getting Photobucket to take it down; someone uploaded a copy there.
(I used to have that animation of a man jumping off a building on my Downside.com site. But after September 11, 2001, when people really were jumping off the World Trade Center, I took it off the home page of Downside. It continues to pop up on the web, eight years later. It's a black and white animated GIF, made as a full 3D animation with Softimage|3D and the Animats physics engine, then processed into a simple silhouette and run through a GIF compressor. One had to do things like that back in the dialup era to put interesting motion on a web page.)
You need a competent lawyer. In the end, you should come out of this way ahead. You can countersue for libel, defamation of character, and copyright violations.
Sheet speakers have been around for years. There were examples in Japan in 1985.
Electrostatic speakers were first developed in 1953, and there are plenty of flat panel speakers
around. Some hobbyists even build their own.
Bass reproduction isn't a problem for large-area thin speakers until the volume becomes high.
Then there's not enough travel to move enough air.
I have a pair of Magneplanars myself, about 18" x 40" x 0.75" . This is an 1980s technology. It works OK, but today you can get equally good or better sound from smaller units. Those never caught on.
Sun had a good run: 27 years. But they lost in workstations, they lost in servers, and Java isn't a big moneymaker.
This has serious implications for Java. To Sun, Java was their one remaining strong product. For IBM, it's just another software product line. IBM will do a decent job of maintaining it, as they do with all their corporate products. But they may not push it forward.
IBM also gets MySQL, which might be a problem, since IBM has other competing database offerings.
Sun's Silicon Valley operations have been shrinking for years. They overbuilt hugely during the dot-com boom, and have far too much office space. There's even an abandoned Sun industrial park in Fremont, where they built the parking lots and the building foundations before stopping construction around 2001.
Arguably, APC has become a mainframe vendor. They sell rack systems with integrated power, cooling, and cable management. Add commodity motherboards, CPU parts, disk drives, and software, and you have a mainframe.
It's not that different from what HP or SGI or IBM or Sun will sell you. Especially since the "mainframe" vendors have mostly moved to commodity CPU parts.
I've pointed out before that computing is becoming more like stationary engineering. Stationary engineers run and maintain all the equipment in building basements and penthouses. With containerized data centers, computing looks more and more like that.
The fundamental problems is that Linux doesn't have organized usability testing. One would think that Red Hat or Novell or VA Linux (remember VA Linux?) would be doing some of this, but they're not.
What's needed is not bug reports. What's needed is more organized.
Basic usability testing looks like this. You have some machines set up, arranged with video recording to record both the screen and the user's face and voice. You bring in some naive users for testing. (A good way to do this today would be to rent a vacant store in a mall.) Each user gets a card with some basic tasks, like "Write and print a letter" or "Download a song and listen to it". Their efforts to do this are recorded. More advanced tasks are provided for users with previous experience.
The recordings then have to be analyzed, looking for obstacles to progress. At what points did the user stop making progress on the task and get stuck? Did they need to use a help facility? How much time did they spend with the help facility? Did it solve their problem? Did they have to back up and retry something? Did the user become angry or frustrated? Did they need outside help? Did they complete the task? How long did it take?
The analysis summaries are used to determine what needs to be fixed. Any single problem that stopped more than one tester is a bug. Anything that made more than one user angry or frustrated is a bug. This is not a matter of opinion.
Microsoft does this for Windows. Apple does it for the Mac. Nobody does it for Linux. That's a big part of why Linux on the desktop still sucks.
Now and then there are attempts to deal with this by papering over the warts of the operating system. At various times, SGI, Asus, and HP have tried. It sort of works if you severely limit what the user can do, but otherwise, the mold shows through the wallpaper.
Have you ever encountered XML with Mandarin tags? It's out there. There was once French COBOL, with French word order, but that seems to have died out. There were some Russian programming languages from the USSR's aerospace community.
One would expect something in Mandarin, perhaps with one glyph for each reserved primitive.
Other than a Forth-like hack, that hasn't happened.
There are headaches with a big-character-set programming language. In Unicode, there are strings that look the same but are not identical. This is a pain in a programming language.
Programming languages work better if what you see is what you've got, because absolute string equality matters so much.
Unicode is fairly recent; much of the Han world is still struggling with "Big5", "GB", and similar hacks to handle a big character set. Because the character set is the vocabulary, there are occasional updates, which is inconvenient. ASCII has been stable for 40 years.
Accented languages are also inconvenient for programming, because the accents are somewhat optional. English has essentially dumped accents. (English has dumped a lot of baggage - accents, dual letters, gender, and case, none of which really contributed to communication.) Most other languages still baggage which is inconvenient when programming.
(I just wish we could get the Web down to using ASCII (0..127) with HTML escapes, or Unicode. We need to get rid of "upper code pages", "GB", "Big5", "Shift JIS", and "KS X 1001". Then at least everything would display for everybody, we wouldn't have mode issues, and all Unicode tools could parse everything.)
The Internet Archive does that. Although not on a very large scale.
The print-on-demand industry has, I think, made a positioning error. They produce cheap paperbacks at hardcover prices. What's needed is a high-quality hardcover binding machine as part of the print-on-demand process. The actual manufacturing cost of binding a book is about $1-$2, but the markup on hardcovers is much higher. Lulu.com now does hardcovers, but they all look exactly the same, all with the same dimensions and bound in plain blue linen. They charge $15 extra for hardcover binding, which is excessive.
Screen devices will take over the disposable book market. There's no reason to use paper for read-once books.
And how, exactly, is moving part of the compute load to the "cloud" supposed to reduce development costs?
OnLive is amusing. The technology isn't that interesting; it's the business model.
Casual games can have a "console-like experience". It also has the ultimate answer to piracy. Since the game software runs entirely in OnLive's data center, there's nothing playable the end user can copy. The OnLive client is just a video player.
But they need an incredibly good bandwidth/latency combination to make it work. They need 5mb/s with under 20ms or so round trip delay to equal the console experience. Unless they have a data center at each cable headend, they're not going to be able to deliver that.
Worse, all the capital costs fall on the provider. Who's going to fund this thing?
I have three early model Eee PC machines, one in Barbie pink and two in lime green. I got these essentially free because the company that bought them couldn't get anybody to use them. The black models were snatched up immediately, but the pink and green ones stayed in inventory until they were obsolete. None of the corporate executives would be seen with the things.
I don't want to be seen with them either. I'm using them in an embedded application where nobody sees them.
Languages like Ruby and Python are hard to beat on easy of use and programmer productivity. However, current implementations don't offer stellar performance.
There's a real problem when a language designer is too attached to his own implementation. That happened with Pascal. Wirth did a simple, clean, recursive-descent compiler that generated naive code, making the language slow. Pascal can be heavily optimized, but for a long time, it wasn't.
Python has a similar problem. Guido is too attached to CPython, which is a straightforward naive implementation that runs maybe 20x - 30x slower than C/C++. Python needs to be formally standardized, so that CPython isn't considered the language definition.
Python could be optimized to go almost as fast as C, but the compiler has to be very smart. It helps if you disallow a few things that aren't very useful but fall out of the CPython implementation. (For example, if you require that the code of a class can't be modified at run-time, (classes can still be subclassed), much more can be bound at compile time.) Then there's type inference. In Python, any variable can potentially take on any type, but in practice, most variables don't change type. The compiler needs to identify the ones that can't change type and hard-type them. There's a huge payoff when a variable can be nailed to "int" or "float" at compile time, rather than being "boxed" as an object. This shouldn't require help from the programmer.
Another huge win is hoisting checks out of loops. All subscripts should be checked, but most of the checks can be optimized out. For most inner loops, this isn't at all hard. It's usually easy to determine at loop entry whether overflow is possible, and do the check once per loop, not once per iteration. Often (especially for FOR loops) all checks can be optimized out. You do need the rule that you can "fail early"; that is, an error condition can be reported as soon as it becomes inevitable. It's inefficient to generate code that waits until the iteration that causes the overflow.
The remaining big problem with Python is the "global interpreter lock". Python's concurrency model is traditional and dumb; the language has no idea which threads own which objects. So automatic lock breakup is tough. That's a longer subject than I have time for now.
What places can people recommend for doing programming language research?
It's not that popular in the US right now. Today, to launch a new programming language, you need a big launch budget. Sun spent $20 million to launch Java, and they were giving it away. Microsoft probably spent more launching C#. You can't just put it out there any more.
Also, to do programming language work, you need to be really good at compilers, or the performance of your language will suck. We don't need another language run on what compiler people call a "naive interpreter".
I shit you not, if you make "too much" money, the processing companies will hold your money for up to 6 months - just because they can justify it with their terms of service.
You need a merchant account with a real bank. This is more work to set up, but your merchant bank account doesn't have to be controlled by the card processing service. When I did this, I used Bank of America. There are monthly charges, and you may have to keep a deposit (a CD, for example) in the bank as security. But the money goes into your account the day after the card is charged.
People in the "adult" industry have much tougher banking problems, because most of the big banks won't take their business. The terms from the "adult" credit card providers are much tougher, and many of them are ripoff outfits. (I once got a heated twenty minute lecture on this subject from a San Francisco bondage model and web site operator; she'd lost hundreds of thousands of dollars through troubles with an offshore "adult" credit card processor.) In that area, you do see multi-month holdbacks.
3D recognition is a solveable problem. As someone else mentioned, there are machine learning techniques that work. Recognizing a 3D object from multiple angles is a very old AI problem, one that DoD-funded work was addressing as early as the 1960s. It's easier than 3D reconstruction from multiple 2D images, which is a commercially available technology.
I think we're reaching the end of the line on CAPCHAs. There's now overlap between the smarter vision programs and the dumber users.
This is disappointing. Shed Skin has shown speed improvements of 2 to 220x over CPython. Going for 5x over CPython is lame. But Shed Skin is a tiny effort, and needs help.
PyPy got a lot of press, but they tried to do an optimizing compiler with "agile programming" and "sprints", and, at six years on with substantial funding, it's still not done.
The fundamental problem with running Python fast is its gratuitous dynamism. In CPython, almost everything is late-bound, and most of the time goes into name lookups. This makes it easy to treat everything as dynamic. You can store into the local variables of a function from outside the
function, for example. In order to make Python go fast, the compiler has to be able to detect the 99.99% of the time when that isn't happening and generate pre-bound code accordingly.
Dynamic typing requires similar handling. Most variables never change type. Recognizing int and float variables that will never contain anything else creates a significant speedup. In CPython, all numbers are "boxed", stored in an object structure. This is general but slow.
CPython is nice and simple, but slow. Serious speedup requires global analysis of the program to detect the hard cases and generate fast code for the easy ones. Shed Skin actually does this, but has to place some limitations on the language to do it. If someone did everything right, Python could probably achieve the speed of C++.
There's also the problem that if you want to be compatible with existing C modules for CPython, you're stuck with CPython's overly general internal representation.
there's nothing inherent about the paper medium that makes for better reporting.
True. The problem is that "online newspapers" don't have a payment model that brings in significant revenue. Only the Wall Street Journal and Bloomberg do. But they sell to the financial community.
You have to realize how desperate the newspaper industry has become. The Seattle Post-Intelligencer printed their last paper edition last week. They're just a web site now, and
they distribute their news via Twitter. That's how far down they've come. The Detroit Free Press only prints on Thursday, Friday, and Sunday now. The San Francisco Chronicle may go next.
And those were once Great Metropolitan Dailies. Little papers go under every day.
Nothing is really replacing them. Blogs are mostly punditry; few have paid reporters. If anything, the future may be TV news presented via the Web. TV news has historically been time-limited, but that's not a Web problem.
First, you need to build a functional prototype. This doesn't have to be manufacturable at low cost; it just has to work. It can be larger than the production version and the parts cost may be higher. Then you'll have something to demo, and can get feedback on whether this is something worth making in quantity. This is something you can get done by one EE who does prototypes.
Second, you need to decide whether your idea is good enough to patent. If it's a "me-too" idea, or something that could be replaced by a similar device not covered by the patent, don't bother.
Read "Patent It Yourself", from Nolo Press, for advice on this. Incidentally, nobody serious files provisional patents; you either file a real patent or don't bother.
The next step is to get a case designed. You're selling a camera accessory, where form factor and design are important. Right now, things are slow in the design business, and you can probably find someone competent to do your sketches and mockups. Start reading industrial design magazines so you understand how to talk to a designer.
Now it's business decision time. Is there a viable product in this? Can you afford to make it?
Can you get enough money together? You now have something to show; it's not vaporware at this point. So you can get opinions on whether manufacturing it is a good idea.
Only now are you ready to talk about manufacturing. There are major companies that will do the whole
job for you, such as Flextronics, which makes, among many other things, most of Microsoft's hardware products, including the Xboxes. Things are slow in that industry right now (Flextronics just did a major downsizing) so they'll probably talk to you. They don't finance you; that's your problem. They design the electronics, design the case, get the parts cost down, and make the thing to order. If you don't have enough money for them, they might pass you down to a lower-tier contract manufacturer.
Slashdot Mirror
A standard electric meter is a true integrating wattmeter. It sums the instantaneous product of voltage and current over time. That's the correct measurement of energy consumed.
The design is quite clever. There are two electromagnets in a single-phase electric meter. The magnetic flux from one is proportional to the voltage, and the flux from the other is proportional to the current. The effect is that the torque on the aluminum meter disc is proportional to the product of the magnetic fluxes. The disc is retarded by a permanent magnet drag brake, which applies a braking torque proportional to speed. So total rotation is the sum of the torque applied by the coils over time. It's one of those neat little results from electromagnetics.
This invention was made by Shallenberger, in 1893. By 1903, General Electric had introduced their Type I meter, which worked like today's mechanical meters. Some were still in use as late as 1960. Progress since then included temperature compensation, better magnets, etc., but the basic concept hasn't changed in a century.
All-electronic versions emulate the electromagnetic design, and are also true integrating wattmeters.
I wrote a piece on Craigslist's Increasingly Complicated Battle Against Spammers last year. They've tried everything known and it hasn't worked. They've tried capchas, email confirmation, phone confirmation, and IP address checking. It hasn't helped. There's a whole industry providing tools to help spam Craigslist.
Craigslist is now leaning hard on some of the companies helping others spam Craigslist, with modest success. At least Craigslist spamming tools are no longer available via Google Checkout. (With that, Google was close to being an active participant in illegal activity.) "www.adsoncraigs.com", the source of Craigslist Auto Poster, has been shut down. Some of the Craigslist posting tools use a program to break captchas, and some outsource the job to a service in a low-wage country.
The going price for oursourced manual captcha solving is around $0.60/1000 captchas.
Forty years on, and they're still flogging this thing. Hollywood has a major idea shortage.
I'd like to see any of David Weber's space operas turned into a series. Or Bujold's. We need some new thinking. Not rehashes of dead TV shows and old comic books.
Apple didn't fool the press. This is being reported as "Apple raises prices 30%".
The Google ad blocks seem to be bigger. And there are more of them. I thought Google limited you to one block of ads per page.
There are, in fact, industrial PCs designed for long life and support over long periods. It's not at all unusual to expect industrial electronics to last 15 years. Welcome to the world of underclocking. In the industrial world, everything is oversized and derated.
I have an occasional problem with photo sites copying this image. It gets quite a few links, to which I don't object, but outright copies I have to bug people about. The worst case was a site which used it as a "smiley" in their forum system. It took them a while to untangle that. They were very unhappy about having to take it down, because removing it messed up old forum posts, but eventually they did. Right now, I'm getting Photobucket to take it down; someone uploaded a copy there.
(I used to have that animation of a man jumping off a building on my Downside.com site. But after September 11, 2001, when people really were jumping off the World Trade Center, I took it off the home page of Downside. It continues to pop up on the web, eight years later. It's a black and white animated GIF, made as a full 3D animation with Softimage|3D and the Animats physics engine, then processed into a simple silhouette and run through a GIF compressor. One had to do things like that back in the dialup era to put interesting motion on a web page.)
You need a competent lawyer. In the end, you should come out of this way ahead. You can countersue for libel, defamation of character, and copyright violations.
Sheet speakers have been around for years. There were examples in Japan in 1985. Electrostatic speakers were first developed in 1953, and there are plenty of flat panel speakers around. Some hobbyists even build their own.
Bass reproduction isn't a problem for large-area thin speakers until the volume becomes high. Then there's not enough travel to move enough air.
I have a pair of Magneplanars myself, about 18" x 40" x 0.75" . This is an 1980s technology. It works OK, but today you can get equally good or better sound from smaller units. Those never caught on.
Forbes predicts 10,000 layoffs from the merger, most on the Sun side, in "IBM and Sun: There Will Be Blood".
Sun had a good run: 27 years. But they lost in workstations, they lost in servers, and Java isn't a big moneymaker.
This has serious implications for Java. To Sun, Java was their one remaining strong product. For IBM, it's just another software product line. IBM will do a decent job of maintaining it, as they do with all their corporate products. But they may not push it forward.
IBM also gets MySQL, which might be a problem, since IBM has other competing database offerings.
Sun's Silicon Valley operations have been shrinking for years. They overbuilt hugely during the dot-com boom, and have far too much office space. There's even an abandoned Sun industrial park in Fremont, where they built the parking lots and the building foundations before stopping construction around 2001.
Watching people play cards is now a televised "sport".
Maybe if people played video games for money....
Arguably, APC has become a mainframe vendor. They sell rack systems with integrated power, cooling, and cable management. Add commodity motherboards, CPU parts, disk drives, and software, and you have a mainframe. It's not that different from what HP or SGI or IBM or Sun will sell you. Especially since the "mainframe" vendors have mostly moved to commodity CPU parts.
I've pointed out before that computing is becoming more like stationary engineering. Stationary engineers run and maintain all the equipment in building basements and penthouses. With containerized data centers, computing looks more and more like that.
The fundamental problems is that Linux doesn't have organized usability testing. One would think that Red Hat or Novell or VA Linux (remember VA Linux?) would be doing some of this, but they're not.
What's needed is not bug reports. What's needed is more organized.
Basic usability testing looks like this. You have some machines set up, arranged with video recording to record both the screen and the user's face and voice. You bring in some naive users for testing. (A good way to do this today would be to rent a vacant store in a mall.) Each user gets a card with some basic tasks, like "Write and print a letter" or "Download a song and listen to it". Their efforts to do this are recorded. More advanced tasks are provided for users with previous experience.
The recordings then have to be analyzed, looking for obstacles to progress. At what points did the user stop making progress on the task and get stuck? Did they need to use a help facility? How much time did they spend with the help facility? Did it solve their problem? Did they have to back up and retry something? Did the user become angry or frustrated? Did they need outside help? Did they complete the task? How long did it take?
The analysis summaries are used to determine what needs to be fixed. Any single problem that stopped more than one tester is a bug. Anything that made more than one user angry or frustrated is a bug. This is not a matter of opinion.
Microsoft does this for Windows. Apple does it for the Mac. Nobody does it for Linux. That's a big part of why Linux on the desktop still sucks.
Now and then there are attempts to deal with this by papering over the warts of the operating system. At various times, SGI, Asus, and HP have tried. It sort of works if you severely limit what the user can do, but otherwise, the mold shows through the wallpaper.
Have you ever encountered XML with Mandarin tags? It's out there. There was once French COBOL, with French word order, but that seems to have died out. There were some Russian programming languages from the USSR's aerospace community.
One would expect something in Mandarin, perhaps with one glyph for each reserved primitive. Other than a Forth-like hack, that hasn't happened.
There are headaches with a big-character-set programming language. In Unicode, there are strings that look the same but are not identical. This is a pain in a programming language. Programming languages work better if what you see is what you've got, because absolute string equality matters so much. Unicode is fairly recent; much of the Han world is still struggling with "Big5", "GB", and similar hacks to handle a big character set. Because the character set is the vocabulary, there are occasional updates, which is inconvenient. ASCII has been stable for 40 years.
Accented languages are also inconvenient for programming, because the accents are somewhat optional. English has essentially dumped accents. (English has dumped a lot of baggage - accents, dual letters, gender, and case, none of which really contributed to communication.) Most other languages still baggage which is inconvenient when programming.
(I just wish we could get the Web down to using ASCII (0..127) with HTML escapes, or Unicode. We need to get rid of "upper code pages", "GB", "Big5", "Shift JIS", and "KS X 1001". Then at least everything would display for everybody, we wouldn't have mode issues, and all Unicode tools could parse everything.)
The Internet Archive does that. Although not on a very large scale.
The print-on-demand industry has, I think, made a positioning error. They produce cheap paperbacks at hardcover prices. What's needed is a high-quality hardcover binding machine as part of the print-on-demand process. The actual manufacturing cost of binding a book is about $1-$2, but the markup on hardcovers is much higher. Lulu.com now does hardcovers, but they all look exactly the same, all with the same dimensions and bound in plain blue linen. They charge $15 extra for hardcover binding, which is excessive.
Screen devices will take over the disposable book market. There's no reason to use paper for read-once books.
And how, exactly, is moving part of the compute load to the "cloud" supposed to reduce development costs?
OnLive is amusing. The technology isn't that interesting; it's the business model. Casual games can have a "console-like experience". It also has the ultimate answer to piracy. Since the game software runs entirely in OnLive's data center, there's nothing playable the end user can copy. The OnLive client is just a video player.
But they need an incredibly good bandwidth/latency combination to make it work. They need 5mb/s with under 20ms or so round trip delay to equal the console experience. Unless they have a data center at each cable headend, they're not going to be able to deliver that.
Worse, all the capital costs fall on the provider. Who's going to fund this thing?
I have three early model Eee PC machines, one in Barbie pink and two in lime green. I got these essentially free because the company that bought them couldn't get anybody to use them. The black models were snatched up immediately, but the pink and green ones stayed in inventory until they were obsolete. None of the corporate executives would be seen with the things.
I don't want to be seen with them either. I'm using them in an embedded application where nobody sees them.
Languages like Ruby and Python are hard to beat on easy of use and programmer productivity. However, current implementations don't offer stellar performance.
There's a real problem when a language designer is too attached to his own implementation. That happened with Pascal. Wirth did a simple, clean, recursive-descent compiler that generated naive code, making the language slow. Pascal can be heavily optimized, but for a long time, it wasn't. Python has a similar problem. Guido is too attached to CPython, which is a straightforward naive implementation that runs maybe 20x - 30x slower than C/C++. Python needs to be formally standardized, so that CPython isn't considered the language definition.
Python could be optimized to go almost as fast as C, but the compiler has to be very smart. It helps if you disallow a few things that aren't very useful but fall out of the CPython implementation. (For example, if you require that the code of a class can't be modified at run-time, (classes can still be subclassed), much more can be bound at compile time.) Then there's type inference. In Python, any variable can potentially take on any type, but in practice, most variables don't change type. The compiler needs to identify the ones that can't change type and hard-type them. There's a huge payoff when a variable can be nailed to "int" or "float" at compile time, rather than being "boxed" as an object. This shouldn't require help from the programmer.
Another huge win is hoisting checks out of loops. All subscripts should be checked, but most of the checks can be optimized out. For most inner loops, this isn't at all hard. It's usually easy to determine at loop entry whether overflow is possible, and do the check once per loop, not once per iteration. Often (especially for FOR loops) all checks can be optimized out. You do need the rule that you can "fail early"; that is, an error condition can be reported as soon as it becomes inevitable. It's inefficient to generate code that waits until the iteration that causes the overflow.
The remaining big problem with Python is the "global interpreter lock". Python's concurrency model is traditional and dumb; the language has no idea which threads own which objects. So automatic lock breakup is tough. That's a longer subject than I have time for now.
What places can people recommend for doing programming language research?
It's not that popular in the US right now. Today, to launch a new programming language, you need a big launch budget. Sun spent $20 million to launch Java, and they were giving it away. Microsoft probably spent more launching C#. You can't just put it out there any more.
Also, to do programming language work, you need to be really good at compilers, or the performance of your language will suck. We don't need another language run on what compiler people call a "naive interpreter".
I shit you not, if you make "too much" money, the processing companies will hold your money for up to 6 months - just because they can justify it with their terms of service.
You need a merchant account with a real bank. This is more work to set up, but your merchant bank account doesn't have to be controlled by the card processing service. When I did this, I used Bank of America. There are monthly charges, and you may have to keep a deposit (a CD, for example) in the bank as security. But the money goes into your account the day after the card is charged.
People in the "adult" industry have much tougher banking problems, because most of the big banks won't take their business. The terms from the "adult" credit card providers are much tougher, and many of them are ripoff outfits. (I once got a heated twenty minute lecture on this subject from a San Francisco bondage model and web site operator; she'd lost hundreds of thousands of dollars through troubles with an offshore "adult" credit card processor.) In that area, you do see multi-month holdbacks.
3D recognition is a solveable problem. As someone else mentioned, there are machine learning techniques that work. Recognizing a 3D object from multiple angles is a very old AI problem, one that DoD-funded work was addressing as early as the 1960s. It's easier than 3D reconstruction from multiple 2D images, which is a commercially available technology.
I think we're reaching the end of the line on CAPCHAs. There's now overlap between the smarter vision programs and the dumber users.
This is disappointing. Shed Skin has shown speed improvements of 2 to 220x over CPython. Going for 5x over CPython is lame. But Shed Skin is a tiny effort, and needs help.
PyPy got a lot of press, but they tried to do an optimizing compiler with "agile programming" and "sprints", and, at six years on with substantial funding, it's still not done.
The fundamental problem with running Python fast is its gratuitous dynamism. In CPython, almost everything is late-bound, and most of the time goes into name lookups. This makes it easy to treat everything as dynamic. You can store into the local variables of a function from outside the function, for example. In order to make Python go fast, the compiler has to be able to detect the 99.99% of the time when that isn't happening and generate pre-bound code accordingly.
Dynamic typing requires similar handling. Most variables never change type. Recognizing int and float variables that will never contain anything else creates a significant speedup. In CPython, all numbers are "boxed", stored in an object structure. This is general but slow.
CPython is nice and simple, but slow. Serious speedup requires global analysis of the program to detect the hard cases and generate fast code for the easy ones. Shed Skin actually does this, but has to place some limitations on the language to do it. If someone did everything right, Python could probably achieve the speed of C++.
There's also the problem that if you want to be compatible with existing C modules for CPython, you're stuck with CPython's overly general internal representation.
there's nothing inherent about the paper medium that makes for better reporting.
True. The problem is that "online newspapers" don't have a payment model that brings in significant revenue. Only the Wall Street Journal and Bloomberg do. But they sell to the financial community.
You have to realize how desperate the newspaper industry has become. The Seattle Post-Intelligencer printed their last paper edition last week. They're just a web site now, and they distribute their news via Twitter. That's how far down they've come. The Detroit Free Press only prints on Thursday, Friday, and Sunday now. The San Francisco Chronicle may go next.
And those were once Great Metropolitan Dailies. Little papers go under every day.
Nothing is really replacing them. Blogs are mostly punditry; few have paid reporters. If anything, the future may be TV news presented via the Web. TV news has historically been time-limited, but that's not a Web problem.
You have a lot of work ahead of you.
First, you need to build a functional prototype. This doesn't have to be manufacturable at low cost; it just has to work. It can be larger than the production version and the parts cost may be higher. Then you'll have something to demo, and can get feedback on whether this is something worth making in quantity. This is something you can get done by one EE who does prototypes.
Second, you need to decide whether your idea is good enough to patent. If it's a "me-too" idea, or something that could be replaced by a similar device not covered by the patent, don't bother. Read "Patent It Yourself", from Nolo Press, for advice on this. Incidentally, nobody serious files provisional patents; you either file a real patent or don't bother.
The next step is to get a case designed. You're selling a camera accessory, where form factor and design are important. Right now, things are slow in the design business, and you can probably find someone competent to do your sketches and mockups. Start reading industrial design magazines so you understand how to talk to a designer.
Now it's business decision time. Is there a viable product in this? Can you afford to make it? Can you get enough money together? You now have something to show; it's not vaporware at this point. So you can get opinions on whether manufacturing it is a good idea.
Only now are you ready to talk about manufacturing. There are major companies that will do the whole job for you, such as Flextronics, which makes, among many other things, most of Microsoft's hardware products, including the Xboxes. Things are slow in that industry right now (Flextronics just did a major downsizing) so they'll probably talk to you. They don't finance you; that's your problem. They design the electronics, design the case, get the parts cost down, and make the thing to order. If you don't have enough money for them, they might pass you down to a lower-tier contract manufacturer.