Please please please support Java in all of its glory and let me get rid of Eclipse!!!!!!
Light Table 0.4 released
161–170 of 193 posts
Re: Light Table 0.4 released
#162Re: Light Table 0.4 released
#163Earlier quoted context omitted.
You're dangerously close to trolling, but I'll comment anyway. > a "I hate parens" Lisp-1 Clojure's minimal syntax is, in my opinion, a gigantic improvement over Common Lisp. And I say this as a person who quite likes parens. I feel similarly about Lisp-1s, but that is well trotted territory: Lisp-1s have won. Parens are overloaded in traditional Lisps for both invocation and grouping. The introduction of vectors wit…
"Parens are overloaded in traditional Lisps for both invocation and grouping." And boy do I wish they were overloaded the same way in Clojure. I hate the fact that I have to say (cond (some-long-predicate involving multipler-parameters) (what-to-do has to go-on-the-next-line because-of wrapping) (here-is-the-next predicate) [(func1 arg1) ...]) It's very easy to end up in this situation (and it's not always just a sig…
I'm not sure how your cond example is related to vector syntax. The decision to use (partition 2 ...) style pairs, rather than extra brackets is orthogonal.
The more important point of literal syntax for composites other than lists is the fact that they are resolved at read time. This means you don't need a macro to have grouping. With (some-macro ((f x) (g y))), you need to force expansion inside the parens. Quoting (some-function '((f x) (g x))) requires forcing evaluation in your function. You could use (vector (f x) (g x)), but now that means some-function gets a vector argument and some-macro would get a list argument with first element 'vector. In Clojure, (some-function-or-macro [(f x) (g y)]) both have a vector as an argument because of the read-time behavior of data structure literals. Huge win in my book.
Re: Light Table 0.4 released
#164Python support! Thank you Chris. Will certainly give it a shot.
Re: Light Table 0.4 released
#165Earlier quoted context omitted.
You're dangerously close to trolling, but I'll comment anyway. > a "I hate parens" Lisp-1 Clojure's minimal syntax is, in my opinion, a gigantic improvement over Common Lisp. And I say this as a person who quite likes parens. I feel similarly about Lisp-1s, but that is well trotted territory: Lisp-1s have won. Parens are overloaded in traditional Lisps for both invocation and grouping. The introduction of vectors wit…
Actually, I'd appreciate expansion on the respect in which Clojure is designed for interop with an arbitrary host. One (relatively uninteresting) respect in which that might be the case is that Clojure-the-language might not say anything about, say, what numeric types there are. Actually it does, though: Clojure supports ... all Java numeric types. And then there are two more Clojure-specific types. Or perhaps that i…
I disagree that Numbers are relatively uninteresting. In fact, I think any language designer would tell you that numerics are one of the hardest areas to get right. It's also the area where Clojure is weakest in terms of interop, I'd say. ClojureScript, for example, only has host Numbers (ie double-precision floating-point)
The main thing that Clojure does in terms of being designed for interop is to require the use of host values/objects. There are no wrapper/proxy/delegate/whatever objects. This has big implications. It (unfortunately) means that there is behavior you simply can't have in core, such as reflection or continuations. That's a big part of being interop friendly: Intentionally specifying fewer things. If you have very strict rules for how something like strings behave, then you might wind up in a situation where you need to create a ClojureString class or something like that.
Additionally, the '. (dot) special form is like a giant "INTEROP HERE" sign, which is extremely useful when porting code from CLJ to CLJS. You can literally grep your source for /\./ and find platform specific code.
Re: Light Table 0.4 released
#166I keep getting - Failed to load resource: .lighttable/img/connectingloader.gif when I try to evaluate Python code. :(
Re: Light Table 0.4 released
#167This is awesome! I haven't used an IDE for a long time now but LT has shown enough to convince me to use one.
Re: Light Table 0.4 released
#168It would be great to get a common lisp supported in Light Table...
People still use common lisp? ducks In all seriousness, the plugin architecture will certainly allow for exactly that to happen. If you're interested in trying your hand at adding CL, I know a guy who could probably sneak you into the beta when it turns private ;)
I can't wait for that to happen, I learned Emacs for the sake of CL development... I was actually thinking of learning Clojure just to check out LT.
Re: Light Table 0.4 released
#169Maybe I'm doing things wrong and I haven't seen anybody mention this, but ... ... all of my code is on remote machines. Either in a VM or on a server, far, far away. Is there a way to use SFTP to open files for editing?
It's easily done in Linux and UNIX via sshfs (it's what I use in the same situation as yourself): http://en.wikipedia.org/wiki/SSHFS
Re: Light Table 0.4 released
#170Earlier quoted context omitted.
Actually we haven't implemented replace yet. There's a few things like that that will either end up in 0.4.* releases or 0.5 at the latest.
Also, multi-line selection, please? =) That's probably the main thing that's keeping me in ST2 right now...
Yeah, multi selection has pretty much replaced my use cases for find/replace. And I work faster that way too.