Light Table reaches 0.1.0
chris-granger.com
chris-granger.com
Anyone know if there's any plans for haskell?
There are lots of windows you have to drag around all the time and click in many places to get to some code.
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).
I always miss the convenience of modifying code with Paredit when I'm working in another language.
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)))
(defmacro get-file-contents [s]
(if-not (string? s)
(throw (Exception. "Expected string"))
`(slurp ~s)))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'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...
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.
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).
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.
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 :)
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.
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.
Keyboard bindings and general IDE approach are orthogonal concepts. There is no reason you can't have modern innovative IDE with familiar keyboard bindings.
(Side note, the real thing is called "Light Table" too, no light boxes 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.
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.
Also it was my first conference ever, so it's even better.
[1] Canadian University Software Engineering Conference, in Montreal.
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.
2. just pushed a fix for that
3. Click anywhere outside the box and it'll close. I'll make that more explicit :)
But I forgot to say how much I love the editor already. Can't wait for the final version!
Also, keep up the awesome work!
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.
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
CodeMirror.defaults["keyMap"]="vim"
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
The best way around this without touching your security settings is to right-click the launcher and selecting "Open".
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.
Planing to support Octave/Matlab at some point?
Why the fuck should a text editor be running in a browser?
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.Tried current version and it seemed interesting, even while I'm still quite of a beginner with code.
Bret Victor's talk was truly inspiring, and I'd wish he'd release his tool too for comparison.
What is the color scheme you're using, by the way?