The future is specific • Hacker News Board

Re: The future is specific

#111

Post by vinodkd » Wed, May 23, 2012, 1:37 AM UTC

radicalbyte wrote: post #93

skrebbel wrote: post #89

A 'macro system for tools'. Isn't this what the academic bozos call Language Workbenches? Extensible tool-building platforms for DSLs are hardly anything new. Reading things like this, i sometimes worry that the HN-circling web crowd is reinventing things that others invented just a few years ago. Like some sort of collective not-invented-here syndrome. E.g. Check out MetaEdit+ - their website isn't Silicon Valley Se…

> Reading things like this, i sometimes worry that > the HN-circling web crowd is reinventing things > that others invented just a few years ago. The difference in this case is that the HN web crowd are targeting their fellow programmers, and not the "Enterprise" crowd. I've been following the DSL tooling scene, and it's horrible. Think closed source, expensive and targeted at the Enterprise (or specific engineering…

> The community is full of MDA (model-driven-architecture) types: too often is the focus on increasing complexity (for ego boosting / job security) instead of simplicity and accessibility. > .. instead of locking it up for fun and "profit".

still, if you ignore the MDA and executable uml silliness, there's quite a few ideas that can be picked from that closed space, imo.

Re: The future is specific

#112

Post by Jach » Wed, May 23, 2012, 1:50 AM UTC

heretohelp wrote: post #101

ibdknox wrote: post #66

Earlier quoted context omitted.

It will probably be under the GPL just like Emacs, so I'm not sure I understand the concern?

I'm fine with profit-seeking, but GNU projects like Emacs tend to be too fundamental to allow a proprietary solution to predominate. (Cf. gcc) I'm fine paying for servers, for contractors, services, random productivity-ware like Pivotal Tracker etc. but I'm never going to be okay with subjecting my development environment, something I've honed for years and years, to fee extraction or proprietary control by a commerc…

He doesn't have to cater to you or me and I think it would be a mistake to do so. Visual Studio is very popular... When Light Table comes out, at the end of the day I'll still be using vim and I suspect most emacs users will still be using emacs. We're not the target audience. I disagree that Light Table needs to be anything like emacs to dominate, it can even have a proprietary license, it can skip over us just as Eclipse, VS, et al. have done. That's fine. I'd rather that be the case and see a pretty end-product that serves its original goals well (and I may even try it for fun if it's free) than having a half-baked "vim-mode" stuck on at the end just to try and attract me.

Re: The future is specific

#113

Post by Arelius » Wed, May 23, 2012, 2:10 AM UTC

Jach wrote: post #112

heretohelp wrote: post #101

Earlier quoted context omitted.

I'm fine with profit-seeking, but GNU projects like Emacs tend to be too fundamental to allow a proprietary solution to predominate. (Cf. gcc) I'm fine paying for servers, for contractors, services, random productivity-ware like Pivotal Tracker etc. but I'm never going to be okay with subjecting my development environment, something I've honed for years and years, to fee extraction or proprietary control by a commerc…

He doesn't have to cater to you or me and I think it would be a mistake to do so. Visual Studio is very popular... When Light Table comes out, at the end of the day I'll still be using vim and I suspect most emacs users will still be using emacs. We're not the target audience. I disagree that Light Table needs to be anything like emacs to dominate, it can even have a proprietary license, it can skip over us just as E…

Visual Studio is a unique case in that it had the giant of Microsoft and their windows platform behind it, and IIRC, at the time no opensource free alternatives. I'm not sure in a modern world, Light Table advantages would afford it the same spread.

Re: The future is specific

#114

Post by Arelius » Wed, May 23, 2012, 2:12 AM UTC

zcam wrote: post #103

Arelius wrote: post #98

Earlier quoted context omitted.

The advantage of LightTable's approach is that using HTML, is a simple, trivially extensible and powerful way to provide advanced UI widgeting, something modern emacs supports very poorly. Mostly due to working in a terminal if needed, but I think it holds it back a bit. The closest thing we have in emacs is pixmap support, which is poor, and painful to use! Though, is LightTable the best/easiest way to get that? I d…

> Though, is LightTable the best/easiest way to get that? I don't know, it may be easier to render emacs buffers into a webkit view, it may also not be. That is what I meant with "connect to browser instances" (swank-js already allows that, among others). Basically when you need more advanced rendering, or browser environment when it is your target (browser based games and whatnot), this could be good enough and you…

Sure, it could be good enough, but the ecosystem has not been building up around that. Perhaps it's the seperate languages used, or the clunkiness of having to use another browser and all the setup just to render a simple graph. But I personally have not found an extension that takes advantage of that.

Re: The future is specific

#115

Post by neutronicus » Wed, May 23, 2012, 3:35 AM UTC

zcam wrote: post #94

Arelius wrote: post #53

Earlier quoted context omitted.

What I worry about Light Table is what it won't be from Emacs. At the end of the day, Emacs is still a text editor, and still edits files. This means that I really can use it for anything, doesn't matter if I have a mode for it, or an embedded compiler/REPL. It still just works, and we can't forget this if we want a modern Emacs. Emacs was born in a world of textfiles, Light Table shows us a post-textfile world, but…

Also emacs provides an extensive platform with tons of modes to support pretty much anything you can throw at it, works in a terminal if needed, has an abstraction over files (buffers), debuggers, easy modes for vi/cua users, can connect to browser instance if needed and tons more. Building a lighttable mode or even several small modes (libraries vs framework) for emacs would make more sense. It is going to require a…

It's the versatility of emacs that keeps me coming back. I need to use R for this project? Python? C? Well, at least I can use it through the comforting interface of emacs.

Re: The future is specific

#116

Post by twelvechairs » Wed, May 23, 2012, 3:56 AM UTC

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-concept discussion is that I'd really like to see more programs which try to be applicable to a broad variety of non-coding domains, which actually occupy the majority of the work that people do on computers (working with images, working with spreadsheets, working with documents and pages, working with 3d spaces, animation, realtime information, etc.), allowing the easy creation of 'domain specific experiences' in these, which is generally impossible or very difficult in most of todays pre-compiled software for these tasks.

[I hope that all makes sense to someone :) Would also appreciate any discussion as something along these lines is a side-project of mine atm]

Re: The future is specific

#117

Post by Rayne » Wed, May 23, 2012, 5:44 AM UTC

Arelius wrote: post #100

phyzome wrote: post #86

Earlier quoted context omitted.

Clojurescript, actually -- a Clojure dialect that compiles to JS. Well, Clojure too, on the server side of things.

Are we really gonna need the JVM running the backend for this? That seems so unnecessary.

I'm pretty sure the core of it is to be written in Clojure, so yes, you'll need the JVM running. It is necessary if it is to be written in a JVM language. Eclipse and a number of other IDEs also require a JVM to be running.

Re: The future is specific

#118

Post by Rayne » Wed, May 23, 2012, 5:49 AM UTC

Arelius wrote: post #48

ibdknox wrote: 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…

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

#119

Post by Rayne » Wed, May 23, 2012, 5:52 AM UTC

victork2 wrote: post #24

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…

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…

The one thing that stands out is the "there's nothing revolutionary" comment. Have you watched the videos this guy puts out? If there is something like this already around, please link me to it so I can use it!

Re: The future is specific

#120

Post by prospero » Wed, May 23, 2012, 6:20 AM UTC

its_so_on wrote: post #83

prospero wrote: post #75

Earlier quoted context omitted.

All of your examples are gestalts . They're not single seamless abstractions, they're patchworks that are more than the sum of their parts. That's precisely what is being proposed here: a platform for creating a development environment that is more than the sum of its parts. Something that gives you composable pieces that can be fit together into something that maps directly onto your problem space. Is this really so…

Well, I looked at the "gestalt" Wikipedia article. As near as I can make out, you're saying that Google in fact highly tailors its search-for-geneticists, which has nothing to do with its search-for-bakers: it seems like a single whole, but isn't. But that patently isn't so. Patently, every niche runs off the same algorithms. Equally, bankers' circle of friends use the same facebook that teenagers' circle of friends…

Let's talk about Google, then. In addition to having special ways of displaying results for different types of searches (local, geo, weather, shopping, etc.), there are also a lot of different heuristics underlying the search results. It's not just PageRank-and-done, it's many different approaches trying to maintain a uniform level of quality across a variety of niches.

I'll repeat that again: it's not the approach that's homogeneous, it's the quality.

You can see this with Apple, too. Their devices aren't limited to some set number of use-cases, it provides an API and ecosystem for creating new, domain-specific applications. You mention Objective-C in your response, which is kind of missing the point; we're talking about domain-specific applications, not domain-specific languages. LightTable will presumably be very consistent and general at the API level, and uses Clojure, which is a general-purpose language as well.

As for Amazon, their offerings span the entire spectrum from general to domain-specific. You can get an empty VM, but you can also get something like Elastic MapReduce. Amazon will happily develop domain-specific products on top of their platform as long as there's a large enough market.

Finally, look at Rails, which is a framework specifically for creating web apps. It doesn't help me write a new NoSQL server, it doesn't help me write a new AAA video game, it seems to be doing okay all the same. It's used because it's a really effective lever in certain, specific cases. If we can have a development environment which is a similarly large lever across a wide range of cases, how could that ever be a bad thing?