[benaiah]

> An open, compile-less, hot-reloading editor sounds like a dream coming true.

You're talking about Emacs, right?

This actually seems really exciting, and I'll give it a whirl when and if I can. It's just funny to see people (the Light Table fans as well) rediscover what Emacs users already knew - modifying your editor in-place is really awesome.

[jared314]

> It's just funny to see people (the Light Table fans as well) rediscover what Emacs users already knew

Since many of the Light Table fans either use or have used Emacs, I would say that it is more of a relief to have something that takes the Emacs concepts and tries to modernize, adapt, or polish them. It might also be good to mention that the Light Table team chose a "usable editor first" strategy to build a user base, before attempting the concepts they demoed early on in development. So, we will see if it ends up mimicking Emacs or, perhaps, something different.

[1qaz2wsx3edc]

You hit the nail on the head there: "tries to modernize, adapt, or polish them". There's a lot we can do with the stack, we've got websockets (pair programming anyone?), workers, sql, and more baked into browsers. I'm not saying an editor cant do those things, but I think the level of entry and collaboration are totally different outside a web stack.

[maxharris]

You're talking about Emacs, right?

Over the last 18 years, I've tried to figure Emacs out a few times, but it always ends up baffling me. It may be as powerful as you say, but given how obtuse I am (or perhaps how terrible Emacs is), I'll never know.

[barrkel]

It took me a good 15 years before I started using Emacs a few months ago.

What made it work was (a) learning how to tweak the configuration to suit me, (b) learning Emacs jargon equivalents (chiefly: selection => region, cursor => point, open => find, file => buffer, pane => window) and (c) already knowing enough lisp to be able to tweak configuration further than simple variables and modes.

Then what really made it work was finding out about package repositories.

Emacs, when I first started out, didn't understand the arrow keys properly on my terminal, and required you to learn all the C-n, C-p, C-f, C-b etc. to move around. It also didn't have transient mark mode. But it can do all these things now (although I still have terminal configuration files to map function keys in Cygwin, Rxvt etc. because I mostly work in the terminal), all it really took was a Sunday afternoon researching settings, key bindings and modes, before it was almost as usable as any GUI editor.

Emacs is awesome. I'm sorry I didn't learn it sooner. I've gone through several generations of IDEs and programmer's editors that have come and gone in the past 20+ years. I could have been using Emacs all that time and increasing my knowledge and library.

It is, however, still weak with languages that heavily rely on IDE support, like Java and C#. emacs-eclim and other hacks aren't quite enough to make up for it. Although I still have an emacs session open on every Eclipse project because helm-git-grep is way too good to not use; and also it's better for certain text editing. I had a big aha moment when I found out that M-/ also works in Eclipse!

[6cxs2hd6]

> It is, however, still weak with languages that heavily rely on IDE support, like Java and C#

Which I see as a weakness of those languages -- not a weakness of Emacs (or Vim, or any other Not-The-Walled-Garden-IDE). I think needing an IDE to be productive is a kind of "language smell".

I do appreciate that some of us don't have a choice but to use them, and that they have good points -- just not this.

[barrkel]

Well, the strengths of languages like C# and Java are extensive libraries along with static typing and the code completion that enables. Object orientation also helps with code completion, because the you normally have the noun to hand in a local or a field before trying the operation.

Java does have a fashion for verbose identifiers, and C# has picked up a little bit of it, although the ceremony is less in C#. Ceremony can be macro'd away, but verbose identifiers are more problematic.

I'd also argue that the scope and complexity of big Java apps is often larger and broader than most C++ apps: more libraries used, and at a higher level of abstraction. When you dance across the surface of many different libraries, good code completion makes your life easier. That is, the chief problem code completion solves is not intrinsic to any given language, but rather the absolute number of symbols used.

When coding languages like Ruby, I rely heavily on the interactive console (Pry for Ruby) in order to get the moral equivalent of code completion.