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

These were examples of extensions to make a point and not at all what we'll be focusing on. What we're making sure of is that the platform for such things exists and enables all of the things that old UI's and such don't allow.

I think the parallel to emacs is a good one and while I certainly won't say at this point that we'll be the "modern emacs", it's our hope we can come close.




I think from the discussions and other threads what I infer is that we need a total re-look at the concept of an editor, Your way actually looks good. Except that we need to retain the 'Emacs infrastructure'.

We need to really keep Lisp as the extension language.

I think what we need is Light Table with something like this : http://www.kickstarter.com/projects/568774734/emacsy-an-embe...

You have to develop Light Table ON the Emacs OS!


Lisp is the extension language :) Everything so far is Clojure + ClojureScript with the language backends written in the language they support (python in python and so on)


How about Stallman's idea for GUILE (Scheme) uber-alles. Do source-to-source translation of approximations of the supported languages to Clojure. This would allow everyone access to almost everything in the tool.


That effort hasn't even materialised for Scheme+Elisp for Emacs.

The whole approach is guaranteed to not produce a perfectly compliant of any other language.


Yes, that is the price. That's the price for native access to the entire codebase of the underlying editor.

So long as it's close enough, you don't need perfect compliance.


I disagree. If the support isn't perfect, you might as well not bother and help people learn your native language.


I think the popularity of CoffeeScript is a datapoint against your idea. I bet a lot of pythonistas use it because it's less of a shift than Javascript. Also, in such a system, if people are curious enough, they will learn the native implementation language as a result of the system being so constructed.


I'm not sure it's a datapoint against; most people I talk to use it because it fixes objective flaws in JavaScript.


It might have been better to demonstrate this with examples like:

  truth-tables for (nested) if statements
  petri-nets for a state machine
  etc. etc. etc.


out of curiosity, is js going to be your "elisp"?


Clojurescript, actually -- a Clojure dialect that compiles to JS.

Well, Clojure too, on the server side of things.


Are we really gonna need the JVM running the backend for this? That seems so unnecessary.


Given the initial goal was for a Clojure editor (which runs on the JVM), running the JVM was a prerequisite anyway.


I'm pretty sure the core of it is to be written in Clojure, so yes, you'll need the JVM running. It is necessary if it is to be written in a JVM language. Eclipse and a number of other IDEs also require a JVM to be running.


you could probably just precompile your extension


afaict, precompiled java still requires the jvm.




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

Search: