Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

I am sad that LT didn't succeed as I hoped (I was a backer), but this email highlights a very important feature for succesful open-source projects (which LT was meant to be from the start), which is to make them accessible to other contributors.

Building your project in a niche language (not just Clojure, but ClojureScript) is a risk. Making it tough to follow the code/data flow is indeed a terrible decision (though usually a silent one as a side-effect of other architectural choices). Etc...

I'm an Emacs user, and I'm still waiting for the Next Great Editable Editor. (Though since it moved to Git [thanks ESR!], maybe Emacs itself will get a new wind)

View on HN

> I am sad that LT didn't succeed as I hoped (I was a backer)

Ditto. I'm especially sad that while it's a cool editor that does some neatish things, it's still just an editor + some neat stuff. The demo that was originally shown and pitched[1] was much more of a re-imagining of the concept of how we use editors, and _that_ was what I was looking forward to. I downloaded LT once and then decided to wait until those concepts arrived. At this point it's pretty clear that day will never come.

[1] http://www.chris-granger.com/2012/04/12/light-table---a-new-...

Chris didn't give up, he just changed his approach to something that has a better chance of working.

Those of us who have been working in this field for awhile already guessed that many of the features promised by the original lighttable kickstarter would require a new programming model to really work out.

I don't mean to imply that Chris gave up, just that LT is not going going to reach the features discussed in the original pitch.

> Those of us who have been working in this field for awhile already guessed that many of the features promised by the original lighttable kickstarter would require a new programming model to really work out.

I guess I was naive, I presumed Chris knew something I didn't.

Reinventing programming is still a new field. We aren't really sure what is possible or not, and there are bound to be overly optimistic as well as pessimistic predictions.

The problem I have with the notion of 'reinventing programming' is, you know what? Those guys in the 60's and 70's where pretty damn smart. A lot of really cool tech came before, but has been forgotten. We are living in the age that Richard Gabriel predicted the unix/c perfect virus won just as he said[1]. Which is sad and good in different ways. One of the sad parts is; all we have to show from xerox parc[2] is modern windowing systems (imo).

So my point is; 'rediscovery' is a more apt way of expressing a lot of things today.

[1] http://www.jwz.org/doc/worse-is-better.html

[2] http://en.wikipedia.org/wiki/PARC_%28company%29#History

A lot of tech comes and goes because either (a) the time isn't right or (b) it isn't that good and gets superseded by something else.

Those guys from the 60s and 70s were smart, but we are smart also! It is time for us to stop living in the past and start moving to the future. Full on live programming hasn't been accomplished yet, the best achieved are simple REPLs, hot code swapping in Erlang/Smalltalk (which does nothing with state), and...direct manipulation (you can just update your objects directly, screw any code).

Some things just haven't been accomplished yet, and to claim they have been is just seriously dishonest and damaging since it dissuades people from trying. (I'm not referring to RPG here, I bet he is as frustrated as I am).

So ignore the haters and just get things done, I guess.

> the best achieved are simple REPLs, hot code swapping in Erlang/Smalltalk (which does nothing with state), and...direct manipulation (you can just update your objects directly, screw any code)

I think that sort of supports the point of the GP. Lisp had all the above and more (e.g. a proper REPL, live recompiling of everything in your image) since almost forever and yet not many people know about that. There's a lot of knowledge that was just forgotten by the fashion-industry IT is.

So I don't think we should stop trying - but it's really worth to go through the work done in 60s and 70s, because we could use it.

It's just not useful, they needed to go farther and wound up with a PX that some liked, but most didn't feel was worth it. Take the REPL for example, you are stuck in a linear command driven level of interaction if state is involved (and if state isn't, it is only useful as a fancy calculator). Take fix and continue in smaltalk - you can change the code, but you can't really fix the state (I.e. By time traveling), leaving your program in a seriously fragile state. And take morphic: where you can change the state (by directly manipulating objects) but not the code, so if you change something driven by code, your changes are completely ephemeral.

Each experience is serious lacking, and there are good reasons they haven't taken over the world. Chris Hancock does a better job than me in describing this, which is why I keep bringing up his dissertation: https://llk.media.mit.edu/papers/ch-phd.pdf

>>So ignore the haters and just get things done, I guess.

Not sure if you're implying I'm a hater here or not, but being charitable I'll assume not.

>> It is time for us to stop living in the past and start moving to the future.

The old saw about those who don't know their history and repetition springs to mind. Edit: not imply you don't know the history, as you clearly do, but many don't.

I was referring to the sentiment in general, with specific people in mind that I dare not say out loud.

I know my PL history pretty well, from Sutherland, McCarthy, Kay, Steele, Papert, Lieberman, not to mention all the VPLs, constraint programming systems, and so on. Ya, there is a lot of work, but that is no excuse to stagnate.

Edit: I'm not sure it is useful to shame people for not knowing their history. There isn't much wrong with reinvention, and who knows, it might be better than what was invented before. Our legacy sometimes does us more harm than good.

Yep, there's nothing intrinsically magical about that time that made language designers better than now. In fact, 30-40 years later we even have more collective experience under our belts!

What would it take for Emacs to become "the next great editor"? It extremely extensible now. Packages like Helm and Company mode have made emacs more competitive, for example.

https://github.com/emacs-helm/helm/wiki

http://company-mode.github.io

Yeah, Emacs may already be the Next Great Editor and not know it yet ;)

It needs to be more novice-friendly, having pre-CUA [1] shortcuts and terms ("windows" & "frames") is a trivial but powerful obstacle, I think. It needs to modernize its extension language: I still can't believe a 'then' clause needs a 'progn' if it's to contain multiple statements, but 'else' doesn't. I'm crossing my fingers for Guile, which, though still a niche language (Scheme), is at least more modern and standardized. I don't know how robust the interaction between the elisp (which is, like it or not, is here to stay) and Guile code is.

Emacs has a humongous codebase at over 2M lines of code [2] (of which, admittedly, 1.5M of that is elisp), with some deep black art as legacy from what it needed to run on when it started (thanks to ESR's work, the git history actually spans the entire 30 year history of the project! Here's the very first commit: [3] [Though admittedly because of RCS's per-file semantics, the early history is a bit weird).

But more importantly, it needs more mindshare. I'm hoping the git transition can help that.

[1] http://en.wikipedia.org/wiki/IBM_Common_User_Access [2] https://www.openhub.net/p/emacs (slow server) [3] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584...

Maybe the CUA thing doesn't matter. After all, Vim is much worse in first impression, but it's more popular by an order of magnitude. Maybe Emacs just needs to be installed by default, and for that, needs to slim down. Make more of its embedded elisp optional?

To me it is all about a sane starting point. With Sublime I could jump in and start writing code in a beautiful and immediately helpful environment, even though I had never programmed before. As I got better at programming I wanted more advanced features and most of them I found in the included batteries, and a few I got from plugins (although all the good plugins I want seem to have died).

With VIM or Emacs I have no idea where to start, except for maybe a few weeks in the terminal and manual before I can even start to code. Then it is still an open question about what it will scale to. I am not sure I want my environment to look like [this].(http://blog.jetbrains.com/pycharm/files/2013/06/vim3-1024x74...)

With Spyder, RStudio and Octave GUI I can start programming right away, I can see the benefit of the IDE right away, the only problem is I have 3 different text editors with their own short cuts and features.

If it takes you a few weeks to get started with the basics (in either Emacs or vim), you're doing it wrong. Following their respective tutorials you can get up and running (for basic open/navigate/edit/save/search/replace) functionality in a few hours. You won't be proficient, but you should be able to get stuff done. The rest comes with usage; you can't learn either editor properly by reading the whole book and then not using them. Proficiency comes from constant use, and you never stop learning. I'm an Emacs user of 13 years, and using Evil for the last 3 or so, so I'm comfortable in vim as well, and I still learn new stuff about them all the time.

The basic functionality is completely useless for doing actual programming work.

> (for basic open/navigate/edit/save/search/replace) functionality in a few hours

Do you know how long it takes in Sublime / Atom / TextMate ? Approximately zero.

I use Spacemacs (Emacs with VIM inside) and even after months of working with it I'm still faster in Atom. That's not because I'm "doing it wrong".

Sorry to chime being negative, but it takes you approximately zero because it uses the same paradigm as software you learnt years ago. It probably didn't take you zero time to learn how to open a file, what a files was, what a search-replace was, how it worked, etc, the first time you were confronted with it

Yes, that's my point. Emacs could, but does not integrate with the OS and established keys that well.

Spacemacs fixes some of that integration. cmd-X C V S all work. but no cmd-F or cmd-R

Well, the keybindings on emacs predate most other keybindings. I don't use it very often, but Cmd-F is forward-word, to move forward a word (heh.) For keyboards without arrow keys it is very handy (my oldest laptop didn't have them.) Cmd-R I have never used its binding (so I could rebind it, but what binding would you like to have in it? "Reload"?

sorry I mean cmd-shift-f which is usually find and replace.

and cmd-f is not the same as ctrl-f. in the emacs tongue it is referred to as s-f

predating is irrelevant. most of the younguns using text editors were born well after emacs was created.

Emacs is technically capable of being customized to suit established usage patterns. its only cultural stubborness that stops it.

Hours? It's more like about one minute --- that's how long it takes to do lesson one of vimtutor, which tells you how to save and quit, move the cursor, and insert and delete text. Going all the way to the end of vimtutor would probably take about 15 to 20 minutes, and assuming you remembered it all would make you pretty effective (I've been using vim for years and there's basic stuff in there I've never used; skimming it just now I kept going 'huh, I did not know that').

I will admit that the vi learning curve can be stupidly steep in places, but right down at the novice end it's not bad at all.

Sigh.

From my angle, I've been learning/using the CUA-type keyboard shortcuts since I was about 8 years old - so that's 20 years now, and 16 or so before I wrote a line of code.

The question is not 'how quickly can I learn open/save/etc in vim/Emacs?', or even 'how quickly can I learn open/save/etc and remember it next time I open vim/Emacs?' but 'how quickly will I be more productive in either of them than something that does use all the shortcuts I've been using for two decades and are basically wired into my unconscious as deep as the need for oxygen, food and sex?'

On that scale, I think a few weeks is the most generous estimate possible. I understand why people love vim and Emacs, but they often underestimate how steep the learning curve is if you're very, very used to doing the same things slightly differently.

What prevents you from programming in Emacs out of the box? It has a superset of Notepad functionality straight away, and more complex functions are easily learned through built-in help.

Does vim really have an order of magnitude more users than emacs? Is emacs really lacking in mindshare? I have no real reason to doubt those claims but I find them kind of mind-boggling. I'd have guessed they were close to parity (for the first).

And then some.

I can't immediately find the survey that struck me, but here's a Quora answer [1] that cites O'Reilley selling twice as many Vim books than Emacs, the Debian PopCon results [2] that are rather striking (but Debian PopCon has quite the preselection bias, and the data may not cover all sub-packages properly), and Ubuntu's results [3] are a bit harder to parse but also striking, with vim-common at 2714181 / 25488 installs / "votes" (regular uses), vs emacsen-common (the highest-placed "emacs" package) at 330647 / 1669.

[1] http://www.quora.com/Are-there-more-Emacs-or-Vim-users [2] https://qa.debian.org/popcon-graph.php?packages=vim%2C+emacs... [3] http://popcon.ubuntu.com/by_inst

Well, I'm an emacs guy, and I've bought a vi book (O'Reilley's in fact) and not an emacs book, because I needed a book to figure out how to use vi and I didn't with emacs. Just throwing that out there.

Same here. I got Practical Vim and then moved to emacs+evil because I liked some of the vim concepts but wasn't willing to trade the usefulness of emacs. Never bought an emacs book either, after all "emacs is the extensible, customizable, self-documenting, real-time display editor."

C-h (+ k or m) is probably one of the first key chords you are to learn when starting emacs, from there everything is downhill.

[3] is misleading as vim is preinstalled on Ubuntu while emacs isn't.

Not entirely misleading, see the "votes" stat which reflects uses.

People use what's available, having Vim preinstalled is a powerful headstart.

I consider myself an emacs user but if you counted invocations I probably invoke vi significantly more frequently than emacs (I'm not going to wait for emacs to start to edit some little thing in /etc).

There are people who can program very productively in vi (I'm not one of them), so they can use vi for long and short tasks. I can program very productively in emacs but I don't consider it the right tool for quick one-off edits of something. Also vi comes with pretty much every UNIX-like base system I know of, while emacs is often off in a port system somewhere.

I too fit that description for some time. Vim is what I would use when starting an editor to do something to a file, and emacs when wanting to live in the editor and reach out to external tools like a repl for some extended time.

Using emacs in daemon mode with launchctl on osx and then making a shell alias and an automator launcher for emacsclient that just connects makes starting the new client so fast that I can use emacs for the quick jobs, too. The only thing I have to do now is get used to the emacs command equivalents for the quick edit jobs. For example, in vim I can open a file to a specific line, delete that line and then the first 5 characters of the next 50 lines, and exit the editor in just a few keystrokes, while in emacs I'd still be playing with C-h a and googling. The things I've spent the most time in emacs doing, common lisp, clojure, latex, and so on, have a very different set of common operations than the common sysadmin tasks I used vim for.

I'm primarily a windows user, but I learnt vim so that I could more easily edit files on linux servers, since it's pretty much guaranteed to be there on any box I'm on.

I don't particularly enjoy programming in vi, but I tend to do it quite a bit when making small changes to our codebase on my dev box in the sky and I don't want to deal with the overhead of starting an IDE locally.

It also stopped people from laughing at me when I ran nano. :p

NOTE: I am neither an Emacs nor a Vim user but I'm interested in editors (and developing one).

Here are the results from the latest SO developer survey. The data may be biased, but it looks like vim outnumbers emacs by 5:1: http://stackoverflow.com/research/developer-survey-2015#tech...

Definitely not close to parity. If you search for "[programming language] emacs" and "[programming language] vim", you'll find more results for vim -- often many more -- for every language except "Lisp." (But even Lisp variants like Racket have more results for Vim.)

It would have to run in a web browser, for me.

For me, the problem with emacs is that (1) it's slow and (2) so many features are half-broken. To use the most random example, I'm using something to intelligently soft-wrap code (which is great!), but for some reason sometimes it doesn't work in C# mode. And in fact, loading C# code gives some random error in font-lock sometime. (Maybe these are slightly unfair since they're 3rd party code, but trust me, the entire emacs ecosystem lives in a state of "kind of, sort of" works.)

Here's me complaining about slow text rendering: http://www.reddit.com/r/emacs/comments/2e8byy/slowass_text_r...

Still, I keep using emacs because so far nothing else I've tried touches it. But I dream of an editor with the flexibility of emacs, but a strong focus on speed and correctness. (And terminal support -- terminals are very much still with us!)

A tall order, I know :)

The interesting projects I've been keeping an eye on are the port of Emacs to Guile and the Haskell-based Yi editor. Guilemacs will be an incremental improvement to Emacs, whereas Yi could be something entirely new.

The extensions would need to be maintainable. And interoperable. And integrated, at which point they'd possibly cease to be extensions.

My problem with extensible editors is that you have a combinatorial explosion of possible configurations, which therefore aren't fully tested. So you always end up with something slightly buggy.

"Building your project in a niche language (not just Clojure, but ClojureScript) is a risk."

If you are writing a tool to help java programmers program in java then writing it in java makes sense.

The problem is he was writing a tool that was not cutting edge enough for the clojure folks, and not easily approachable for its main users.

I disagree. I think LightTable was a great success. Personally, the product we made with LightTable positively affects thousands of people here in Scandinavia. What were your expectations from Light Table?

Reply on news.ycombinator.com