Look out Sublime and Textmate ... here comes Brackets (stunning)
blog.brackets.io
blog.brackets.io
If a new decent editor shows up, it wont be shiny, it wont grab headlines on HN with a fancily designed website, it will simply grow popular slowly, be added to package managers across platforms after withstanding the test of time. The test of more than one person or just a few developing it and then moving on to something else.
With vim and emacs you're guaranteed to not be wasting your time learning their arcane ways. Long after humans have left the Earth someone will be reprogramming a couple of launch tubes on their trans-stellar space vehicle with vim. They wont be using this fluff from Adobe.
And back to the original article, live programming and rich editing experiences is the future; emacs and VIM will go the way of the typewriter and x-terminal.
Emacs and VIM use has actually been going down since
the 90s as a percentage of the developer community
The quality of the developer community seems to have gone down since the 90s. Maybe the OP should have stated "Eventually every great developer's editor search ends with vim, emacs or a management position." At least, this has been my experience. live programming and rich editing experiences is the future
I was previously assured that VPLs were the future.Really? Can you back this up? As it seems to me the community is more engaged, productive and delivering high quality code. Yes, there's a lot more bad code as well, but that seems to be proportional to the increase in developers.
To quote Jack Churchill (during WII) "any officer who goes into action without his sword is improperly armed."
> I was previously assured that VPLs were the future.
They are. Its just that we are getting the VPL features that we want (live programming and rich editing experiences) in editors for our textual languages instead.
How many of us use x-terminals these days? I was referring to the hardware, not the emulation program. Perhaps parent lives in a world where they have a bunch of surplus DEC or HP X terminals and haven't moved on to PCs yet. Or perhaps parent just misunderstood my comment.
My Google-Fu is coming up short, i can't corroborate this. Can you provide any links to data confirming this claim up?
I took a stab at getting some stats by searching stack overflow / server fault / super user for vim questions, emacs questions, textmate and sublime, vim comes out top by a long way, emacs next, the other 2 are a rounding error.
This is all informal and anecdotal, but I'll try to explain my reasoning/experience. In the mid/early 90s, you weren't really a great programmer unless you used a real text editor, so we would all eventually evolve into using Emacs (or VIM for the more daring). But then in 1997, Visual Studio got support for code completion (in VB), and Java and even C++ eventually followed. These language editors improved productivity for programming in those languages so much that it was hard to be competitive staying on Emacs. So perhaps most (~90%) of the Java/C#/C++ code written today is done with a well supported language aware editor (Eclipse, Visual Studio, JetBrains, ...).
Of course, if you are programming in a dynamic language, or a language with lousy tool support (C), then the language-aware editor doesn't really give you much (no static type system --> no static type feedback). There is a greater chance you are programming in Emacs (or VIM), but then you might not want to bother with the learning curve, or you might want something with a more modern non-ASCII UI, so maybe you are programming in Sublime or TextMate. There is nothing really wrong with this, you can be a great developer and prefer to avoid UX-archaic tooling, especially if you happen to also be a strong designer. There are strong trends away from text-based tools to visual tools, and I have no reason to believe that this isn't at play here.
The emacs community is vocal, and is particularly magnified in my field (systems/PL/PhD-level computer science) and demagnified at my place of employment (Microsoft, though keep in mind MSR has lots of Emacs/VIM users). But look at what the students prefer: they have no patience to learn these weapons from a more civilized time. They'll take whatever is the path of least resistance, and honestly who blames them!? Its not like they are losing much.
Why then, in circa 40 years, have we still not managed to find a better alternative?
I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems.
To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI.
With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite).
The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on.
So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon.
As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.
I'm not going to completely disagree with you here. There are lots of time I've found a shell to be useful, but I've also changed my workflow to minimize the amount of time I spend there. Learning curve for shell is steep, not shallow, but I've gone through much of that 20 years ago. If there is an old tool I can use to do something, I'm all for it, but if its a new tool, I'll go for the visual one with the lower learning curve, because I'm quite busy. Still, nothing beats shell for composability and flexibility, I definitely lose something with my approach. I find lots of promise in projects like Mozilla's Ubiquity, but I have a feeling the next step are actually Siri-like dialogue systems (whether typed or spoken).
But we are talking about editors that are used to edit code. I'll argue that language aware editors (in Eclipse, Idea, VS) have already greatly surpassed VIM/Emacs in terms of productivity, but then you could argue back that VIM/Emacs could re-support these features (and people have crammed them in at some points, though these have failed to stick). So let's just assume equal footing for now, and evaluate the experience. Given that we have a good understanding of the development process now, I'll argue that an IDE with high-discoverability of its capabilities is easier to use than Emacs/VIM which require substantial training to master. Now what Emacs/VIM give you is lots of power, but I don't think most of us need that. Heck, I've even moved away from Emacs for Latex programming, where the "build project/view PDF" menu option in TeXniCenter is good enough for me.
It's probably not worth for a quick "let's change a setting in /etc/xyz" edit but it's worth it for everything else!
p.s.: i'm quit esure mac os x can do the same and in windows there is some third party app for remote ssh access/mounting.
We are really honored to be compared to Sublime and Textmate at this early stage. Those are fantastic text editors.
The purpose of the Brackets project isn't to replace those editors, but to inspire new ideas for web development tooling. It's simply a sandbox where the web development community can experiment with new ideas. Because it's written in JavaScript, HTML and CSS, everyone can get involved.
-Adam Lehman Brackets Product Manager
I respect the wit (a lot), but I'm not sure this the opinion you profess is really true of everyone in general.
I can type plenty fast and my muscle memory is kinda crazy insane... Notepad++ gets me everywhere I ever need to go.
I spend most of my time trying to write the least amount of code possible rather than worrying too much about what editor I use for writing my code.
Not trying to argue. Whatever floats your boat etc.
But that I'm an Emacs guy.
I hope it can survive long enough to accumulate enough plugins
I don't think I'll ever understand why people would invest time (e.g., hundreds of hours over the course of years) extending closed source software over which they have so little control. So many people used TextMate until the development slowed. And now these same people seem to have jumped to Sublime Text. Did they port all the TextMate plugins they had written? Or did they not write any TextMate plugins to begin with? I'm guessing the latter because when I've browsed collections of config files at GitHub, the people who use closed source editors tend not to extend them, which is probably a wise choice.I recognize that anecdotes != winning PowerBall tickets, but I have never in my life met a user of Chocolat, Light IDE, or Cloud9.
But pretty much every Mac or Windows developer I know has ST2 at least installed (Linux, not so much (at least not yet), although it is available).
So my fingers don't look as busy as when using Vim, but I'm actually doing the same thing and postponing RSI.
The editors are different, yes, but both brilliant.
I'd pay an arm and leg for IDEA or PyCharm with Sublime as the text editor (or something else with multiple cursors and all the "shiny" editor stuff), and the ability to launch either the full IDE or just the editor and be able to share editor settings, depending on what I'm doing (eg. the IDE for browsing a huge codebase or just the editor for working on a small project)...
I can even think of a business idea: 1. make awesome open source editor (Sublime text with optional Vim keybindings is awesome enough for me) 2. build smart IDE on top of it (what I expect from an IDE are things that require "understanding the code", ie. lots of language specific features, refactoring and tools integration, nice looking tree code browser etc.) 3. profit!!! (imagine that you'll also profit from the evolution of the open-source editor and from the "complex" IDE features you develop, at the same time! and the "IDE haters" that will just use the editor would use or recommend the IDE whenever they would need to navigate an ugly codebase or recommend something to someone else)
I'll ping @intelliyole on twitter to respond.
https://twitter.com/mahmoudimus/status/279494119431217153
Update:
For now, what I do is use an external command that pipes out the buffer to Emacs and I use Emacs to slice and dice - then I just C-c # out of Emacs and switch back to PyCharm and keep on coding.
Second, all the smart stuff has performance costs. As soon as you're building a complete model of the codebase and updating it in real time, you're losing all the low CPU/memory usage benefits of a plain text editor.
Really, the only aspect in which we fell the pain of not being native is font rendering on Linux (which has a crappy implementation in AWT and there's little we can do about it). Other than that, it's not a problem at all to integrate as many editor features as you like into a JetBrains IDE.
Both try to dabble in eachother's realm, but the places where they shine should be inter-operable, not combative.
IDEA supports multiple cursors, actually, ;).
As for IDE support, I find Sublime text extended with a few key plugins to be just as good as a proper IDE when it comes to (in my case) front-end development; JS checking with JSHint, syntax highlighting for html/js/less, quick HTML using ZenCoding, andsoforth.
Care to enlighten me about how to enable or use this? (yes, it finally got column mode editing, but it is far from true multi-cursors, ctr+click in 3 different random places, even two of them on the same line and then move around, expand/contract selection to scope and do zen-coding tricks to them at the same time - yes, it's functionally equivalent to a refactor or a search and replace, but these alternatives break the "don't make me think!" philosophy of true multi-cursor editing that I consider the biggest advantage)
Without it, we are left with hacks, or lots of work for every new language, like Eclipse, which Yegge says has 3 Java compilers inside.
The good: auto-refreshing preview of HTML page upon save
The bad: no auto-end-brackets or end quotes as one types (ironic, considering the editor is named Brackets)
I am sure that the talented Adobe engineers will make this editor a major contender for Sublime and Textmate in the future, but at this point, I think the stunning attribute in the post title is a bit link-baitish. I'm looking forward to watching the editor develop into a mature product!
Sure, you can "improve" (read: mess up) the editor by changing it's source code - but I still don't see the point. I'm using Sublime Text 2, with it's package manager. Everything I need is a few key presses away, and there's usually no need to restart the editor after installing something.
Also, I'd never use an editor that didn't support remote sync on save, version control, etc. (Managing component source code outside of the webroot makes it so much easier to handle in git.)
I hadn't realized that was working yet. I saw the repo for the shell itself is here https://github.com/adobe/brackets-shell - it seems almost like a lightweight version of AIR. Does anybody have any more information on this..?
Do you mean that you weren't impressed with the font?
Or that there was something of value that I missed in this self-descriptive blog announcement of yet another pre-alpha release of an experimental text editor?
EDIT: Modern after-the-fact typo correction, be damned! Self-descriptive not 'self-deceptive'...
I think that putting Adobe's logo / name next to everything would overshadow all the work and contributions from the community.
-Adam Lehman Brackets Product Manager (at Adobe)
The flipside is Twitter Bootstrap, which was never an "official" Twitter project.
Flash - Difficult to work with (I know most beginners struggle with it). Dreamweaver - Bloated software that generates weird HTML code. Acrobat - Slow and bloated software. Can't a PDF reader be simpler ?
But as adrocknaphobia pointed out 'this isn't "Adobe Brackets", it's just "Brackets"'. Turns out there's no hiding after-all.
I'm not too impressed by the editor. It's like a less mature and worse version of cloud9. The only neat thing was the inline tag-based css editing window but I wouldn't switch editors just for that.
1. Make awesome software
2. Profit!
3. Party while software languishes (pure assumption)
4. FailVim. That is all.