Hacker News new | comments | show | ask | jobs | submit login

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



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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: