100,000 stars - <AUTHOR> http://workshop.chromeexperiments.com/stars/ <comment><USER2> WOW, that is amazing. I'm always blown away by stuff like this, where you can actually get a sense of how small we all are and how distant even the closest neighbor stars are.

I just close my eyes for a minute and think (or try to), what would it be like for those people that are finally able to reach, say, Vega (I know it's not the closest). Sure, this is not a big deal in sci-fi, but for reality, it's pretty mind blowing. This is 100% why I seriously want to live for a few hundred years: to have an opportunity to see the first time we actually go to the nearest star.

In the meantime, I guess this will have to suffice.

I also love this image that is not interactive like this, but still mind blowing: [http://en.wikipedia.org/wiki/File:Earths_Location_in_the_Uni...](http://en.wikipedia.org/wiki/File:Earths_Location_in_the_Universe_\(JPEG\).jpg)

<comment><USER3> >WOW, that is amazing. I'm always blown away by stuff like this, where you can actually get a sense of how small we all are and how distant even the closest neighbor stars are.

Same.

If you don't already own a pair, I'd recommend getting a basic pair of binoculars and doing some backyard astronomy. You'd be amazed how much more you can see with even a basic 10x50 pair, even in thoroughly light-polluted skies.

Also SpaceRip [1] collects hundreds of interesting, easily digestible and pretty timely videos.

1: <http://www.youtube.com/user/SpaceRip>

<comment><USER4> > I'd recommend getting a basic pair of binoculars and doing some backyard > astronomy

If you've got the spare cash, get image stabilized ones. I could clearly see the moons around Jupiter with my Canon 12x36 IS binos the other night despite my hand tremors. The real party trick is handing them to a friend and telling them to look at the moon. Blows them away every time - to most people it's just a yellowish glowing thing in the sky, rather than a scarred rocky globe.

</comment></comment></comment><comment><USER5> This is without a doubt one of the coolest and most beautiful webgl experiments I have seen in the last few years, it actually struck a real chord with me - music, lighting, effects, the zoom and the sheer beauty of it.

For those people unlucky enough to not be able to load this app (it took me quite a while) here is a particularly fantastic image I took (without asking or any right to, of course) - [http://shanearmstrong.co.uk/content/cdn/the_beauty_of_the_co...](http://shanearmstrong.co.uk/content/cdn/the_beauty_of_the_cosmos.png) \- I apologize for any slow load times.

<comment><USER6> I am guessing you have liked this too - <http://www.youtube.com/watch?v=17jymDn0W6U>

Being a video it is not interactive, but definitely does strike something in me. It's almost the Total Perspective Vortex.

<comment><USER5> Until now I had not seen this video, but thank you.

This really puts in to perspective the brevity of human life and how little we have achieved so far, from leaving the primordial soup to firing Glee across our television network to entertain teenage girls and travelling to and from the moon.

We are irrelevantly small and unimportant and yet we have already done the hardest thing, of what we know for sure, there are 8.5 million species on the planet and we are the only constructively intelligent one present here, there are 400 known satellites in our solar system, if you assume that every solar system in the milky way has a similar amount of planetoids on which some minor form of life could have grown, placed around 300 billion stars. I'm going to take a _complete_ guess that only 1 in 10,000 of those contain a similar amount of life, which could be light years off, or could be spot on, or could even be far, far less tan the actual number - we simply don't know yet.

The maths is breathtakingly overwhelming:

(1 / ((8500000 * 400) * 300000000000)) * 10000 = 0.000000000000000098

Our significance in the Milky Way is 0.000000000000000098.

We account for only 0.0000000000000098% of potential life in this galaxy.

But we survived. We made it this far. From here the only way is up, or down, or left or under (depending on the location of the camera when we finally make it far enough off this rock to consider it interstellar travel.)

 _Disclaimer: This maths was about as well as I could do at 5.30am and is the product of a Google search of the accumulated human knowledge of the last few thousand years_

<comment><USER7> >> We are irrelevantly small and unimportant

That we are relatively small is undeniable. That we are unimportant is an emotional judgement that I think is unwarranted. Size != importance.

Importance is a value judgement made in a mind. My left thumb is more important to me than Alpha Centauri is. As far as I know, Alpha Centauri has no opinion on the matter.

Are we important to one another? To yet-unknown sentient creatures? To God?

The answers to those questions will probably not depend on whether we are 1 meter or 1 parsec tall.

</comment></comment></comment></comment><comment><USER8> _Warning: Scientific accuracy is not guaranteed. Please do not use this visualization for interstellar navigation._

<comment><USER9> If you are interested in scientifically accurate models in webgl, you may like this asteroid simulation, which models objects in our solar system in an astronomically accurate manner: <http://asterank.com/3d/>

<comment><USER10> that's a really cool simulator! what's the license for it? I can't find it on your github account.

</comment></comment></comment><comment><USER11> This is REALLY COOL!

Could someone explain how this is built or give an overview of how it works? In the 'about' page <http://www.chromeexperiments.com/detail/100000-stars/> it says WebGL and CSS3D, but I'm wondering how they fit together and what does what.

Is there a better way to view the source than just 'view source' in chrome?

I know a number of programming languages and I'd like to learn more about how this project works. [Saw the link to book on graphic programming in other comments below <http://www.arcsynthesis.org/gltut/index.html>, but how to "take apart and study" this project? ] Kudos to anyone who can point me in the right direction. Thanks!

<comment><USER12> <https://github.com/mrdoob/three.js/> \- That should get you going. Download that and take a look at all the examples and how they are made. Here is a good book on webgl too - [http://www.amazon.com/WebGL-Up-Running-Tony- Parisi/dp/144932...](http://www.amazon.com/WebGL-Up-Running-Tony- Parisi/dp/144932357X/)

<comment><USER11> Tanks Krsunny! Really helps to have some advice on what's current and where to start.

</comment></comment></comment><comment><USER13> Here is a great Youtube video showing the sizes of objects starting with the moon and working its way up to the largest known star. (Our Sun is a rounding error at that point!) <https://www.youtube.com/watch?v=HEheh1BH34Q> \- if youtube refuses to play because of audio try <https://www.youtube.com/watch?v=fKTu6B4Rgek>

Here is another one showing an animation of asteroids discovered in our solar system from 1980 to 2011. It starts off pretty tame, and by the end gets scary! <https://www.youtube.com/watch?v=ONUSP23cmAE>

</comment><comment><USER14> Amusingly for a "Chrome Experiment" it refuses to run on my chrome (Chrome 23 on Fedora 17 with Ivy Bridge graphics).

Firefox on the same machine works flawlessly.

</comment><comment><USER15> For those of you interested in the topic, the best publicly available database I've found is <http://www.astronexus.com/node/34>, and The Book for astronomical computation is Astronomical Algorithms, by Jean Meeus, <http://www.willbell.com/math/mc1.HTM>

(Shameless plug: I used both to implement the Common Lisp sky renderization engine for my startup, <http://greaterskies.com>, that makes pretty personalized posters out of thousands of stars)

</comment><comment><USER16> It's like the galaxy map in Frontier Elite II was, in my imagination.

<comment><USER17> This is exactly what I was thinking

</comment></comment><comment><USER18> On my MBP scrolling is backwards (swipe up moves closer), and mouse motion controls the camera offset angle. It's easy to write the code this way, but awkward and surprising during use. It's better to pretend that the hand manipulates the model, with a swipe up pushing it away and a swipe right turning the model counterclockwise around the vertical axis of the view.

<comment><USER19> Swiping up to move closer feels natural to me. Perhaps it is the other platforms that are wrong?

<comment><USER18> It would take a proper user interaction study to find out, but I don't think that I am wrong. Imagine a photograph on a table that you want to see better (make larger). Your natural motion is to touch and pull, which is dragging down.

<comment><USER20> Hold control on your MBP and scroll up. It zooms in.

command and '+' zooms text.

Scrolling down generally scrolls to the end of a page. Scrolling down here scrolls to the end of the galaxy.

Hold out your hand and make the "unpinch" gesture, which enlarges photos in iOS and Android. Which direction do your scrolling fingers move?

<comment><USER18> _Hold control on your MBP and scroll up. It zooms in._

This is a rare interaction, which is arguably backwards.

 _command and '+' zooms text. Scrolling down generally scrolls to the end of a page. Scrolling down here scrolls to the end of the galaxy._

Those are all logical, not physical mappings. They are not relevant here.

 _Hold out your hand and make the "unpinch" gesture, which enlarges photos in iOS and Android. Which direction do your scrolling fingers move?_

Left and right? You're seriously stretching to make your argument. People pull things towards them to get a better view. They push them away to see the bigger picture. Done.

<comment><USER20> You can't be serious. Put your hand to your monitor, and with your thumb and forefinger, unpinch. Your thumb and finger move left and right?

So my counterexamples are irrelevant, and you unpinch in a way nobody else does. Sounds like you just get off on being contrarian.

</comment></comment></comment></comment></comment></comment><comment><USER21> Absolutely amazing. By the way, it also works on Firefox. (Though performance isn't... _stellar_ )

<comment><USER22> FF 16.0.2 on Windows 7 64 here... it works smoothly, but that's no surprise, this machine is very powerful.

The page is so beautiful! Until now I've never felt the need to say this: wish I could upvote it more :-)

</comment></comment><comment><USER23> This is incredible, and with all the positional, magnitude, and spectral information publicly available, anyone could do it.

I would really love to see a search box that would allow me to jump to a specific star.

</comment><comment><USER24> MBP Chrome here, I see maybe 50 closest stars. When I zoom out, the stars in galaxy are just transparent squares. Doesn't look like [http://shanearmstrong.co.uk/content/cdn/the_beauty_of_the_co...](http://shanearmstrong.co.uk/content/cdn/the_beauty_of_the_cosmos.png) or [http://www.chromeexperiments.com/detail/100000-stars/img/ahZ...](http://www.chromeexperiments.com/detail/100000-stars/img/ahZzfmNocm9tZXhwZXJpbWVudHMtaHJkchgLEg9FeHBlcmltZW50SW1hZ2UY27DmBQw/large)

<comment><USER25> Same, on a Mac Mini.

</comment></comment><comment><USER26> 67:2 [He] who created death and life to test you [as to] which of you is best in deed - and He is the Exalted in Might, the Forgiving -

67:3 [And] who created seven heavens in layers. You do not see in the creation of the Most Merciful any inconsistency. So return [your] vision [to the sky]; do you see any breaks?

67:4 Then return [your] vision twice again. [Your] vision will return to you humbled while it is fatigued.

</comment><comment><USER27> Nothing interesting to add except it was an enjoyable way to start the day, thanks. Always good to have something remind you how insignificant you are! The music was great too

edit: loaded it in chrome instead, even better (should have been obvious given it's located on chromeexperiments.com)

</comment><comment><USER28> I need to learn 3D graphics for some of my scientific projects. Specifically, I want to rotate clouds of points just as shown here. I have no idea where to start with doing this, however. Can somebody point me to a good tutorial or other resource in 3D graphics?

<comment><USER29> I don't know of a good one, so I'll write one here. This focuses on how things work, rather than how to use existing APIs, because I've basically never used GL. What's below is short and doesn't have much math, but it should be enough to allow someone who knows linear algebra and 2-D graphics to both understand and rederive most of 3D graphics.

To rotate a point cloud, you multiply each point by a rotation matrix to get the rotated point. A rotation matrix that rotates around the X-axis looks like

        [[1  0  0]
         [0  c  s]
         [0 -s  c]]

where s and c are the sin and cos of the angle you want to rotate. Then you can do an orthographic projection by just dropping the Z coordinate, leaving just X and Y coordinates (which you may need to scale to your screen), or a perspective projection by dividing X and Y by Z. (Be wary of division by zero.)

The usual approach is to maintain the original points unrotated and make a rotated copy of them for every frame, instead of overwriting them with a rotated version every frame, so that numerical errors don't accumulate and you can get away with single-precision floating-point. Also, conventionally, positive Z coordinates are in front of the camera and negative Z coordinates are behind it.

If the above isn't sufficiently clear, there's some code I wrote to generate an ASCII-art animation of a perspective-projected point cloud (the corners of a cube) at [http://lists.canonical.org/pipermail/kragen- hacks/2012-April...](http://lists.canonical.org/pipermail/kragen- hacks/2012-April/000540.html). It's 15 lines of code and the only library it depends on are Python's functions to sleep for a fraction of a second, output stuff to stdout, and round to integer.

EXTRAS:

DISTANCE: For things that aren't points, you might be interested in how far away they are from the camera, too, like to scale them or figure out which ones are in front. That's the Z-coordinate after you rotate into camera space.

TRANSFORM COMPOSITION: If you want to rotate around two axes, it's probably better to multiply the two rotation matrices together, then multiply each point by the resulting transformation matrix, rather than doing two matrix multiplies for each point. You can also scale camera space to screen coordinates this way.

TRANSLATION: If you want to move the camera, you probably want to translate your points so the camera is at the origin before rotating them. If you represent your transformations as 4x4 matrices, with a possibly implicit fourth element in each point vector that is 1, you can represent translation in your transformation matrices too.

MULTIPLE SEPARATELY MOVING OBJECTS: A point cloud is a single rigid object. But whether you're drawing point clouds or something more complicated, it's often interesting to be able to move multiple objects separately. The usual way is to go from two coordinate systems, camera and world, to N: camera, world, and one for each object. Each object has a transformation matrix that maps its object space into world space. You move the object by changing its transformation matrix.

POLYGONS: If you're drawing polygons, straight lines are still straight lines when you rotate them, and in either perspective or orthographic projections, so you can just rotate and project the corners of the polygons into your canvas space, and then connect them with 2-D straight lines (or fill the resulting 2-D triangle).

FLAT SHADING: The color resulting from ordinary illumination ("diffuse reflection") is the underlying color of the polygon, multiplied by the cosine of the angle between the normal (perpendicular) to the surface and the direction of illumination; it's easiest to compute that cosine by taking a dot-product between two unit vectors, and to compute the normal by normalizing a cross-product between two of the sides. If you have more than one lighting source, add together the colors generated by each lighting source. You probably want to treat negative cosines as zero, or you'll get negative lighting when faces are illuminated from behind.

BACKFACE REMOVAL: if you're drawing a single convex object made of polygons, you can do correct hidden surface removal just by not drawing polygons whose normal points away from the camera (has a positive Z component). This is a useful optimization even if your object is more complicated, because it halves the load on the heavier-weight algorithms below.

HIDDEN SURFACE REMOVAL: If your polygons don't intersect, or only intersect at their edges, you can use the "painter's algorithm" to get correctly displayed hidden surfaces by just drawing them in order from the furthest to the closest; if they do intersect, you can either cut them up so they don't intersect any more, or you can use a "Z buffer" which tells you which object is closest to the camera at each pixel --- as you draw your things, you check the Z buffer to see what's the currently closest Z coordinate at each pixel you're drawing, and if the relevant point on that object has a lower Z coordinate, you update that pixel in both the Z buffer and the canvas.

SMOOTH SHADING: you can get apparently smooth surfaces out of quite rough polygon grids by storing a separate surface normal at each vertex, and then instead of coloring the whole polygon a single flat color, interpolate. You can either compute the colors at the corners of the polygons and interpolate the colors at each point you draw (Gouraud shading) or you can interpolate the normals and redo the lighting calculation for each point (Phong shading), which gives you dramatically better results if you have specular highlights.

SPECULAR HIGHLIGHTS: The diffuse-illumination calculation explained in "FLAT SHADING" above is sufficient for things that aren't shiny at all. For things that are somewhat shiny, you want "specular highlights", and the usual way to do those is to do the lighting calculation a second time, but instead of directly using the cosine of the angle between the light source direction and the surface normal, you take that cosine to some power (called the "shininess" or "Phong exponent") first. The 5th power is pretty shiny.

FOG: Faraway things fade exponentially. That is, you take the density of the fog (a fraction slightly less than 1) to the power of the Z coordinate of the point on the object, and multiply that by the color of the object.

TEXTURE MAPPING: If you want your surfaces not to be a single solid color, you can use a raster image (called a "texture") to map colors onto the surface. You just figure out where you are on the surface (by doing a matrix multiply from your surface point into "texture space") and figure out which texture pixel ("texel") you're at, or which ones you should interpolate between. (You can also use some other function to generate the color, rather than having an explicitly stored texture. The important thing is that it maps a 3-D point in object space to a color.) This is the start of the whole universe of "shaders", which represents a big part of current 3-D work. Another application of shaders is bump mapping:

BUMP MAPPING: If you're doing Phong shading, you can get apparent texture (in the usual sense: something you could feel if you could touch the object) on your surfaces without having to transform more points by simply perturbing the interpolated surface normals you're using to do your shading calculations. It's helpful if you perturb them in a deterministic way so that the texture moves with the surface.

<comment><USER30> Wow, thanks for posting this!

<comment><USER29> Sure, I hope it's helpful!

</comment></comment></comment></comment><comment><USER31> I wonder if there are clusters where distance between neighbouring stars are much less than with Sun and Proxima Centauri. Would these locations provide better opportunities for space faring civilizations to reach other star systems?

<comment><USER32> I'm no expert but I think the answer is "No", due to other problems.

Distances are closer in Globular Clusters. Alas, those are "metal poor", so the only planets are gas giants like Jupiter.

Distances are closer in Open Galactic Clusters like the Pleiades. Unfortunately those cluster tend to disperse. By the time a space faring civilization has evolved, the stars are no longer close.

Distances are closer in the Galactic Core. Unfortunately that is a high radiation environment due to Sagitarius A* (the mega-black hole at the center of the galaxy_ and all the nebulae the hole is dragging in.

Short answer: places where the distance between stars is closer are unlikely to have space faring civilizations.

Of course there is always Zeta Reticuli A and B.

</comment></comment><comment><USER33> Eventually crashed Safari on my rMBP, but this seems to be a trend, so possibly Safari's fault (and would explain why WebGL is not enabled by default).

In any case, great visualisation. Would be a perfect use for a 3D monitor.

</comment><comment><USER34> As cool as this is, if you have an iPad check out Star Walk. It's really really cool, and if you hold your iPad up to the sky it'd show you what the sky would look like if there isn't any pollutions.

</comment><comment><USER35> Awesome! The only issue is that the visualization makes it look like we are in a cluster of stars. That is not correct. We're part of the diffuse field star population in the Milky Way.

</comment><comment><USER36> I love the way they made the stars - from close a sun actually looks like a pile of hot, glowing, boiling gas, and not like cold orange sphere you can see pretty much everywhere else.

</comment><comment><USER37> If your interested in simulating the physics of the universe checkout Universe Sandbox <http://universesandbox.com/>

</comment><comment><USER38> Was I the only one really hoping for "Reticulating Splines"?

<comment><USER39> I see I'm not the only one here who was reminded of Spore when they saw this...

</comment></comment><comment><USER40> I am on rMBP and it hardlocked Chrome after I navigated towards the sun and clicked the information button about the sun. Worked fine until then, really cool.

</comment><comment><USER41> OMG, someone pinch me, nexus 10 was born for this :)

</comment><comment><USER42> Wow, this is great. Reminds me of Mass Effect and its presentation of planets and their descriptions. At least this stuff is real! :)

</comment><comment><USER43> Small typo: should be "farthest man-made object" instead of "furthest." Otherwise, awesome job.

</comment><comment><USER44> Beautiful. Someone needs to make a turn-based strategy game out of this visualization.

</comment><comment><USER45> This is amazing. Now to figure out how to make this my desktop background...

</comment><comment><USER46> that is very cool. How was the glow crated using CSS3 for the Sun?

<comment><USER47> this is all canvas and webgl, no css

<comment><USER48> Not that I've actually checked the code yet, but the project page states "CSS3D" as one of the technologies used.

<http://www.chromeexperiments.com/detail/100000-stars/>

</comment></comment></comment><comment><USER49> Aaaaaaaaaand chrome mobile fails once again. What's the point of chrome mobile if it's never updated? The stock aosp browser has seen more updates than Google's own browser. The only feature of this god damn browser is idiocy. /rage

</comment><comment><USER50> wow, awesome visualization.

I always wondered how scientist determine the position of earth in our galaxy and the center of the galaxy. can somebody throw some light on this ???

</comment><comment><USER51> This is what EVE Online's map ought to look like. :)

Works fine in Safari.

</comment><comment><USER52> a. this is so beautiful and well done... what we've come to expect of Chrome Experiments.

b. If you haven't already, Toggle the spectral index... so sick

</comment><comment><USER53> That is incredible, wasn't expecting much.

</comment><comment><USER54> What was this optimized with? Closure?

</comment><comment><USER55> It's a small world after all.

</comment><comment><USER46> slow as hell while loading up but in the end worth it

</comment><comment><USER56> "There's a lot of space out there to get lost in."

</comment><comment><USER57> Thumbs up!!!!

</comment><comment><USER58> I have my first child coming in a couple weeks and this is the type of stuff that I'm going to love showing she or he.

Awesome

</comment><comment><USER59> Who made that music? And do they make more from where that came from?

<comment><AUTHOR> Music by Sam Hulick, whose work you may have heard in the video game, Mass Effect. The track is titled "In a Strange Land" and is used with his permission.

<comment><USER60> Ya. This would have been perfect: <http://www.youtube.com/watch?v=BwJtYfF72Io>

</comment></comment></comment><comment><USER61> Unfortunately, it looks wonky as hell on Chrome for Mac.

Edit: I'm sorry for my misleading and value-free comment. Allow me to clarify: THIS EXPERIMENT LOOKS LIKE HOT BROKEN GARBAGE ON CHROME FOR MAC, A FACT WHICH MAY BE OF INTEREST TO PERHAPS HALF OF THE HACKER NEWS READERSHIP WHO WILL MOST LIKELY EXPERIENCE THE SAME VISUAL CORRUPTION AT VARIOUS VIEW LEVELS. SOME MAY VIEW THIS AS UNFORTUNATE, AS THE INTENDED EXPERIENCE IS A WORTHY ONE THAT EXERCISES A NUMBER OF CUTTING EDGE WEB PRESENTATION TECHNIQUES THAT ARE LIKELY TO GAIN SIGNIFICANT TRACTION IN THE NEAR FUTURE.

<comment><USER62> I'm guessing for your edit that you feel you're being downvoted for a negative comment about a cool demo. However, you're being downvoted for not giving any actionable information, or even a screenshot; you're not making it possible for the author to make the project better, you're just making a valueless comment (and making it worse with your edit).

<comment><USER61> TinyGrab is down again, I have a headache, etc. And I felt this thread is a bit more interesting with an hand-crafted ALL-CAPS punching bag. :)

Ever at your service! -JPXXX</comment></comment></comment>


Visualization of tweets during Champions League final - <AUTHOR> http://cartodb.github.io/lisbon-2014/#/4/44.62/10.77/75

<comment><USER2> Clearly noone tweets from Germany, or none activate the location

<comment><USER3> That is probably because Twitter is not really popular in Germany. Looking at the numbers [1] I am still surprised because I would have expected something even lower not knowing a single active Twitter user personally.

[1] [http://www.ibtimes.com/twitter-usage-statistics-which- countr...](http://www.ibtimes.com/twitter-usage-statistics-which-country-has- most-active-twitter-population-1474852)

<comment><USER4> If you think about it, there's not a lot you can say in German in 140 characters.

<comment><USER5> I'm aware that German translations of English sentences are about 30% longer, but by that logic Twitter should only be popular in countries with logographic or ideographic writing systems like Twitter is in Japan. jatorre's assumption that location is deactivated seems to be an appropriate explanation.

</comment></comment></comment></comment><comment><USER6> Love that we see some tweets from some pretty remote places in Africa - Botwana, Zambia and Malawi. Mobile phones have some pretty big penetration there, but internet connection is still not too strong (texting is far bigger).

</comment><comment><USER7> Very cool. Does this use an open source map library?

<comment><USER8> CartoDB[1] allows you to put your data on top of rich base layers. Use Mapbox or any other basemap provider. You can even create maps without a background.

Their Javascript library code is on Github[2], and they encourage people to collaborate. But it doesn't seem to have a license, I couldn't find one in the repo.

[1] [http://cartodb.com/](http://cartodb.com/)

[2] [https://github.com/CartoDB/cartodb.js](https://github.com/CartoDB/cartodb.js)

<comment><USER9> Just to complete your comment, the animation layer is done with torque.js:

[https://github.com/cartodb/torque](https://github.com/cartodb/torque)

</comment></comment></comment><comment><USER10> would love to see this for the world cup.

</comment><comment><USER11> Awesome to see Turkey showing up big on this map, had no clue that the sport was so popular there.

<comment><USER12> That might be due to the fact that one of the most effective players of Atletico Madrid, Arda Turan [0], is Turkish.

Although he was injured and missed the match.

[0] [http://en.wikipedia.org/wiki/Arda_Turan](http://en.wikipedia.org/wiki/Arda_Turan)

<comment><USER13> might also be due to the fact that Turks are simply - really mad about soccer :)! I lived couple years in Istanbul, and was amazed by how Turks are obsessed with soccer overall.

<comment><USER14> It seems odd that a country of that size with a huge love for the sport, misses so many of the final stages of the World Cup / European championship.

<comment><USER15> "Soccernomics" author predicted Turkey becoming much better at soccer competitions for those and other reasons, it hasn't materialized yet though.

</comment></comment></comment></comment></comment><comment><USER16> I thought this was about League of Legends.</comment>


How Sanctions Helped Iranian Startups Thrive - <AUTHOR> http://techrasa.com/2015/06/24/how-sanctions-helped-iranian-startups-thrive/

<comment><USER2> Some say that Free Trade is really a tool of oppression. Third world countries can never develop their own industry because they cannot compete because they will never get over the Ricardian hump where their products will always be inferior or more expensive.

All they can look forward to is low margin agriculture and exploitative "offshore" manufacturing.

The solution would be self imposed sanctions aka trade tarrifs but the IMF and WTO will punish you for trying.

[http://www.freetradedoesntwork.com/](http://www.freetradedoesntwork.com/)

<comment><AUTHOR> I should disagree. In some cases you are right like high tech stuff but in other cases that don't need that kind of tech like online retailing, mobile apps and games and generally internet based services they could grow.</comment></comment>


The New York City Subway Is Beyond Repair - <AUTHOR> https://www.theatlantic.com/technology/archive/2018/06/the-new-york-city-subway-is-beyond-repair/562472/?single_page=true <comment><USER2> Whoever wrote this either doesn't live in NYC or has somehow miraculously avoided riding the subway while living there. This is nonsense. There is absolutely no way a fleet of autonomous vehicles could replace the sheer volume of passengers that the subway handles. An autonomous car can fit maybe 6 people who all would need to load and disembark. Also, good luck finding 6 people going from one station to the same destination station easily. Finally, let's just ignore "The stations would have to be redesigned, outfitted with little entrance and exit ramps" because, yeah, subway construction is trivial.</comment>


Gene Simmons to sue the pants off Anonymous - <AUTHOR> http://www.geek.com/articles/news/gene-simmons-to-sue-the-pants-off-anonymous-20111214/

<comment><USER2> Simmons has shown a remarkable endurance for public displays of hubris (sometimes successfully, at least in terms of his own aims).

Maybe he will make an 'example' of the one fellow they arrested, but the possibility of less amateur reprisals from others seems to be just around the corner. Not because it's inherently the right response, but because Simmons makes such a goading spectacle of it.

I'm sincerely curious to see whether this kind of dies off on the awareness radar or if it has recurring flareups over the next few cycles.</comment>


Excel team considering Python as scripting language: asking for feedback - <AUTHOR> Folks, Microsoft is officially considering providing Python support in Excel (finally).  If you are interested in this, please visit their uservoice page and let them know what you think. Thank you!<p>https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/10549005-python-as-an-excel-scripting-language <comment><USER2> Much as i would love for the power of Python in Excel it is important that whatever is done is consistent across the office experience. Some of us old enough to remember the multiple versions of VB-whatever across Excel, Word, Access and that in itself was a blow to productivity.

Yes they should choose Python, and in the process decide if it will be Python with a .Net library (standard and core as seperate libs please!) or IronPython. This in itself is an important first choice.

Then it has to be done in a mechanism that enables the exact same libs and user written python code to work in the same way across all the Office products.

Other languages have been suggested, all good choices with their own merits. Lua is a good chocie for compactness and speed. C# is lingua franca of commercial developers so would suit ISVs but i think too heavy for end user scripting. Nim or even freepascal maybe? Lastly whatabout just using VB.net consistently? VB is a great language for newbs and casual/adhoc programmers .... but it gets ignored because of problems with consistency of implementation by MS.

Last point i would like to make is IMHO the choice needs to be based on: \- ability to transpile to javascript so that Excel365 can be scripted from webapps \- install-free deployment; should be built into Excel in a way it can be used without any user install for dev or runtime \- standard vanilla language, not a variant

Disclaimer: A huge fan and long time user of python here. I also spent largest part of working life in ISV world rather than end user land.

<comment><USER3> > VB is a great language for newbs and casual/adhoc programmers

Is it, though? For example, VB puts four different ways of passing arguments right in your face: values by reference, values by value, object references by reference and objects references by value. Python only has the last one and doesn't make you think about it.

And without "Option Explicit" VB does something very unhelpful (also seen in PHP): misspelled variables are created _on read_ and silently converted to the required type, giving you nonsense results. (With "Option Explicit" enabled it gets verbose and tedious instead.)

<comment><USER4> I'd say what Python does is passing object references by value.

<comment><USER3> Right. I listed them in the wrong order and wasn't quick enough with my edit. :)

</comment></comment></comment></comment><comment><USER5> Dear Excel team,

Take a look at the top three results for "excel python" on bing.com for some great ideas on how to incorporate python into excel.

\---

1.) [https://www.python-excel.org](https://www.python-excel.org)

2.) [https://www.pyxll.com/](https://www.pyxll.com/)

3.) [https://www.xlwings.org/](https://www.xlwings.org/)

<comment><USER6> There is also pyspread as a full spreadsheet implementation using and for Python: [https://manns.github.io/pyspread/](https://manns.github.io/pyspread/)

<comment><USER7> > _Pyspread expects Python expressions in its grid cells, which makes a > spreadsheet specific language obsolete. Each cell returns a Python object > that can be accessed from other cells. These objects can represent anything > including lists or matrices._

Huh, on the one hand sounds like a such a simple way to deal with it that I can have trouble imagining a more elegant approach.

On the other hand, does it still respect the ways that Excel updates cells? Sicne that kind of requires immutability I think.

</comment></comment></comment><comment><AUTHOR> Clickable Link:

[https://excel.uservoice.com/forums/304921-excel-for- windows-...](https://excel.uservoice.com/forums/304921-excel-for-windows- desktop-application/suggestions/10549005-python-as-an-excel-scripting- language)

[disclaimer+bias: on Python team @ msft & would love to see this happen!]

<comment><USER8> So what's the strategy here re: security? I assume it'd be a fairly stripped- down version of Python ... or will you just design the UI to say "you probably shouldn't execute files from people you don't know" etc?

<comment><USER9> From a security point of view how is embedding python different from embedding Visual Basic? This is not my area of expertise so I'm genuinely curious.

<comment><USER10> Potentially different. .NET allows signed binaries / libs / a fully signed execution context, Python has nothing equivalent AFAIK.

<comment><USER11> Excel VBA is not .Net though. It's plain old VB code in text files inside the .xlsx, and you just have to trust it (or not).

<comment><USER10> Aaah. Then probably about the same, yea :) Maybe less of a nightmare around dependencies than the pip world...?

</comment></comment></comment></comment></comment></comment><comment><USER12> Imagine all of those simple tasks that you could do in seconds with a python script. Export to csv in UTF-8 with double quoted fields. Loop through cells

      for row in rows:
         do some cool stuff

Pull data from a REST API using requests rather than some VBA hack. I'm getting over excited already. Edit data for your ERP and then post it back to the API and update the db... This is exactly what finance/data people want. Write custom functions (with numpy maths!)! No more nested If's. This will keep Excel as the premium spreadsheet app. I love it

<comment><USER13> I already find myself reaching for Google Sheets quite frequently just to do this. I'd love to be able to use Python instead of JavaScript.

</comment></comment><comment><USER14> Does Excel have a "plugin framework" for new languages the way Jupyter does? Ideally _any_ language (Python/Julia/R/whatever) can be added by a third party without Microsoft's direct involvement.

The plugin authors would only need to map a language or library's DataFrame mechanics to Excel's table layout. (Microsoft could even use Apache Arrow to represent the data.)

I imagine there would be lots of possibilities by providing "hooks" for language designers to connect to.

<comment><USER15> You can pretty much already do what you want with VSTO or XLLs. However having a standard scripting language installed on everyone's machine is a all different thing. It means you can add some scripted logic in your spreadsheet, give it to someone else, and know it will run without having to install or maintain anything.

<comment><USER16> This is incredibly important. When I worked at BigFinCorp, we always used vanilla Excel (VBA and ODBC to RDBMSs). So our sheets would always "just work".

Python would be great in this role, but to avoid separate configuration, you'd need to ship the runtime with the spreadsheet, right?

Or would this new Excel capability be built on .NET? In that case, C# (for the enterprise folks) and F# (for the bleeding edgers) would be fun, too.

Bottom line, the Developer mode of Excel should support more than VBA.

</comment></comment></comment><comment><USER17> I'd vote for Lua: faster and less heavy than Python... Plus my biggest concern for Python would be how well the team can sandbox it. I know in this regard Lua also has advantages. Disclaimer: I am _way_ more proficient in Python than Lua, I just think Lua is a better choice.

<comment><USER12> Does Lua have anything like Numpy or Scikit-learn?

<comment><USER18> Yes, it has Torch.

<comment><USER19> Pandas?

<comment><USER18> [https://github.com/AlexMili/torch- dataframe](https://github.com/AlexMili/torch-dataframe)

</comment></comment></comment></comment></comment><comment><USER15> Might be worth reminding everyone of a dead Microsoft project called VSTA, which was basically a live .net IDE embedded in Office. Effectively a mini visual studio inside any office application, where you can write any .net language. This would have allowed people to script in VB.net, C# or F#. Microsoft killed the project before it shipped (but licensed VSTA as a scripting tool for third party apps for a while). It's a pitty. I think this would have been a better solution than python.

<comment><AUTHOR> Good point that the tooling would've been awesome. However, I don't think .net would have spawned the rich ecosystem of Python pkgs that we enjoy today. And /that/ is a huge part of the whole Python value prop. From astronomy to finance to bioinformatics to ML & everything in between, there's a pkg for that. We even did sponsored a port of numpy+scipy to .Net (via Anaconda). At the end of the day, there were just too many corner cases & too many pkgs to port for it to make sense.

</comment></comment><comment><USER15> What is interesting is also the implications of them now considering python.

First if it is python, it is not javascript, which seemed to have been their previous favorite candidate until now (not sure if it really picked up).

Second, the writing on the wall for VB as a language starts to look like a time square billboard. They basically put VB.net in maintenance / compatibility mode like webforms and winforms. I think it is clear that a new scripting language would be meant to ultimately replace VBA (which has been on maintenance / compatibility mode for 20 years!).

<comment><USER20> excel already supports javascript for custom functions, add-ins, etc

<comment><USER15> I wasn't aware one could do UDF with javascript. Thought it was for addins only.

</comment></comment></comment><comment><USER21> VBA's one saving grace is that it's been available on every company computer I've ever used. Alt+F11 and I have an IDE. It's probably responsible for getting a few people involved in programming.

But it had some serious limitations and some unexpected behavior compared to "real" programming languages. I hope that adding Python to Excel can be my new "guaranteed to be there" language on coworker's computers and get even more people involved in programming.

</comment><comment><USER22> So when I google how to do something in Python I will have to comb through solutions specific to v2, v3 and now also Excel? ;)

Aside from that it sounds like a cool idea.

</comment><comment><USER23> I've probably mentioned this before on another news article. Not like it really matters. Python is nice as a beginner scripting language since it's (to my own judgement) the most easily readable language to its function set.

When working with software like office, you are going to have a lot of users that don't exactly spend their days programming, or studying syntax. Excel is a little different in their own regard. The functions system has a lot of depth to it, and makes sense to a cell system, but for some it can be a but overwhelming in terms of how its written, since everything has to be written exactly as a function. I guess you also have generic office macros, haven't used them since high school.

In saying that, could this somehow be a reason why the office team have decided on a python interpreter, instead of say JavaScript or Microsoft's work on Typescript. Because python is easy to write, fast to learn, therefore users or even really employees in large data management positions don't have to worry about their time input?

</comment><comment><USER24> I use PANDAS in Jupyter Notebooks a lot. Sometimes, exploring large data frames can get tedious and I find myself loading up excel to explore and browse around, usually when deciding how to normalize or clean things up. Using Excel as a PANDAS Gui this way would be really great, but also using Python to script excel would be useful. And I guess I would love to call bokeh / seaborn after making an excel cell selection.

I am looking forward to what a Python & Excel marriage will look like.

</comment><comment><USER25> This post suddenly reminded me of Resolver Systems, who made a Python/.Net spreadsheet back in the '00s:

[http://www.prweb.com/releases/spreadsheet/competition/prweb1...](http://www.prweb.com/releases/spreadsheet/competition/prweb1826304.htm)

I thought it was a good idea at the time, especially after having read "A Small Matter of Programming" which makes the case that spreadsheets are one of the very few successful end-user programming systems (the other being CAD):

[https://mitpress.mit.edu/books/small-matter- programming](https://mitpress.mit.edu/books/small-matter-programming)

</comment><comment><USER26> Port it as a plug in to old versions of excel as first class citizens on release.

There's been far too much, "here's a feature people will use so you're going to have to pay us yet again to open spreadsheets" in the history of excel. It's shit. It's awful. Don't do it. Using rich customers desires to extract money from those who neither need nor want the new feature is a crook's game. If microsoft aren't evil don't do it.

</comment><comment><USER27> This would be great but it's a bit surprising given the move to add support for R in SQL server, Power BI, etc...

<comment><USER28> Yes I agree.

</comment></comment><comment><USER29> I made a prototype programming environment that is more like a spreadsheet interface into Python called Flowsheets that y'all might be interested in: [https://www.youtube.com/watch?v=y1Ca5czOY7Q](https://www.youtube.com/watch?v=y1Ca5czOY7Q)

Flowsheets has become my preferred data manipulation environment.

</comment><comment><USER30> My biggest issue hasn't been VBA but the poor documentation of the Excel (Office) object model and the weird way of accessing cells and cell ranges.

Would this get better in Python? I hope so.

</comment><comment><USER31> OK, I'll be honest. I usually avoid excel, except for excel to csv conversion. Then I write a python3 script starting with `import csv`.

This would make the product actually useful for me. VB is terrible. I don't even want to think about it. JS is a language I put up with when I have to work in a browser. Python is a joy to use especially in situations like this.

I can't tell you how many little apps I've had to write against CSV dumps from some stupid proprietary app without an API for Infosec or Capacity Planning or whatever that is essentially a report. I would do this instead in a heartbeat to avoid maintaining a service that gets used weekly/monthly/whatever.

</comment><comment><USER32> I'm actually more concerned with good tools for working with code than the language, but Python would be an improvement over VBA, and conceptually allow them to use Python tooling they've developed for other uses in Office.

</comment><comment><USER33> here's my feedback: embed sqlite in it and you're done. Nobody needs any more servers, you can literally replace a hundred thousand dollar "big data" center and team of PhD data scientists with a business school dropout. And you will get prettier, more actionable results.

<comment><USER34> Can everyone read this and vote this up in the survey? This is the real LPT.

</comment></comment><comment><USER35> This would be awesome! I've built some tools using VBA and found it to be the most painfully unpleasant programming language I've ever used. Python is by contrast the most pleasant!

</comment><comment><USER36> No love for C#? Imagine the power of LINQ in Excel.

<comment><USER37> For C# and LINQ in Excel there is my ESharper add-in [https://vlasovstudio.com/esharper/](https://vlasovstudio.com/esharper/)

</comment></comment><comment><USER38> Unless the Excel team somehow integrates Python with the existing GUI design tool already found in Excel, it wouldn't bring anything new to the table. There are already existing solutions such as DataNitro, which allow to code Python macros and functions and make use of Numpy, Pandas and Matplotlib. Microsoft is so far behind the curve it's not funny. Their integration of either Python or IronPython in Visual Studio has been a mess for years.

See Http://www.datanitro.com

</comment><comment><USER39> It would be great for a scripting language, but for field functions I would have preferred something that's more akin to FRP-oriented language (e.g. Scheme).

<comment><USER7> Excel itself is functional and reactive already, wouldn't adding an FRP language on top of that be a bit superfluous? Check out Felienne Hermans' work if you haven't already:

[https://www.youtube.com/watch?v=0yKf8TrLUOw](https://www.youtube.com/watch?v=0yKf8TrLUOw)

[http://www.felienne.com/publications](http://www.felienne.com/publications)

<comment><USER39> Excel is reactive already, but its field functions can't have variable bindings or procedural operation as far as I know (unless, of course, you write your own separate VBA function). I sometimes want to write in a complex one-liner and thought lisp/scheme would be a great choice.

<comment><USER7> Ah, fair enough. I mean, I'm not debating the power of Lisp, and it would be great first languages for someone not trained in programming. OTOH, there is of course the trade-off to make it as useful for as broad a selection of users as possible; Python has a lot more mind-share, and the SciPy ecosystem would be a great complement.

If Excel adds some practical convenience functions to the global namespace, would it be that hard to make Python fit the reactive paradigm in this context?

About those variables: maybe the Bumblebee tool she and her team made[0][1][2] would work for you

        Our language is an extension of regular Excel formulas,
    	 so you can write a transformation like

        A1+A2 <-> SUM(A1:A2)

        which allows BumbleBee to transform exactly the formula
    	 A1+A2 to SUM(A1:A2) or vice versa.

    	 In addition to using exact cell references, you may also
    	 use variables instead of cell references:

        {i,j} + {i,j+1} <-> SUM({i,j}:{i,j+1})

I hope it can be useful to you! :)

In the video I linked before she mentions it at 31m33s. Oh and here[3] are the slides for that video, in case you prefer those.

(Disclaimer: I don't use Excel myself; I'm just a programmer who wants to get more people into programming, so I was both happy and impressed when I saw her presentation on how people not trained as programmers use it to do really complex tasks)

[0] [http://www.felienne.com/BumbleBee](http://www.felienne.com/BumbleBee)

[1] [http://www.felienne.com/archives/2964](http://www.felienne.com/archives/2964)

[2] [https://figshare.com/articles/BumbleBee_A_Transformation_Env...](https://figshare.com/articles/BumbleBee_A_Transformation_Environment_for_Spreadsheet_Formulas/813347) Paper on BumbleBee

[3] [http://gotocon.com/dl/goto- amsterdam-2016/slides/FelienneHer...](http://gotocon.com/dl/goto- amsterdam-2016/slides/FelienneHermans_PureFunctionalProgrammingInExcel.pdf)

</comment></comment></comment></comment><comment><USER40> 1) performance, including multi-sheet setups, should be better than the current Macros.

For maintainability reasons, in one personal experience, I moved in-cell macros to VBA, and saw significant degradation in performance (my excel was calculating financial instrument attributes, based on raw input data (store in separate workbook with the same sheet)).

So my ask would be that Python-based scripting would not just be the same as VBA in speed, but faster than in-cell macros.

2) There needs to be easy-to-use capability, to be able create XLS files with the new language macros, from within other programs. So that the new Python modules can be written out together with data from within other programming languages (and MS-supported libraries to replace or augment something like openpyxl, and similar libs for other langauages will be much welcomed)

3) I think Python as a choice for Excel is a good idea. It should be a language with 'duck typing', and that has support for Data Frames, Reactive programming. And in that light, I would like to see that Python's Pandas are first class citizens in being able to address Excel cells, participate in graphing, pivoting, etc.

4) Version control within the excel file... may be this is going beyond the original ask... but I think the spirit of introducing Python into excel, is around better SDLC/reusability. And so local and remote version control models should be supported.

5) I personally do not care if other MS Office tools (eg MS word) support Python. Would be nice.. but for my needs, this is not relevant.

6) a type-checking mode to be able to say, this Module will type check the data it uses... at run time.

</comment><comment><USER41> An absolute no-brainer. Python is the new BASIC - very popular with people who have to program to do their work but aren't programmers. It's an excellent choice for a spreadsheet.

<comment><USER42> >aren't programmers

Also extremely popular with people who _are_ programmers and need to do things.

Sorry, this is a frustration of mine lately. Python is a _fantastic_ introductory language. It's also a _fantastic_ general purpose language.

Newbies get turned off of it because it feels too easy, and they know that "real" programming is supposed to be hard.

<comment><USER43> I disagree.

Python is great for scripting and for small projects, but I believe strong, static typing is an essential feature for large scale projects. I wouldn't want to use Python for anything that's predicted to end up with more than a couple thousand lines of code.

<comment><USER44> Last time I saw the Bank of America python codebase, it had ~6 million lines of code, was worked on by about 4,000 developers, and ran some core, performance critical functionality.

Python programming is an aesthetic that needs learning. Many of the worst written, and least maintainable python codebases I've seen are by programmers/teams coming from "proper" languages and don't think they have to learn how to write idiomatic python.

<comment><USER45> A bit dated now, but still a great read about a Python project done by Java developers: [http://dirtsimple.org/2004/12/python-is-not- java.html](http://dirtsimple.org/2004/12/python-is-not-java.html)

"So, the sad thing is that these poor folks worked much, much harder than they needed to, in order to produce much more code than they needed to write, that then performs much more slowly than the equivalent idiomatic Python would."

<comment><USER44> Yeah, I've seen that story played out so many times.

Best example I've seen was from a couple of Java devs transitioning to python, they re-wrote a system 3 times: 1st time: 35k loc 2nd time: 10k 3rd: 2k

The third rewrite was also significantly faster than the first two :)

</comment></comment></comment></comment></comment></comment><comment><USER46> Glad to hear that the Excel team is finally listening to your requests on this one. It's been a long time coming. Too bad they weren't interested during the TC days. If it does happen, it would be great if you could get the Cloud Numerics effort rebooted as well. There might still be a few people from our old team at NERD capable of resurrecting it.

</comment><comment><USER47> I would love this, but for a unique use case: we generate _a lot_ of workbooks using Python. Some of them have hundreds of thousands of automatically generated formulas. We also have to write tests for workbooks. If we could embed Python, which all of our developers know, into Excel, it would make testing our formulas a bliss, rather than the burden it is today.

</comment><comment><USER48> Excel already has VBA, C add-ins, COM interop, VSTO, javascript addins, and random functionality that's only available by using functions left over from Excel 5.0 macros (before VBA). These all have different weird limitations.

What Excel absolutely does not need is for Microsoft to add another scripting language in a half-assed fashion and then get bored and stop again.

</comment><comment><USER49> Is anyone using javascript to write excel macros?

That functionality has been out but a while right?

Do people use it? What do they use it for? What makes them step back and reach for pandas or salesforce instead?

For me, working across multiple excel files sucks right now. Excels handling of datatypes kind of sucks. And pretty spreadsheets that people like looking at and working with have a bunch of annotation in them so you end up extracting the sub tables you need anyway - why not into csv/dataframes.

Tableu makes a lot of this better. Why not copy them instead of giving us another language to cheer about then ignore.

Why not integrate power bi more tightly with Excel and ship it in the basic version of office, then let us script in there?

</comment><comment><USER50> There are now plenty of Python modules for working with Excel and Excel format files. Why are they trying to compete with those? As a university teacher I have dropped the use of Excel from my classes. I'm really not convinced this would convince me to go back. The philosophy of the product is just wrong. The should probably consider retiring Excel itself while maintaining support for Excel file formats. If they were to get behind some of the existing Python module initiatives or do something similar this would not be bad either, but using Excel as a front-end to Python is just a bad idea.

<comment><USER51> >Excel as a front-end to Python is just a bad idea

I think a lot of people would like this because you can look at more data on your screen at once with excel compared to jupyter notebooks. What's the downside?

<comment><USER50> The downside is

i) reproducibility. In the academic/research world there is a big move towards reproducible research, the nature of the Excel interface is not conducive to that. A standard scripting language is fine that plays with Excel but you don't want Excel necessarily as the main access point and the menu driven approach isn't conducive to keeping a permanent record of what buttons you click on. ii) In multi-cultural settings Excel defaults to the users system language, these days you simply jsut work with students laptops rather than using a standardized lab, so unlss you are polyglot working with Excel is just a really bad idea. Jupyter provides a standard interface and the default is always English, but supports multilingual content. iii) Python modules provide a huge range of solutions for many different domain applications, it's hard to see how Excel as an interface would provide support for every one of these modules. What I mean is how would Excel work as an I/O interface to a Python script that was doing something other than working with data? Notebook solutions already do this quite well.

</comment></comment></comment><comment><USER52> Just do it! We 've been waiting for decades for a replacement of visual basic.

</comment><comment><USER53> Aim for a front end notebook interface like Jupyter or Mathematica. Most excel i've had to play with was to store/manipulate data _and then_ C&P charts or data to word for the report. Seriously, notebooks.

<comment><USER50> You can basically use Jupyter as a frontend to Excel now anyway and never need to open Excel except to read and write to Excel files that you are sharing with Excel users.

<comment><USER53> that's cool - hadn't realised. i still dream about a word-excel mashup. imagine a table in word that when you click on it revolves around to reveal a spreadsheet and you hook the 'other side' to the calculation cells. literally separate data and text/analysis but packaged as a unit.

</comment></comment></comment><comment><USER54> As well as agreeing to this, I would add the following:

* I would support both Python 2 and Python 3. Yes I know that the push to Python 3 is ongoing but there are a lot more libraries to be found for 2. Don't bother with IronPython.

* I would integrate pip or whatever package manager Python uses these days so that people can download their own modules and use them in the Excel sheets. Not only that, the packages should be restored automatically when the Excel sheet is loaded.

* It goes without saying that Python should be sandboxed.

* VS Code integration in Excel with full syntax highlighting and autocomplete - again a no-brainer.

<comment><USER55> > I would support both Python 2 and Python 3.

Nah. They can spare a lot of pain and confusion by not having two _different_ Pythons with different sets of libraries in Excel, and they have this opportunity because they don't have to support people's old Python 2 spreadsheets. There _aren 't_ old Python 2 spreadsheets.

The libraries that are stuck on Python 2 really don't seem relevant here. There aren't many of them anymore [1], and I don't think people will be trying to run graphite-web or some busted old OpenID provider in their spreadsheet.

(I originally used Fabric and Twisted as examples in the above, but hey, those are on Python 3 now. Also not things you'd be likely to use in a spreadsheet.)

[1] [http://py3readiness.org/](http://py3readiness.org/)

</comment></comment><comment><USER56> They should never do this because many people spent lots of time learning existing Excel scripting and they won't like it. Fortunately the user feedback will likely be very negative, so will stop this is it's tracks./s

Henry Ford: "If I asked customers what they wanted, they would have said faster horses"

Steve Jobs: "A lot of times, people don't know what they want until you show it to them"

Seriously. Just build it and and make it great. When you can show that you can do amazing things with it, release it. The downvoters will also then adopt it, if you made it great.

</comment><comment><USER57> As long as the range object works in the same way, I don't care. Would be nice to have proper objects instead of having to use interfaces. It would also make a nice sandbox for beginners to learn python.

</comment><comment><USER58> Please God no! I'm all for a scripting language but the poor quality and inconsistencies of Python makes my life so much harder in the 5 other applications where it is the ONLY way to script everything. The fact that it is whitespace sensitive I have found makes it harder for beginners who try to edit pre-existing files that mix tabs and spaces. That's one dumb thing but there are many other thongs that bother me about Python. Yes to a scripting language, please no to Python.

</comment><comment><USER59> I know it's heretical amongst the Finance types... but one of the few reasons to use Sheets over Excel is for its scripting abilities. This will remove that advantage.

<comment><USER60> Alt+F11... Script away.

</comment></comment><comment><USER61> Anything you think you can solve with Excel plus Python is much better done in just Python.

This is like adding a tumor to Python.

Operable, luckily.

</comment><comment><USER62> I hate to say it but why not ECMA Script (JS)? It's everywhere and everyone knows enough to get by...

<comment><USER63> JavaScript is the obvious call.

App Script for Google Docs/Sheets is very powerful and one of my favorite features:

[https://developers.google.com/apps- script/guides/sheets](https://developers.google.com/apps-script/guides/sheets)

It makes for an excellent API runner. You massage a data set and then run it against an API very easily.

</comment></comment><comment><USER64> I am all for more ways to hook into Excel since it is integral to many things I do for my job. There are some F# ways to play with Excel. I just wish MS would give more love to F#.

      [1]  http://fsharp.org/guides/data-science/#excel-interop

</comment><comment><USER65> python isn't the bestest thing in the world but it's still a massive win for them, and a massive win for excel users. VBA had too many shortcomings and led to loads of scalability problems even for medium size apps.

<comment><USER15> To its defense VBA litterally hasn't been updated in 20 years. It's hard to hold a 90s language to the 2010s standards.

<comment><USER65> Fair enough. Although the jury is still out about it's value in the 90s too :p

</comment></comment></comment><comment><USER66> Am already excited for this and would use it to the fullest.

But i think Microsoft in doing this should come up with a way we can plug any other language(julia,lua,...). Getting this right now would mean a lot.

</comment><comment><USER67> Supporting R or Typescript/JavaScript would be great and probably closer to the Microsoft ethos (R is already very well supported in SQL server and PowerBI).

</comment><comment><USER68> honestly don't know how they are going to integrate python for me to think about how it could affect my workflow.

it could be entirely possible that you could create both VB modules and Python modules in alt-f11 and functions and subs from either could be called from the spreadsheet. this would be great. if python had to be run in a separate app, not so great.

will python in excel rely on the environment(s) installed independently in the system or the excel python environment? if the former, how to standardize runtime across different machines?

support for the scipy libs and matplotlib would be nice. maybe matplotlib will generate plots in its own window - 6/10 if so. if matplotlib can generate plots as its own object within excel sheets - 7/10\. if the plot is reactive to changes along its dependency chain - 9/10\. if you can right-click format shape and adjust colors, lines, scales, axes - 10/10

support for python exception handling - well... ANY exception handling besides "ON" ERROR GO TO" / "RESUME NEXT" \- 11/10

python with alt-f11's immediate and locals window + breakpoints + steps - 10/10.

what about windows api? office interop? internally built xlls? guessing these will remain with VB and will remain compatible. guessing excel/office object models will also remain the same structure in python for excel.

don't really care about output into jupyter. excel has "cells" too so you could technically output into a protected sheet if you wanted a read only report. we used to generate publications out of excel - chuck in some data into the sheets, matlab takes over the computation and spits it back into excel and a full report with cover sheet / table of contents / page numbers etc will be generated and we'd print and bind it professionally and send it back to the client.

just a philosophical musing... excel is very "functional". from each cell/cse- array in your raw data to each cell/cse-array in final output there really ought to be a single chain of functions. i see a few comments here and on reddit where people are looking forward to happily blasting for loops on each cell in book-wide subroutines. that breaks the "functional"-like quality of excel. that makes excel a million times harder to audit. excel at its best should look a lot like f#.

</comment><comment><USER69> I am 90% certain that MS has abandoned its EEE strategy from the nineties.

But the scars from that era are so vivid in my mind, that I feel the need of a confirmation.

<comment><USER70> What do you want confirmation of?

That MS is now a gentle, caring beast? Large organizations are not like that, they are money making machines that adopt strategies to maximise profit. EEE is no longer such a strategy, though it worked very well for a long time.

Will MS ever go EEE again? In a heartbeat if they felt it would maximise profits.

Does that seem likely in the short to medium term? No, the industry is different now, and they have to play nice.

</comment></comment><comment><USER71> This is a long time coming. There's a big backstory to it. Let me explain.

"Exie" was the codename for Microsoft's attempt to create, in Excel, a language similar to MATLAB (and later, Julia). The name "Exie" meant that it would be integrated with Excel. It was based on Alan Edelman's Interactive Supercomputing (ISC), which Microsoft acquired in late 2009 [0]. ISC's main product was Star-P, an auto-parallelizing compiler in which users used a *p suffix in an array dimension to indicate parallelism across that dimension, similar to CoArray Fortran.

Unfortunately, the ISC acquisition was a failure. Microsoft already had agreements with MathWorks and Cleve Moler (makers of MATLAB) which prohibited competitive software like Star-P. So Microsoft had to scramble and find other ways to get analytic, REPL, MATLAB-like software out the door. Unbeknownst to Microsoft, Julia was already making faster progress than they ever did, but on similar goals. Julia is what Microsoft had hoped Exie to become, and it's not a coincidence that Alan Edelman has been involved in Julia.

Then, Steve Ballmer decided to abandon HPC and mathematical software, and to focus mostly on the cloud, which led to the very public dismissal of Bob Muglia.

The head of Microsoft Technical Computing, Kyril Faenov, unfortunately committed suicide a year later. His wife, the daughter of a famous Seattle architect [1], did not respect his Jewish mother's wishes on the handling of his remains. His mother fought and lost in court [2].

Maybe Microsoft embracing Python in Excel is the best that can be hoped for now. It's certainly better than VB. But Exie tried, almost 10 years ago, to create an Excel environment closer to modern-day Julia than anything else.

There were a lot of personal sacrifices in that effort. For example, Bill Blake, the former CEO of ISC, stayed at MS for a while during the transition, then moved to Cray as CTO for a while, and then died unexpectedly less than 4 months after he joined D-Wave. [3] [4]

There's certainly been a lot of casualties, in the attempt to bring Excel up to being more analytically-friendly. Is it really worth it?

[0] [https://blogs.technet.microsoft.com/windowsserver/2009/09/21...](https://blogs.technet.microsoft.com/windowsserver/2009/09/21/microsoft- acquires-the-technology-assets-of-interactive-supercomputing-isc/)

[1] [http://archive.seattleweekly.com/news/956673-129/seattleland...](http://archive.seattleweekly.com/news/956673-129/seattleland- latest-selig-real-estate-fight)

[2] [http://caselaw.findlaw.com/wa-court-of- appeals/1735359.html](http://caselaw.findlaw.com/wa-court-of- appeals/1735359.html)

[3] [https://www.cray.com/blog/cray-ceo-reflects-on-bill- blakes-l...](https://www.cray.com/blog/cray-ceo-reflects-on-bill-blakes- legacy/)

[4] [https://www.dwavesys.com/blog/2015/04/bill- blake](https://www.dwavesys.com/blog/2015/04/bill-blake)

<comment><USER46> An additional note for posterity here...one of the main reasons Microsoft was interested in acquiring Interactive Supercomputing was that ISC developed it's own M-language (Matlab) compiler M# built on Mono/.NET...basically a faster Matlab replacement than Octave, using features like multiple dispatch. One of the primary developers of the M# compiler at ISC was Jeff Bezanson, co-creator of Julia.

Exie used a bit of code from M#. When Exie was cancelled, the libraries were given a C#/F# facelift as Cloud Numerics, which was eventually cancelled, and then given a GUI facelift as part of the initial version of AzureML.

Disclaimer: I previously worked at Interactive Supercomputing, was part of the team acquired into Technical Computing/HPC at Microsoft, and also worked at Julia Computing.

<comment><USER72> Julia is open source...why don't they just incorporate it?

</comment></comment></comment><comment><USER73> I hope they wont localise the function names like they do for cell formulas. Never have i met someone who enjoyed this.

<comment><USER74> I do quite a bit of VBA, but not much other programming. Could you clarify what you mean by localized?

Just that the cell formulas cannot be (elegantly) accessed from VBA?

<comment><USER75> The formula names are translated into different languages so if you are used to using Excel in your native language you can't easily use it in English or vice versa.

</comment></comment></comment><comment><USER76> I would prefer JavaScript as scripting language. Or make support all clr compatible languages

</comment><comment><USER77> F# should be best is Excel macros language. You may provide option to run Python from F#.

<comment><USER78> yes please !

</comment></comment><comment><USER79> This will be >>> better than using JS as a scripting language in Google Sheets.

</comment><comment><USER80> pro: better compatibility with external libraries, syntax is nicer

con: GUI programming will suck unless .net adds "visual python"

I don't have statistics but I imagine people would prefer sticking to VB for ease of adding buttons, etc.

</comment><comment><USER81> I thought there was a project for typed Excel. Any news on that one?

</comment><comment><USER82> Do it!!!!!! To stay relevant do it!

I mean any language would be better than VBA.

</comment><comment><USER83> Native virtualenv and python inside windows would be great :p

</comment><comment><USER84> I'd like to see perl integration, that would be rad.

</comment><comment><USER85> You can already do this with xlrd and xlwt.

<comment><USER86> Excel spreadsheets are cool because if you update data somewhere, it'll update all the formulas and products elsewhere.

How do you get that kind of "watch" behavior with `xlrd` and `xlwt`? You don't, you have to re-run a script. Sucks.

<comment><USER50> Try XLWings

<comment><USER86> Right. XLWings looks like a cool tool.

But the point I'm making is that: It's still a good thing for Excel to be integrating more tightly with python. It'll help all of those non-developer normies get the magic of coding.

</comment></comment></comment></comment><comment><USER87> Why not Typescript or some languages with stronger type support? Auto-complete is much more useful with a typed language.

</comment><comment><USER88> Yes please.

</comment><comment><USER60> Why not make it work with Windows Script Host for any compatible language?

</comment><comment><USER89> "NO! I prefer VBA to Python!" Said no one ever :)

<comment><USER90> Thousands of people would say it if MS attempted to remove VBA telling people to use python instead.

</comment></comment><comment><USER91> please do that

</comment><comment><USER92> Yes, please.

</comment><comment><USER93> Why not C# ?

<comment><USER94> Python is used a lot for number crunching/data science. It has an ecosystem for that. Excel has the numbers. People want the two together!

</comment></comment><comment><USER95> Don't do it!

<comment><USER86> Why?

<comment><USER95> The people that are going to use this aren't programmers. They are going to hate that the code has to be indented properly or it is considered an error.

</comment></comment></comment><comment><USER96> should probably be prolog or apl instead

</comment><comment><USER97> Maybe they read it here: Keep Excel application as is. Excel is OK without Python and VB seems ok, it's BASIC after all. Instead, concentrate on making Excel functions embeddable in server applications, this is area totally neglected so far. Think about server-side spreadsheet handling and calculations, that would allow Excel to drive business logic of systems. And maybe there Python would be useful, but i'd prefer just .Net runtime libraries instead.

<comment><USER8> The best solution to this, in my experience, has been a data-backend for Excel.

No, I'm not talking about connecting via ODBC. Rather, generating Excel documents from a data store: which may possibly be versioned and so on.

Excel is not a good place to store data. It is good to work with data. It's really, really good to view data. People love it for that. But when you start to store a lot of data in Excel ...

</comment></comment><comment><USER98> Well python is pretty much already well established but it should be wary of te famous "Embrace Extend Extinguish".

</comment><comment><USER99> Ruby is a lot more non-programmer friendly and has an easier syntax if you ask me

</comment><comment><USER100> I think python is a bad choice for Excel, Ruby would probably be easier to people who are not developers and javascript might work just because if its reach (while still being simple).

<comment><USER101> I think basic Python is far easier for a newbie to learn than Ruby, and is commonly used as a scripting language for non-programmers.

</comment></comment><comment><USER102> Does not M$ have a track record of getting everyone on board and then murdering everything in site. I mean it sounds good, but I don't trust M$. Maybe they have changed, but I'm not yet convinced.

<comment><USER103> Embrace and extend python? I think not.</comment></comment>


Finally, There's a Book About Which Animals Fart - <AUTHOR> https://gizmodo.com/finally-theres-a-book-about-which-animals-fart-1824263109 <comment><USER2> A quick check of Amazon suggests that this work is fairly comprehensive and so should prove fascinating to its intended demographic. The topic appears to be endlessly interesting. Sadly, it does not appear to include information about the impact of farting on Global Warming.

</comment><comment><USER3> Why would animals fart about a book?</comment>


Nuclear Plant Accidents: Sodium Reactor Experiment - <AUTHOR> http://allthingsnuclear.org/dlochbaum/nuclear-plant-accidents-sodium-reactor-experiment <comment><USER2> At least they didn't have a sodium fire. Monju (Japan) and Clinch River (US) both had sodium fires.

The U.S. Navy tried sodium reactors in the early days. In addition to Nautilus, the first nuclear submarine, they also built USS Seawolf, with a sodium-cooled reactor. Seawolf worked, but was enough of a headache that its reactor was replaced with a Nautilus-type pressurized water reactor. The US Navy didn't try sodium-cooled reactors again. Rickover on sodium-cooled reactors: "expensive to build, complex to operate, susceptible to prolonged shutdown as a result of even minor malfunctions, and difficult and time- consuming to repair."

The USSR tried sodium-cooled reactors, with moderate success.[1] They had leaks and fires too. One big reactor had 39 leaks over the years, none catastrophic. In the last 15 years of operation, none. Eventually they found all the construction defects.

Basic truth: complexity in the radioactive parts of a nuclear reactor causes trouble. Sodium reactors have fires. Pebble-bed reactors have pebble jams. (There's one in Germany that can't be unjammed or decommissioned.) Helium- cooled reactors leak helium. The nice thing about water-cooled reactors is that the complexity is on the outside, where repairs are possible. This is why new fancy reactor designs are viewed sceptically in the industry. You can't have any problems inside the reactor vessel, because you can't fix them.

[1] [http://www- pub.iaea.org/mtcd/meetings/PDFplus/2009/cn176/cn1...](http://www- pub.iaea.org/mtcd/meetings/PDFplus/2009/cn176/cn176_Presentations/plenary_session_6/INV-08.Ashurko.pdf)

<comment><USER3> I hadn't heard about pebble jams as a problem in pebble-bed reactors. Here's a link to (scant) details about that German event: [https://en.wikipedia.org/wiki/Pebble- bed_reactor#1986_accide...](https://en.wikipedia.org/wiki/Pebble- bed_reactor#1986_accident)

<comment><USER2> More info: [1] Most of the pebbles were removed through the fueling system, but broken pebbles and dust remain, all highly radioactive. Bits of broken pebbles are jammed into crevices in broken graphite. "The reflector bottom of the core cavity is funnel shaped, with an inclination of 30°, ending in the 0.5 m wide vertical fuel discharge tube. In that geometrical setting it could simply be assumed that all pebbles must have rolled into the discharge tube and that there was no need for an inspection. The reflector bottom, however, contains many slits for coolant penetration, 3.4 cm wide and in radial orientation. A piece of broken pebble could have stuck in such a slit, and, standing out, one or more pebbles might lay behind it guided by the slit like by a rail."

"An upper limit of 197 fuel pebbles, respectively fuel pebble equivalent in form of broken pieces, has been evaluated to be residual in the reactor vessels containing an upper limit amount of 98g of fissile material."

"AVR has most probably the strongest β-contamination, and in the worst form, of all nuclear installations world wide".

This is why complexity in the radioactive portion of the system is strongly undesirable. If anything goes wrong, dealing with it is extremely expensive, difficult, and dangerous.

[1] [http://www.wmsym.org/archives/2000/pdf/36/36-5.pdf](http://www.wmsym.org/archives/2000/pdf/36/36-5.pdf)

<comment><USER4> Thank you, very enlightening.

It is often exhausting arguing with overly enthusiastic people claiming certain reactor designs aren't just safer but "inherently safe". All operations with massive energy releases are inherently unsafe. That's just thermodynamics at work, and the reason we still have fire brigades after millennia of using fire. What makes a difference with nuclear is the energy concentrations and the material hazard involved. The problem from your citation is a subtle and arguably minor engineering oversight which wouldn't be much of an issue to handle on say a coal plant. Nuclear however multiplies the consequences of any design defect.

<comment><USER5> I believe thats why certain molten salt reactors do away with any complexity in the reaction chambers - some designs are planned to operate with fuel dissolved in the salt. Criticality comes from the shape of the reaction chamber vessel. Worst kind of failure mode - fuel cell rupture/core meltdown are not really possible - simply because those are the normal operating procedure. Should anything go really wrong the molten salt/fuel mix should melt emergency reliefs and drain into non-criticality vessel. I do not remember the nitty-gritty details and can't find it now, sorry.

<comment><USER4> Yes, that's another popular contender.

Now imagine the emergency drain failure, due to a quake seismic shift, massive explosion nearby or a construction worker forgetting his helmet in. What's the plan B?

<comment><USER6> Rely on gravity and put the non-critical tank underneath the critical tank. Make sure to make the critical tank a much lower melting point than the non- critical tank. Burst diaphragms (well, low melting point plugs, like steam boilers have used for a few centuries now).

Possibly you're confusing "inherently safe" with "it can't break or become uneconomical". Also talking about inherently safe plants, usually they're talking physics, an inattentive enough electrician could probably find a way to put his hand across the output of an alternator, there's just nothing "nuclear" about those kind of accidents other than the worksite happening to be a plant.

Inherently safe just means you can't have a Chernobyl because water doesn't burn as well as charcoal. Its inherently very difficult to set PWR moderator on fire (water) compared to the Chernobyl experience (graphite, more or less purified coal). Although its against the spirit of the linked article, the PWR "near" my house inherently can't have a sodium leak because it doesn't use sodium as a coolant.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I have a bit of a connection with this incident, I grew up in Simi Valley, not far from Los Angeles; it is not an academic subject to me. In short, they built a defective reactor in a warehouse a few miles away from several cities and covered it up when it exploded.

A number of workers and their spouses (known by my parents) died early in their 40s from cancer ostensibly due to contamination. There is a belief in increased birth defects in the area, but I can't find anything to cite right now.

The shame is that we used to be proud of having rocketdyne nearby, testing rocket engines and such, which we could hear from our school yards. Little did we know how reckless they were, and had had a meltdown a few years prior.

</comment><comment><USER8> I find various accounts of nuclear accidents fascinating because, as the intro of the article alludes to, they often involve complex systems undergoing complex failure scenarios.

Then there's SL-1 ([https://en.wikipedia.org/wiki/SL-1](https://en.wikipedia.org/wiki/SL-1)). That was a really stupidly simple failure, but of all the accidents I've read about I find it the most poignant reminder of why nuclear reactors _are_ such complex systems in the first place.

<comment><USER9> But it was well documented that you shouldn't lift that one rod above point X. Maybe the message didn't sink into the guy, maybe he screwed up, they even wonder if he committed suicide. Its big message was to eliminate all possible single points of failure, especially ones controlled by fallible humans, even at the cost of increased complexity.

<comment><USER10> It should be noted that reactivity control in military and commercial PWRs is fundamentally different. That said it's hard to understand how the SL1 operator managed to yank the rod so far out of the core. The procedure was to withdraw each rod 4 inches and attach it to the crdm, which in itself is a little mind blowing to me. The rod was withdrawn 26 inches and prompt criticality was achieved at 23 inches or so. The rod weighed 86 pounds. Even if it was stuck it's hard to imagine yanking something that heavy that far to unstick it.

</comment></comment></comment><comment><USER11> Santa Susana is notorious for a dangerously cavalier attitude about chemical safety. For years they burned toxic chemical waste in open pits. They filled barrels and shot them with rifles until they exploded. One person was killed in 1994. They disposed of sodium coated parts by letting them burn in the same open-air pits.

[https://en.wikipedia.org/wiki/Santa_Susana_Field_Laboratory#...](https://en.wikipedia.org/wiki/Santa_Susana_Field_Laboratory#Sodium_burn_pits) [http://www.latimes.com/business/hiltzik/la-fi- hiltzik-201406...](http://www.latimes.com/business/hiltzik/la-fi- hiltzik-20140613-column.html)

</comment><comment><USER12> If you're into this, you might also like:

Inviting Disaster: Lessons From the Edge of Technology: [https://www.amazon.com/gp/product/0066620821](https://www.amazon.com/gp/product/0066620821)

<comment><USER13> Or Atomic Accidents by James Mahaffey - this is a great book

[https://www.amazon.com/Atomic-Accidents-Meltdowns- Disasters-...](https://www.amazon.com/Atomic-Accidents-Meltdowns-Disasters- Mountains/dp/1605986801/ref=sr_1_1?s=books&ie=UTF8&qid=1467769048&sr=1-1&keywords=atomic+accidents)

</comment></comment><comment><USER14> I'm always surprised that the CANDU[1] reactor isn't more popular, as you don't require uranium enrichment, can use a mix of fuels, and has a number of fail-safes that work without power -- such as gravity-dropped control rods into the low pressure chamber, and requiring the moderator (deuterium in the original models) to be present to maintain a reaction.

[1] [https://en.m.wikipedia.org/wiki/CANDU_reactor](https://en.m.wikipedia.org/wiki/CANDU_reactor)

</comment><comment><USER15> Happens all the time. They ignored multiple and repeated warnings that they should stop and think things through.

On a lower scale it's like (repeatedly) rebooting the PC when it's misbehaving.

</comment><comment><USER16> Reminds me of an old one-liner I saw in an email signature years ago - "There's one really terrifying word in nuclear physics.

Oops."

I'll lead myself out.

</comment><comment><USER17> This is a great read that sums up many criticality accidents and their causes over the years - "A Review of Criticality Accidents" [https://www.orau.org/ptp/Library/accidents/la-13638.pdf](https://www.orau.org/ptp/Library/accidents/la-13638.pdf)

</comment><comment><USER18> Kind of weirdly disingenuous that the article says "the workers" did this and "the workers" did that. What, was management completely absent for a period of months, and a bunch of yokels were just randomly flipping switches?

If "a worker" was overriding a failsafe, it's because right behind him a supervisor was telling him they had to get the plant back online, or else he'd be fired.

<comment><USER19> I think you are being just as disingenuous. Without knowing the processes, we have absolutely no idea what the decision chain looks like. I can think of many emergency situations where I would want workers who are close to the problem to make judgement calls. Even if they make the wrong call, at least the chance of success was optimised.

I often notice a bias amongst some people that they think management is more susceptible to caving in to pressure for "success" (success being measured by getting a job done quickly/cheaply, etc). In reality, I think it's just a human condition.

Imagine working in a shop where every move you make is scrutinised. If you get something done fast, everyone assumes that you cheated somehow or that you did an exceptionally poor job. People always doubt you and assume that you are on the take somehow. This would be pretty dysfunctional.

Now imagine working in a situation where when you do work everyone assumes that it is of high quality. They don't have to check it because they know you are capable, hard working and reliable. If you get it done more quickly than expected, it's because you are a genius and should be promoted.

People often try to build companies like the latter. The problem is that it's very easy to let your standards slide. If you do poor work very quickly you get congratulated and rewarded. If you do good work very slowly, nobody looks at it, nobody understands the quality and everyone complains that you took a long time.

If you are in management, it's even worse. If you check up on the quality of work of your workers: 1. They are upset that you don't trust them. 2. If you find problems, it only causes you headaches and makes you look bad because nobody understands quality _at all_. They just think everything is wonderful and if you bring up a problem, then it's because you are the worst manager on the team! It's really easy to close your eyes and reward poor work.

What I find really interesting is that on teams where there is absolutely _no_ pressure to deliver, conversely programmers often imagine pressure from management to deliver quickly. Again, it's because nobody sees the quality of their work and the only thing they see being evaluated is the speed with which they deliver.

In the end, management must take responsibility when workers make mistakes. Maybe the wrong people were hired. Maybe there was a lack of training. Maybe the social dynamics were poor. It doesn't matter.

However, it is also possible that workers made the wrong choice, but that the system still allowed the choice with the highest chance of success to be made (given the information that they had). You are never guaranteed to have success. Even when workers and management do an excellent job, sometimes you fail because of something you didn't realise at the time. In that vein, I wouldn't assume that "the workers did X" is an indication that they were incompetent. Nor would I assume that management pressured them into doing something stupid.

</comment></comment><comment><USER20> Nuclear electric power production carries risks, which are outweighed by the expectations of lives saved by reducing air pollution and greenhouse gas production.

<comment><USER21> How can you calculate the risk if the modus operandi for the nuclear waste management for the next few thousand years is not known yet?

<comment><USER22> Clearly it's better to spew the radioactive waste randomly into the air, like our existing coal plants do. The solution to pollution is dilution, right?

<comment><USER23> _> Clearly it's better to spew the radioactive waste randomly into the air, like our existing coal plants do._

While coal plants do emit more radioactivity _through the chimney_ than nuclear plants, that radioactivity pales in comparison to that emitted by both the nuclear waste and accidents of the latter. See [http://skeptics.stackexchange.com/questions/1018/do-coal- pla...](http://skeptics.stackexchange.com/questions/1018/do-coal-plants- release-more-radiation-than-nuclear-power-plants) for sources.

Also, nobody said coal and nuclear are the only possible technologies for creating electricity.

<comment><USER22> What matters isn't how much pollution is released. What matters is the harm and suffering it causes. Nuclear has a long, long way to go to catch up with carbon-based fuels in that regard.

I disagree that nuclear waste is a problem. To the extent that it is a problem, the solution is stupidly simple: store it in Antarctica where no technologically-illiterate humans can possibly come into contact with it, and where we can reclaim it later if/when we need it.

 _Also, nobody said coal and nuclear are the only possible technologies for creating electricity._

They're what we have to work with. Renewable sources should be aggressively explored and developed, but they are currently not sufficient by themselves.</comment></comment></comment></comment></comment>