Light Table reaches 0.1.0(chris-granger.com)
chris-granger.com
Light Table reaches 0.1.0
http://www.chris-granger.com/2012/08/17/light-table-reaches-010/
96 comments
A lot of people are mentioning Python support. I just wanted to put in my vote that Python support will be the thing that gets me to download and try this. It looks awesome but it'll be so much easier for me to relate to if there's a supported language I'm already productive in. I'd like to learn some lisp-likes, but learning a new and innovative IDE at the same time is a bit more to bite off than I have for at one time.
They promised on kickstarter to have Python the 3rd language if they reach the 300K goal. (they reached it).
http://www.kickstarter.com/projects/ibdknox/light-table
http://www.kickstarter.com/projects/ibdknox/light-table
Python is not cool enough for this :) I want Ruby support!!
Python is a great language and anything that Ruby can do Python can do as well.
So does ASM, and VB6. all languages can do the same (mostly, with some effort), the question is the developer, not the language. a good developer with a bad language can do more than a bad developer with a great language.
Sure, but besides some small design and stylistic differences, Python and Ruby are extremely similar, in almost every way.
Except not at all?
Compare each to C, Haskell, Prolog, Lisp. They suddenly appear very similar.
It's awesome how similar some of this looks to Smalltalk IDEs, with some bonus improvements. It's true that it's high time someone picked up the baton on the concepts they pushed, and I'm pumped to see that Light Table is picking up that baton and running with it to present even more interesting possibilities.
I hope you are wrong, because I find Smalltalk IDEs infuriating. Mostly I dislike the fact I have to either make 10 click to reach any code I want to see, or manage a large number of annoying windows to keep track of what I'm working on.
More importantly I think than some of the other responses, as I said, Light Table is “picking up that baton and running with it to present even more interesting possibilities”. Taking strong inspiration from some features in Smalltalk IDEs is different from building a Smalltalk-style IDE for Clojure. I see inspiration here, but not straight copying per se.
I don't know why you're downvoted. I think you're right.
There are lots of windows you have to drag around all the time and click in many places to get to some code.
There are lots of windows you have to drag around all the time and click in many places to get to some code.
Much like when you complain about parenthesis in Lisp, if you complain about windows in Smalltalk (or key combinations on Emacs) you are probably focusing your attention on the wrong thing. Stop fighting the environment. Let it flow around you.
I don't think this type of argument carries much weight. Just because one can get used to something, doesn't really make it a clear choice.
All of these environments are good choices for many reasons. However, they aren't without major flaws.
Smalltalk environments do tend to be a bear when following the code around window after window, emacs keychords are not very human friendly or composable and can give you RSI, and lisp parentheses are mainly for the convenience of the language parser, not for the programmer (contrary to the famous quote).
All of these environments are good choices for many reasons. However, they aren't without major flaws.
Smalltalk environments do tend to be a bear when following the code around window after window, emacs keychords are not very human friendly or composable and can give you RSI, and lisp parentheses are mainly for the convenience of the language parser, not for the programmer (contrary to the famous quote).
While I don't disagree on your other points, lisp's parentheses aren't just for the convenience of the parser, they're also for the convenience of the programmer who uses macros. Homoiconicity is a huge boon there.
Try using another language which allows macros and you'll see what I mean. For example, Haxe allows macros, and while it's syntax for them has recently improved, it still has a ways to go. Here's an example macro which checks if its argument is a constant string, and if it is, reads the file it represents. http://haxe.org/manual/macros/#manipulating-expressions
edit: The equivalent in clojure would be something like
Try using another language which allows macros and you'll see what I mean. For example, Haxe allows macros, and while it's syntax for them has recently improved, it still has a ways to go. Here's an example macro which checks if its argument is a constant string, and if it is, reads the file it represents. http://haxe.org/manual/macros/#manipulating-expressions
edit: The equivalent in clojure would be something like
(defmacro get-file-contents [s]
(if-not (string? s)
(throw (Exception. "Expected string"))
(slurp s)))
The haxe macro reads the file at runtime. Your clojure macro reads the file at compile-time. The proper version would be :
(defmacro get-file-contents [s]
(if-not (string? s)
(throw (Exception. "Expected string"))
`(slurp ~s)))Nope, the Haxe program reads and includes the file at compile time, but only if it's a string literal. If it's an expression that evaluates to a string (which only works if you have static typing, as Haxe does), it reads it at runtime. If its neither it fails.
The convenience for the language parser at least translates into convenience for structured editing in the case of Lisp.
I always miss the convenience of modifying code with Paredit when I'm working in another language.
I always miss the convenience of modifying code with Paredit when I'm working in another language.
Lisp quotes does have plenty of advantages for human reading, though.
Only the parenthesis in Lisp have to be like that to serve a purpose (data is code is AST, homoiconicity, macros, et al). They cannot really be changed much and still have a Lisp proper.
Whereas Smalltalk IDE window handling could be improved tremendously from the mid-90's designs it still carries to this day. Not the reflective/debugging/refactoring capabilities (the good parts). Just the GUI and the handling.
Whereas Smalltalk IDE window handling could be improved tremendously from the mid-90's designs it still carries to this day. Not the reflective/debugging/refactoring capabilities (the good parts). Just the GUI and the handling.
I agree. One of Smalltalk's (the system) greatest assets is that it integrates fantastically with a GUI/mouse input. However, I also find that one of its biggest problems.
I've pretty much stopped using the mouse for input -- due to RSI -- and I don't care much for trackballs etc. I think the next five years might vindicate Smalltalk a bit as I expect touch interfaces to keep rising -- both touch in the sense of touching with your finger(s) as well as proper "pen" input (which is much better for drawing anyway).
However, for typing -- I still prefer vim -- and at least someone is toying with that idea in Pharo:
http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-o...
I've pretty much stopped using the mouse for input -- due to RSI -- and I don't care much for trackballs etc. I think the next five years might vindicate Smalltalk a bit as I expect touch interfaces to keep rising -- both touch in the sense of touching with your finger(s) as well as proper "pen" input (which is much better for drawing anyway).
However, for typing -- I still prefer vim -- and at least someone is toying with that idea in Pharo:
http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-o...
While your drawing comment leads me to suspect you probably already have one, it's worth pointing out that Wacom pen tablets are an excellent alternative to mice, especially for people who have difficulty using the latter (arthritis in my case), and in particular when using "mouse-heavy" IDEs, as they're particularly good for text selection. I haven't personally used a mouse on a regular basis in well over a decade.
More recently, I've also found the combination of large Intuos tablet "stage right" and an Apple Magic Trackpad "stage left" for gestures and other things where precision is unnecessary to be a nice way to spread the load across both hands, though I'm not sure how well it'd work, if at all, under Windows or Linux (natively — it works great with VMware Fusion). And while it'd be a nonstarter for people who do lots of numeric input, I've also found smaller keyboards without numeric keypads can make a significant difference in ergonomics, though this is probably somewhat specific to elbow problems like my own.
More recently, I've also found the combination of large Intuos tablet "stage right" and an Apple Magic Trackpad "stage left" for gestures and other things where precision is unnecessary to be a nice way to spread the load across both hands, though I'm not sure how well it'd work, if at all, under Windows or Linux (natively — it works great with VMware Fusion). And while it'd be a nonstarter for people who do lots of numeric input, I've also found smaller keyboards without numeric keypads can make a significant difference in ergonomics, though this is probably somewhat specific to elbow problems like my own.
Actually no -- I've only recently taken up graphical input (for post-processing/touching up photos) -- and I've yet to invest in any new hardware for that. Your comment on using one for "normal" input is very welcome -- I would've thought they'd be pretty horrible for exactly the things you say they're good at. Moves a wacom tablet higher on my list of hardware to get.
Still, if I can afford it when it gets out, I'm considering getting a modbook:
http://www.modbook.com/modbookpro
I suspect we'll see more hardware along these lines as Microsoft push out w8 and touch input becomes more viable for the mainstream (or perhaps more marketed -- hence increasing the sales/production volume and dropping the price of parts).
Still, if I can afford it when it gets out, I'm considering getting a modbook:
http://www.modbook.com/modbookpro
I suspect we'll see more hardware along these lines as Microsoft push out w8 and touch input becomes more viable for the mainstream (or perhaps more marketed -- hence increasing the sales/production volume and dropping the price of parts).
I felt the exact same way using the Seaside IDE, but I only used it for a day, maybe it just takes some getting used to?
Some comments in this thread are hilarious. Light Table is a modern IDE meant to demonstrate some cool concepts that belong to this time. And people are asking can if they can have vim and emacs bindings.
If all you want is vim or emacs, then use vim or emacs. What is the whole point is asking Light Table to behave like them?
Light Table is supposed to bring in new ways of developing software. Dragging ancient usability concepts just because a few can't work with anything else isn't how you build a new product.
If all you want is vim or emacs, then use vim or emacs. What is the whole point is asking Light Table to behave like them?
Light Table is supposed to bring in new ways of developing software. Dragging ancient usability concepts just because a few can't work with anything else isn't how you build a new product.
Here is something else that belongs to "this time": the mouse and keyboard.
I do hope there will be some time in the future when we never have to type or reach for a mouse because our brains are the only I/O device. But until that time comes, we have essentially the same input mechanisms that we had when Vi and Emacs were invented.
In some ways, your point is a valid one; there are many, many features of these old programs that the Light Table developers should spend zero time re-implementing. However, editor bindings are a special case.
No matter how fancy the code editing interface is, in the end you still have to type out some code at some point. When the fingers hit the keyboard, many professional programmers have preferred and habitual ways of entering and editing text. In 10 years I might be using a text editor with flying swirling animations and cool animations that "zoom in" on an identifier into its definition, and so forth, but I won't be using it if it doesn't have Ctrl+c and Ctrl+v. Vim and Emacs keybindings are just second nature to many of the core audience for Light Table; it makes sense that those shortcuts are requested.
For further evidence that key-bindings and editing modes are acknowledged as universally useful things, regardless of origin, try typing Ctrl+E or Ctrl+A in any OS X text field. You'll jump to the end of beginning of the line, respectively. These are two of the many Emacs keybindings that are supported out of the box on every text control in OS X.
Now, to the last part of your point. I agree that these kinds of things shouldn't be the focus when developing a new product. When you're still just trying out ideas, you really don't have the time to implement every little feature request. However, when the thing you're developing is a developer tool, I think it behooves you to design and implement a rich plugin system as one of your first tasks. If your program and programmers have the Lisp nature, you almost do this without a second thought. But the payoff is big. If you can implement most of the program using its own plugin system, you're forced to design highly orthogonal primitives that play well together from the start. The end result is or should be that there's nothing a plugin author can't do that the original developers can do.
So if it were me writing this thing, I'd make sure to release a plugin system pretty early and tell everyone who wants to add Emacs, Vim, and Minesweeper to go nuts :)
I do hope there will be some time in the future when we never have to type or reach for a mouse because our brains are the only I/O device. But until that time comes, we have essentially the same input mechanisms that we had when Vi and Emacs were invented.
In some ways, your point is a valid one; there are many, many features of these old programs that the Light Table developers should spend zero time re-implementing. However, editor bindings are a special case.
No matter how fancy the code editing interface is, in the end you still have to type out some code at some point. When the fingers hit the keyboard, many professional programmers have preferred and habitual ways of entering and editing text. In 10 years I might be using a text editor with flying swirling animations and cool animations that "zoom in" on an identifier into its definition, and so forth, but I won't be using it if it doesn't have Ctrl+c and Ctrl+v. Vim and Emacs keybindings are just second nature to many of the core audience for Light Table; it makes sense that those shortcuts are requested.
For further evidence that key-bindings and editing modes are acknowledged as universally useful things, regardless of origin, try typing Ctrl+E or Ctrl+A in any OS X text field. You'll jump to the end of beginning of the line, respectively. These are two of the many Emacs keybindings that are supported out of the box on every text control in OS X.
Now, to the last part of your point. I agree that these kinds of things shouldn't be the focus when developing a new product. When you're still just trying out ideas, you really don't have the time to implement every little feature request. However, when the thing you're developing is a developer tool, I think it behooves you to design and implement a rich plugin system as one of your first tasks. If your program and programmers have the Lisp nature, you almost do this without a second thought. But the payoff is big. If you can implement most of the program using its own plugin system, you're forced to design highly orthogonal primitives that play well together from the start. The end result is or should be that there's nothing a plugin author can't do that the original developers can do.
So if it were me writing this thing, I'd make sure to release a plugin system pretty early and tell everyone who wants to add Emacs, Vim, and Minesweeper to go nuts :)
> but I won't be using it if it doesn't have Ctrl+c and Ctrl+v
I would use an editor which makes copy&pasting a thing of the past very happily.
In my experience copy&pasting is a big part of the problem. Some people use it to think less about the given structure and duplicate code, others use it to re-arrange code. Both are tasks which an editor like light table might handle better.
I would use an editor which makes copy&pasting a thing of the past very happily.
In my experience copy&pasting is a big part of the problem. Some people use it to think less about the given structure and duplicate code, others use it to re-arrange code. Both are tasks which an editor like light table might handle better.
I don't understand how something like copying and pasting could be obviated from a text editor. There are a million reasons you might need this functionality, and they don't all have to deal with poorly structured code.
>But until that time comes, we have essentially the same input mechanisms that we had when Vi and Emacs were invented.
Actually the mouse was not a big deal at all when Emacs and Vi were invented -- virtually not existent at the kind of machines vi and emacs were developed, and it was not taken into account at all.
Actually the mouse was not a big deal at all when Emacs and Vi were invented -- virtually not existent at the kind of machines vi and emacs were developed, and it was not taken into account at all.
You would feel differently if you were an avid vim/emacs user. There's no reason you can't combine the interactivity of Light Table with the key bindings from other text editors. The combination may prove more powerful, at least for those with the muscle memory for it.
The reason we want bindings similar to certain popular editors is because we have years of mechanical memory invested in them and for us it means better mechanical speed of interaction with the interface.
Keyboard bindings and general IDE approach are orthogonal concepts. There is no reason you can't have modern innovative IDE with familiar keyboard bindings.
Keyboard bindings and general IDE approach are orthogonal concepts. There is no reason you can't have modern innovative IDE with familiar keyboard bindings.
Well, Light Table supports both vim and emacs bindings anyway.
Some system of shortcuts for doing everything with the keyboard would be nice though. Every time I move my hand to the mouse I'm losing time. I don't mind learning a new map, as long as it's as efficient as emacs.
Constructive criticism: pretend that someone hasn't head of Light Table before. Have a one-sentence description near the top that links to a longer description. (Clicking on "Light Table Playground" takes me a something that includes the features you are working on for Light Box.)
done. Thanks for the suggestion!
(Side note, the real thing is called "Light Table" too, no light boxes here :)
(Side note, the real thing is called "Light Table" too, no light boxes here :)
The live evaluation is nice, but seems a little limited. If I have:
I greatly prefer the idea of showing the value propagation explicitly as you click on things. For example, using lines and arrows to show that this came from there and that came from here.
(defn my-add [a b]
(+ a b))
(my-add 3 45)
(my-add 1 2)
I greatly prefer the idea of showing the value propagation explicitly as you click on things. For example, using lines and arrows to show that this came from there and that came from here.
In this case I suspect it's dealing with compiler optimizations. The first one is being optimized out since it produces no side effects and the return isn't used anywhere. How to work around this I have no idea.
I'm not sure if this is what you want, but you can turn live evaluation off with Ctrl/Cmd-l and then evaluate the individual line you are interested in with Shift-Enter.
This may sound completely insane or stupid to people who don't configure their tools much or are avid followers of the project - but is it possible to expose the preview functionality so that it can be used with other editors (e.g. vim)?
The ideas are interesting but swapping out my entire existing setup for them is not terribly appealing, even with some key-scheme... since I am not using notepad, there is a lot more which goes into my editing environment than the keys. And I am skeptical that anybody is going to do significantly better on text editing.
The ideas are interesting but swapping out my entire existing setup for them is not terribly appealing, even with some key-scheme... since I am not using notepad, there is a lot more which goes into my editing environment than the keys. And I am skeptical that anybody is going to do significantly better on text editing.
I'm not sure if Chris or any of you guys have seen this video but it is exactly what Light Table is about to become (perhaps more) and that makes me very excited.
http://vimeo.com/36579366
http://vimeo.com/36579366
Chris started work on Light Table _because_ of that video. So be excited :)
Here's the blog post where Chris first talked about Light Table (before it was called Light Table) http://www.chris-granger.com/2012/02/26/connecting-to-your-c...
Oh my. After re-reading that blog post I remember seeing it on HN before. My apologies.
I was at this conference (CUSEC 2012[1]), and he (Bret) gave a truly awesome lecture.
Also it was my first conference ever, so it's even better.
[1] Canadian University Software Engineering Conference, in Montreal.
Also it was my first conference ever, so it's even better.
[1] Canadian University Software Engineering Conference, in Montreal.
I managed to make it to CUSEC 2011 but not 2012. Looks like I missed some really great presentations. It's unfortunate when this conference is in another province.
[deleted]
I don't have a github account, but since I noticed the creator reads the comments here I'll report some quick bugs I found:
1. Closing parentheses do not work in table mode, the key combination for ")" on my Swedish keyboard produces a "(" instead. (this has already been reported on github)
2. When I was asked to type in "(+ 4 5)" in the scratch during the tutorial, pressing the spacebar without any modifier keys did not register as a keypress. I had to press shift+spacebar to separate the numbers and complete the task.
3. The window displaying all shortcuts (accessed from the bottom right corner) cannot be closed. I had to restart Light Table for it to disappear so that I could continue coding.
1. Closing parentheses do not work in table mode, the key combination for ")" on my Swedish keyboard produces a "(" instead. (this has already been reported on github)
2. When I was asked to type in "(+ 4 5)" in the scratch during the tutorial, pressing the spacebar without any modifier keys did not register as a keypress. I had to press shift+spacebar to separate the numbers and complete the task.
3. The window displaying all shortcuts (accessed from the bottom right corner) cannot be closed. I had to restart Light Table for it to disappear so that I could continue coding.
1. yeah, I didn't think about international keyboards. I'll have to come up with something there.
2. just pushed a fix for that
3. Click anywhere outside the box and it'll close. I'll make that more explicit :)
2. just pushed a fix for that
3. Click anywhere outside the box and it'll close. I'll make that more explicit :)
Yeah, I realized I had probably missed something when it came to closing the window. Strange how I never managed to click outside the box, considering how much else I tried (pressing esc, clicking inside the box, opening the menu, etc.) :)
But I forgot to say how much I love the editor already. Can't wait for the final version!
But I forgot to say how much I love the editor already. Can't wait for the final version!
Chris, if you're around, you mentioned that you're now building Light Table in Light Table. Does this include the front end Clojurescript? Because I would love to move my Clojure / Clojurescript project over to LT if that's possible.
It does indeed, but we punted on including CLJS in this release because we didn't have enough time to test it. It should make it into the next release though :)
Very cool. I look forward to it. I'm just poking around this release now, and it's great to see the vision you had in the original video coming together. Not to rush you or anything, but I was wondering how the plugin API was coming along. Is that something that we'll get to play with anytime soon, or will that be something that comes with the final release next year?
Isn't it going to be open sourced at some point? Why not just let people get at your dev branches or at least provide builds for them
Also, keep up the awesome work!
Also, keep up the awesome work!
Even if OSS isn't an option, I think it would be a nice idea for Light Table to provide low level API/Interface so that eco system grow like emacs/vim/eclipse.
Perhaps Chris has already considered this idea.
Yep, that should all be happening. Scroll to the FAQ section of the kickstarter - http://www.kickstarter.com/projects/ibdknox/light-table - it will be OSS and will also have an API for developing plugins with Javascript. He's already shown a cool benchmarking mode in one of the videos.
Chris: I know you're a vim guy, so I know you'll be doing vim bindings eventually. I also know that vim emulation modes are always incomplete. I'd like to offer my services as a vim-mode tester. I vow to provide extremely robust feedback. I'm willing to offer this service for free, so that I can ensure Light Table's vim subset is a superset of my brain's vim subset ;-)
From the original kickstarter[1] app:
What about key bindings?
I'm a VIM guy myself, but since we'll be using the awesome CodeMirror[2] editor, this is something that is easily adapted. If you're looking for a way to contribute, help improve CodeMirror and its emacs/vim plugins!
I haven't actually played around with the current release to see if it's been integrated yet, but it's almost certainly part of the plan.
[1] http://www.kickstarter.com/projects/306316578/light-table
[2] http://codemirror.net/
What about key bindings?
I'm a VIM guy myself, but since we'll be using the awesome CodeMirror[2] editor, this is something that is easily adapted. If you're looking for a way to contribute, help improve CodeMirror and its emacs/vim plugins!
I haven't actually played around with the current release to see if it's been integrated yet, but it's almost certainly part of the plan.
[1] http://www.kickstarter.com/projects/306316578/light-table
[2] http://codemirror.net/
If you view-source on this release you can see a vim.js file is included with vim bindings. I was able to activate them by setting a breakpoint in chrome on line 2098 of codemirror.js and typing this in the console:
CodeMirror.defaults["keyMap"]="vim"
CodeMirror's vim support is fairly limited though. Here's the list, in comments at the top of the code here: http://codemirror.net/keymap/vim.js
Also, "Because CodeMirror's internal API is quite different from Vim, they are only a loose approximation of actual vim bindings" http://codemirror.net/demo/vim.html
Also, "Because CodeMirror's internal API is quite different from Vim, they are only a loose approximation of actual vim bindings" http://codemirror.net/demo/vim.html
Maybe so, but then again - "contribute for free, after we raised a whole lot of money and funding for our work"...
The concept of light table is very different than vim. Besides I believe chris is aiming his IDE for clojure users which in case it makes more sense for him to target it to emacs users.
Besides vim is all about modes, and memorizing commands.
That is exactly what light table is opposite off. Modes and Commands in vim is 'ancientness' when it comes to usability design.
But if you are still interested may be you should build a feature comparison matrix and track it.
Besides vim is all about modes, and memorizing commands.
That is exactly what light table is opposite off. Modes and Commands in vim is 'ancientness' when it comes to usability design.
But if you are still interested may be you should build a feature comparison matrix and track it.
Modes and commands in vim are well designed and useable for an expert, which is the entire point.
I wish to note that what can be better than one brain's subset: the union of two brain subsets! Hint Hint.
If you're on Mountain Lion, Gatekeeper won't open the launcher, complaining it isn't signed.
The best way around this without touching your security settings is to right-click the launcher and selecting "Open".
The best way around this without touching your security settings is to right-click the launcher and selecting "Open".
I love this. Chris Granger is officially one of my heroes.
One quick suggestion: on the first time start up of the app, it goes through a brief explanation of the various parts. It might seem obvious to most, but I think it would make it a little nicer if the dialog that says "The instarepl is an area where you can write code..." had an arrow shape, or an arrow in the box pointing toward the repl.
Same for the dialog talking about the output area.
It's not so much that it's confusing, it's just an unfamiliar interface, and an arrow would be reassuring that what I thought was the repl was really indeed the repl.
One quick suggestion: on the first time start up of the app, it goes through a brief explanation of the various parts. It might seem obvious to most, but I think it would make it a little nicer if the dialog that says "The instarepl is an area where you can write code..." had an arrow shape, or an arrow in the box pointing toward the repl.
Same for the dialog talking about the output area.
It's not so much that it's confusing, it's just an unfamiliar interface, and an arrow would be reassuring that what I thought was the repl was really indeed the repl.
I'm really impressed with how this is coming along. The UI has a great feel to it. Playing with LT Playground makes me want to go back and give Clojure another shot. Very cool!
When are you guys planning to add python support? BTW, will it be python 3 or 2?
Looks cool! When I first saw it I thought you where this guy:
Bret Victor - Inventing on Principle
http://vimeo.com/36579366
Planing to support Octave/Matlab at some point?
Planing to support Octave/Matlab at some point?
It's simply great. Any estimates when will the Python module come out?
Shame on you, you made start playing and even liking Lisp instead of working. These were the best sources for me by the way if anyone is interested: http://tryclj.com/ http://www.4clojure.com/ (both are interactive, more coding, less reading)
I'm wondering how difficult it would be to support Scheme. After seeing http://www.wescheme.org/about/ I'm guessing solutions to most of the hard parts are already out there?
Any plans for emacs keybindings?
I'm pretty sure it has been mentioned before that yes, you'll be able to use emacs keybindings. The editing surface is based on CodeMirror http://codemirror.net/, which is very customizable.
The problem right now is that the editor runs in a browser and so the shortcuts for emacs conflict.
Why the fuck should a text editor be running in a browser?
Why the fuck should a text editor be running in a browser?
It's using webkit as a rendering engine - while it's in beta, that means a browser (although on mac it runs standalone). I'm pretty sure they've mentioned that Windows & Linux will be a standalone app before the final release.
What languages are supported right now? I keep forgetting and all the images are showing clojure.
Anyone know if there's any plans for haskell?
http://khamphukhoa.com.vn/
I tried loading my clojure project (https://github.com/dmix/documeds) but I'm only getting a "Connecting" loading screen for 30min.
the reason it fails is because it's looking for an artifact that doesn't exist:
Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
1) org.clojure.contrib:prxml:jar:1.3.0-alpha4
Try downloading the file manually from the project website.It takes a VERY long time to load.
Impressive project and it certainly gives a good reason to learn Clojure in the future. :)
Tried current version and it seemed interesting, even while I'm still quite of a beginner with code.
Tried current version and it seemed interesting, even while I'm still quite of a beginner with code.
Maybe add '(YC S12)' in the title? I know you were working on this before YC, but these are the kinds of things I like to see get supported.
Enjoyed playing with light table. Ruby is still my favorite language, but clojure seems to be where all the innovation is at these days.
So how would I use light table in building a django app? I'm trying to envision some real world use cases for myself.
Anyone using this for "real world" development? How does this compare with something you were previously using?
I love this thing, ever since you've announced it. Just wondering if it would eventually support Common Lisp?
I hope it allows for a "light" theme as well. Not all coding is done on dark backgrounds
Looks beautiful on a Retina screen.
What is the color scheme you're using, by the way?
What is the color scheme you're using, by the way?
Looks remarkable! Can't wait to try it.
Go Chris and Rob!
I have created a Propster fan tip jar for Light Table. When it collects at least $5, Chris will be contact and will get the money.