ibdknox

We've been thinking about this a lot lately for some of the projects we've been doing for Light Table and we've essentially been doing the same thing as what David's proposing here.

What react ultimately opens up is a way to do immediate mode UI [1] on top of the DOM _efficiently_, which changes things pretty dramatically. It means we can start to treat the browser as just a renderer and get the infectious design decisions of the DOM out of our programs. If nothing else, this gives us freedom, but as david is suggesting, I think this also gives us an opportunity to treat UI much more directly than we currently are. If you want to know what the state of your UI is, you just have to read linearly down through the code that produces your tree. No nest of dependencies, no state hidden in the UI components, you could even get rid of event hierarchies if you wanted.

More important than anything else, this gives us a chance to dramatically simplify our model for UI and magically be even faster than we were before. Sounds like a win to me.

[1]: http://en.wikipedia.org/wiki/Immediate_mode

In practice, unless you're animating at 60fps over hundreds of objects (and who would do that with dom elements?), you shouldn't run into any GC issues. LightTable uses ClojureScript datastructures for pretty much everything and there were only a small handful of cases we had to optimize. Any "normal" application probably won't ever have to.

Clojure doesn't have a real code formatter unfortunately. I posted a slightly better version that preserves formatting if nothing changes and tries to use the clojure pprinter to format as best as it can.

You are quite welcome! And that's what I love to hear - we're pretty excited too :)

actually the tools for doing this in other languages have gotten a lot better than they used to be. Using esprima you can do some pretty neat code rewriting in JavaScript and Python includes ast tools in the standard lib. Plus if more new languages start to include things like gofmt by default then we'll end up with more of this stuff as first class. Either way though, it's nearly always the case that the platform itself has the best tools for doing this, so at the very least if gives you the best possible chance. :)

I think this is one of my favorite features that we've added to Light Table recently and it shows one of the benefits of being connected to a running process of the language you're working with: you can use the tools of that language to write code for you. There's nothing that makes this Clojure specific - you could do these same things in any other language too.

Sure. Where do we derive most of our knowledge as individuals? From anecdotes from others. Is that science? No, not at all, but it's where science often starts. It's a preliminary experiment to at least find out some idea of what may be possible. While not repeated, peer reviewed, or verified in any meaningful way that doesn't make this useless.

The OP walked into a room full of very curious people and called them idiots without any attempt at enlightening them on what statements or assumptions might be wrong. In what way is that helpful? HN is not a peer-reviewed journal, it's a place for discussion and he detracted from that discussion.

Instead, I was hoping he might provide something meaningful that we could consider in trying to process this anecdote.

Instead of a contentless dismissal, can you provide us some information that supports your claim?

> The longer you're fasting, the more cautious you have to be with restarting your diet.

Do you have any experience on what happens if you don't? It certainly makes intuitive sense that you need to ease yourself back into "normalcy", but what are the potential risks that everyone is very explicit about trying to avoid?

CodeMirror is significantly easier to work with than Ace.

Reminds me of the early days of Microsoft FrontPage. Make some hand modifications to the html and accidentally move something.

Then stare in terror as all of your work just disappears.

Given that Simon Peyton Jones is listed as a co-author on several of the papers, I find that a bit too coincidental to be true.

LT has had project-wide and intra-editor search/replace since 0.5

For this specific aspect of the problem, you'll probably find some inspiration in code bubbles, debugger canvas, and Light Table. I implemented a prototype of the former in VS before I left MSFT, it later became the basis for the debugger canvas, and then Light Table happened.

[1]: http://www.andrewbragdon.com/codebubbles_site.asp

[2]: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...

[3]: http://www.chris-granger.com/2012/04/12/light-table---a-new-...

That's correct! We're not just doing window.eval(yourCode)

I actually spoke briefly with Stefan at the very beginning of LT about how Julia could fit really nicely. It's something I'd like to see myself when the plugin stuff is released :)

The project has a different name, but it's not divergent from LT, it's an extension of it. JS, Python, and even Clojure are far from the ideal for what we could be doing if we took the ideas behind LT to a logical extreme. What I showed is a very early example of what that might look like.

My end goal is to "fix" programming, that talk was me explaining that it will take far more than what I originally showed in those first videos of Light Table - we'll have to think about the problem differently. That doesn't detract from the value of LT in any way, and I still believe it's out to fill a very important gap in the programming world. But filling a gap is just the first step, not the end of the line. And since we have the opportunity to push some boundaries and try to find something "better", I fully intend to do so. :)

To be more explicit - LT is our focus and you'll see more and more of the thinking I expressed in my Strange Loop talk start to show in it over time.

Nope. What I presented there is a natural place for LT to end up eventually. :)

We have someone working with us on basic paredit support :) So.. soon!

Can you tell me what you were doing when it silently exited? Can you put up a gist of whatevers in your logs/ dir?

To change the skin/theme you can put the following in your user behaviors:

  :app [(:lt.objs.style/set-skin "light")]
  :editor [(:lt.objs.style/set-theme "codemirror")]

Updated docs are coming soon, just didn't want to hold the release any longer.

In your user behaviors add this: :editor [:lt.plugins.vim/activate-vim]

and then save.

Sorry, we haven't had a chance to update the docs yet - we didn't want to hold the release any longer. It's at the top of my priority list as soon as I get done moving apartments this weekend.

ctlr-o is the equivalent of ctrl-p in sublime or ctrl-t in textmate. It shows you the files available in your workspace. It used to tell you how to add files to your workspace when it was empty but that seems to have gotten nuked. [1] If you go to view->workspace you have a tree you can then fill in with folders and files. Click the folder button and off you go.

I'll add a menu item for opening a folder. [2]

> if the browser tab has focus, cmd-shift-o dialog will not show (as I'm asked to do in the docs)

Unfortunately this depends on whether the site tries to be clever and capture keys, though, there could just be a regular bug here. Will take a look.

> control-tab doesn't switch between tabs

Ah, I used chrome's default ctrl-shift-[ and ctrl-shift-]. Makes sense to add that one too though. [3]

> what is the relationship between this browser window and my js file?

If you press ctrl-enter or ctrl-shift-enter you have now evaled that file into that browser window. Any time you eval again, you'll be injecting code into that frame.

> Sublime may have help somewhere, but since it works just like every other desktop program I've never needed to refer to it.

Can you tell me more about what's missing here? Are there specific menu items, etc? If you tried to use it just like Sublime (as in none of the other fancy stuff), what is harder/more difficult to wrap your head around?

[1]: https://github.com/Kodowa/Light-Table-Playground/issues/695

[2]: https://github.com/Kodowa/Light-Table-Playground/issues/694

[3]: https://github.com/Kodowa/Light-Table-Playground/issues/697

Yeah, gauging your audience is a different aspect of this problem entirely. If Arc's ultimate audience is intended to be HN that's probably not a very good strategy, but if it isn't, then it doesn't really matter. You're always going to piss someone off if you pick something that isn't very obscure (or made up).

Names are hard. :/

Isn't this a problem that the market will correct? If Arc the language has a significant enough following, then "Arc" in common use will refer to the language. I'm not saying people should go around picking names others have used, but it seems a little heavy-handed to assume that because a few thousand people have an attachment to a name it is now off limits for everyone else. Moreover, at what point does it become ok? There's also Ark the YC company: http://ark.com/ is that fine because it uses a k?

Taking a look at it from a different angle, even in the case of the legal framework for names - trademark - having Arc the language and Arc the VM thing would be fine.

The truth is, if you don't want people to collide with your name, picking a 3 letter common word probably isn't the way to do it.

As I recall, Dirpy had hundreds of thousands of users. That's a lot of video transcoding.

Perhaps I should phrase it as "all good names"...

Arc the language hasn't been officially updated in 4 years. All names have been used at some point - it's not realistic to expect them to be truly unique.

From the post:

"Arc is only packaged for OS X right now. It will be packaged and available for Ubuntu and Windows soon."

Before I worked for ReadyForZero and before I started Light Table, I built a whole bunch of "real-time" infrastructure for a little live-blogging as a service company I started called TypeWire. It was miserable, difficult, full of quirks, had very unusual scaling characteristics and just a huge mess. I sincerely wish something like Firebase had existed back then, because it would've completely trivialized what I was trying to do. And that's the way things should be. We shouldn't be constantly rebuilding infrastructure, we should be solving problems - and Firebase is a wonderful way to get you back to solving problems.

I've been good friends with these guys for a while, and I'm impressed with how well they've done, how much people seem to love the service, and just the general quality they instill in what they do. Congratulations guys, it's been awesome watching you get to here.