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.
The future is specific
131–138 of 138 posts
Re: The future is specific
#132Earlier 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?
Re: The future is specific
#133Earlier 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.
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
#134Earlier 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.
Re: The future is specific
#135Earlier 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.
Re: The future is specific
#136The 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.
Best of luck to you by the way :)
Re: The future is specific
#137The 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.