Hacker News Reader

> 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.

Oh what, it's not open source? The little interest I had in this just evaporated. I would definitely be interested in something like Emacs built on modern technologies, but Emacs is already there and quite good. I feel like something like this could be neat, just because far more people know HTML/JS than Elisp, but if it's not open source that kills my enthusiasm for the project.

check out lighttable [http://www.chris-granger.com/2014/01/07/light-table-is-open-...]

Checkout lighttable.el

https://github.com/Fuco1/litable

Nice. I was able to read and understand the whole implementation on my phone.

Of course, thanks to Apple, I can't load and eval it, but I will take it for a spin when I get to a machine. :)

Brackets (http://brackets.io/) is another option - it's MIT-licensed, and also written in JavaScript.

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.

> That's the paradigm shift.

You can make desktop apps in Python, Ruby, Tcl, hell even PHP for a long time now. No compilation needed.

Whether this works effectively or not comes rests almost entirely on how good their architecture is. "Hackable" doesn't mean anything if the codebase is a coupled mess. Given GH's pedigree, I don't expect that this is the case; which means there will be some ramp-up time learning the various subsystems.

Desktop apps aren't things that you can cram into this week's hipster JS framework.

Redcar is a TextMate compatible editor in Ruby (JRuby).

http://redcareditor.com/

But like all editors, they have to have some clear advantages and a community, or it's not a viable option.

Yes, Redcar is pretty cool! This is an inspiring talk on how to hack on it - even though I'm still mostly using vim/sublime it was pretty eye opening to me, rubies all the way down:

Crafting iOS Dev Tools in Redcar - Delisa Mason (#inspect 2013)

https://vimeo.com/69745309

I don't follow. These hipster JS frameworks have to work well on phones and various inconsistent browsers. Targeting the desktop and one JS environment seems feasible.

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.

I'm sure the emacs GUI runs great on your macbook, but for people who live on remove linux servers day in and day out, trust me they are using emacs in the terminal.

That or they're using tramp to ssh in to the remote machine and edit that way.

Actually it doesn't run great. It's so clunky you might as well just run it in the terminal.

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.

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.

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

That's totally exaggerating. Anyone who is that green to code is probably not even thinking extending their editor yet, and any working programmer has picked up more than enough JS in their to be able to write and understand far more than that line.

Plus, Emacs is a ghost town anyway. You're going to run into the problem that there are not bodies willing to use the editor, let alone extend it.

Yeah, it's definitely true that a large percentage of people who "know" javascript have about that much knowledge. But still, if you look at absolute numbers of people who can make a function and write a for loop in JS, it's still going to dwarf the number of people who can loop and write a defun in elisp.

What'd be cool is an editor that had LLVM IR as a low-level extension language. At runtime, it'd JIT your plugin, and go.

Have you seen Light Table? Go check it out!

Good point!

Most emacs users I know alias emacs to emacs-nw, or install emacs-nox.

Myself included (:

Most emacs users I know don't. Myself included.

I have it aliased but for some reason I still add -nw every time I open it. Silly muscle memory.

Yup. Terminals ahoy.

> people didn't born knowing Javascript. They learnt it. And one could argue that Lisp is just as easy to learn

Just about everyone here knows javascript. Almost know one here knows Lisp, make your own conclusions.

You do realize this site was written in Lisp?

Unless the authors of the software behind HN make up a large portion of its comment contributors, I don't see the relevance.

Where did you get that impression from?

* Almost know one here knows Lisp, make your own conclusions.

nor English it seems :)

Still waiting for someone to correct the GP...

"No one is born knowing JS" or "No one was born..."

Looks like timmm isn't a native English speaker, should his command of English be more important than his message?

There are languages where "to be born" is one verb and it makes it reasonable to make the mistake and think that in english it would be the same: "to born".

I apologize if i came off as snarky. I was trying every bit not to. I didn't correct it immediately, but when i saw another user correcting, I added my own correction to his comment.

Btw, English isn't my first language either, so please do not see this as "arrogant English speaker wants everyone to speak his language". In fact, my mother tongue is far far different from english (we dont even have a common script!)

Emacs has pull down menus, cut and paste, CUA bindings, displays graphics, plays sounds...

WTF do you mean by "terminal-style buffers/frames?"

I don't mean to sound hipster or anything but I prefer software with native look-n-feel on the platform I'm using.

I tried Emacs on OS X (proglang on Coursera asks students to use it for editing SML), gave it a couple of hours and switched back to Sublime.

I understand I missed all its glory and power but at least Sublime scrolls like OS X apps scroll, has shortcuts like OS X apps and looks like a OS X app.

But then again, I understand why you might think this is a fool's position. I'm okay with that.

you ain't going to get native look and feel from atom.

Scrolling in WebKit is native, scrolling in Emacs isn't.

so write ruby or python for vim then.

not saying vim doesn't have it shortcomings, but people always forget that a scripting language for random app xyz still means you have to learn it's grammar. just like people who use ruby motion have to painfully learn that in the end while it looks like ruby it's still cocoa.

All programmers end up either learning or rewriting Lisp.

Just because people can program in Javascript doesn't mean they will be able to easily modify the code. Complicated code is complicated in any language, and Javascript in particular allows to write completely incomprehensible code that even pros would have trouble with. In addition, you'd still have to learn all the necessary APIs which might be harder than learning a new language.

Paradigm shift? I don't know, I've been writing desktop software in JavaScript for years now, it has its place but it also has big disadvantages yet, especially with accesibility stuff, which comes free if you use the stuff your OS offers for free.

  Atom is not only not open source but ...

Do you have a source for this? I'd be very disappointed to hear that if it were true.

EDIT: It appears that this isn't true. From a GitHub employee in freenode/##atom:

  <jonrohan> EvanDotPro: it will be open source, and other platforms, when it's out of beta
  <chance> jonrohan: where are you getting that information?
  <jonrohan> chance: i work at github

From Tom Preston-Warner: http://discuss.atom.io/t/why-is-atom-closed-source/82/8

> Atom won't be closed source, but it won't be open source either. It will be somewhere inbetween, making it easy for us to charge for Atom while still making the source available under a restrictive license so you can see how everything works. We haven't finalized exactly how this will work yet. We will have full details ready for the official launch.

Either jonrohan is misinformed, or he's using a rather tortured definition of "open source" - even the Open Source Initiative would disagree with that usage[0].

I must say, I'm a bit disappointed by the fact that Github doesn't seem to be on the same page internally about this; it's a rather important piece of information.

[0]http://opensource.org/definition

> not only open source

That means the opposite of what you thought it did :)

It was

> not only not

> Atom is free during the beta period.

Where does it say it won't be free after the beta period?

Well, one can only assume, based on the wording they use here:

https://github.com/atom/welcome/blob/master/lib/welcome.md

> Atom is free during the beta period.

This reminds me of one of Mitch Hedberg's more famous jokes: "I used to do drugs. I still do, but I used to, too."

How refreshing, a correct usage of "the exception that proves the rule"!

And there goes four hours of my night to wikipedia

One can assume that, but that's not what it says. The statement that the editor is free during beta could mean "we haven't figured out whether to sell it after the beta, sell services around it, or develop integration with our other services and keep it free to enhance our overall value proposition."

Atom won't be closed source, but it won't be open source either. It will be somewhere inbetween, making it easy for us to charge for Atom while still making the source available under a restrictive license so you can see how everything works. We haven't finalized exactly how this will work yet. We will have full details ready for the official launch.

> http://discuss.atom.io/t/why-is-atom-closed-source/82/9

It's funny you say that, because as the only full time-ish developer of Chocolat, I could really use a lot of help!

There's ~600 open issues, my personal todo list alone is several years' worth of work. Too much for one man.

---

People make too much of open vs closed source. The real distinction is individual-lead vs committee-written.

TextMate, Sublime and Vim are good editors. But they are also Allan, Jon and Bram. Writing an editor requires good taste, accumulated experience, and a certain disregard for users' feelings.

You need someone who cares about the editor. Without that, you get a program where everything is wrong, but nobody ever bothers to fix it.

This is however a blessing and a curse. If the author can't financially support themselves, the editor will die. If the author becomes a millionaire, the editor will die. Thankfully, I'm still poor.

---

What are the 25 little things, by the way?

Haha, too much work indeed. :) I'm not going to list all 25 here, but I'd say the biggest three are definitely issues #1157 (this is HUGE, add a pref option please!!), #1369 (please!), and #1451/1417 (constantly crashing).

But overall, it's still just the most beautiful and elegant editor. :) Thanks for it!

Never heard of Chocolat before - but it is a very attractive OS X app!

Have you looked at Adobe Brackets? It's basically that, open-sourced today. Or look at node-webkit if you only want the app framework without the editor. The biggest downside I see right now is HUGE binaries (100+MB) because you're bundling a browser in your exe.

Browsers are 100+MB?

>> and it's in JavaScript, so it couldn't be easier for programmers in general

Because JavaScript is magically easier than any other programming language ever invented.

Even if this were true, it still wouldn't help an expert Objective C programmer with no JS experience hack on Atom.

Your bias is showing.

Adobe has been working on Brackets for a while, and it's essentially the exact same concept.

> 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.

http://discuss.atom.io/t/atom-is-so-powerful-that-it-blows-m...

> How I felt after that? I felt awesome. I had only installed Atom minutes ago. I didn't even had to think to fix my problem. All the knowledge I needed was already in my head! It was simple as editing a webpage. TL;DR: Atom allowed me to fix one simple problem – that I still encounter in most text editors nowadays – in seconds. What about yours?

You are so on-the-money about Chocolat. I love it except for the things that drive me crazy. I've been trying to love Sublime Text lately. Even though I see the benefits, I see the un-Mac-like-ness of it even more.

It's a benefit if your team uses a mix of Mac/Linux/Windows.

Oh don't get me wrong. The benefits are potentially huge. But it's also frustrating because I have decades of muscle memory built up that doesn't always work with Sublime.

I'm with you. I'm an Emacs user, which ostensibly has a similar design philosophy (open source, with powerful extensibility from a full-blown programming language), but Emacs Lisp has a lot of baggage and is nowhere near as widely used as JavaScript. I also find the Emacs community disjointed and hard to navigate and participate in. Ultimately, assuming that the underlying design decisions of Atom are reasonable, its success will depend on the community that develops (double meaning intended) around it. It could be great.

> Emacs Lisp has a lot of baggage and is nowhere near as widely used as JavaScript

Back in the 90ies, when I started using Emacs, Elisp had a lot of baggage and was nowhere near as widely used as Perl.

I'm still using Emacs.

That is also one of the ideas behind Light Table.