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

11–20 of 138 posts

Re: The future is specific

#11

Post by ibdknox »

lubutu wrote: post #6

I don't quite understand what the difference is between Light Table's modes and IDEs' plugins. Domain-specific components are exactly what make IDEs 'integrated'; without them they are generalised editors. But there is absolutely no difference, as far as I can tell, between Light Table's new SQL mode and an SQL IDE plugin. I'm personally much more fond of the Unix 'tool approach', in which there are no task-specific…

Sure, anything can be built given enough time :) The difference is that those modes can be built in a couple of hours with arbitrary UI and virtually any interactions you can think of. It's hard for me to imagine being able to build any of the things I showed in say Eclipse in any reasonable amount of time.

The idea is that Light Table will be built from the ground up to support very dynamic environmental contexts in which you can place anything.

Re: The future is specific

#13

Post by bnegreve »

Being specific is not a feature, this is what you do when you have no other way to solve a problem. The ambitious challenge raised by Light Table was to generalize Bret Victor's ideas to general programming, if they are unable to do this, I'll stick to my IDE.

Re: The future is specific

#14

Post by option_greek »

mcrittenden wrote: post #9

With all of the demos and information posted I still have trouble visualizing this working for real-world applications. A specific example: in the Python/Flask demo, functions were added to the current view as it was called. How would this work in a more complex case with calls to many functions, each which call many more functions (and so on), each belonging to different objects, etc.? The view would quickly become…

They could display it as a graph with function names like a call stack. Most IDEs support most of the features shown in a piecemeal fashion but Light table seem to have the features more integrated, reducing the friction between coding and testing.

Re: The future is specific

#15

Post by ibdknox »

mcrittenden wrote: post #9

With all of the demos and information posted I still have trouble visualizing this working for real-world applications. A specific example: in the Python/Flask demo, functions were added to the current view as it was called. How would this work in a more complex case with calls to many functions, each which call many more functions (and so on), each belonging to different objects, etc.? The view would quickly become…

Right now it goes at most one level deep into the call tree to prevent what you're talking about. The thinking I've had so far is that you then have a few options. You could go to one of the specific functions and say I want to see everything, you could go to a specific token and bring up its definition, or you could "focus" it to switch the starting point to that function. I think any of those could work, but I haven't tested them yet :)

To your second point the normal caveats of a replish environment will apply to any code execution stuff :) And the benchmarking mode was a simple example for working against functions once you already know they're the bottleneck. In a real application you probably need help getting there.

I agree and I think a big part of the job ahead is to understand how we can ensure these sorts of experiences mesh and flow together when working on something larger. Fortunately, Light Table itself provides a great project to prove that on.

Re: The future is specific

#16

Post by ulf »

Looks more promising every time! While I like the idea to not work on your stuff as files, I have a question in that regard:

Do you have specific plans on how to incorporate version control when not primarily relying on files?

Re: The future is specific

#17

Post by ibdknox »

ulf wrote: post #16

Looks more promising every time! While I like the idea to not work on your stuff as files, I have a question in that regard: Do you have specific plans on how to incorporate version control when not primarily relying on files?

It's still serializing to files - it has to, our workflows are entirely dependent on them :)

Re: The future is specific

#18

Post by frou_dh »

If you come up with some new code in a "scratchpad" area and want to save it, where will it go? In a new file? Appended to the end of an existing file?

Similarly, if you edit one of the "supporting" functions that appear and want to save those changes, will they be saved in-place (e.g. line 217-241) in whichever file that function is from?

Re: The future is specific

#19

Post by viscanti »

gumuz wrote: post #5

I love it, especially the grouping of files: route + models + templates, in 1 view is something I see a use for. Does anyone know of an editor which can do something similar?

Plenty of editors offer split view editing. You'll need to actually open the route, model and template files, but it's easy enough to have them all open at the same time. The real challenge here is how they'll handle larger files (real-world production code rarely is that small and clean, you almost always have complex logic and a number of database calls).

Re: The future is specific

#20

Post by SudarshanP »

ibdknox wrote: post #2

As promised, this is the second demo complete with python! For those who can't use vimeo: http://www.youtube.com/watch?v=osLReQSB9F0

It is so sad that Vimeo is blocked by many Indian ISPs for silly reasons. The whole Internet feels crippled. There must have been at least a dozen videos I wanted to watch today that were recklessly censored. Thanks for the youtube link. I think we need a Redundant Array of Cloud Videos.
Post reply on HN