Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future is specific

chris-granger.com

Post reply on HN
Print view View original

51–60 of 138 posts

Re: The future is specific

#51

Post by ashliana »

More of a meta comment on the future being specific and how it is all about creating more domain-specific tools vs generalized tools... I think that's really a common property in any complex, highly powerful system. Think about the brain, the economy, DNA, a corporation even... etc. Domain specificity is the past and the present, too!

Re: The future is specific

#52

Post by mattbriggs »

DanI-S wrote: post #38
moe wrote: post #30

Earlier quoted context omitted.

Same here. As much as I like vim - it remains software from the stone age and it seems absurd that our main work interface (editor and shell) still consists of an emulated 1980s text-mode terminal. LightTable looks like a major step in the right direction. I think the best indicator for success will be when the vim/emacs-diehards start porting their respective shortcuts and functionality over. I could very well see t…

The thing that draws me to Vim, really, is the extensibility. There's a steep learning curve to creating a powerful Vim extension, but there are still a huge number of them. Imagine if Light Table can make editor extension something you can do per project ! I probably have a unique preferred layout of Vim splits and tabs that I use for each codebase I work with. Being able to take this further, telling the editor whi…

vims extensibility is a commonly cited positive, but I totally do not understand it, since pretty much every editor imaginable is extensible in similar fashion, and pretty much all of the use better languages then vim.

By contrast, emacs is basically an application platform that ships with an editor implementation, and eclipse is a platform for building editors.

It's not that vim isn't extensible, it is, just not as much as other alternatives, and nowhere near as easily as most of its competition.

IMO the real advantage of vim is that it is a highly efficient and productive tool that works great without any customization, and is available everywhere without installation. Which is pretty much the opposite of the above opinion.

Re: The future is specific

#53

Post by Arelius »

kamaal wrote: post #26

I don't mind if the future is specific. But its really wrong to say IDE's like Eclipse don't do one specific task well. Eclipse really makes Java programming very easy. And I can tell you minus Eclipse programming in Java would be a very frustrating experience, given the verbosity, configuration mess and XML's all over the place. Eclipse these days is advanced enough to really blur the difference between and novice a…

What I worry about Light Table is what it won't be from Emacs. At the end of the day, Emacs is still a text editor, and still edits files. This means that I really can use it for anything, doesn't matter if I have a mode for it, or an embedded compiler/REPL. It still just works, and we can't forget this if we want a modern Emacs.

Emacs was born in a world of textfiles, Light Table shows us a post-textfile world, but before we can get to the future, it needs to be able to survive in the world we live in today, which is one where textfiles are king.

Re: The future is specific

#54

Post by stcredzero »

kamaal wrote: post #26

I don't mind if the future is specific. But its really wrong to say IDE's like Eclipse don't do one specific task well. Eclipse really makes Java programming very easy. And I can tell you minus Eclipse programming in Java would be a very frustrating experience, given the verbosity, configuration mess and XML's all over the place. Eclipse these days is advanced enough to really blur the difference between and novice a…

I would say eclipse already does what light table aims to do.

Can you come to a realization in the middle of an Eclipse debugging session, get a great idea for making yourself more productive, take time to script yourself a working and fully debugged extension of Eclipse and continue what you were doing 20 minutes later?

I've done precisely this in Smalltalk on many occasions. You can script something like a custom browser that shows you everything that uses function A and also function B and has a reference to class C (and with complete syntactic accuracy) in around that time.

I suspect that this kind of very small grained toolsmithing is common for really good programmers in dynamic environments. The only problem is that it's been harder than necessary to integrate that with the most commonly used coding tool. (TextMate's ability to export selections to scripts is very nice, but it can go farther than that. Emacs is very powerful for this, but not everyone wants to script in elisp.)

It's not that Light Table is going to do something unprecedented. It's more like what git did with quick access to diffs: a quantitative change can become a qualitative change. Change the cost-benefit of toolsmithing, and you can use it in new ways.

Re: The future is specific

#55

Post by ibdknox »

Arelius wrote: post #53
kamaal wrote: post #26

I don't mind if the future is specific. But its really wrong to say IDE's like Eclipse don't do one specific task well. Eclipse really makes Java programming very easy. And I can tell you minus Eclipse programming in Java would be a very frustrating experience, given the verbosity, configuration mess and XML's all over the place. Eclipse these days is advanced enough to really blur the difference between and novice a…

What I worry about Light Table is what it won't be from Emacs. At the end of the day, Emacs is still a text editor, and still edits files. This means that I really can use it for anything, doesn't matter if I have a mode for it, or an embedded compiler/REPL. It still just works, and we can't forget this if we want a modern Emacs. Emacs was born in a world of textfiles, Light Table shows us a post-textfile world, but…

From the bottom of the post:

"If you couple [DSTs] with the generalized editing capabilities I showed last time, you have what we believe to be the future of tools: an environment that you are able to mold to the exact shape of your problem."

I agree, we have no intention of removing general editing - you need it as much as anything else at this point.

Re: The future is specific

#57

Post by stcredzero »

ibdknox wrote: post #36
kamaal wrote: post #35

Earlier quoted context omitted.

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 Tab…

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.
Post reply on HN