puppysoli.blogg.se - Lighttable github

#Lighttable github manual
#Lighttable github code

And so we have to live with those limitations (which exist in even fantastic languages like Clojure). By virtue of the way we program now, really important notions like “flow” are lost and hidden under layers upon layers of indirection.

#Lighttable github code

It turns out that the way we organize code files ends up being very important, and there’s no way to glean a lot of the information that is stored in that organization purely through code walking.

For example, showing functions individually actually introduces another level of cognitive load through the loss of locality. They seem to reach beyond making a kick-ass modern editor and ask for a more fundamental change, as Chris Granger hinted shortly after Atom’s announcement:įrom the outset, our goal has been to make programming better, and I’ve honestly come to the conclusion that LT on its own can’t do that. The last three, and especially the last two, are more timeless goals than the rest.

Abstract above the files and folders paradigm of code organization and navigation.

Interpret our code as we type it, showing results locally to reduce cycles.

Allow free-form presentation of more than code: text markup, hints, refactorings, function flows, live previews, etc.

Integrate with modern app dev environments, browsers, source control, cloud and mobile deployment, etc.

Allow a network of collaboration to easily build and maintain language and platform support within the editor.

Integrate with compilers, interpreters, REPLs, CI.

Let us navigate projects and edit source code.

What are we looking for?Ĭonsidering a larger list of modern programming environments (at the end of this post) we get an expansive view of the landscape of features we’d like to see our editors include. It sounds like Atom is trying to hone what TextMate and Sublime Text had both started to deliver, though we can likely guess that that’s just the starting point. We can’t wait to see what you build with it. Atom is modern, approachable, and hackable to the core. A tool you can customize to do anything, but also use productively on the first day without ever touching a config file. building the text editor we’ve always wanted. Light Table is based on exploring a future of building software.Ītom has some lofty goals too. He was inspired by Bret Victor’s talk Inventing on Principle, and cites some big historic landmarks on this path as the spark for Light Table: Smalltalk, Symbolics Genera, Logo, and HyperCard. What makes someone say, “Let’s just start from scratch”?įor Chris Granger, it was aspirations to change the way programming happens. What really interests me about new editors are the forces that bring these new projects to the surface. There’s no shortage of editors or opinions on them.

So if these two recent programming environment projects are points on a line, where does that line point? But I’m so comfy using ! Both envision open-source communities of 3rd party plugins ( Atom, Light Table).Both leverage modern languages to implement the editor itself ( Atom, LightTable).Both offer a web-based programming platform targeting customizability ( Atom, LightTable).Here’s some of what Light Table shares with Github’s Atom: In 2012, Chris Granger announced a project called Light Table, which I think was a recent mile marker on the same road as Atom. (Nice logo! *wink*) If you haven’t seen it, here’s a great hands-on post showing off its features. However, I ran into issues with Apollo not exposing sufficient information to build these policies.Github recently announced their project to create their own programming editor called Atom. Given this, I set about writing code to inspect our schema and generate type policies. To me, this sounds like an unacceptable combination.

#Lighttable github manual

Thanks for developing it! :) Now that Apollo 3 is out, we tried to upgrade and ran into some issues with caching.Īpollo 3 seems to believe that it is practical to manually specify merge strategies for every type and/or field (hundreds or thousands of lines of configuration) and also that this manual configuration cannot be checked at build time or start time, but instead fail eventually at runtime. We are using Apollo 2 in production and are very happy with it. Synthetic IDs and cache normalization in Apollo 3