I would love to run Light Table on a Surface http://www.microsoft.com/surface/en/us/default.aspx Feature request! :-)
Light Table reaches 300k necessary for Python support
11–20 of 37 posts
Re: Light Table reaches 300k necessary for Python support
#12As if money would magically make hard things happen :) Seriously, what if Python is specially hard to support for some reason? I feel if it was in the easy-to-medium-hard space, there would be a Slime port to Python, and if there isn't, its because its probably hard...
> As if money would magically make hard things happen :) If those hard things require people working full-time on solving them, then yes, money does magically makes them happen. > Seriously, what if Python is specially hard to support for some reason? This is engineering and computer science, there are no magical reasons, only specifics. What would make Python difficult to support exactly? It has full introspection,…
Well, I imagine one reason is that there are exactly zero static call sites in Python. Everything is called by name, and monkey-patching is, for better or worse, an accepted and widely used tactic. I have seen projects that use Python's source code introspection facility to rewrite code inside decorators. You can even define new keywords in this way.
Decorators in general are a widely used tactic to execute arbitrarily Python code with potentially unknown runtime state to transform the Python code you just parsed into a totally new function.
There is just very little you can learn from parsing Python code, you need runtime state to understand some functions. It is potentially as difficult as Lisp, and with a much larger set of primitives to cover.
And if you take the approach that you aren't going to just parse, you are going to implicitly execute the Python that is being written, then you need to sandbox the whole of Python. It's not like a REPL where everything is explicit and if a programmer writes subprocess.call(['rm', '-rf', '/']) they want their filesystem to blow up. You can't just go around implicitly executing WIP code.
Now, a reasonable approach might be to punt on the whole issue and say, "If your code doesn't execute in a vacuum, with standard python libraries and no funny business with decorators and monkey-patching, then we won't touch it" but I think the reality is that there is a lot of important Python code that can't be correct in such a vacuum.
It's not a total lost cause, but I do think there are many good reasons why a Python Light Table is very hard.
Re: Light Table reaches 300k necessary for Python support
#13As if money would magically make hard things happen :) Seriously, what if Python is specially hard to support for some reason? I feel if it was in the easy-to-medium-hard space, there would be a Slime port to Python, and if there isn't, its because its probably hard...
> Seriously, what if Python is specially hard to support for some reason? Many of the cool features in LightTable are already supported by fancy python interpreters like iPython and bPython. LightTable must either implement a Python parser and a partial interpreter/evaluator that is used to analyze call graphs and such or use the relevant parts from the Python core. Not a simple task to implement (and maintain) but m…
What call graphs? Everything in python is call-by-name. `globals()['foo']` isn't exactly a very strong reference, and anyone can change it.
Re: Light Table reaches 300k necessary for Python support
#14The bp editor has similar features (code bubbles), though dynamic evaluation and code bubble workspaces are still in development. And I'm pretty sure it won't cost me 300k to finish it.
http://blitzprog.org/
Re: Light Table reaches 300k necessary for Python support
#15I still can't believe people are paying this much attention to a glorified text editor.
As programmers, we spend most of our working time in glorified text editors (I'm using mostly Emacs at the moment, which that is certainly an apt description of). I guess it's natural to be excited about new alternatives for our primary tool.
Re: Light Table reaches 300k necessary for Python support
#16Earlier quoted context omitted.
> Seriously, what if Python is specially hard to support for some reason? Many of the cool features in LightTable are already supported by fancy python interpreters like iPython and bPython. LightTable must either implement a Python parser and a partial interpreter/evaluator that is used to analyze call graphs and such or use the relevant parts from the Python core. Not a simple task to implement (and maintain) but m…
What call graphs? Everything in python is call-by-name. `globals()['foo']` isn't exactly a very strong reference, and anyone can change it.
In practice, those things are hardly changed. When they are, users understand that the IDE might not be able to help them,
Re: Light Table reaches 300k necessary for Python support
#17The bp editor has similar features (code bubbles), though dynamic evaluation and code bubble workspaces are still in development. And I'm pretty sure it won't cost me 300k to finish it. http://blitzprog.org/
That website is awful.
Re: Light Table reaches 300k necessary for Python support
#18Re: Light Table reaches 300k necessary for Python support
#19Earlier quoted context omitted.
That website is awful.
Alright, what do you want me to fix then?
It requires a lot of effort to get information. The embedded auto-playing video reminds me of pre-Facebook social networking, requiring further effort turning it off (especially after scrolling down trying to figure out what's what) before a user can then move their cursor around the site to access the content they wants.