Live data from Hacker News

The future is specific

chris-granger.com

131–138 of 138 posts

Re: The future is specific

#131

Earlier quoted context omitted.

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.

Re: The future is specific

#132
post #118
post #48

Earlier quoted context omitted.

But, instead compare that to Emacs, these are exactly the sorts of things people can and do do in emacs in reasonable amounts of time. And exactly why emacs has many great tools, from paredit-mode to SLIME. The comparison to emacs isn't meant as a slight to LightTable either, but please, let's not forgot the past when creating the future.

I've seen a lot of cool stuff in Emacs, but I haven't seen anything nearly this nice done in any reasonable amount of time. Emacs is a predominately text-based thing. Light table is not. With that said, wouldn't his "It's hard for me to imagine being able to build anything I showed in say Eclipse in any reasonable amount of time" comment also apply to Emacs?

Generally speaking, it ends up much less graphical, which is the major failing of Emacs in comparison to Lights Table, but if the functionality is what you are looking for, instead of the pretties then Emacs has similar development time. I'm not saying there is no value in Lights Table, but we should just be clear on exactly what the advantages are.

Re: The future is specific

#133
post #128

Earlier quoted context omitted.

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.

Is Light Table written in Haskell-like language? Because other functional language still allow side effect and IO and running everything in those language can still cause bad things.

Well, you can have bad things happen even more easily in Smalltalk, but enough of the library is well behaved that it's workable in development, especially since you can save the image periodically and you have a transactional log for even what you do after your last save.

To make Light Table work, you don't need 100% perfect semantics. You just need 99% good semantics, plus some way of turning off automatic refresh and refreshing manually.

Re: The future is specific

#134

Earlier quoted context omitted.

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.

Re: The future is specific

#135

Earlier quoted context omitted.

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.

Re: The future is specific

#136

The key line for me here is that the future is in 'easily created domain specific experiences'. I think this is very eloquently stated and can't agree more. I like what Light table is trying to do, hoewver it is still working in pretty much the same 'domain' space as existing IDE's ('code'), and trying to improve on the 'easily created... experiences' part. As the post is waxing lyrical, my piece to add to the broad-…

We showed examples that relate very cleanly to "normal coding", but what we ultimately want to see is exactly what you're describing. There are so many places where a thin veil over the implementation would be immensely useful, presenting new interfaces for things like working with physics simulations, financial models, etc etc.

Thanks for the response. I realise you probably have huge priorities finding your way to MVP right now, however I hope to see more of this side in the future. I just saw your 'live game editor' video, which is probably closer to what I am thinking of - using the visual element (in that case the game window) to feed back into the live code [this hasn't really been in the lighttable videos - which led me to my assumption lighttable was 'code' based in my prev post]. I really think that the future is in there somewhere.

Best of luck to you by the way :)

Re: The future is specific

#137
post #124

The key line for me here is that the future is in 'easily created domain specific experiences'. I think this is very eloquently stated and can't agree more. I like what Light table is trying to do, hoewver it is still working in pretty much the same 'domain' space as existing IDE's ('code'), and trying to improve on the 'easily created... experiences' part. As the post is waxing lyrical, my piece to add to the broad-…

I think a lot of that stuff can be done if there are JS implmentation. You want be able to use the importend functions from excel in a browser (or anywhere else) its just made for this kind of stuff. If there are JS you might be able to inlude them into the working process of Light Table. Lets see, its a nice idea.

Yeah. JS might help in this regard, but I guess I am hoping for an system where there isn't the same divide between coding environment and platform being coded for. If you could build excel (or similar) _within_ lighttable - and still allow all sorts of live code testing - that would be a real leap to me.
Post reply on HN