Live data from Hacker News

The future is specific

chris-granger.com

41–50 of 138 posts

Re: The future is specific

#41
>> The future of tools isn't in a better Eclipse or Visual Studio, it's in easily created domain specific experiences.

How is that goal different from that of the Eclipse platform (http://www.eclipse.org/platform/overview.php) - a common base where people can develop individual add-ons to suit the domain they're working on? Eclipse platform and LT clearly have different interaction models and technologies, but from the leading quote of the article, the same goal.

Writing Java in Eclipse is, as many have said, a great experience (in the continuum of Java-development experience). But you know what else is pretty good? PyDev (http://pydev.org/) - a Python IDE that's written on the Eclipse platform. It uses the same interaction models and designs as Eclipse for Java, but it's also got a whole bunch of bits that are just targeted at Python development. There's also a tool (the name of which I don't recall) that our DBA uses for all his database management that's written on the Eclipse platform.

I'm all for specific - I use PyCharm every day, which does one thing (Python development) really well. But I think calling out Eclipse like the parent article does is wrong. It too can be a platform for "easily created domain specific experiences"; it's just a different one with a different paradigm.

Re: The future is specific

#44
post #11

Earlier quoted context omitted.

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…

So Light Table is a rapid prototyping tool?

Light Table is a rapid tool prototyping platform :)

Re: The future is specific

#45

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.

In case anyone is wondering:

"Bret Victor - Inventing on Principle" (http://www.youtube.com/watch?v=PUv66718DII)

Re: The future is specific

#46
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

Thank you for taking time to put it on Youtube also! I really liked the website example. Reaching to the right code in the right file gets cumbersome pretty quickly in a project of even medium size!

Re: The future is specific

#47
post #39
post #26

I don't mind if the future is specific. But its really wrong to say IDE's like Eclipse don't do one specific task well. Eclipse really makes Java programming very easy. And I can tell you minus Eclipse programming in Java would be a very frustrating experience, given the verbosity, configuration mess and XML's all over the place. Eclipse these days is advanced enough to really blur the difference between and novice a…

> minus Eclipse programming in Java would be a very frustrating experience I'm not sure about that... Eclipse gets fatter and slower with each release. Of course, I still use it because Google really wants Android developers to do so. In my opinion, the most frustrating thing about using Eclipse for Android work is that it crashes every time I try to export a package, unless I close every open file and restart Eclips…

I face similar issues at work but I don't think Eclipse's issue is Java, else you're saying that anything developed in Java will face a "boated" fate. Eclipse's problem is exactly what Chris mentioned in the article, ok on most things and awesome at none.

Edit: Typos.

Re: The future is specific

#48
post #11
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…

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.

Re: The future is specific

#49
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…

Same. At least you have my upvote, for what it's worth! Light table looks to me (with all the respect due to the work of the authors) like a fad where people get all hyped up about a product. I mean there's nothing revolutionary and while looking at the video I was thinking "boy this is too confusing!". I also believe that when the project is going to have 500+ lines of code per file, the way it's done now, is going…

Watch it again. It's not so much the LOC per file that matters, it's the size of your functions / methods. Notice when light table pulls up the relevant code being used by a call it's method specific and not file specific.

Isn't that the whole point? To me this looks pretty amazing.

Re: The future is specific

#50
It's a pretty impressive demo. It looks like it could be the mother of all scratchpads. It looks like it might have a bit of a scary learning curve though.

I can certainly think of a lot of ideas of what I might try to implement with such an approach. Really any existing code inspection/analysis approach.

I'm thinking some sort of view onto Powershell providers could be interesting.

Maybe exception lookups in the code as your browse through an error log.

Definitely a regex tester utility: does your string match the regex? Do parts of it match part of the regex? What's an example string that would match? Can we display all of this dynamically in real time?

Post reply on HN