Developers are quite conservative of their environment, but a cloud IDE could be awesome.
I want to write code on a 2 lb MacBook, with continuous build-as-you-type in the cloud on a fleet of Xeons that have larger CPU caches than my entire project.
Have 5, 50, 500 tests that need to run? Run them all in parallel continuously and get immediate red/green feedback in your IDE. Behind the scenes Lambda takes horizontal scaling from minutes/seconds down to milliseconds, so go radically horizontal.
I want my editor, exactly as I left it, down to the open tabs and cursor position, on any machine. And pair-programming Google docs simultaneous-edit style, without either party giving up the ability to run/debug the software on their own.
What if the FaaS/Lambda lifecycle management was tightly integrated in the IDE? Working on, testing, versioning and publishing a function could be re-imagined in a non-file centric way.
This is a great idea. It makes much more sense to run your tests in the cloud than on your local machine. I don't think it can be done 'as-you-type' due to resource constraints. But I do think it can be done pre-commit. As a programmer I'm waiting for my tests to finish for hours per day, leading to a lot of inefficient multitasking and distractions. Obligatory adapted XKCD http://www.codeproject.com/Articles/381622/Unit-test-and-the... If we can improve this it would be an amazing thing.
We're considering building this in GitLab I want a local client that pushes my working copy to GitLab and runs tests on it. GitLab can receive the code, commit it to a 'hidden' repo, and run the tests. Sending feedback about failing test or successful tests back to the client. The client could be part of an official command line client, currently we have community ones under CLI clients on https://about.gitlab.com/applications/
> I don't think it can be done 'as-you-type' due to resource constraints. But I do think it can be done pre-commit.
When you rent a Google Compute Engine machine, it doesn't matter how much you use the CPU, the monthly cost is the same (roughly $30/vCPU/month). So you incur no additional cost by restarting tests after each input character. And if we can spread multiple users' tests out over multiple machine instances, the cost would remain constant per user, but their tests would execute in parallel on multiple instances.
If you restart the tests it indeed doesn't matters less. Currently GitLab doesn't allow for an easy cancel and rerun I think. Also keep in mind that that testing can keep over 30 CPU's busy for 5 minutes. I think it makes more sense to start that when a human indicates it. But we can also consider 'restart as you type' and 'restart when you save'. Thanks for your suggestion.
That would be nice! For now we're offering static .gitlab-ci.yml templates for many languages in the interface itself so you can easily start. Making plugins is a larger undertaking.
Does a cloud IDE work well with a flaky network connection?
Any time I see a network-always-on browser-based service, I'm only interested in it if I can run offline and synchronize my state in the background.
Which is exactly what I do. I use a local editor on different machines. I sync my projects (git). I get builds and tests farmed out for me automatically (CI).
I'm just not dead in the water if I'm on a train, or a plane, or in a car, or my network dies, etc.
I haven't tried running C9 in a connection that intermittent or totally offline, but it does work well for hopping on/off across networks without losing local state in the browser.
Just tried C9 again -- You can change text in open files, but you can't open new files (doesn't seem to cache everything) and I couldn't refresh the browser view of my web app. To be fair, my app pulls some assets from CDNs, but if C9 gave me cached versions or just failed to load them I could have kept working. I'd say at this point, fully offline is too limited... at least if your use case involves many files and building web apps.
> I want to write code on a 2 lb MacBook, with continuous build-as-you-type in the cloud on a fleet of Xeons that have larger CPU caches than my entire project.
Your editor doesn't need to run remotely in order to do this; it just needs to be able to run things remotely in order to do it.
> I want my editor, exactly as I left it, down to the open tabs and cursor position, on any machine.
You could build this from syncthing and emacs, if you wanted.
> And pair-programming Google docs simultaneous-edit style, without either party giving up the ability to run/debug the software on their own.
You can do this, too, with emacs. It's just a simple matter of programming.
Why spend time reinventing the wheel when there's already a network-aware, extensible editor with man-centuries (man-millennia?) of extensions already built?
> You're telling me rsync already does everything that I want to do, when I'm trying to describe Dropbox.
Alternatively, you're trying to say that a McDonald's Happy Meal™ is great food, when I'm serving salt-crusted ribeye, served with fresh English peas, roasted sweet corn and garlic mashed potatoes with cream.
Good quality ingredients is the most important part, some chefs would say. You're right, but all you'd have to do is build an opinionated "skin" over Emacs, bringing together and properly configuring existing plugins, writing some new ones, and packaging it nicely.
I recently started using Spacemacs[1], and I'm basically sold on Emacs as an IDE-building toolkit. And I say that as a decades-long Vim user (I still use Vim, just as key bindings within Spacemacs).
Eh.. what? Cloud9 is the reinvention of the wheel. That's the point you missed. With far fewer features, it just happens to be packaged together nicely to suit a particular purpose.
Cloud 9 is one of many. In 3 years you won't remember the name.
It might be, but so was google. In addition, some of the greatest software is nothing more than bundling the right components together that existed before. Microsoft Office is not exactly unique, emacs can do that and was available well before it (emacs can do everything!). Wordpress is not really innovative, it's just a collection of things others already had, yet it is huge now. Point is, Emacs is missing to much to equal cloud9 right now. It might all be somewhere, but it isn't readily available in a form users of cloud9 would like.
So reinventing the wheel? If you refer to some magical emacs setup living somewhere on a fictional users local machine which is being cloned and made very real and available to the world. Yes they are reinventing the wheel. If it's easy, please make the fictional emacs become real and share it with us in a shown HN. I think there is a difference between a hacky approach that works and a product.
What if he doesn't want to spend the next 6yrs learning Emacs?
c9 has a very low entry bar. It's not reinventing the wheel, it's improving it. You can't really compare a terminal based editor, with an extremely high learning curve, to a preconfigured web based IDE.
>> Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
It's really not hard to use a decent text editor like emacs.
> You can't really compare a terminal based editor
emacs has supported X11 since at least November 1994 — your information is at least two decades out of date.
I've got a nice GUI emacs frame open right now.
> with an extremely high learning curve
Learning emacs is not really hard at all. There's a lot to learn, but that's because it does a lot. If something is quick to learn, by definition there can't be much substance to it.
> to a preconfigured web based IDE
Check out emacs prelude (https://github.com/bbatsov/prelude): it's a great some of mostly-sane emacs defaults in one easy-to-use package.
Heck, emacs out of the box is pretty great, too. It evens displays a nice little message about how to use its built-in tutorial.
> > If something is quick to learn, by definition there can't be much substance to it.
> That's as wrong as 2+2=5.
If something can be quickly learnt, then it can't have been too different from what one already knows: i.e., the diff between HEAD & HEAD~1 is relatively small. But small diffs don't do much.
Emacs has a gentle but very long learning curve: it's quick to pick up (quicker than vi!) because it does have some similarities to tools one may already be familiar with, but there's real depth and complexity to emacs as a whole, which means that one never stops learning it. Kinda like life in general: being born was easy, and we never stop learning after.
As someone that's tried many times to learn Emacs, I found Vim's basic features a lot easier to pick up.
I think that may be because all the mode changes are single keys, rather than Emacs, where I constantly have to ask things like "Okay, was it control, alt, meta, or some combination + S to save my file?"
Vim does the : command line thing, but it's an actual command line, with editing, rather than a series of hotkeys.
This annoys me because I'd really like to learn Emacs. It seems you can live in it - but the learning curve is hardly gentle.
I have more or less the same problem coming from vi(m). I forced myself to use Emacs for about 2-3 months to get past the "this is hard because it is unfamiliar" stage.
I found Emacs to be relatively pleasant as an environment for hacking source code but I was nowhere near the same level of proficiency at editing with it after several months of usage compared to where I was within a few weeks of forcing myself to learn vi(m).
Emacs has a lot going for it as far as out of the box functionality and the ease of installing packages but it seems that unless you want to take the time to dive deep and learn the minutiae of elisp and configuration you are never really going to become super proficient with it.
The one thing I did come away with after using Emacs was that swapping ctrl/capslocks is the best thing ever and helps even with vi(m) and I now do that for all my environments even though I never touch Emacs anymore.
At the risk of sounding precocious but I doubt a novel programmer today has as much time for a project as the folks had back in the 70s and 80s. Development cycles have gotten much, much shorter. And there are already numerous tools which you have to learn for an efficient workflow, like build and testing tools, code repositories, etc. Every bit of time saved in dealing with your environment rather than the actual programming problem at hand is very valuable nowadays. Remember software has always been about raising productivity, not just of an industry but of the developer himself. Eventually we'll look back on programmers using text editors and rsync for development and deployment the same way we look at people developing software in Pascal and BASIC.
> And there are already numerous tools which you have to learn for an efficient workflow, like build and testing tools, code repositories, etc.
emacs already has interfaces to build and testing tools. It has Magit, the best git interface I've used.
> Remember software has always been about raising productivity, not just of an industry but of the developer himself.
That's why I'm advocating a user-extensible editing environment! That's why I use emacs.
> Eventually we'll look back on programmers using text editors and rsync for development and deployment the same way we look at people developing software in Pascal and BASIC.
We emacs users already look at folks using editors and rsync for development that way: we have TRAMP (https://www.gnu.org/software/tramp/), which enables one to run an editor locally on remote files. One can even run commands on the server a remote file is located on.
There's no reason that elisp can't be written to spin up DigitalOcean droplets, AWS EC2 instances, fire off Lambda code, deploy pods to kubernetes, control a Mesos cluster, &c. &c. &c. And if one does that, one gets all that plus a world-class, best-of-breed text editing environment with millions of lines of code to do just about anything else one might want to do already written.
Or one could spend time trying to extend a proprietary product, running elsewhere, ignoring forty years of experience and improvements. One could try to reinvent the wooden wheel while others are running transcontinental airline service.
That's really how I feel: every day I'm taking a teleporter to the office, and meanwhile I'm watching others talk about how they've noticed that if they rub a pair of sticks together they get pretty warm. I'm not saying that the folks busily reinventing fire are dumb — most definitely not: they're brilliant — but rather that no-one has bothered teaching them all the innovations which have occurred since fire was first invented.
Setting the metaphor aside, our industry seems to do an amazing job of utterly refusing to learn from and develop on the past. Every half-decade or so someone comes along and reinvents things which were truly groundbreaking ideas before I was born. We seem to be stuck repeating 1970s computer science, over and over and over, rather than trying to live in the 2010s.
I think it's clear to everybody here that you can integrate any type of functionality into emacs. But if most new programmers prefer browsers, then that's what they are going to use... Maybe they just prefer building tools on top of javascript/css (where they can create actual GUIs) rather than lisp. For most programmers this is kind of a moot discussion because usually you don't get to choose the tools yourself and have to make do with what's supported. On a side note: Your TRAMP teleporter appears to use rsync most of the time anyway ;)
> But if most new programmers prefer browsers, then that's what they are going to use...
If most new programmers prefer to edit code in browsers than in editors, then they are just wrong. I don't know why the preferences of new programmers should matter to professionals any more than the preferences of peewee football players matter to the NFL. The whole point of education is to improve people, not leave them satisfied where they are.
> Maybe they just prefer building tools on top of javascript/css (where they can create actual GUIs) rather than lisp.
Anyone who prefers JavaScript to Lisp or SmallTalk is just wrong. And, of course, one can create 'actual GUIs' in Lisp or SmallTalk just as in JavaScript. In fact, SmallTalk kinda invented the GUI IIRC.
> On a side note: Your TRAMP teleporter appears to use rsync most of the time anyway ;)
At least in my experience it's mostly SSH, not rsync.
> Anyone who prefers JavaScript to Lisp or SmallTalk is just wrong.
I also happen to share that opinion, but the trick is to avoid falling into the Smug Lisp Weenie trap.
It is amazing how primitive most editors are in comparison to Emacs. However, what is also amazing is how fast they are progressing. I've been trying (of all things!) Atom, and it is already adequate for most folks.
Just the other day I've overhead colleagues talking about how some editor (MS Code?) finally added tabs. I kept to myself, but couldn't help rolling my eyes. Not only buffers are more practical (specially if paired with something like Helm), one could hack their own tab bar in a reasonable amount of time (or just download something to do so).
Recent editors are just not customizable enough (not yet, at least). Doesn't matter if they are written in Lisp or BrainF*ck.
> the trick is to avoid falling into the Smug Lisp Weenie trap.
Yeah, I know — that's why I included a shoutout to SmallTalk, another great language. There are any number of truly great languages out there (ML, Erlang also leap to mind), although not all of them are great for writing a great editor.
It's hard to avoid being a Smug Lisp Weenie when one sees so much effort wasted on haphazardly reinventing stuff which has been working well for decades elsewhere. Why not spend a few hours or weeks improving what is already great rather than spending years building something new which will probably never be great?
It's probably the thing which makes me most bitter about our profession: the amount of sloppy and wishful thinking, which includes ignoring the numerous lessons of the past. Can you imagine where automotive technology would be if every new engineer spent the first decade of his career playing with rubber trees and ore trying to develop tyres and engine-suitable alloys rather than building on over a century of experience of others?
What's really weird is that there's so much new territory to explore in our field. We're spending entire careers re-exploring our own backyards when there's an entire continent out there to discover.
One of the most important metrics for a language is the number of people using it.
For new programmers learning elisp adds possibility to create best possible editor on base of emacs (a problem they still don't want to solve), learning javascript allows to find a job (a problem many want to solve). When they learn javascript for their day job, they like the language that gives them power to create things, and they don't see emacs as great, because what they can do for js based editor in hours, will take them months in emacs.
But all that aside, the most important advantage building editor in the browser instead of in emacs, is the huge amount of work that large groups of very good engineers put into making browsers fast, stable and well documented. Small emacs team never can make the part of emacs written in c on par with browser, even for handling the small number of features needed for the ide.
So on one hand we had to redo some of the things lisp had acomplished earlier, on the other hand there is a high chance we won't have to redo in the future what web is doing now.
It's funny that you use the 2 lb Macbook as an example. Mine has a terrible problem with its wifi, requiring me to restart it every minute or so. It's unusable with Cloud9's IDE.
Furthermore, their IDE is extremely slow and vim mode is broken. Other than that, I share your ambition and hope that one day some other company will solve this. Perhaps Microsoft will be the first. Visual Studio Code has as a nice web-based editor.
Hyperdev does the cloud IDE thing pretty well; I spun up a half-serious prototype of a web app in a weekend, and sitting down at any nearby computer to hack / run / test really was a joy. I even logged in from my iPad to fix some css (not painless, do not recommend, but it worked.)
Nothing to install, no environment to configure, just log in and start editing.
I remember trying it, and Fog Creek is a company I really like and trust, but it's hard to tell if they're interested in turning HyperDev into more. I want it to be a fully professional development environment, and today it's "JSFiddle for backend".
Side note: I have really wanted to get this _exact_ testing setup with aggressive parallelism running on a large Django app.
Lambda would be cool, but really any way to spin up several machines near instantly and for just a few minutes without paying for full hours would suffice. GitLab CI has helped lots.
If you're seriously pursuing it at all, we should talk more.
Another thing I've always wanted is when working on two feature branches, or a feature branch and separately a hotfix branch -- to leave my open files in the IDE, virtual environment, git untouched and have both co-exist.
Sublime doesn't handle this too well today.
Sure I can setup all of this manually a second time, but it takes too long to be practical.
I want to write code on a 2 lb MacBook, with continuous build-as-you-type in the cloud on a fleet of Xeons that have larger CPU caches than my entire project.
Have 5, 50, 500 tests that need to run? Run them all in parallel continuously and get immediate red/green feedback in your IDE. Behind the scenes Lambda takes horizontal scaling from minutes/seconds down to milliseconds, so go radically horizontal.
I want my editor, exactly as I left it, down to the open tabs and cursor position, on any machine. And pair-programming Google docs simultaneous-edit style, without either party giving up the ability to run/debug the software on their own.
What if the FaaS/Lambda lifecycle management was tightly integrated in the IDE? Working on, testing, versioning and publishing a function could be re-imagined in a non-file centric way.