101–110 of 193 posts
When trying to download using chrome, I'm getting a warning, saying "LightTableWin.zip is not commonly downloaded and could be dangerous." Guess it is a false positive.
I'm interested in writing a simple rest API using compojure as a learning exercise. Can anyone experienced give an outline of what a reasonable workflow would be to do this using light table? I see that light table can "connect" to my project.clj...
1. make a new lein project 2. fill in the dependencies in project.clj 3. open your src/core.clj (or whatever) in LT 4. start coding LT will automatically launch a client and connect to it. In between lein will have seamlessly fetched the dependencies for you (this happens automatically each time you launch or relaunch a client). You can do manual (C-Enter) or live (Instarepl) inline evaluation in any of your project…
Earlier quoted context omitted.
I was actually suggesting that I can't believe people still use CL when Clojure exists... I await my lynching. :D
Well, since you threw that out there... ...I can't believe that people use Clojure-the-language over CL-the-language. It seems to have no reason to exist except as a "I hate parens" Lisp-1. The interesting parts of Clojure (i.e., the sequence abstraction design) are replicatable in CL as a library. Extant issues (e.g., cl's map not mapping over vectors)* can be abstracted over with other tools. While the JVM interop…
1)Library support. With Clojure, it's a five minute import to get Bessel functions. When I asked about how to do Bessel functions in 2006, I was told to write it myself. I've heard things have become better since then, but I haven't been able to find any evidence that
2)Immutable data structures. Yes, this can be implemented as a library in CL. However, having it as the default means that I know every non-Java function I call isn't going to break that assumption. If I did find a Bessel function library, I can't assume that it's safe.
3)GUI support. In 2006, I needed to write a GUI application that ran on Windows, Mac, and Linux. PLT Scheme (now racket) had options available, but they weren't pretty. When I went to Common Lisp, I was first directed toward CLX, which wasn't native on Mac or Windows. Someone then suggested McClim, which still needed an X-server on Windows and now seems to be largely dead. It was then suggested that I write my own binding to WXwidgets. I considered that, but I'd then need to write a high level wrapper over those low level bindings.
Comparatively, from the little I've toyed with the Seesaw library from Clojure, it seems to be a beautiful way of handling GUIs.
Okay, I guess this comes down to another library issues.
4)Dotted pairs. The only use I've ever encountered for these is extremely fine tuning performance optimizations, but third party libraries loved surprising me with these at odd moments. I can see how Lisp-1 versus Lisp-2 might be a matter of taste, but I've never heard someone complain that how they missed dotted pairs when working in Scheme or Clojure. They may be a good argument, but I've never heard it.
5) Libraries. I'm sorry that I keep coming back to this point, but I guess it's a big one. Every time I tried to do something interesting in Common Lisp, the recommendation that I was given was to write low level wrappers to three different C libraries. For several of those projects, I found it easier to just cut out the middle man and write the whole damn thing in C. The rest of the time, I wound up writing Lisp that looked almost exactly like C.
Honestly, half of this is because I'm a mediocre programmer. I have no pretensions of greatness. If I was a great programmer, I could see how to make my own DSL that made the interaction of the libraries beautiful, instead of C with more parentheses. However, in scheme or clojure, I can usually find the work of another, better programmer, who has already made that DSL. In Common Lisp, I'm usually told to write it myself. I don't know if that's because all the other Common Lisp programmers are so brilliant that they all write DSLs all day or if it's just because they're all mediocre programmers like myself and no one knows how to do it.
6) Global variables. Every examples of idiomatic Common Lisp code I was delivered was littered with globals. This might be a stylistic decision, but it's one I've never liked. A third of my problems seemed to be solved by setting OPEN-NETWORK-SOCKET-AND-SET-FIRE-TO-PRINTER to 1 and STOP-PRINTER-FIRE to nil. I can see this reliance on globals if you're writing servers, where you have a long running application with lots of state, but I wasn't, so it just made the code harder to reason about.
7)Image based programming. I understand from the SmallTalkers that this is the best way to write code, but I don't get it. What always happened for me was that some global SWITCH-CHARACTER-ENCODING-TO-EBCDIC would get set at some point and all my code would now fail. With a file based language, I'd exit and restart to kill this accidental state and everything would be okay. With the image based code, I'd have to go through the assorted globals and find which one had changed.
It looks pretty nifty! It's kind of like what Subtext and Bicicleta wanted to do, but never did (or haven't done yet). You get live update of the code and, apparently, live inspection of all the values in the code. The missing piece would be inspecting values inside a function call. But it sounds like it's proprietary software? Why do you need that if you're getting funded through Kickstarter? Either way, it looks li…
LT will be open source, just want it to get a bit more stable first.
It looks pretty nifty! It's kind of like what Subtext and Bicicleta wanted to do, but never did (or haven't done yet). You get live update of the code and, apparently, live inspection of all the values in the code. The missing piece would be inspecting values inside a function call. But it sounds like it's proprietary software? Why do you need that if you're getting funded through Kickstarter? Either way, it looks li…
What happened with Bicicleta? I love the premises I saw listed in response to Perlis. LT will be open source, just want it to get a bit more stable first.
My first prototype implementation, a tree-walking interpreter in OCaml I threw together in a few days, was discouragingly slow, so a lot of work may be needed to get it to run acceptably fast; and I haven't done the GUI work to realize the potential Light-Table-land advantages yet.
I dream of the day Light Table has Go support.
You know, I looked into this briefly and based on the way go works, it's not clear to me how useful it would be. Go doesn't really have a good REPL, which is an indication. If there was a decent way to handle dynamic evaluation though, it could certainly be added, and without too much issue I would imagine :)
I know this is already done in any number of big enterprisey IDEs, but you would surely take a fresh and creative approach.
Go would be a perfect test candidate.
Looks like there was an issue trying to connect to the project. Here's what we got:
Traceback (most recent call last):
File "C:\Users\way\.lighttable\plugins\python\ltmain.py", line 12, in
import ltipy
File "C:\Users\way\.lighttable\plugins\python\ltipy.py", line 181
print "no proc"
^which looks like a typical error when running 2.7 code on 3+. Anyone else suffering from the same issue or is something messed up on my end? Running Windows 64-bit, Python 3.3, IPython 0.13.
This is awesome, congrats on the release. I'm very excited with the Python integration. I'm going to try doing some web development with Light Table now. One thing that would be very handy would be support for virtualenvs or requirements files to integrate into workspaces so that we can work on projects without installing all dependancies globally.
Earlier quoted context omitted.
The plugin architecture is something we have to be deliberate about given that it allows you to do literally anything we can do. I talk a little bit about the plan moving forward at the bottom of the post, but gist is that there's going to be one more public release, and then the private beta (for KS folks) is going to focus on really hammering out how we expose LT to plugins.
Is there a way to preorder in order to get into the private beta as well? I wasn't with the Kickstarter crowd. If plugins are as powerful as you say they are, I'm very interested.