Emacs could gain a lot of performance boosts with some significant changes to its architecture. It would be a lot of work to do and doing so requires a set of skills that are much less available than other software engineering skills unfortunately. I am hoping either that occurs or there exists a viable replacement for Emacs that incorporates the improvements more easily due to starting with a blank slate.
Proprietary programs are a deal breaker for me as far as contributing to them in my free time a great deal due to how frequent they go out of business and lose support. So, a new iteration of Emacs would require a very free license for me to have confidence that my efforts won't be wasted in a short period later.
I am hoping that Light Table is released with a license and degree of openness that provides a similar degree of hackability as the Emacs platform does. If that happens I think I will make a lot of effort to bring it up to speed with features Emacs has but Light Table doesn't at the time.
Chris Granger has made a lot of smart design decisions that really appeal to me about Light Table. His point in one presentation that while Emacs and VIM are fantastic at text related operations, there doesn't exist something comparable that has both great support for text and great support for visualization.
That is a thought that really resonates with me. Having fantastic graphing capabilities and embedding of graphic tools such that the work flow can exploit both graphics manipulations and text operations would be a huge boost in capabilities, something which adding to Emacs would be much harder due to so much legacy code in the platform that will have to be accommodated in the process.
As an example, people have really wanted to move Emacs underlying language from elisp to common lisp for a long time, but it is such a massive undertaking and transitioning the community to using it would be so difficult that (without a team to work on it constantly) no one has succeeded in doing so fully.
Light Table's decision to use any language which can compile to javascript as its backend and use node-webkit as its front end results in a lot of features that are free in the process that are very nice to have for tool building.
And Granger has made a point to customize the compilers for the languages it supports to glean even more information and manipulation of the languages in the process, something which I hope is kept up as its support expands.
I absolutely love its instarepl design that is motivated by his idea of real time debugging. Combining that with Crockford's context or scope based coloring concept would be a massively useful feature set for development and tools to be able to exploit. The scope based coloring isn't something that Light Table has already or something Granger has mentioned adding, but it is something I hope enthusiasts can add assuming the platform is sufficiently extensible.
Granger's earlier idea of breaking down the environment based on functions as the smallest unit of focus instead of a file is another brilliant design concept that will be available in the future (according to another presentation he did).
So, I am very excited about its potential as a replacement for Emacs that takes that idea and makes it even better based on adding modern developments, and Granger seems to really appreciate open source and has a willingness to contribute towards that.
So, I am hoping that somehow the Light Table team is able to both charge for the tool and make it fully extensible as well as remove the potential for abandonment of the platform to result in a volunteer's effort being wasted, such as fully porting SLIME (a very exceptional lisp development environment that emacs has) to Light Table as well as ESS (a statistics development environment which could benefit from more graphics potential being available) that emacs has.
I think Light Table will already be a killer app for REPL centric platforms by the 1.0 release, and languages which have excellent REPL support and debugging is what I mainly use already. Adding the other features I mentioned will make it unquestionably the new state of the art for that context.
Comments
Emacs could gain a lot of performance boosts with some significant changes to its architecture. It would be a lot of work to do and doing so requires a set of skills that are much less available than other software engineering skills unfortunately. I am hoping either that occurs or there exists a viable replacement for Emacs that incorporates the improvements more easily due to starting with a blank slate.
Proprietary programs are a deal breaker for me as far as contributing to them in my free time a great deal due to how frequent they go out of business and lose support. So, a new iteration of Emacs would require a very free license for me to have confidence that my efforts won't be wasted in a short period later.
I am hoping that Light Table is released with a license and degree of openness that provides a similar degree of hackability as the Emacs platform does. If that happens I think I will make a lot of effort to bring it up to speed with features Emacs has but Light Table doesn't at the time.
Chris Granger has made a lot of smart design decisions that really appeal to me about Light Table. His point in one presentation that while Emacs and VIM are fantastic at text related operations, there doesn't exist something comparable that has both great support for text and great support for visualization.
That is a thought that really resonates with me. Having fantastic graphing capabilities and embedding of graphic tools such that the work flow can exploit both graphics manipulations and text operations would be a huge boost in capabilities, something which adding to Emacs would be much harder due to so much legacy code in the platform that will have to be accommodated in the process.
As an example, people have really wanted to move Emacs underlying language from elisp to common lisp for a long time, but it is such a massive undertaking and transitioning the community to using it would be so difficult that (without a team to work on it constantly) no one has succeeded in doing so fully.
Light Table's decision to use any language which can compile to javascript as its backend and use node-webkit as its front end results in a lot of features that are free in the process that are very nice to have for tool building.
And Granger has made a point to customize the compilers for the languages it supports to glean even more information and manipulation of the languages in the process, something which I hope is kept up as its support expands.
I absolutely love its instarepl design that is motivated by his idea of real time debugging. Combining that with Crockford's context or scope based coloring concept would be a massively useful feature set for development and tools to be able to exploit. The scope based coloring isn't something that Light Table has already or something Granger has mentioned adding, but it is something I hope enthusiasts can add assuming the platform is sufficiently extensible.
Granger's earlier idea of breaking down the environment based on functions as the smallest unit of focus instead of a file is another brilliant design concept that will be available in the future (according to another presentation he did).
So, I am very excited about its potential as a replacement for Emacs that takes that idea and makes it even better based on adding modern developments, and Granger seems to really appreciate open source and has a willingness to contribute towards that.
So, I am hoping that somehow the Light Table team is able to both charge for the tool and make it fully extensible as well as remove the potential for abandonment of the platform to result in a volunteer's effort being wasted, such as fully porting SLIME (a very exceptional lisp development environment that emacs has) to Light Table as well as ESS (a statistics development environment which could benefit from more graphics potential being available) that emacs has.
I think Light Table will already be a killer app for REPL centric platforms by the 1.0 release, and languages which have excellent REPL support and debugging is what I mainly use already. Adding the other features I mentioned will make it unquestionably the new state of the art for that context.
Yup, Light Table looks really interesting.