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

101–110 of 138 posts

Re: The future is specific

#101

Post by heretohelp »

ibdknox wrote: post #66
heretohelp wrote: post #65

Earlier quoted context omitted.

I'm more deeply concerned about the fact that Emacs is something which, roughly speaking, I can control. Emacs is a community project. Your project appears to be commercial in nature, regardless of whether or not it's open source. Your project will also be a dictatorship by dint of the fact that it belongs to you. Why should I trust you to provide the most fundamental tool in my work?

It will probably be under the GPL just like Emacs, so I'm not sure I understand the concern?

I'm fine with profit-seeking, but GNU projects like Emacs tend to be too fundamental to allow a proprietary solution to predominate. (Cf. gcc)

I'm fine paying for servers, for contractors, services, random productivity-ware like Pivotal Tracker etc. but I'm never going to be okay with subjecting my development environment, something I've honed for years and years, to fee extraction or proprietary control by a commercial entity.

Re: The future is specific

#102

Post by mattbriggs »

Arelius wrote: post #100
phyzome wrote: post #86

Earlier quoted context omitted.

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.

you could probably just precompile your extension

Re: The future is specific

#103

Post by zcam »

Arelius wrote: post #98
zcam wrote: post #94

Earlier quoted context omitted.

Also emacs provides an extensive platform with tons of modes to support pretty much anything you can throw at it, works in a terminal if needed, has an abstraction over files (buffers), debuggers, easy modes for vi/cua users, can connect to browser instance if needed and tons more. Building a lighttable mode or even several small modes (libraries vs framework) for emacs would make more sense. It is going to require a…

The advantage of LightTable's approach is that using HTML, is a simple, trivially extensible and powerful way to provide advanced UI widgeting, something modern emacs supports very poorly. Mostly due to working in a terminal if needed, but I think it holds it back a bit. The closest thing we have in emacs is pixmap support, which is poor, and painful to use! Though, is LightTable the best/easiest way to get that? I d…

> Though, is LightTable the best/easiest way to get that? I don't know, it may be easier to render emacs buffers into a webkit view, it may also not be.

That is what I meant with "connect to browser instances" (swank-js already allows that, among others). Basically when you need more advanced rendering, or browser environment when it is your target (browser based games and whatnot), this could be good enough and you can leverage a huge ecosystem for all the rest.

Re: The future is specific

#104

Post by stcredzero »

silverlake wrote: post #72
stcredzero wrote: post #54

Earlier quoted context omitted.

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

Couldn't you build a LightTable-like IDE in Squeak right now?

Squeak is somewhat LightTable-like already, except everything needs to be refreshed manually. (And not all of it is obvious to the beginner, though all of it is readily available if you know how.)

You actually couldn't have everything update automatically and expect bad things never to happen. Functional programming has an advantage here.

Re: The future is specific

#105

Post by stcredzero »

lucian1900 wrote: post #76
stcredzero wrote: post #57

Earlier quoted context omitted.

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.

Re: The future is specific

#106

Post by Estragon »

ibdknox wrote: post #66
heretohelp wrote: post #65

Earlier quoted context omitted.

I'm more deeply concerned about the fact that Emacs is something which, roughly speaking, I can control. Emacs is a community project. Your project appears to be commercial in nature, regardless of whether or not it's open source. Your project will also be a dictatorship by dint of the fact that it belongs to you. Why should I trust you to provide the most fundamental tool in my work?

It will probably be under the GPL just like Emacs, so I'm not sure I understand the concern?

What kind of business strategies would be compatible with that?

Re: The future is specific

#108

Post by frio »

Arelius wrote: post #100
phyzome wrote: post #86

Earlier quoted context omitted.

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.

Re: The future is specific

#110

Post by anigbrowl »

What I would like is a way to do more graphical programming, like this: https://www.google.com/search?hl=en&q=reaktor&ion=1&... or this: https://www.google.com/search?hl=en&q=reaktor&ion=1&... (which latter includes both C-like and assembly code modules, as well as extensive GUI manipulation capabilities).

When I was learning to code, and still sometimes, what annoys me about typing is that I don't know what I don't know. With graphical programming, having predefined modules with discoverable inputs and outputs encourages me to try connecting things together on a what-if basis to a much greater degree than a textual environment. This is what I find very attractive about the way Light Table is going; a lot of the time I want to build things but not necessarily to write code.

Post reply on HN