If you don't wipe your phone this can happen with anything (including an iPhone)...

However, if you reset an iPhone there is NO way to recover anything. Everything written on an iPhone is encrypted... when you reset an iPhone it securely wipes the key and then nothing is retrievable.

I feel it's really important that this piece get approved. The media is replete with Hachette, its authors and agents, and the various traditional publishing old-guard trying to stack the deck against Amazon. The other night the New York Public Library held a so-called "panel discussion" that was essentially an excuse to get together and bash Amazon. We need more people to hear the other side!

Interesting... I'm not sure what's unproductive about producing a freely available scientific engineering platform that is directly impacting the energy generation issues in this country.

But, ok :-)

You can install PETSc without a Fortran compiler at all. Change that --download-f-blas-lapack to --download-c-blas-lapack and you're good to go...

In fact... MOOSE works on platforms without a Fortran compiler at all... although we generally recommend that you have one (so that you can still link in any legacy routines you've written in Fortran).

I'm not specifically against Fortran... I was just trying to say that most new computational science development at the National Labs is NOT being done in it. We've moved on...

Easily fixed with libraries like Eigen ( http://eigen.tuxfamily.org/ind... ) and many others.

Most of the better "frameworks" out there come with their own proxy objects for multidemensional arrays (like http://libmesh.sourceforge.net... )

Multidmensional arrays haven't been an issue (especially in C++) for quite a long time...

Firstly... 10^-15 is WAY beyond what most scientific codes care about. Most nonlinear finite-element codes generally shoot for convergence tolerances between 1e-5 and 1e-8. Most of the problems are just too hard (read: incredibly nonlinear) to solve to anything beyond that. Further, 1e-8 is generally WAY beyond the physical engineering parameters for the problem. Beyond that level we either can't measure the inputs, have uncertainty about material properties, can't perfectly represent the geometry, have discretization error etc., etc. Who cares if you can reproduce the exact same numbers down to 1e-15 when your inputs have uncertainty above 1e-3??

Secondly... lots of the best computational scientists in the world would disagree:

http://www.openfoam.org/docs/u...
http://libmesh.sourceforge.net...
http://www.dealii.org/
http://eigen.tuxfamily.org/ind...
http://trilinos.sandia.gov/

I could go on... but you're just VERY wrong... and there's no reason to spend more time on you...

Not everyone needs to know all of the quirks of C++ to use it. My project ( http://mooseframework.org/ ) does all of the nasty C++ stuff under the hood so that we can expose a very straightforward interface to non-computer-scientists.

It's working out well so far.

Object-oriented is still a good paradigm until the functional language people get everything figured out and there are enough computational science libraries written in functional languages. And if you want to do object-oriented and you still want to be fairly close to the metal for performance reasons then C++ is a good choice.

There are people that do object-oriented with C like the PETSc team ( http://www.mcs.anl.gov/petsc/ )... and they have good reasons for doing so... but the result isn't necessarily less imposing to the uninitiated than C++...

I saw this link bait the other day...

We're NOT using Fortran anymore...

Many of us at the National Labs do modern, object-oriented C/C++... Like the project I'm in charge of: http://www.mooseframework.org/

There are whole labs that have completely expunged Fortran in favor of C++... Like Sandia (http://trilinos.sandia.gov) who actually went through a period in the late 90s and early 2000s where they systematically replaced all of their largest Fortan computational science codes with C++.

Those places that don't use C++ use C like the awesome PETSc library from Argonne ( http://www.mcs.anl.gov/petsc/ ) which actually employs an object-oriented scheme in C.

The big name modern codes that are getting run on the biggest machines are generally done in C and C++.

I don't see that situation changing anytime soon as there is simply a massive amount of C and C++ libraries that will continue to provide the engine for tomorrows codes. The trend i see happening most often is utilizing C and C++ libraries with Python glue for everything doesn't need raw speed.... I think that trend will continue.

Are you trying to say you don't find any value in GitHub?

I'm (semi) with you on knew languages... but new platforms like GitHub have totally changed how people develop open source projects...

If you haven't tried it... then you REALLY should.

It does not run in the browser. It's a standalone application that is based on web technologies.

And my current Emacs: 150MB

What's your point?

You don't have 100MB of RAM to spare?

That's not it - I've been in the beta for a long time... they are just targeting Mac first.

In the web develop / startup world around San Francisco (where GitHub is) Apple computers are fairly popular... and that's apparently what GitHub primarily uses.

It will be on more platforms soon - they just chose Mac first because that's primarily what's used at GitHub.

To be fair... Emacs 10.7 running on my Mac is currently consuming 150MB...

We've moved on past the days where we care how much memory this stuff takes up. If you're a developer you've probably got a pretty decent machine anyway.

I personally want more features... and more features means more memory and I'm happy to give it.

I did try Atom for a week and it wasn't quite ready for what I wanted to do with it and so I moved back to Emacs. I'm going to keep any eye on it though because the extensibility is CRAZY easy so there are going to be TONS of plugins built over time...