if, say its 80%, I don't think we'll double the amount of work/change we've done in the entire history of the human race in 100 years, and even if we do, we'll have 100 years to come up with new technology to mitigate our destruction... If we have 10 years, then we have to change everything today.. better park your car and get out your bike. Turn off your computer and all your lights. Better start building your mud hut.

So... we've altered 43% of the land mass.. and catastrophic things happen *somewhere* between 50-90%... So either in like 10 years the world will fall apart, or it won't because it turns out that the number is much closer to 90% than 50%...

It would be nice if these "scientists" could you know.. provide some accurate data upon which to make their oh so important decision. Last time I looked that was their job, not making sensationalist claims with little to know proof or evidence.

I'm not saying its right or good, but if China isn't going to fine them for the violations, then what incentive do they have to stop? If China wants this to stop they need to fine Foxconn more than they are making violating the law.

My guess would be existing contracts. Their existing contracts with companies (apple, dell, hp, etc) specify their rates for product, if they raise wages, hire more workers and have to continue to deliver product at their existing contract rates, they'll be losing millions per day.

Now obviously, the companies could let Foxconn out of the existing contracts, and/or renegotiate now to raise wages, but they probably don't want to do that... Also, Foxconn probably can't hire an extra 100,000-200,000 workers in a day.

Sorry for the double reply... what is your language of choice? In the end I don't think this is a static vs dynamic competition... I'm just comparing python to the "big" statically typed languages (java, c, c++). There could easily be a statically typed language that offers a better trade off in terms of code length and performance than the "big" three, but I don't know about it...

I don't think C, C++, and Java get their verbosity only from being statically typed. And the code shrinkage I've achieved with python has not generally been due to dynamic typing. I'm willing to learn, if there is something better out there that allows for short code, and is faster than python, I'd agree with your argument.

The problem with your argument is it isnt "a little less code". I regularly over 10 years have had at least 50% code reduction when converting from C/C++/Java to python. Currently I'm converting 250k lines of C++ to python... I'm on course for a 75% reduction in code.

Now python is not a magic bullet, you do have to know how to use it... as an example at a previous job my team re-wrote a python program in python, and reduced lines of code by 50%... The original devs were C developers who were told "you will write this in python". They thought in C, the wrote in C, they took zero advantage of the standard library, they reimplemented the "lower" method all strings have.... The only reason it was python was the syntax was python. If you're thinking in Java, and writing Python, your code won't get shorter. You have to embrace functional programming where it makes sense to eliminate lines of code. You have to think in python and understand the standard library and what it can do for you to really get lots of code shrinkage. But it is possible to massively decrease the amount of code for the same feature set.

The point is I can (and have) replaced 100k lines of C, 150k lines of java, or 110k lines of C++ with 10-15k lines of python.

I don't care who you are, its easier and faster to write 15k lines of code than 100k lines of code, significantly faster. Its easier and faster to debug 15k lines of code than 100k lines of code, again significantly. Most bugs are not type errors. Most bugs are logic errors. Sure, is a type error annoying? Yes, but it annoys *me* as a thinking person that I changed the assumed type of a function argument and didn't go change a caller, its not the languages fault that I forgot, just like its not C/C++/Java's fault when you walk off the end of an array and segfault... automated tests find these bugs just as reliably as a compiler, and you have to write automated tests to test logic even in a statically typed language, so its not extra work.

The tradeoff is that my python code might run slower (if the modules I'm using aren't already C which a lot of them are), but vs Java, startup time is significantly faster, and memory usage in python is significantly better, like an order of magnitude at least. vs c/c++ I don't have to deal with pointers, null dereferencing, memory management, or any of those headachy things that a large proportion of developers do wrong, and end up with insecure programs. So... to me at least the choice is clear. Shorter code that is easier to read, easier to debug, quicker to write, easier to maintain, and generally has less bugs, python gets all those things 100% of the time vs C, C++, or Java. The only downside is it might be slow... and if it is, you write a couple hundred lines of C, write all manner of tests around it to make sure it deals with all the pointer stuff correctly, and you're still way ahead of a pure C program.

All I can say is you've obviously never built a large scale system in either a static or dynamic language... The number 1 correlation between bugs and code is the number of lines of code. More lines of code == more bugs. Always, every time. The fact that I can write the same thing in python in 1/5 or 1/7th the code vs Java or C++ means on average I'll have less bugs.

As someone who's spent the last year rebuilding in python the middle and frontend tiers of a large system that integrates a large number of C/C++ modules on the backend, I can tell you that the number of "dynamic" type issues that have leaked into QA (IE beyond automated test cases) are... 0

The number of null pointer dereferences, linking errors (which end up building successfully, but as soon as you try to call a function crash), and other various segfaults that have been found in the C/C++ modules.. well over 100

dynamic typing is *easy* to deal with compared to pointer math. Maybe if the C/C++ coders didn't have to spend all their time making sure they were passing char pointers instead of wchar pointers they could have spent a little time bounds checking arrays and verifying pointer math.

As to all the contentions that python isn't a "real" language, I would say the middle and frontend of this application are much better designed than anything that is in the backend. The code is clean, well documented, easily maintainable, much more flexible, modular, and for the most part 90%+ covered by automated tests. It is a solid OO design with a decent chunk of functional programming thrown in where it makes sense. The C code has a 75 page testing manual that must be run by hand after every QA build (takes 2-3 weeks)... I'm not surprised by this at all, because C requires you to spend all your time making trivial things work, so you don't have any time to actually do design. And once you get something "working" you can't touch it, because nothing is modular and everything is set in stone. I've written a decent amount of C in my life, I'm pretty fluent in it, and in writing python I've had to drop down to C to optimize a number of things. You do it when you have to, just like C coders used to drop to assembly when they had to.

Sure I'm generalizing in the paragraph above, I'm sure you *can* write well designed C, I've just never seen it in practice in the real world in 15 years of real life experience... I've seen "OK" designed C++, and well designed Java... I can recreate those designs in less than half the code in python, and VS java I'll use 1/10th the RAM, and vs C++ I won't have memory leaks or bad pointer math, and an average developer can read the code.

I believe Guido is spot on, in my experience the part of the code that has to be fast and isn't already a C module in python is tiny, and most of the time can be built in a day or two. Compare that to the 8 months I'm under budget building these middle and frontend tiers in python (they budgeted based on the last implementation which took 3 years in C++)... And I'd say python is a win, the interface is just as responsive, I'm well within all SLA metrics in the business logic tier, and in a number of places the python implementation is faster than the old C++ (just using better algorithms). I'm going to be at feature parity in the next month with the existing system... well except that now our system is 100% cross platform compatible (tested on OS X, Various linux flavors, Various bsd flavors, and Windows)... Vs the old C++ that made extensive use of win32 only functionality and was 100% windows only. Getting cross platform support was the reason for the redesign/rebuild... The fact that I built a prototype in python faster than the C++ guys could decide on a cross platform GUI toolkit gave my team the win to implement it in python.

Ok, I'm a middle class person, I have 50k invested in a 401k, said 401k goes up 20% this year... creating a gain of 10k and I get taxed at say 25%.. so I now need to sell $2500 in my retirement account to pay the tax... It gets even crazier if say I'm close to retirement and I have 500-600k or something in said account... now I have a $25000 tax bill on income I didn't make... and I have to sell investments just to pay the tax man... And next year the market could drop 20% and I'll just be out the 25k in taxes plus the 100k in investment losses...

I thought everyone was agreed we needed to simplify the tax code not make it insanely more complicated.

I knew they were doing some heavy lifting on the server side, cause obviously it doesn't work without a network connection.

However, I figured they would at least do an initial processing pass on the phone and pass up the data points to the server instead of the raw audio. That at least would make sense, and you'd be able to pass much smaller amounts of data. It would also explain the need to have better hardware on the phone. Sending the raw audio seems insane.

Other engineering disciplines are different I know, but in CS, I'd argue opportunity cost is a big factor. Myself and 2 of my classmates dropped out when after our sophomore years we were offered full time positions making real money (well... we were 20, 55k/yr sounded like a lot). This was in post bust 2001, and the three of us had conversations about it and all thought it was crazy to keep paying 10k/year for the next 2 years (or 3 depending on how courses were offered) when we could make 110 or 165k over the same time span... Since then 2 of us have completed our degrees (myself 8 years after dropping out), but I for one don't regret dropping out in the least. I got a lot of experience in those couple years, I learned way more about real software development than I was learning in college, and I've never spent a minute unemployed. My employer luckily has tuition reimbursement, so when I did finish my degree it didn't cost me anything.

Maybe I've been passed over for jobs/promotions over the years because of my lack of degree, but I've enjoyed my career so far, I love what I'm doing now, and I don't feel like I've been slighted in the least.

I didn't read the article... so I don't know, but the summary doesn't say anything about capturing the MRI data, the data is the data... They are using a new process to generate images from said data.

Now, in the summary, it says they do some up front processing, and then save the result of that, and use it for all subsequent image generation activities... because this processing used to be done on every image generation pass... well guess what, thats the definition of caching, and it has 0 to do with a new algorithm. They are still using the exact same *algorithm* to process the data, they are just storing the part that gets repeated over and over, and using it multiple times...

I use a Script I found on VMware forums that takes a snapshot and then backs up the snapshot... It's not fool proof but crash consistent at least. Yeah no live migrations...

I point out that my solution is affordable... How many nics are on your SAN? 15k rpm sas drives are more than twice as expensive as 7200rpm sata. It may well be that the iscsi hardware we were using didn't have the io ops to handle the load but it really felt like a bandwidth issue, Same iscsi San with 10gb vs 1 gb nics performed well enough..

Since when is caching a "new" algorithm? From the basic info in the summary it appears this is just a cache of some initial processing that is then reused for subsequent image generation passes...