PhD Comics: Academic Salaries - <AUTHOR> http://www.phdcomics.com/comics.php?n=1086

<comment><USER2> To be fair, the numbers are not directly comparable. The football coach salaries are only for division I teams, which most schools don't have; the mean and median football coach salaries over all schools is probably much lower, and the academic salaries at schools with division I teams may well be higher than average.

In essence, this is comparing the average salary of the top 150 best-paid football coaches to the average for all academics. It would be interesting to see what the average of the top 150 academic salaries is.

<comment><USER3> Not to mention the fact that many of the top 150 academics would have side income as consultants, expert witnesses, etc.

<comment><USER4> If you consider that, you have to consider the non-monetary benefits of being a football coach, which are probably huge.

</comment></comment></comment><comment><USER5> Yep, that's the way it is.

Universities are only incidentally about knowledge and learning.

Please do not confuse the grant money draw that is research with either teaching or learning. Clearly they are part of it but money is the main driver.

Money is priority #1, that's why sports are so important.

Money is important to students as well, the bulk of the income their degree will generate depends on the reputation of the school, _not_ on how much they actually know.

And that's when they are first entering the job market. After that first job, the only way college matters is through the relationships you built there. Obviously relationships you build at work matter more and more over time.

And here again sports is important in creating that image of tribal success that draws the people that you want to connect with, to make it far in life after college.

That's the way life and college work.

If you don't like this harsh and cynical money based game, go to a school that doesn't have a sports program and be a scholar. And if you do that, don't ever think about money.

If you do find yourself thinking about money, especially more then is needed to simply survive, then get an MBA... preferably from a school with a very successful sports program.

<comment><USER6> That's true in the US, but sports has barely any importance at all in British universities (and perhaps applies to the EU generally). Okay, we all know about the Oxford vs Cambridge boat race, but beyond that, there's no public exposure to university sports.

I think the focus on sports at US colleges says a lot about the US, rather than universities or the education system in general.

</comment></comment><comment><USER7> The true injustice is how much money universities make on the backs of athletes who don't earn a red cent. And the coach salaries demonstrate the value of collegiate athletics, adding insult to real injuries.

<comment><USER8> I don't understand this view that just because you're doing work you deserve to get paid. Rowing was the first amateur sport in the United States, and if you look back at the history of why Rowing when amateur in the late 1800s then you see there are some very good reasons. The reason the NCAA is amateur is because it creates a better experience for athletes. You don't have to worry about people fixing the games, getting stabbed, being pressured to take steroids, sports overshadowing schoolwork, etc. If athletes started earning a salary then you'd see a lot of the best student-athletes give up sports overnight. I certainly would have.

Furthermore, schools aren't making money on the backs of athletes, they're raising money. That money doesn't get redistributed to shareholders, it gets added to the endowment and spent on the university. If anything student- athletes should get an income tax credit on their first X dollars earned after college rather than a check, basically a modified form of the tax credit they would get for any other charitable contribution.

<comment><USER7> That's a very naive perspective. Briefly,

* There is tremendous pressure to juice for any athlete who hopes to go pro or even be competitive.

* People gamble heavily on collegiate athletics. Of course you have to worry about fixed games.

* Look at USC, Miami, or just about any major sports school: The players barely have to attend class to remain eligible.

* No, they're making money. Take a look at the salaries of coaches, athletic directors, and college presidents and think again. If universities cared about endowments, they'd spend the athletic dollars on academics, investing in contributions from future alumni.

I highly recommend "What's My Name, Fool!", specifically the section on collegiate athletics (page 230).

[http://books.google.com/books?id=ut3M85a6yTMC&dq=What%27...](http://books.google.com/books?id=ut3M85a6yTMC&dq=What%27s+my+name,+fool&pg=PP1&ots=qpDGt6hEac&source=bn&sig=kEjOQBDaMbUH6EG5Cm3BOBzo9LA&hl=en&sa=X&oi=book_result&resnum=4&ct=result)

<comment><USER8> It seems to me that your view of the 380,000 U.S. student-athletes is heavily skewed toward on the 200 people you see on TV. Creating policy based on this view is the equivalent of designing child protection laws to benefit the one missing white girl on CNN.

I'll check out the book though.

<comment><USER9> College basketball + College baseball + College football = thousands of players. Even though it might be a small percent of the total, it's still a significant amount of people.

<comment><USER10> And a free ride to a good school is the equivalent of a 50+k a year salary without working the full year.

<comment><USER9> True. But being a division 1 athlete is significantly more difficult than most 50k per year white collar jobs.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Sure, this seems unjust, mainly because none of us are professional football coaches (I'm assuming).

But I'm not sure what point the comic is trying to make, really. If this imbalance in pay pushed top academics to drop their career and switch to coaching football, I could understand the argument that it's harmful. I highly doubt that's the case.

<comment><USER12> As an academic in training(phd student), I would never want to be a football coach at a top school. The hours they have to work to remain competitive are insane. One bad season or embarrassing loss to a rival and you will be fired. I'll take the promise of tenure over the extra pay. Also as previous posts have stated the imbalance in pay is skewed by comparing top coaches with all academics. I'm pretty sure coaches at a Div III school are not paid in 7 figures, probably not even 6 figures.

<comment><USER13> I don't think I would take the promise of tenure over a job that pays me 12x the salary. Even most Div 1 coaches last more than 3 years.

Also, it's far better to make $3 million in 3 years than it is to do so in 30.

</comment></comment></comment><comment><USER14> where's the companion graph of how much money each of those people bring in to the university?

<comment><USER15> Excellent point. While you're at it, make sure to include the salaries of the players.

Or are we applying corporate-compensation logic, in which all the money that a company brings in is credited to the CEO, who promptly gives himself a lavish raise?

<comment><USER16> It's my opinion that college football players should receive salary, or at least be able to accept endorsement opportunities. There would be a decreased financial motivation to leave school early.

There's a ton of downside to this, I know, but I don't think that universities should be regulating what sort of money their students bring in.

<comment><USER17> They receive salary in the form of a scholarship.

<comment><USER18> Thank you.

Another way to look at it is that the university is 'paying' them with a free education, and 4 years with no financial obligations. Depending on the school, that has the potential for massive financial equivalents.

<comment><USER15> I agree that a scholarship has a nonzero value.

That said, let me propose a deal for you: Instead of being paid for your next four years of work, your employer gives the cash to a university. In return, the university gives you a four-year scholarship with a value equal to your deferred salary plus X%. Note that the scholarship is nontransferable, it cannot be deferred, and you cannot stretch it out over more than four years, unless the university agrees to give you a single extra "red-shirt" year. Also, if you quit your job, you lose the scholarship, so don't expect to be a full-time student unless you're _really_ good at multitasking and don't need a lot of sleep.

How large does X have to be before you accept this offer? My guess is that it is considerably higher than zero.

<comment><USER18> Right, I think we're both in agreement here. To say that college athletes are unpaid workers isn't exactly true, but it also isn't entirely honest to say they're paid like a regular job. I responded to the parent of my post because it had been down-modded for simply saying scholarships are a form of payment.

If I were a high-school kid coming from a family with very little ability to help pay for college I'd say that sounds like fantastic deal.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> It's crazy how fanatic people are about sports. I know in Europe there are gangs that kill each other based on what soccer team they support. Is this just because we can't go out and make war on the neigboring village anymore?

</comment><comment><USER20> For the benefit of non-American people like me, can someone explain what this thing with athletic scholarships in US universities is all about? To me it just seems silly, like a sports team having academic scholarships would be.

<comment><USER21> Particularly with football, the players would not be able to afford to go to college without a scholarship, nor get into college without receiving some preferential treatment.

<comment><USER22> That does not answer the question. You could just pick poor bright kids to give scholarships to, instead of athletic kids.

<comment><USER21> I'm sorry, I think I might be misunderstanding you, so I'll try to elaborate some. Each athletic program has a certain number of scholarships they give out. In the case of football, these scholarships are awarded almost entirely without regard to the academic quality of the athlete. How true that last statement is varies greatly from school to school, but in general, they only need to meet some pretty minimum requirements. If your question is _why_ do schools do this its because football brings in a LOT of money.

The same thing happens to a lesser extent with basketball, but for the most part other athletes of other sports have to earn there way in to school like everyone else.

<comment><USER20> So the universities do it because it's a money-making proposition?

<comment><USER21> Yes, college football is insanely popular. I live in a county of 200k people that has absolutely no trouble filling up a stadium of 90k people for home games. The skyboxes sell in the millions, and the best seats in the stands require a 10k/year donation for the right to purchase them. TV deals are also very lucrative, and I would assume so is merchandise.

<comment><USER23> This sounds a lot like what I experienced at the University of Florida.

<comment><USER21> This is not a coincidence :P

I don't think UF is really very different than a lot of the other major football schools. Most of them are in pretty moderately sized cities, especially in comparison to cities with professional teams. Green Bay is the only NFL city that's college town sized.

<comment><USER23> What's your major?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I once read that the highest paid employee of 20 some states is a college football coach. I know it's true in good old Ohio.</comment>


The Advantages of Being Different - <AUTHOR> http://www.mpg.de/english/illustrationsDocumentation/multimedia/mpResearch/2007/heft01/015/index.html

<comment><USER2> Excerpt:

 _Ornithology

The Advantages of Being Different

Zebra Finches Display Remarkable Differences in Their Individual Sexual Behavior

by Christina Beck

      .

The male zebra finch shakes himself after the scientist opens his hand and releases the bird into the cage but he doesnt appear to be put out by this involuntary displacement. Instead, he ruffles his head and neck feathers and immediately starts to court the only female in the cage. Her reaction is one of diffidence, reluctance hes really quite a womanizer. Zebra finches display remarkable differences in their individual sexual behavior, says Wolfgang Forstmeier. Many males begin to court a female immediately and persistently, while others are surprisingly shy. The females, too, all react very differently: some are prepared to copulate with one or more males immediately, while others strictly reject all advances.

Extrovert or introvert, confident or shy, macho or softie observers may use attributes like these to describe human beings, but surely not birds? On the contrary, says Forstmeier, such personality traits can be observed in young zebra finches early on, and they are still apparent years later._</comment>


GitLab 8.17 Released with GitLab Pages in GitLab CE and Squash on Merge - <AUTHOR> https://about.gitlab.com/2017/02/22/gitlab-8-17-released/ <comment><USER2> Consistently impressed and surprised with how quickly GitLab appear to be able to deliver value to users. I am certain that we will be using both Pages and Squash on Merge in the near future.

</comment><comment><USER3> Nice! Excited about squash on merge finally making its way into Gitlab.

<comment><USER4> Great to hear; It has taken us a bit longer than we wanted, but we're happy it's here. Let us know if there are any further improvements we can make.

<comment><USER3> We've started using Gitlab at work and fully plan on getting off Github, just because the experience is so much better.

My only other issue is the the UI in the merge requests. It all seems to run together and it's difficult (for me at least) to get a handle on what's going on with comments and the status at the top.

<comment><USER4> That's great to hear.

We're working on making it easier to see what is happening in merge requests. It's the intersection of much of GitLab's power [0]. I see some thing in the issue that might help your case, but I'm also sharing your comment there. If you have more comments, please feel free to leave them in that issue or to me directly.

[0]: [https://gitlab.com/gitlab-org/gitlab- ce/issues/25424](https://gitlab.com/gitlab-org/gitlab-ce/issues/25424)</comment></comment></comment></comment>


Ask HN: Are there any Code Camps based on C and Python? - <AUTHOR> I'm looking for immersive learning - "Code Camp" - based on C, Python, instead of the normal JS plus <insert framework/web stack here> type curriculum.  Learning on my own, I make good progress for a few days, then have to go back to work, and forget most of what I learned.
I would like to find the 3 to 6 week, immersive, on site atmosphere like at many Code Camps, but for C, Python, maybe Django, and a database maybe Postgres. (Not Mongo or other "noSQL".)
Location doesn't matter, would relocate for the duration within US, (or London as a remote possibility).
Thanks! <comment><USER2> [http://byteacademy.co/all-courses/software- development/](http://byteacademy.co/all-courses/software-development/)</comment>


Cryptographically and Constantly Changing Port Opening - <AUTHOR> http://www.jgc.org/blog/2007/11/cryptographicallt-changing-port-opening.html A little layer of security I use for my servers. <comment><USER2> I'd like to get expert advice on this (cperciva or rtm?)

I guess we can agree that it doesn't fix any security problem; it's just redundancy, right? In this case, it's not another link in a chain but an additional layer of security. But is it "defense in depth" or just plain paranoia? Defense in depth is believed to be a good security principle; paranoia is not, because you don't use the rational part of your mind anymore so you don't focus where it's important and you're blind to some attacks.

So, the question is, do you think this trick actually:

\- makes the system more secure;

\- makes the system less secure;

\- is irrelevant to security.

edit: jgrahamc, I didn't notice you were both the author of the trick and the submitter; can you provide some rationale backround?

<comment><USER3> Well, it depends how you look at the problem. Brute force attacks against SSH are a real threat, but this can be mitigated in different ways.

<comment><USER3> I didn't have a chance to post a more elaborate response earlier but I'll give it a shot now. The problem that needs to be addressed is the ability of attackers to brute force the SSH service. In order to mitigate this one should

1) Use only public key authorization for SSH or 2) Use VERY STRONG passwords 3) Have a long limit between password attempts or 4) Have the computer blacklist any IP that tries to log in unsuccessfully more than X times (where X ~ 10) 5) Have SSH running on a non-standard port. This will deflect the majority of automated attacks but will not stop a dedicated attacker. 6) Use port knocking or the technique described to allow only users with some knowledge of the system to be able to talk to the SSH service 7) MONITOR YOUR LOG FILES. An attacker should not EVER be able to brute force passwords for a few days without YOU noticing.

Now you are free to layer as many of these as you need and each will reduce the probability of a successful attack, but you need to take into consideration the cost vs risk. For example the technique described in this article offers added security but places limitations on connecting to the machine (from a client that has the right algorithm, with synchronized clocks, and also make sure not to make a mistake otherwise you'll get locked out for 15 minutes which can HURT if you're dealing with a critical matter).

Personally I like the concept but I think the added costs are too great and compared with using some of the other security mechanisms.

</comment></comment></comment><comment><USER4> How do you make sure the times are synchronized?

Why don't you just have your server broadcast a bunch of bits that change every minute and use them instead of a timestamp to hash with your secret?

Your protocol seems vulnerable to eavesdropping, technically couldn't someone sniff any client's packets to find out which port to connect to?

Also, I suppose you have some kind of tolerance for when you send a packet to the server at minute x and 59 sec and it arrives at minute (x+1) and 01 sec?

<comment><USER5> Yes, you are correct this approach would be vulnerable to a simple man-in-the- middle attack. Just sniff packet headers to find out what port the server is accepting indicated by packets sent back with an ACK flag set. Headers with that flag set will be the currently valid port at that instant, since all other packets will be sent back with RST set (blocked).

And yes you could have potentially very frustrating synchronization problems. With TCP you wont be able to control certain things such if a connection request is going through exponential back-off due to network congestion. For example, lets say you could make a connection request within your alloted tolerance, but if there is network congestion and your NIC is not getting either RST or ACK packets back, it will continue to send connection requests at continuously increasing intervals which you cannot easily control since its done at the transport layer. Then one of your connection request packets finally reaches the server late, and you are blocked from connecting again for 15 minutes.

If you could work around the second issue though it could work. I think its a great idea in general, nice creative work!!

<comment><AUTHOR> So the way I currently have it the man-in-the-middle is useless because once a client connects to the SSH server all other IP addresses are locked out from that port.

I agree about congestion, but IIRC the TCP connection timeout defaults to 75s so since I'm tolerant to connections across two windows (i.e. two minutes) then I think I'm safe.

John.

<comment><USER5> Ah, so your server only accepts 1 connection at a time on a given listening port? That is good protection.

I didnt realize there was a TCP standard for the max acceptable amount of retransmissions. But yeah if you can account for this with a pad then you should always be safe.

If you ever opensource your network code I'd love to see it.

<comment><AUTHOR> I plan to open source it once I get it a little cleaned up :-) It's on my TODO list.

John.

</comment></comment></comment></comment></comment><comment><USER6> Why am I reminded of the poison scene from The Princess Bride?

</comment><comment><USER7> "Both bits of software hash this secret with the current UTC time in minutes (using SHA256) to get 256 bits of random data."

Not random...

<comment><AUTHOR> Agreed. A hash could be a good CPRNG, but if I want to claim randomness I probably should use a cipher with an incrementing input.

John.

</comment></comment><comment><USER8> I just use non-dictionary-based passwords and denyhosts.</comment>


Ask HN: Any good sites for following product/tech legal issues? - <AUTHOR> Like new cases coming up, to be decided, etc. regarding tech, startups, antitrust, etc. from a legal perspective? Even caselaw or regulations in one place. Maybe a site or really good blog that follows/FAQs this stuff. <comment><USER2> [https://www.techdirt.com/](https://www.techdirt.com/)</comment>


Demand for sand is fuelling murders, mafias and ecological devastation - <AUTHOR> https://www.abc.net.au/news/2020-01-11/illegal-sand-trade-india-mafia-murders-vince-beiser/11779570 <comment><USER2> The article just states "Sand from the desert is unsuitable for construction," without further explanation. A search on that comes up with:

"Desert sand grains are finer and smoother so their surface chemistry would not be able to offer sufficient number of multidirectional chemical linkages. ... Sea sand does not have high compressive strength, high tensile strength etc so it cannot be used in construction activities."</comment>


Atom - <AUTHOR> http://atom.io/ <comment><USER2> From "The Zen of Programming":

\</comment><comment>

Hearing a disturbance, the master programmer went into the novice's cubicle.

"Curse these personal computers!" cried the novice in anger, "To make them do anything I must use three or even four editing programs. Sometimes I get so confused that I erase entire files. This is truly intolerable!"

The master programmer stared at the novice. "And what would you do to remedy this state of affairs?" he asked.

The novice thought for a moment. "I will design a new editing program," he said, "a program that will replace all these others."

Suddenly the master struck the novice on the side of his head. It was not a heavy blow, but the novice was nonetheless surprised. "What did you do that for?" exclaimed the novice.

"I have no wish to learn another editing program," said the master.

And suddenly the novice was enlightened.

<comment><USER3> > Sometimes I get so confused that I erase entire files

OT, but just this week my wife did something that really got me thinking about how far computers haven't come in terms of usability.

I heard her say "O crap" from behind her macbook, and out of habit I came to assist.

For some reason unknown to both of us, she had pasted the text of an email into a document called "thesis.docx", and then saved it.

The text was completely unrelated to "thesis.docx", which of course was not backed up.

Now, I love my wife deeply. And she is no fool. On the contrary, she is a graduate student.

Moreover, I completely understand how something like this can happen. We have two small children, and it was the end of the day. It is just too much to expect of the human mind that one should not say something one doesn't mean.

I felt guilty on behalf of my profession that this was the best we had to offer. Microsoft word on a macbook, and your penultimate version of a file is not backed up. It truly is intolerable.

So, while I have had some of my greatest highs using emacs macros, I somehow feel that the brilliant tooling made by developers for developers never quite percolates into userland.

<comment><USER4> VMS file versions solved that problem in the late 70ies. We are not learning anything from out history as a profession.

<comment><USER5> I'm a loyal unix guy but as a millenial without much actual hands-on experience with VMS I always love to hear anecdotes like that :) The first time I read about it was in Clifford Stoll's Cuckoo's Egg where it seemed as if there was constant competition between UNIX/VMS folks over which was the more sophisticated/elegant operating system - mostly good hearted competition of a more civilized age of course ;) I vividly remember the one encounter I had with it's weird shell where I had to re-configure an application running on an Alpha machine which had a consecutive uptime of something like 12 years...

One of humanity's biggest enemies to progress are "Not invented here" and the cult of youth. It's often better to start with a blank slate ("being ignorant") because amongst other things like simply having a different perspective (worth 100 IQ points ~Alan Key) it helps with actually starting to build something. Eventually though we should still be aware of what we as a collective have learned already.

To be fair I think Github folks should know their history so this project might be one of the exceptions - looking forward to it! <3

<comment><USER6> How do you differentiate "the cult of youth" from "it is better to start from a blank slate"?

Side note: Neither of the two issues you mentioned are "one of humanity's biggest enemies to progress."

<comment><USER5> I guess it boils down to respect - for both sides, young and old. Thanks for the compiler error ;)

</comment></comment></comment></comment></comment></comment><comment><USER7> I was all ready to be skeptical and everything... but this could actually be amazing.

I currently use Chocolat for code editing, which is beautifully elegant and I love it, but there are 25 little tiny things that I _really_ wish I could fix. I file issues, but the developers rightly have their own priorities. It's closed-source, but even if it were open source, I'm not about to learn how to use XCode and Objective C and figure out how to compile and whatnot.

But if Atom is ultimately just a big collection of straight-up node.js files, and anyone can go in at any time to change a line here or there -- and it's in _JavaScript_ , so it couldn't be easier for programmers in general -- and there's no compilation step or anything -- then it's almost a fundamental paradigm shift for what desktop software could be.

It already makes me dream of a word processor I could hack like that, or a music player. Just by opening up a text editor. It's an inspiring thought.

<comment><USER8> > and there's no compilation step or anything -- then it's almost a > fundamental paradigm shift for what desktop software could be. > It already > makes me dream of a word processor I could hack like that, or a music > player. Just by opening up a text editor. It's an inspiring thought.

Not to rain on your parade or anything, but you can already do this with Emacs, not to mention that Emacs is free, open source software. Atom is not only not open source but their readme says it won't even be free after the beta.

Emacs has been around for almost 40 years, and because it's FOSS it will be around for at least another 40. Editors like Atom come and go.

<comment><USER7> True, but it's a question of accessibility.

Far more people can program in JavaScript than Lisp, and far more people use GUI desktop software that follows traditional GUI user-interface paradigms, than do things inside their terminal. (Edit: or terminal-style buffers/frames.)

So that's why my statement was limited to what " _desktop_ software" could be. :) I mean, I use LibreOffice, which is FOSS, but I am never going to touch its code in a million years. The cost-to-benefit ratio is too high. But Atom makes doing that sound almost trivial. That's the paradigm shift.

<comment><USER8> Emacs is GUI desktop software. Few people use it in a terminal.

Also, people didn't born knowing Javascript. They learnt it. And one could argue that Lisp is just as easy to learn, if not easier.

<comment><USER9> I mostly agree with that although I think it's also kind of irrelevant in a practical sense because many programmers already have to know javascript for their work so you get a lot more people who can contribute right away.

Aside from that -- lisp or javascript as the extension language, I'd love to see a brand-new extensible editor like emacs just to have a shot at changing terminology and some of the APIs. Emacs terminology is a little off-putting because it was invented before the GUIs were widely adopted so it doesn't map that well. I also find some of the APIs a bit weird, but that could just be me.

<comment><USER8> It's true that a lot of people work with Javascript, but honestly I wouldn't say that they can contribute to anything right away. A lot of these people don't know more than

      $('#element').hide();

In fact, I would wager that there are more potential contributors to Emacs than there are to Atom.

<comment><USER10> But if someone just wants to customize their text editor, $('#element').hide();, or something not orders of magnitude more complex, would actually be useful.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> > A hackable text editor for the 21st century

I'll fix: A proprietary (unhackable) text editor that only runs on OS X.

I imagine that web developers will drool over this.

<comment><USER12> Where are you getting this from? I can see all the source at [https://github.com/atom](https://github.com/atom). Every repo I checked has the MIT license.

<comment><USER13> Can you build a fully functional version of Atom just from those repos?

To compare, Apple releases source code for some components, but they definitely don't distribute "/System/Library/Extensions/Dont Steal Mac OS X.kext".

<comment><USER14> I thought that file was a joke until I checked it and it actually exists. For those (like me) wondering what it does: [http://en.wikipedia.org/wiki/Apple%E2%80%93Intel_architectur...](http://en.wikipedia.org/wiki/Apple%E2%80%93Intel_architecture#Dont_Steal_Mac_OS_X.kext)

<comment><USER15> Oh my, "DSMOS has arrived" line (and subsequent freeze) is gonna haunt me for years.

</comment></comment></comment></comment></comment><comment><USER16> There's real opportunity here for Github and I hope they take it.

Why is the basic workflow of the modern-day programmer split over multiple tools and over multiple systems?

Aspects of Github could be modularised and added to the editor while still keeping the underlying tool simple and this could change our user experience for the better.

Imagine flipping through your pull requests in the text editor and then seeing your friends comments and code reviews appear on top.

Imagine an issue being created on Github and the file(s) referenced instantly glowing.

This opens doors to thinking about the engineering workflow in a new holistic manner.

<comment><USER17> Why is seeing your friends comments and code reviews in the text editor any better than seeing them in the browser? Are we becoming this lazy? or this busy?

<comment><USER18> i see people saying less context switches. but isn't this the exact opposite? it's way more context switches?

isn't this the same as having our mails popup up notifications every so often or your gmail aggregating twitter and Facebook, because people thought it would make them more productive

<comment><USER19> Exactly - making context switches cheaper isn't very helpful if you're doing so at the expense of making context switches more frequent[0].

[0] and easier to do "by accident"

<comment><USER20> This is a silly argument. You're all assuming this type of integration will be have the UI quality of your dishwasher.

Of course context switches and irrelevant information will be distracting _if done poorly._ This is a UX challenge—not a reason to abandon the idea.

Having the focus you need during concentrated tasks such as coding, while also enabling the integration of other tasks—such as high-level team context awareness and collaboration—is the key design challenge. Done well, it would be a killer app.

Done poorly, as with anything, it will fail miserably.

Programmers have a poor reputation for UI design prowess, and programmers tools are sadly usually made by programmers, and thus carry the same reputation. Very few amalgam programmer/designers exist to bridge the gap of motivation and ability to design a better toolset. But they do exist.

Let's be optimistic, shall we?

</comment></comment></comment></comment></comment><comment><USER21> The more I see new editors floating around, the more I'm sticking to VIm. I am getting old, or it's a just a survival instinct.

On the other hand, the more the better, but we have already too many editors around.

<comment><USER22> I've sworn by SublimeText until now. And Atom is getting released during a time when I'm increasingly learning to love console-only computing. I envision a day when I can travel the world with a cheap laptop/chromebook and do all my coding remotely via SSH.. and Vim is very much at the core of that dream.

Now I just have to master it.

<comment><USER8> Try using the Vim plugin (Vintage or the newer one, Vintageous) with Sublime. That way, you can gradually get used to modal editing.

I worked like that for 8-10 months then made the switch to Vim. I've gotten so used to modal editing (not to mention window management etc.) by then, that I didn't even skip a beat.

<comment><USER23> This was my strategy when I switched from TextMate to Sublime a few years ago, the plan being to make the full switch to vim in a few months.

Sublime never gave me a reason to go all the way, though :p

<comment><USER8> I was like that while using ST2. But then better plugins started appearing for ST3 (the aforementioned Vintageous being one of them) so I switched to ST3.

But it crashed constantly; also, by that time the Vim emulation was really hurting me. The dot command was anemic, tabs were interfering with splits etc.

All in all, Vim was calling me, haha.

</comment></comment></comment></comment></comment><comment><USER24> I am very excited about this, I love the Github team and this looks like a great tool.

My only question is -- why should I switch to this from Sublime Text? Are there specific use cases it handles better out of the box, or is it more of a modular base that will be expected to grow and outfeature ST2/3's seasoned plugin economy? I am very happy with Sublime Text now, but I would be willing to switch if either it gained a lot of traction, or could do stuff that I couldn't do with Sublime.

<comment><USER25> In practice, the ST3 API is extremely limiting and poorly implemented. The docs are both lacking and dated (read incorrect). It is trivial to crash ST3 by making the incorrect sequence of correct API calls. It is also common to resort to polling the editor to make up for other deficiencies. The API also only allows for extremely limited UI choices forcing highly unintuitive interfaces on end users. The ST3 runtime also features such gems as not shipping the ssl module on linux (while ST2 stripped out even more stuff).

I also expect NPM to be much better in practice than the sublime package manager which frequently ships broken code. JS is a better choice than python for async code which will make writing plugins easier.

Furthermore, ST is 3 people who largely ignore all feedback from the community regarding bugs and features. It won't be hard to out compete ST in the long run.

<comment><USER26> I don't know if I'd call it extremely limiting… there are some places I'd like to see more accessibility. However, I've built some pretty extensive stuff with it.

I would love to see ssl compiled in - I believe the reason Jon currently doesn't is that it would require building on at least 6 different machines to cover 0.9.8 and 1.0.0 (libssl.so.10 and libssl.so.1.0.0) for x86/x64 plus a customized version of ssl.py.

<comment><USER27> where on earth would a professional software developer find SIX different machines to run builds on??

</comment></comment></comment></comment><comment><USER28> Metrics is an interesting package. It reports usage stats to Google Analytics, referenced by a hash of the machine's MAC address:

[http://atom.io/packages/metrics](http://atom.io/packages/metrics)

<comment><USER29> Good catch. I really shouldn't have any more of a problem with a desktop app tracking me than I do a web app but for some reason I do. I guess because I can always use Disconnect in the browser and I can't with Atom. I guess the fact that it is open about it is a positive thing, though.

<comment><USER30> It sounds like you can disable Metrics in the settings.

<comment><USER28> Some apps ask on install if you agree to share usage data. I can't say how Atom handles it, but it sounds like you're in unless you modify the config.

BTW, I'm less concerned and more just surprised to see Google Analytics used like this. I guess it really is the blurring of the lines between desktop and browser-based apps.

Maybe this GA usage is not unique, but it's new to me.

<comment><USER30> > it sounds like you're in unless you modify the config.

You are, though it's mentioned on the very first screen that pops up when you open the app: [https://github.com/atom/welcome/blob/master/lib/welcome.md](https://github.com/atom/welcome/blob/master/lib/welcome.md)

<comment><USER28> I think that's fair for a beta app where they really need the data to tighten things up. It would be nice if metrics became opt-in post-beta, though.

</comment></comment></comment></comment></comment></comment><comment><USER31> _To help us improve the editor, Atom sends usage information to Google Analytics. See [atom /metrics]([https://github.com/atom/metrics](https://github.com/atom/metrics)) for details._

More data going to Google without opting in first? Bummer.

<comment><USER32> See, I never get the tinfoil hat crowd.

Are any of us so self-important, that we think our usage stats for a text editor are some kind of top-secret data?

I mean, come on - it's a text editor - I edit my scratchpad and my coding projects on it.

If any of the stuff I had was _that_ top-secret, I'd be doing it in a digital clean-room, with an airgap. And I'd actually have top-secret clearance.

How many of us here actually _have_ top secret clearance? I'd bet very few...lol. And I doubt they'd be posting here, or admit it.

My list of text files I have open is quite frankly, is not _that_ interesting. I don't really care if Google wants to mine it. Or if Github finds out I edit a document called "Lolcat images" fifteen times a day. I seriously doubt any Githubber is going to be sitting there, pouring through logs looking for salacious information about the documents I edit...

<comment><USER33> I just don't understand why people downvote you. It's quite stupid to downvote someone who is merely pointing out facts.

Google analytic is everywhere. If you don't want Github to track you, then don't use it. So if people fear Google, then should Github do the tracking on its own? Then all the sudden Github is not evil anymore. But look: github has your repository, your code. If you have a private repo, github still owns the source code in their data store. So in the end, privacy on Github? Minimal.

And you know what? Github itself has been using Google analytic for years. And now we are complaining about Google collecting data?

If you care about privacy, you shouldn't even be using Github. If you care about your privacy, you should never give up your true IP, your true identity on the Internet.

<comment><USER34> So it's either all or nothing? It's possible to concede some privacy in some aspects of work/life while trying to retain it in another. Even though you have a Github account doesn't mean that all your code is on Github. You might not have remotely close to all the work you do in an editor on Github, at least if you're the kind of person who's more comfortable in your favorite editor than in a word-processor. People have been power users of editors for decades without needing the cloud or a remote, third party service in order to use them.

<comment><USER33> I was addressing the reaction. Github has been using GA for years and AFAIK there is no way to opt out via Github account settings. Atom is not something you use on Github; it's a desktop application. If you install a browser, you have the option to NOT send data to the browser vendor, but most people choose to use the default settings. I don't see why we have to think auto opt-in is bad or a bummer. Github even makes it explicit that you can disable GA (or whatever metric software they are using in Atom) in Atom and atom's opt out option is 100x better than Google Plus integration.

</comment></comment></comment></comment></comment><comment><USER35> No mention of supported platforms, but the documentation refers to keyboard shortcuts like "cmd-shift-P". This isn't Mac-only, is it?

<comment><USER29> No, just normal developer monoculturalism. Same as showing only Mac screenshots that is common, or showing your website inside a Macbook, etc.

<comment><USER36> The most common cause of people showing websites inside a Macbook is that the graphic designer is using a Mac and Apple provides some pretty nice high resolution tiffs of all its products.

</comment></comment></comment><comment><USER37> I'm really sad to see that they totally blew it.

The performance of a webapp with the accessibility of a desktop app. Not to mention that it's closed source. This is a tremendous step backwards.

Looking at the implementation of the open sourced packages is discouraging as well. It looks like they are using a Backbone inspired jQuery infested nightmare of clientside MVC.

Maybe my bitterness comes from the fact that I've already been down that road and it leads to a bad place.

Here's an editor that has deep Github integration, runs in the browser, and self hosts: [http://www.danielx.net/editor](http://www.danielx.net/editor)

Maybe I just live too far in the future.

<comment><USER38> I would wait until I actually try the product instead of calling quits. And jQuery/Backbone is not an infested nightmare MVC. It's beautiful modular javascript.

<comment><USER39> > beautiful

> javascript

Choose one.

</comment></comment></comment><comment><USER40> Apparently this was almost 6 years in the making. [https://twitter.com/defunkt/status/438791340222971904](https://twitter.com/defunkt/status/438791340222971904)

<comment><USER41> Wow - I didn't even think node.js was that old. It will be interesting to see its genesis. The first git commit for node appears to have been on Feb 16, 2009:

        commit 9d7895c567e8f38abfff35da1b6d6d6a0a06f9aa
        Author: Ryan <email@example.com>
        Date:   Mon Feb 16 01:02:00 2009 +0100

        add dependencies

<comment><USER42> I'm guessing the Atom project was WAY different back then, and has probably gone through several ground-up re-writes.

</comment></comment></comment><comment><USER43> "Our goal is a zero-compromise combination of hackability and usability"

I can see a huge compromise in hackability - its core is closed source.

</comment><comment><USER44> Imagine Linus had used that sort of license for git. There would be no github, no nothing. I don't get it. Take for free, build a million dollar business and then make your own stuff closed...

<comment><USER45> Github folks are awesome mostly. I'd have imagined they would have made it a liberal license if they could.

But they are the venture invested company now. Need to show returns 10 to 100x the investment in a few years.

</comment></comment><comment><USER46> I've just had play around with the beta. It looks like it's using a version of CodeMirror 4 (as it has multiple ranges). Fairly fast but it doesn't match Sublime Text just yet

Initial impressions: it's early days but this thing is just oozing for customisation. The fact it's written in JS means writing packages is pretty simple compared to Python for ST; we're going to see TONNES of addons for it. I can already think of 2-3 I'd like to build.

The one thing that really excites me is how people getting into programming could start off with a pretty basic editor and add and write packages as they hone their skills, ending with something incredible powerful and tailored to them. In fact I'd really love to see a super customised starter version for children / beginners that acts as a learning aid as well as a text editor.

No doubt there's going to be haters in the vim / emacs / ST / _insert favourite editor here_ camp but I really hope this works out for the Github guys (and I have a feeling it will).

<comment><USER47> Fwiw, Brackets ([http://brackets.io](http://brackets.io)) supports a similar degree of customization since it's also written in JS/HTML, uses CodeMirror, and offers lots of extensibility APIs. And it's MIT-licensed. Writing an extension is as easy as this: [https://github.com/adobe/brackets/wiki/Simple-"Hello- World"-...](https://github.com/adobe/brackets/wiki/Simple-"Hello- World"-extension)

<comment><USER48> Looks like in Atom you can just inspect elements of the editor and change them right there. In Brackets if you want to change the font of the editor then you have to write an extension or search for the CSS file of the editor which is barely editable with Brackets because it's slows down with the somewhat bigger CSS file, syntax highlight stops at the half of the file and searching was extremely slow for me in this big file.

<comment><USER47> You can open dev tools on either of these editors, but in both cases you're not making permanent changes to the source that will stick around the next time you launch the app.

Hacking the minified source isn't going to be fun no matter what, but if you clone Brackets from git the original LESS files are very easy to modify. Or you could just write a three line extension ([https://github.com/adobe/brackets/wiki/Customize-Your- Code-F...](https://github.com/adobe/brackets/wiki/Customize-Your-Code-Font)) to adjust the CSS without modifying the core at all. That flexibility is the advantage of building on the web tech stack (an advantage shared by Brackets, Light Table, and Atom alike).

</comment></comment></comment></comment><comment><USER49> Turns out it's going to be payware, closed-source only while the rest of their community gets to build and support it. [http://discuss.atom.io/t/why-is-atom- closed-source/82/9](http://discuss.atom.io/t/why-is-atom-closed-source/82/9)

But who's going to buy an editor that can't even open a 1 MiB file? [http://discuss.atom.io/t/unable-to-open-files-more- than-1mb/...](http://discuss.atom.io/t/unable-to-open-files-more-than-1mb/549)

Moreover, besides code posers and managers, who is going to throw away all their knowledge and time configuring the editor they were using?

<comment><USER32> I was the one who reported the 1 Mb file issue...

I mean, it looks nice - but I'm a bit undecided about the whole proprietary code project thing.

If it was open-source, we might actually be able to see if there was some silly hardcoded limit in there - heck, we could even submit a patch and do a pull request.

That, and the blatant ripping off of Sublime Text's interface.

It's bad enough they don't put the source itself on Github, but they aren't even using Github's issue tracker for the project - or heck, any other issue tracker as all.

So we're resorting to filing bug reports on a discussion forum... _shakes head_.

Hopefully Github will come through, and sort things out.

I have no objections to paying for an editor - heck, Sublime is $70 - but with this being closed source, and Brackets.io being more mature, and open-source, not sure what the attraction is.

<comment><USER50> Brackets is focussed on frontend webdev only. You might wanna try LightTable.

</comment></comment></comment><comment><USER51> A common thread or line of argument that I find when reading about new editors is their out-of-the-box ease of use compared to Emacs and Vim. For example, a quote from the Atom blog:

>Sublime and TextMate offer convenience but only limited extensibility. On the other end of the spectrum, Emacs and Vim offer extreme flexibility, but they aren't very approachable and can only be customized with special-purpose scripting languages.

It doesn't seem like they (and many others) are denying that Emacs and Vim are excellent editors. Why is ease of use such an important issue for text editors? Emacs isn't terribly difficult to use, but if my livelihood and the majority of my time is tied to what tools I use, then it's worth the investment of time. I don't think I've met an Emacs user who has put in the effort of learning Elisp and customizing Emacs to their liking ever deny the benefits of learning it in the first place. Yes, it's a pain in the ass initially. I quit Emacs twice before I became determined to stop whining and spend quality time learning about tooling.

There is no doubt that Emacs has a steep learning curve and perhaps that's because its developers have a higher expectation of its users. I would argue that these expectations are easily matched by the capabilities of a competent programmer.

<comment><USER52> There is no reason why "editing plain text" should be anything other than immediately intuitive. Advanced, time-saving features, like multi-cursors or regexp-based find-and-replace, can and should be progressively revealed through normal use of the software.

This ludditic reverence for user-hostile text editors is one of the more perplexing and frustrating things about our industry.

<comment><USER53> > There is no reason why "editing plain text" should be anything other than > immediately intuitive.

Are you suggesting that it isn't in Emacs?

Well, I remember using Emacs for the first time. It opened up and I started editing the opened file. I saved the file from the file menu (which also showed me the shortcut for saving the file the next time I have to save something). Done. Now, this is exactly what a novice would do with notepad.

I found that many people 'demonize' Emacs just because they found it _unfamiliar_. Sure it's unfamiliar. For about a day. Then, it's just as familiar as any other user interface. I now used Emacs for, well, the shell, the dired and wdired, multiple cursors, keyboard macros, project-wide grepping and everything in between. Getting familiar with the editor was a great thing to have done, however unfamiliar it was in the beginning.

With the benefit of hindsight, I can truly say that learning how to properly use a text editor, especially one so powerful as Emacs, is _the one thing_ the any programmer absolutely must do. So, even if the editor isn't "anything other than immediately intuitive", it's still a good idea to wrap your head around the non-intuitive things.

<comment><USER52>
        > Are you suggesting that it isn't in Emacs?

Yes, of course. Emacs is obviously and inarguably _not_ immediately intuitive.

<comment><USER51> What is immediately intuitive about anything a programmer does on their machine? I assume you have used a Unix shell, right? Was there anything immediately intuitive about that? You've probably done some programming, so was there anything immediately intuitive about your programming language?

<comment><USER27> You press the key labeled 'X' in the keyboard, and an X shows up in the screen. Can't be more intuitive than that.

</comment></comment></comment></comment></comment></comment><comment><USER54> It could be really great. I wonder if Jon Skinner knew, and said to himself "Welp, I might as well stop with Sublime". However, Sublime is (mostly) blazingly fast. I don't expect this from a node based app, especially in Windows. And: I didn't see it under Features, but Atom definitely needs the command palette from Sublime baked into core. Only if it's core, plugin authors will set their hooks correctly from the beginning. Or even better, there might be a flexible command api that exposes each plugin's commands from the start and can be extended too. -> edit: the readme says it has Command Palette. Great! Also, since the term is identical with Sublime Text, I wonder if there's more to it than inspiration.

<comment><USER55> You do know that v8 is generally much much _much_ faster than cpython, don't you?

<comment><USER56> Although, most of the Sublime core is in C/C++ as far as I know. And it's using native drawing, not webkit. Will be interesting to see how the performance compares.

<comment><USER57> sublime is using opengl to render every glype. Its speed will blow anything out of the water. Open 2MB text will be highlighted and colored in an instant. I wonder how could webkit achieve that.

<comment><USER55> My suspicion is sublime's speed has very little to do with its rendering method and a lot more to do with its I/O philosophy. Because, let's be honest, there is no way OpenGL can make loading a 50mb file into memory significantly faster than plain rendering.

</comment></comment></comment></comment></comment><comment><USER58> Nice to see some innovate architecture for an editor but this product launch reminds me to product launches from Apple or Google: it doesn't matter what product or feature is shown, there is always tons of premature praise.

If an unknown third party came up with Atom it would have never gotten that attention.

ST3 is a very good product viewed from any angle and VIM either—it will be hard to beat these reference products. I love Node/npm and again the stack sounds great but I don't know if this stack will be much easier to extend than something like ST3 or VIM.

What I have seen from a product perspective on the Atom landing page does not blow me away, not at all. And it is wether free nor open source.

But it's from Github and that's reason enough to vote it up.

</comment><comment><USER59> As was speculated in the other thread the beta looks like it will be closed, there's a "request and invite" form on the page.

Others noted that the source mentioned "free during beta", I certainly hope that's not the case and it's truly FOSS. Sublime Text development has slowed significantly recently and the community can't continue to drive it since it's closed.

Funnily enough, Sublime Text was born out of Textmate development slowing, and I can't seem to shake that vibe here too.

<comment><USER60> If you want an open-source text editor based on Node.js, Light Table might interest you.

(Light Table itself is written in ClojureScript, which is a bit idiosyncratic, but it's hardly worse than Elisp, and anyway you can write plugins in normal JavaScript.)

<comment><USER47> Or Brackets: [http://brackets.io](http://brackets.io)

</comment></comment></comment><comment><USER30> I can't tell from this page whether it's open source -- I hope it is.

<comment><USER30> From ##atom IRC:

<DouweM> kevinsawicki: is the actual core going to be OS?

<kevinsawicki> DouweM: not during the beta

<tyOverby> How is atom both invite-only and open source at the same time?

<avidal> tyOverby: the engine isn't open source (or at least yet)

<comment><USER29> Welp, makes that decision easy. Not making the most important tool in my toolbox one that I can't hack to my liking.

<comment><USER61> Agree. It's a tough decision for them -- I'm sure the "Hot New Text Editor" market has a decent chunk of money associated with it. But it's pretty hard to commit to a text editor that you can't open up and recompile.

EDIT: Plus, if an editor is going to join the ranks of vim and emacs in history (something which neither Sublime nor TextMate are on track to do) it _has_ to be open source. Anything else and it's just another product.

<comment><USER62> I agree on the open source nature. However if this editor treats github as a first class citizen (while being free/open) then it does have value to github. This is especially the case for new github features introduced in the future.

<comment><USER63> There are very few people who would opt in to a editor for everything only to use it with Github. Most of the world's developers don't even have a Github account.

Tools work in a strange way. I recently saw a whole team of embedded developers use TextPad. They haven't heard of anything called 'vim' or 'emacs'. From their perspective its either a vendor supplied IDE or TextPad. One of them was even startled to see this shiny new thing called 'Sublime Text' when I was using it. He went out with enthusiasm, but was hardly able to convince any one to use it.

<comment><USER62> There will always be outliers.

A code editor with first class prominent Github support is more likely to encourage creating Github accounts - it would just work. Compare to regular code editors which require jumping through various hoops (typically having to find relevant plugins, install them on all machines/users, and then figure out how to use them as they are extensions not core).

A pitch of "if you use this editor then all the team's work is automatically synchronized and available" is a very powerful sell.

</comment></comment></comment></comment></comment></comment></comment><comment><USER64> I don't like how it looks like Sublime text... couldn't they have designed something new?

<comment><USER65> As the designer who worked on the main interface for Sublime Text 2, it does irk me that it looks so similar. They had carte blanche to create a wonderful new interface and they mostly just copied Sublime Text. The go-to anything menu looks especially similar. [https://t.co/5YxVbZcVcK](https://t.co/5YxVbZcVcK)

<comment><USER66> Just wondering, do you know how to code? What are your day to day tools as a designer?

<comment><USER67> The Atom team is recruiting I see. -.^

</comment></comment></comment></comment><comment> vhost- > Emacs and Vim offer extreme flexibility, but they aren't very approachable > and can only be customized with special-purpose scripting languages.

Only? I can point to a large number of Python, Ruby and Perl plugins for Vim. Unless they are considering those special-purpose and nodejs is the only truly flexible scripting language.

</comment><comment><USER68> The blog post: [http://blog.atom.io/2014/02/26/introducing- atom.html](http://blog.atom.io/2014/02/26/introducing-atom.html)

<comment><USER69> > _we 've open-sourced over 80 of the libraries_

Some of them look quite interesting already.

</comment></comment><comment><USER70> Atom is a cargo cult.

Atom is eventually a dead end. They are paying lip service to eventually partially opensourcing it.

It is the opposite direction of the magic of git, which enables easy sharing and collaboration.

Beware the promise of later opensourcing of projects. Without an early commitment, the developers of atom will invariably include proprietary software to ease development which will preclude later opensourcing.

You are better off taking the hard road and investing your time in tools that are not cargo cults.

</comment><comment><USER71> Apparently github will be charging for it and it will not be fully open source.

[http://discuss.atom.io/t/why-is-atom-closed- source/82/9](http://discuss.atom.io/t/why-is-atom-closed-source/82/9)

</comment><comment><USER72> I've been observing the reactions to this over several communities and I find it all to be rather interesting! [ Warning; meta comment incoming ]

[http://www.reddit.com/r/programming/comments/1z0ykn/atom_lau...](http://www.reddit.com/r/programming/comments/1z0ykn/atom_launched/)

Almost every single comment is negative, dismissive, one liners filled with half truths and very few child comments seek to rectify any misinformation or support a discussion.

The first and by far most-upvoted with a 700 point margin.

>I must be out of touch with modern development. I don't understand the thought process that leads people to be excited about a closed source, node.js text editor that reports your usage to Google.

It suggests the user simply scanned over other comments, glanced at atom's site and proceeded to regurgitate karma bait. I suppose it says a lot about the attention span of these people as there are also highly voted "tl;dr" request comments.

A perfect example of misinformation:

>[ unquietwiki 70 points] Isn't Brackets this already? Node.js/Chromium app with plugin support? > \--- [ MrSenorSan 67 points] yup, but atom is not open source yay! wait a min... > \--- [ kmeisthax 17 points ] Yes, but with Atom, you have the priviledge of paying GitHub money for a software product in a market with numerous competent free and Free Software options.

The supply of vitriol is unending.

It was the same with the /g/ thread, though surprisingly not quite as bad.

[http://archive.rebeccablacktech.com/g/thread/S40550074](http://archive.rebeccablacktech.com/g/thread/S40550074)

My point is, stay classy Hacker News. While you may even have similar opinions with these communities, the reception in this thread has been far more exciting and you put effort into your discussions. The contrast is massive, and especially interesting considering this is one the highest upvoted articles on HN, sitting alongside Neovim. suggesting we _desperately_ want to replace our editors.

</comment><comment><USER73> Eclipse is massively modifiable but everyone hates it because of bloat. You see this kind of thing starts off with good intentions and then all the plugin madness gets going and suddenly everyone gets revolted and charges off to embrace the next great "lightweight" editor.

</comment><comment><USER74> This might make developing on chromebook viable.

<comment><USER75> THIS.

<comment><USER75> Wow. Lost karma because I'm enthusiastic about something? Neutral, I'd understand... but downvotes? Really? I've seen even more plain and simple comments get upvotes. You folks are a fickle bunch.

</comment></comment></comment><comment><USER76> Seems like quite a weird priority for GitHub to dedicate resources into creating Yet Another Text Editor.

I don't know, I can't see how this is a priority for them...

<comment><USER77> Github has iPad-based robots that allow remote workers to wonder about their SF office. Obviously, that $100m VC money has to be spent on ~something~.

Compared to that, a text editor is a mere bagatelle.

</comment></comment><comment><USER78> So it's light table without Chris Granger, for better or worse..

<comment><USER79> Light Table is a great project, but it's all in closurescript -.- This is a big obstacle to people wanting to edit/customize/write their own plugins

<comment><USER80> It's really sad that learning a new language is considered "a big obstacle." An average programmer should be able to pick up nearly any new computing language quite easily.

<comment><USER81> Depends, is not like some who have code in a Imperative, OOP paradigm, is gonna learn a functional language in no time.

</comment></comment></comment></comment><comment><USER82> The "space-pen" part of this deserves separate attention:

[http://atom.github.io/space-pen/](http://atom.github.io/space-pen/)

I bet this space-pen DOM DSL would mix well with the React virtual-DOM approach.

</comment><comment><USER83> So how much is written in Javascript? Won't that performance pale in comparison to, say, Sublime which is written in C++?

Or are just the plugins/extensions written in Javascript while the core editor is in C or C++?

Obligatory: People who got a beta invite, anyone feeling generous and want to give me one? (As I understand it, when you're invited you get a few to hand out, too.)

<comment><USER45> Sublime is written in Python.

I'd imagine, all of this is written in Javascript and compiled/rendered with v8.

<comment><USER84> Sublime is written in C++, the plugins are written in Python.

</comment></comment></comment><comment><USER85> I wish it was open source. We need a modern, good looking, libre text editor.

<comment><USER81> There is LightTable, also you can even make Emacs or Vim as "good looking" as this if you give them so tweak.

</comment></comment><comment><USER86> So, they want people to contribute writing plugins so they can turn-around and make money off the plugin ecosystem by selling atom?

Seems transparently under-handed to me.

</comment><comment><USER87> Can I use it online? That would be the killer feature for me, being able to code on anyone's computer in a second. Currently it's basically the only thing stopping me from being able to pick up anyone's computer and use it as I use my own.

<comment><USER88> Guessing no, because of the Node.js plugin architecture ("need to call into C or C++?", "full access to the filesystem"). Really only the UI seems to be done in WebKit.

<comment><USER89> From a quick glance it looks like its architected the same as Light Table (Local node server that accesses the file system and a decoupled UI that connects over http and uses WebKit). If it works like that it could run in the browser. Not so easily from anywhere though

</comment></comment></comment><comment><USER90> Thanks to Atom not being really free software and people here suggesting it a lot I give LightTable a try. I'm an emacs user but I like experimenting different foss editors and LighTable + emacs keybindings plugin is a really nice and beautiful tool.

Couldn't get it to work on Debian Wheezy yet (GLIBC_2.15 not found)* but worked on a Windows machine at work so I'm testing it there. I'll get back to linux later. Looking forward for v1.0. :)

* It seems to be a known issue: [https://github.com/LightTable/LightTable/issues/972](https://github.com/LightTable/LightTable/issues/972)

</comment><comment><USER91> I find it interesting that there is little to no conversation about the integration with git. In one of the the screenshots I saw a branch name and icon in the bottom status bar. I assume this is an important motivation for GitHub.

</comment><comment><USER92> Looks like Sublime Text but with a ton of resource-consuming shit I'll never use, which itself is similar to the reason I stopped using Sublime Text. I'll sick with vim, thanks.

</comment><comment><USER93> Atom team, if you're reading this, I have a big feature request that would make this far, far greater than just another editor.

Pair editing.

Specifically, having the ability to pair two editors over a network and edit the same set of files.

Lots of other editors do this, but here's the key: Each editor keeps its own settings and environment.

I'm a vim guy. I can set up my Atom to be vimlike. My buddy, the Emacs (heretic!) guy, can set up his Atom the way he likes, and we can work in harmony.

That's all I want.

<comment><USER94> Floobits.

<comment><USER95> That is to say, [https://floobits.com/](https://floobits.com/) appears to already do this.

</comment></comment></comment><comment><USER96> It's ironic that you're unable to commit code from within Atom. Apart from that there are a couple of things that I feel can be added.

\- Soft undo for multiple selections.

\- Search settings since the panel is overwhelming.

\- Markdown preview should be updated live?

\- I really miss Go To Anything from Sublime Text 3.

\- You should be able to select the syntax highlighting from the status bar.

\- Inline preview of audio, SVG (toggle?) and fonts? That would be _rad_.

\- Syncing of settings using GitHub settings?

But other than that this is really good progress!

<comment><USER97> Commit is not needed if the next version includes a dropbox-like sync to your github repo.

I'm pretty sure it's one of the reasons to come up with its own desktop editor (that later can be also used online) -- to bridge the gap.

</comment></comment><comment><USER98> Looking forward to this. The fact that it's all JavaScript/Node based makes this particularly attracting for me. I haven't really been able to hack on ST2/3 because I'm not that proficient in Python and never found the time to properly dig into it. The repositories look great, really hope it'll live up to the expectations.

That being said, anyone with a spare invite? :) Ta.

</comment><comment><USER99> First let me say that I've used only vim and emacs for the last 5+ years that I have been a daily coder.

I'm extremely comfortable with vim. I can cruise seemingly at light speed and have just never been able to find a text editor which offered the same level of productivity when jumping back and forth between the mouse/trackpad and keyboard.

However I just couldn't resist the urge to try out a new text editor that was created by github and thankfully I scored an invite from someone on twitter.

I've only had the thing open for about 10 minutes and already I'm impressed.

It allows me to write in markdown, save the file, render the markdown into markup, and then launch the webkit dev tools to inspect the rendered DOM.[0]

Do other modern text editors such as Sublime Text allow you to render the markup and then inspect the DOM with browser dev tools? If not that alone seems like a pretty good innovation.

More Info: [0] [https://pbs.twimg.com/media/BhdTeedCcAARgYV.jpg:large](https://pbs.twimg.com/media/BhdTeedCcAARgYV.jpg:large)

</comment><comment><USER100> A competitor to Sublime is a great thing. Sublime is great and I love it, but we need more teams like Github building editors that make sense.

Thanks Github!

<comment><USER101> It's called vim.

<comment><USER102> I think he means that we need editors that are powerful AND easy to use.

Seems like vim isn't really for someone like me (I haven't studied PhD level computer science and I don't write compilers and/or lisp interpreters in my spare time for fun).

<comment><USER78> I taught Linux Admin courses before I graduated high school, and the first order was learning vim. If you have a mac, 'vimtutor' is available to you.

vim has nothing to do with PhD-level CS or writing compilers and/or lisp interpreters. The Emacs community might fit that stereotype a _little_ more but really not much more.

Vi (vim being 'vi improved') is great because it works on basically any terminal. It works with my iPad's keyboard and with a teletype terminal from the 70s or 80s, as well as a normal PC keyboard. Emacs has similar brags.

The terminal's not going anywhere and if you like keyboard shortcuts, knowing five or ten that will work on _any keyboard in existence_ for an editor that is on _most_ unix systems you'll find has some value.

<comment><USER102> I was being a smartass, which was uncalled for. Sorry, Angersock!

Also, I do have a mac, so maybe I'll check out vimtutor.

My point is that I'm very new to programming, and it's so much easier for me to load up Sublime Text and start getting work done. At least for now, learning vim would be something that get's in the way of learning/making. It also doesn't seem like the benefits would outweigh the cost.

<comment><USER103> I started using vim when I had first started to learn to program. I'd say give it a shot if for no other reason than it's an interesting paradigm shift, and can be really effective.

I'd say give Vintage mode on sublime a shot. It does the basic keybindings/motions of vim and will give you an idea of whether or not you might be interested in it. It's also nice because in insert mode it's basically just normal sublime, so you can just switch back to that if you get frustrated.

Are you on linux, osx, windows, or something else?

If you use vim/vintage mode, remap capslock to be escape.

This took me forever to figure out, for whatever reason, but if you're on windows, the easiest thing to do is get autohotkey [1] and write a script with one line:

Capslock::Escape

You can compile that to a portable binary and use it anywhere as well. It's really straight forward.

I also added two keybindings to make Alt+movement to add cursors above and below: { "keys": ["alt+k"], "command": "select_lines", "args": {"forward": false} }, { "keys": ["alt+j"], "command": "select_lines", "args": {"forward": true} },

It doesn't always interact naturally with vintage/vim mode, though, but that was just a personal preference.

[1] [http://www.autohotkey.com/](http://www.autohotkey.com/)

</comment></comment></comment></comment></comment></comment><comment><USER104> What's the difference between this and Emacs?

<comment><USER105> The big difference from my perspective is that Atom isn't currently FOSS. Other than that, the maturity of the emacs ecosystem is both one of its greatest features and a bit of a curse.

<comment><USER103> The non-FOSS part is the part that bothers me the most. Maybe bothers is too strong a word. It's just hard for me to get into a text editor without knowing that the community could pick it up and run with it, if the originator dropped it.

Not sure if that's an unfounded fear, but I don't want to invest time customizing a platform and writing plugins when it could close shop in a second. I suppose I could say that about a lot of things I _do_ customize, but it's hard when the FOSS text editor world is so rich.

</comment></comment></comment><comment><USER106> Can this work at all without an internet connection? Can it work offline?

<comment><USER107> It is a desktop app, so yes.

</comment></comment><comment><USER108> This sounds like a very promising tool. I'm really excited to hear all of the talk about extensibility.

One thing that is conspicuously absent is any mention of it being open source. I can certainly appreciate that Github is for-profit, but I would love to have a clearer idea of how free / not-free this tool will be when it is publicly available.

</comment><comment><USER109> Maybe it's not true of all JavaScript GUI apps, but almost all the ones I tried are _hecka sluggish_ for things like drag+drop. I could see that being a problem with tabs in this case. Plus I'm concerned about the CPU on my poor little MBP, Chrome usually eats it all the way up, is that somehow mitigated in Atom?

</comment><comment><USER110> I will switch to this if it is as good as Sublime Text, but with a more open API. Sublime Text's API is too restricted, and there's a ton of things I want in Sublime Text that IDEs have.. but I don't want a full-blown IDE.

Take the overall diff bar of most IDEs for example (Jetbrains, Netbeans, etc.). I want that in Sublime/Atom. There is a plug-in for Sublime to show diffs per line, but no way to manipulate the mini-map to show diffs at a glance.

[http://blog.jetbrains.com/pycharm/files/2013/12/2.png](http://blog.jetbrains.com/pycharm/files/2013/12/2.png)

Edit:

See, this is inferior and what Sublime Text already has: [http://atom.io/packages/git-diff](http://atom.io/packages/git-diff)

What's superior is a full-blown diff bar overview of the file.

</comment><comment><USER96> I've ported the Oblivion scheme across; [https://atom.io/packages/Oblivion](https://atom.io/packages/Oblivion) from [https://github.com/jbrooksuk/Oblivion](https://github.com/jbrooksuk/Oblivion)

</comment><comment><USER111> Does it have emacs emulation?

</comment><comment><USER112> I'd think it's not a requirement for OSS (look at textmate, sublime) but as new comers hit the store it would be nice to know it beforehand and have an expectation of what would come. Since for people writing addons it would be a decision-maker.

What most people wouldn't like to see are yearly subscriptions of another editor or paid upgrade every 18-month. I could personally bear with textmate and sublime for their current licensing (personal => works on as many computers I have - which I have at least 4)

For OSS ones, we have the traditional ones like emacs, vim, eclipse, and newer ones like brackets (which also sold as paid editor as Edge Code CC), lighttable or google's half-baked collide.

</comment><comment><USER113> Sublime has 'limited extensibility'? Package Manager lists over 2000 packages. And what about Brackets? This looks very similar - editor built with web tech. [http://brackets.io/](http://brackets.io/)

</comment><comment><USER114> [http://discuss.atom.io/t/atom-is-so-powerful-that-it- blows-m...](http://discuss.atom.io/t/atom-is-so-powerful-that-it-blows-my- mind/294) sounds great!

</comment><comment><USER115> Bracket is built on top of Code Mirror. It never feels like a native editor. If Atom is using a Webkit renderer for core editor part, I'm not gonna switch from Sublime anytime soon

<comment><USER60> Light Table is build on Node-Webkit and it feels pretty good most of the time. (Opening folders is the only spot I've found where it's like, "Wait, something is a little off here.")

<comment><USER116> My experience with Light Table isn't that fortunate, even moving the cursor through some lines feels sluggish and not great.

</comment></comment></comment><comment><USER117> I think, in the long run -3 to 5 years-, Jon Skinner -Sublime Text- will be leading, like now. I can clearly see his passion and investment in his product.

People at GitHub are also great, well funded, but this is not their core product. Do they have a leader -I don't know if they have or not- who will be focusing only on this product and keep up with jskinner?

I am sure Atom will be around for long years, as well as Sublime Text. Thanks to GitHub, I am looking forward to give it a try.

<comment><USER118> > in the long run -3 to 5 years-, Jon Skinner -Sublime Text- will be leading

As an Emacs user, I find it funny to hear 3-5 years be referred to as "the long run".

Also, Sublime Text won't be leading until it has a package with more features than Org mode. ;-)

<comment><USER117> actually I was expecting a comment on that one :) don't you think the time frame narrows on predicting the future on topics like these -web, desktop or mobile applications-?

I am not arguing that Sublime Text is the best -because I am not that pro-, but I can assure you it is hot right now, all around the world. It may be wrong, but all cs students and developers I personally know in 4-5 countries use it, like it. Most of the online courses tell their students to use it. It is highly recommended, all over the web.

The word is spreading.

[http://www.google.com/trends/explore#q=%2Fm%2F01yp0m%2C%20%2...](http://www.google.com/trends/explore#q=%2Fm%2F01yp0m%2C%20%2Fm%2F0b6h18n&cmpt=q)

</comment></comment></comment><comment><USER119> I thought this was an open source project, but when I read FAQ beta version is only out for OSX and they talk about charging for it so it probably wont be open source.

</comment><comment><USER120> You know, I'm usually very skeptical of web apps, but building a text editor in WebKit actually seems like a really good idea. Everything a browser should be good at — text display, scripting, styling — also applies to text editors. You don't really have to worry about complex UI, animation, or user input. You also get remote access almost for free.

What other text-centric apps can be made better by a browser framework? Maybe the terminal?

<comment><USER121> So why is every text editor I have ever seen embedded in a website an abomination?

> text display, scripting, styling

The only thing that really matters is scripting. Every serious editor has solved displaying text and styling since ages and those two points aren't even that important in programming languages. All you want is a syntax aware highlighting. Maybe underlines and a little bold here and there.

Scripting is the really hard part. There are many flavors, languages, APIs to chose from. Just because you now can script things in <hip-language-of-the- day>, the problem isn't solved. My editor uses a lisp dialect and I'm perfectly happy with it, not because of the language choice but the APIs and amount of integration.

One thing that is incredibly important for text editors is speed: something web engines are notoriously bad at.

<comment><USER120>
      "Every serious editor has solved displaying text and styling since ages ago..."

Sure, but why reinvent the wheel? In this case, Github is leveraging a technology specifically optimized for text and styling. They don't have to maintain it, and they get a lot of cutting-edge optimizations for free. It also gives them the freedom to do some crazy things that would otherwise be very difficult — see Light Table.

      "...and those two points aren't even that important in programming languages."

I disagree. Efficient text display and presentation in a text editor are very important, at least for me. Not that scripting is any less important, but it looks like Github has that front covered as well. (Then again, I've never been a heavy vim or emacs user. I guess I'm what you might call a "filthy casual".)

      "One thing that is incredibly important for text editors is speed: something web engines are notoriously bad at."

I was under the impression that web engines are really good at text when there's not a lot of other crazy nonsense going on. Guess we'll see!

      "So why is every text editor I have ever seen embedded in a website an abomination?"

My guess is going (partially) native and using Node.js will make the experience a whole lot better.

</comment></comment></comment><comment><USER122> The editor looks good. I'm more excited about the fact that this is a good looking desktop app, built using, what are normally considered, web technologies.

</comment><comment><USER123> For me, this might be the killer feature: [http://atom.io/packages/vim- mode](http://atom.io/packages/vim-mode)

<comment><USER78> Light Table has it, as well as emacs - both using tools that are not specific to LT.

</comment></comment><comment><USER124> Can you edit files while offline? Or do you need to be always-connected? (i.e. this is an actual web service)

I couldn't find mention anywhere about offline abilities.

<comment><USER68> There is no online component. So yes, you can edit offline.

</comment></comment><comment><USER125> More online editors...

Check out Brackets ([http://brackets.io/](http://brackets.io/)) and Eclipse Orion ([http://eclipse.org/orion/](http://eclipse.org/orion/)) who both have been trying to build fully open editing experiences. There are more out there but those come to mind.

Would be nice if more people started working together on these things...

</comment><comment><USER59> Mojombo[0] commented[1] that it won't be either closed or open source, but "somewhere inbetween" to make it easy for them to charge for it.

[0] [https://github.com/mojombo](https://github.com/mojombo)

[1] [http://discuss.atom.io/t/why-is-atom-closed- source/82/9](http://discuss.atom.io/t/why-is-atom-closed-source/82/9)

</comment><comment><USER109> I hate to say it, but honestly, I think Atom is probably going to be my next full-time editor. The purist in me hates the idea of running such a powerful rendering engine inside a desktop app, but all desktop GUI toolkits have proven that they really really suck at text editing (I've tried almost all of them). This is probably the best way forward.

</comment><comment><USER109> When I saw a screenshot, I was put off by the ugly tabs. So I made a theme for flat tabs[1]. You can install it by going to Install Themes in the app and searching for "flat". It's called "Atom Dark Flat UI".

[1]: [http://atom.io/packages/atom-dark-flat-ui](http://atom.io/packages/atom- dark-flat-ui)

<comment><USER126> Heads up: The image on the package page is broken

<comment><USER109> Thanks, should be fixed now. Seems like a caching issue on Atom's end (probably github-pages related).

</comment></comment></comment><comment><USER127> Last thing I need is another editor. Having said that, I will for sure examine and give a fair chance to anything you produce.

I am a vim user, I recently learned a lot of power moves in SublimeText and this is my go-to editor now. Making me use anything else would be super difficult but not impossible. Price is not the issue.

</comment><comment><USER81> So this it yet another web base text editor like Brackets and LT, one have it's "live-reload" feature the other his "live-code-evaluation", and which is the selling point for this?. Going throught the website it just give me the idea that is a what i mentioned before.

</comment><comment><USER53> I'm willing to bet anything that just like Sublime was FOSS cloned to Lime ([https://github.com/limetext/lime](https://github.com/limetext/lime)), this as well will be cloned as FOSS, if it is any good, that is.

Subatom seems like a great project title :)

</comment><comment><USER128> Bespin, Skywriter, Ace, Brackets… now Atom. Everybody seems to be having the same idea: that browser based technologies are the future for code editors.

I for one am more enticed by the possibility of a WebKit frontend, with a NeoVim core and a libuv backend. Finally, Vim as an embeddable library.

</comment><comment><USER109> Where's the emacs keybindings repo and the paredit-clone repo? Am I gonna have to write them?

</comment><comment><USER129> I see people saying they get into the beta within 15 minutes of signing up, but I still haven't gotten one and I signed up day 1. Anybody have an extra invite they're willing to spare? Email in profile. It'd be much appreciated!

</comment><comment><USER130> I just played with atom for the last 2+ hours.

It is kinda cool, but holy shit is it slow. Editing a plugin requires a reload. A reload is a good 2-4 seconds on my 4 year old mbp.

The vim-mode is very incomplete and very buggy. Granted that should get a lot better in time.

<comment><USER72> It may have to do what ST3 did and queue loading of plugins after startup, instead of all at once before the editor is "usable". If they do that it could start up nice and fast in theory, though we obviously don't know what else it's trying to do yet.

</comment></comment><comment><USER131> If you're looking for an invite, there are lots of people offering and requesting invites on IRC:

[http://webchat.freenode.net/?channels=##atom](http://webchat.freenode.net/?channels=##atom)

</comment><comment><USER132> I use github and do a fair amount of Ruby, but I can't say I find Atom to provide enough benefit to move from a native option. I would have to see it used in more example cases to make that leap.

</comment><comment><USER133> I've been wanting, for a long time, to be able to have custom UIs to websites (just like how video games do it). If this is a step in that direction for github, I will be very, very happy.

</comment><comment><USER134> So... it's like Emacs but based on Javascript rather than Lisp?

</comment><comment><USER135> To try out Atom:

[https://gist.github.com/anonymous/9265315](https://gist.github.com/anonymous/9265315)

Then visit the resulting link output by curl. You're welcome.

</comment><comment><USER136> Can somebody tell me how to run/install the editor? Thanks.

<comment><USER137> It's in private beta right now.

</comment></comment><comment><USER138> Having used it for the past couple hours, it looks great! It is pretty intuitive, snappy, and looks great. I'm definitely looking forward to using it more.

</comment><comment><USER139> I exclusively use Sublime Text editor for some time now. But this Atom editor by GitHub is very interesting. Will definantly try it.

</comment><comment><USER140> Is it just me or do most of the new IDEs tend to focus around front-end technology?

Would love to see some innovation on the Ruby editor front.

<comment><USER141> I haven't used this but if it's comparable to text mate and sublime, you should stop calling it an IDE.

</comment></comment><comment><USER142> Am lost. Where do I download it from? I do not see any link. Or is it an online based editor? Will it work on Windows?

<comment><USER143> Invite. Offline. Not yet.

</comment></comment><comment><USER144> Granted they started this effort a while ago but would be pretty boss if hypothetically they built this on Dart

</comment><comment><USER145> I was hoping Github will offer a one stop shop for Online Editor via Atom and Communication via Gitter.

Looks like i was wrong.

</comment><comment><USER146> Screenshot on front page of site made me think of Sublimetext immediately, which is not a bad thing at all.

</comment><comment><USER147> Wait, so now I have to deal with all the shittiness of the web stack in order to develop a native app?

<comment><USER148> The new, dominant and universal front end/back end/desktop app all round programming language. JavaScript :(

</comment></comment><comment><USER149> Will it have vim key bindings? My fingers have vim wired in and that's not going to change.

</comment><comment><USER81> I hope that it doesn't suffer from the same text redering issuies that LT nad Brackets has.

</comment><comment><USER150> This isn't the best thing since sliced bread. It's better than sliced bread.

</comment><comment><USER151> All right, but no invitation responses are coming back. Ho to download Atom?

</comment><comment><USER152> Interesting, this has been in development since sometime in November of 2013

</comment><comment><USER153> I wonder if it will have similar performance issues like Brackets does.

</comment><comment><USER154> Hopefully this will run on arm, which is something SublimeText does not

</comment><comment><USER155> It needs a LaTeX plugin!

</comment><comment><USER156> Has anyone got a spare invite? davfuc at gmail dot com Thanks

</comment><comment><USER157> If anyone wants to spare me an invite - him {at} ian [d0t] sh

</comment><comment><USER158> At first glance the UI seems 'inspired' by Sublime

</comment><comment><USER102> Guess I will have to break down and learn vim... no invite

</comment><comment><USER159> What framework is Atom using? chromiumembedded or appjs?

</comment><comment><USER160> looks cool, i really enjoy gedit with all the dev plugins and theme customization etc. Will def try this out to see how it compares

</comment><comment><USER161> What is web based core? Does it run on Chrome?

</comment><comment><USER162> wow, there are 2,078 lines of (unminified) css styling this page. Nice page though. Can't wait to try out the editor.

</comment><comment><USER163> Someone explain Atom to me like I'm 5?

<comment><USER143> Yet Another File Editor. This one's made by Github which the kids love to use on their Macbook Pros hacking some Ruby.

</comment></comment><comment><USER164> When did web dev become the only dev?

<comment><USER39> When you started frequenting Hacker News ;).

(I really need a lobste.rs invite...)

</comment></comment><comment><USER165> this looks fantastic! i've been wanting a reason to pick up a cheap chromebook.

<comment><USER35> It won't run on a Chromebook.

<comment><USER50> Source?

<comment><USER81> Only works on mac and windows, no Linux port.

<comment><USER50> You seem to oddly out of the loop here. Atom has been released for Mac only (private beta that too.) Linux, Windows builds are coming up, by their own admission. (My source? IRC and Discuss from atom.io footer.)

Besides, for the tech purported to be behind Atom: node-webkit, There would be no additional costs or efforts required to get it running on Linux.

</comment></comment></comment></comment></comment><comment><USER166> Gross.

The moment that their new editor provides some piece of Github functionality that isn't exposed to an open API is the moment that we need to bail, en masse.

We've already killed Freshmeat and Sourceforge for turning lame, this shouldn't be hard.

</comment><comment><USER167> how is this not a blatant ripoff of sublime text??

</comment><comment><USER168> Can it send email?

</comment><comment><USER169> Finally.

</comment><comment><USER170> firstname.lastname@example.com

</comment><comment><USER171> My Poe's Law detector is itching uncomfortably right now.

Really, was anybody asking for all this?

</comment><comment><USER172> how i feel about atom.io... [http://desmond.yfrog.com/Himg876/scaled.php?tn=0&server=876&...](http://desmond.yfrog.com/Himg876/scaled.php?tn=0&server=876&filename=79jka.jpg&xsize=480&ysize=480)

</comment><comment><USER173> so this is Brackets aka Bones on steroids ?

</comment><comment><USER174> That's great things !

</comment><comment><USER175> No thanks, I'll stick with jEdit.</comment>