I would love to but i got a very late start on this and I'm coming up against a time crunch... I was without my laptop while traveling because I left it in the security line... also for HIPAA reasons I have to be very careful about what gets included in the git push, etc. etc. For various reasons it's a PITA so I might only do a blog post about it if it's successful, and after the contest is over.
It's basically an attempt to bring the user interface of Mathematica or MATLAB (the "notebook") to the Python world. You can get an idea of what this is like in Mathematic by watching Wolfram's demo: https://www.youtube.com/watch?v=_P9HqHVPeik
This comment overstates the current power of Julia's parallel programming model — as of now Julia has no real tools for shared-memory parallelism and probably will not for another few versions or so. For distributed memory Julia is great, but please do not use Julia if you are being hindered by the GIL.
(NB I say this as a big Julia evangelist. it has a lot of potential but is not really there yet on a number of things, this being one of them.)
This is not strictly accurate. Julia does not support multi-threaded parallelism, but there is decent (if, yes, still immature) support for multi-process shared memory parallelism - similar to Python's multiprocessing library. Not an alternative to the GIL as such, but definitely more than nothing.
One nice example using this is a shared memory, parallel sparse matrix multiplication implementation:
it's interesting how some software problems have garnered many really good solutions while others are still mired in stuff like this.
e.g. no matter what your preferred source control tool is I think we can all agree that there are some pretty good options out there these days. compare that to the insanity that prevails in packaging in every corner.
I don't follow. We've had TextWrangler, SubEthaEdit, TextMate, Sublime Text, and Smultron alongside rapidly improving IDEs like Coda, XCode, VS, LightTable, and a host of web-based environments like JSfiddle, Cloud9IDE, and Codepen. Text editors don't just attract attention, they attract a lot of attention, and I'm glad for it.
First of all, drawing a line between IDEs and text editors is a surefire way to ignore the kind of innovation that is happening with regard to text-editing. If you insist on doing this then in your search for innovation you've drawn a box so narrow that you should not be surprised to find nothing in it. There are only so many pure text-editing actions with positive ROI and E&V mastered the bulk of them long ago. Even so, E&V haven't been standing still. It's true they refuse to innovate in certain directions:
1. Out-of-the-box integration with modern toolsets (0-configuration documentation, smart autocomplete, build, debug, jump-to-definition, etc)
2. Present an interface that is easily discoverable by GUI-minded folk
3. Take advantage of the opportunities afforded by non-textual displays
but each of these is done "poorly" in E&V for a good reason, as per your text editor / IDE distinction. They can't change these things without stepping on the toes of their power users (i.e. all of them) and leaving behind part of what made them great, which is why this kind of innovation is happening away from E&V. Most of the apps I listed address between 1 and 3 of the above issues. Just because the young upstart editors don't support keyboard input and customization with the fluidity of E&V doesn't mean they are purely derivative. They do something that a lot of people want done that E&V don't do, and they do it well. That's what innovation is all about.
So I ask again what it is that you would consider innovation and why the projects I listed don't count.
You know what, I don't really disagree with what you are writing.
I'll repeat that we're partly talking past each other, but you are correct that the kind of (valuable! useful!) innovations you list tend to happen by an upstart and then are copied into other programs. So it is healthy to have a field of contenders rather than two dinosaurs.
You're also pitching this as some kind of argument, which I think is your mistake.
Never did I say that people shouldn't make new text editors. I remarked that some problems seem to attract developers, and some don't. I think that structural issue is more interesting than editor feature evolution.
Emacs has an infinite number of features; but the end user may be required to write a few thousand lines of configuration file to enable some of them :)
The power of Emacs is that the configuration file is more than just that. It is code that becomes part of the editor and can replace pretty much any part thereof if the user so desires.
