Dividing by population is biased. Dividing by domestic output shows the true efficiency of a country's economic engine.
Using Wikipedia, so if the GDP numbers are wrong, that's why, we can divide the emissions by country GDP to find out how efficiently (in terms of emissions) the country is making it's economy work.
Taking the top 15 polluters and ordering by Emissions/GDP, we get:
Rank Country Emissions GDP ($M) Emissions/GDP
Ukraine 108431 81,664 1.33
Russia 431090 766,180 0.56
China 917997 2,224,811 0.41
India 272212 775,410 0.35
Poland 97375 300,533 0.32
South Korea 111370 793,070 0.14
Mexico 95007 768,437 0.12
Australia 83688 707,992 0.12
US 1446777 12,485,725 0.12
Canada 111723 1,130,208 0.10
Germany 235050 2,797,343 0.08
Japan 318686 4,571,314 0.07
UK 152015 2,201,473 0.07
Italy 110052 1,766,160 0.06
France 98750 2,105,864 0.05
So how about the top three least efficient countries (Ukraine, Russia, and China) focus on fixing themselves before people start landing on the US (btw those three added together have the same emissions level as the US).
(disclaimer: I work for Curl and love programming in Curl. However, the following is not 'officially' signed off on by Curl Corp., this is a personal diatribe.)
Unfortunately, the motivation behind developing the Curl language has not been accurately portrayed in this discussion. This is understandable due to many factors, mainly that our demos may not represent our vision completely (they are admittedly applet oriented while Curl is much, much more than that) and our pricing page not conveying the fact that employing Curl powered Web pages/sites can significantly reduce current operational costs such as Web hosting and backend infrustructure charges.
I have been developing database driven HTML/JS/CSS/DHTML/... Web pages/sites for quite some time now and have always run into the same problems. Cross browser incompatibility problems (not even just btwn NS and IE, but btwn different *versions* of the same browser), difficulty with maintainence, debugging, stability, and extensibility, and limitations inherent to the languages/protocols themselves.
One of Curl's missions is to provide a way for Web programmers get away from this restrictive situation by placing the programming power back into the Web developer's hands. Since Curl is a full fledged OO programming language (including multiple inheritence) with native support for text formatting and scripting, Web developers can very rapidly produce Weby UIs with the programming power only available outside of Web UIs - like in a C/C++/Java application. Sure you can embed a Java applet in an HTML page but only through liveconnect can that applet talk w/ JS - and then only through DOM can JS modify the page dynamically - now you are back dealing with cross browser incompatability issues...
With Curl, you can really start thinking about advanced DHTML-like things in a cross browser environment with a development environment previously only available outside the DHTML world.
Additionally, there is a SAX2 compliant XML parser in the Core of the Curl runtime. So, writing a Curl Web page which gets its data from an XML stream opened to a server side PHP script based upon a user's interaction w/ the page (like clicking a button, filling out a form, or mousing over some text) is possible without embedding Java in an HTML page or refreshing the entire HTML page by applying an XSLT to the XML response. XML has been searching for a way to be employed on the client side in a Web environment and Curl is, in my opinion, a great answer.
How about graphics - many of the graphics on the Web are curves, gradients, and so on - graphics which can be procedurally generated. Curl's 2D library allows Web developers to reduce the number of little gifs their pages contain (obviously many situtations like pictures of people don't apply here).
And then there is 3D. With native 3D support, a Scene can be placed anywhere in a Curl page. Since it is not a third party 3D Scene embedded in an HTML page, but rather a single semantic framework that contains 3D objects, everything can talk to everything else. Drop down lists, buttons, text, etc. can contain events which interact w/ the Scene and vice versa. There is no break btwn components on the page - everything is uniform, knowledgable about each other, and live.
So, sorry for the rambling, I know that was long winded, but I just wanted get out some thoughts as to why I love programming in Curl and do not want to go back to the old environment where I'm always concerned as to whether my tables will line up right in both IE and NS. Let alone the whole other host of incompatabilities.
Slashdot Mirror
Dividing by population is biased. Dividing by domestic output shows the true efficiency of a country's economic engine.
Using Wikipedia, so if the GDP numbers are wrong, that's why, we can divide the emissions by country GDP to find out how efficiently (in terms of emissions) the country is making it's economy work.
Taking the top 15 polluters and ordering by Emissions/GDP, we get:
Rank Country Emissions GDP ($M) Emissions/GDP
So how about the top three least efficient countries (Ukraine, Russia, and China) focus on fixing themselves before people start landing on the US (btw those three added together have the same emissions level as the US).
http://en.wikipedia.org/wiki/List_of_countries_by
http://www.ucsusa.org/global_warming/science/each
"Christopher Barber gave a talk on Curl, a bizarre little language that fills the same sort of niche as Flash."
... that's terribly myopic.
Come on now
(disclaimer: I work for Curl and love programming in Curl. However, the following is not 'officially' signed off on by Curl Corp., this is a personal diatribe.)
...
Unfortunately, the motivation behind developing the Curl language has not been accurately portrayed in this discussion. This is understandable due to many factors, mainly that our demos may not represent our vision completely (they are admittedly applet oriented while Curl is much, much more than that) and our pricing page not conveying the fact that employing Curl powered Web pages/sites can significantly reduce current operational costs such as Web hosting and backend infrustructure charges.
I have been developing database driven HTML/JS/CSS/DHTML/... Web pages/sites for quite some time now and have always run into the same problems. Cross browser incompatibility problems (not even just btwn NS and IE, but btwn different *versions* of the same browser), difficulty with maintainence, debugging, stability, and extensibility, and limitations inherent to the languages/protocols themselves.
One of Curl's missions is to provide a way for Web programmers get away from this restrictive situation by placing the programming power back into the Web developer's hands. Since Curl is a full fledged OO programming language (including multiple inheritence) with native support for text formatting and scripting, Web developers can very rapidly produce Weby UIs with the programming power only available outside of Web UIs - like in a C/C++/Java application. Sure you can embed a Java applet in an HTML page but only through liveconnect can that applet talk w/ JS - and then only through DOM can JS modify the page dynamically - now you are back dealing with cross browser incompatability issues
With Curl, you can really start thinking about advanced DHTML-like things in a cross browser environment with a development environment previously only available outside the DHTML world.
Additionally, there is a SAX2 compliant XML parser in the Core of the Curl runtime. So, writing a Curl Web page which gets its data from an XML stream opened to a server side PHP script based upon a user's interaction w/ the page (like clicking a button, filling out a form, or mousing over some text) is possible without embedding Java in an HTML page or refreshing the entire HTML page by applying an XSLT to the XML response. XML has been searching for a way to be employed on the client side in a Web environment and Curl is, in my opinion, a great answer.
How about graphics - many of the graphics on the Web are curves, gradients, and so on - graphics which can be procedurally generated. Curl's 2D library allows Web developers to reduce the number of little gifs their pages contain (obviously many situtations like pictures of people don't apply here).
And then there is 3D. With native 3D support, a Scene can be placed anywhere in a Curl page. Since it is not a third party 3D Scene embedded in an HTML page, but rather a single semantic framework that contains 3D objects, everything can talk to everything else. Drop down lists, buttons, text, etc. can contain events which interact w/ the Scene and vice versa. There is no break btwn components on the page - everything is uniform, knowledgable about each other, and live.
So, sorry for the rambling, I know that was long winded, but I just wanted get out some thoughts as to why I love programming in Curl and do not want to go back to the old environment where I'm always concerned as to whether my tables will line up right in both IE and NS. Let alone the whole other host of incompatabilities.
Open to discussion, I love talking about Curl...