![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
orthecreedence 3 days ago
| link |
Common Lisp guy gonna chime in here...having a REPL that integrates with your editor (vim/slimv in my case) is an intense improvement on any other language I've ever used. With C you edit, leave, `make`, run. With PHP you edit, open browser, F5, run...same with JS.
With lisp, I edit, eval (simple command in my editor), see result. If I'm building a game or a long-running app, I can redefine functions while it's running without doing a full recompile and having to try and get back to the state the app was in when I wanted to test my change.
So you get the ability to live-code while the app is running. Once you get used to being able to do this, leaving your editor and opening to shell to test your app seems like a barbaric exercise.
So a good REPL (lisp or not, doesn't matter) can make the experience a lot more interactive and experimental that your average write -> save -> compile -> run cycle.
reply
gsg 3 days ago
| link |
Unfortunately the OCaml toplevel pales in comparison to CL environments like slime in terms of visibility and debuggability. Redefinition is also off the table, as OCaml is a very static language. (You can rebind the same name, which can be helpful in exploratory programming but is not at all the same thing.)
It remains an extremely useful tool though.
reply
--
"I'm not arguing that you can't get work done in these languages. You can get very solid work done in all of them, with enough persistence. My basic impetus for blogging about this stuff stems from the desire to have my cake and eat it at work. I want a language with Python's succinctness, Lisp's extensibility, C's performance, Erlang's parallelism, Java's tools, Io's orthogonality, and apparently Qi's type system. :-) And more besides." -- http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html
--
" My concept of the system expanded from that of a hierarchical notebook to a complete programming system. Yet I knew that it could not satisfy me if it contained any parts not modifiable from within itself. Emacs would stand a chance, were it not for its C-language core. Then I discovered that system-level reflection is not an unreasonable demand. I found out that instant documentation and source access for any object known to the user/programmer is a reasonable thing to expect. That it is possible to halt, repair, and resume a running program. And, depressingly, that one could do these things on 1980s vintage hardware but not on modern machines.My concept of the system expanded from that of a hierarchical notebook to a complete programming system. Yet I knew that it could not satisfy me if it contained any parts not modifiable from within itself. Emacs would stand a chance, were it not for its C-language core. Then I discovered that system-level reflection is not an unreasonable demand. I found out that instant documentation and source access for any object known to the user/programmer is a reasonable thing to expect. That it is possible to halt, repair, and resume a running program. And, depressingly, that one could do these things on 1980s vintage hardware but not on modern machines. " -- http://www.loper-os.org/?p=8
---
https://groups.google.com/forum/?hl=en#!topic/comp.lang.lisp/XpvUwF2xKbk[101-125-false]
---
Design of a LISP-based microprocessor
http://dl.acm.org/citation.cfm?id=359031&coll=portal&dl=ACM
---
" Kent M Pitman 2/20/99 More LispOS? talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))) cba...@2xtreme.net (Christopher R. Barry) writes:
> Within Garnet you can move your mouse over any object in your GUI and > hit F1 to bring up the Inspector which gives you information about > every single slot value in the object, displays it's "is-a" hierarchy, > and shows you what things it's formulas depend on.
Within DW, you can move your mouse over any object or subobject that has been displayed, whether or not it was part of any GUI. You get this virtually for free and have to work hard to suppress it if you don't want it. But it doesn't require any special programming.
One of the most common ways to get a foothold in Genera for debugging something is to (1) find a place where the thing you want to use appears visually, (2) click Super-Left to get the object into your hands for read-eval-print, inspection, etc, (3) use (ed (type-of *)) to find its source reliably and with no foreknowledge of what the type is, who wrote the program, what their file conventions were, who loaded it, or any of myriad other things that other systems make me do.
> Under the X windowing system there is this standard tool "editres" > that lets you click on any client and bring up it's class hierarchy > tree and edit resources interactively.
Not resources. Objects. All objects. Not just the heavyweight ones. Lists. Integers. I somehow don't believe you when you say this is the same as what Genera does.
The usual thing DW enables is the debugging of things that the person did NOT make part of the standard interface. Pointing to a UI tool and saying it allows you to plan for structured debugging of something is missing the point.
Or maybe you're saying that Garnet allows me to cross the boundary into the internals of systems. Maybe I'm missing out.
When you can make the claim that if you teach me a few paragraphs worth of stuff, I will have all of the information I need in order to bootstrap myself into a complete understanding of the entire operating system and all of its conventions, I'll believe you Garnet and X are as powerful as Genera and Dynamic Windows. Until then, I'll continue to believe they are different. Incidentally, I'm dying to know that there is a tool that will do all that Genera could do only for stock hardware becuase the stack of books I need to buy in order to be equivalently competent with other systems is daunting and I could really do with the savings in time, energy, and money of learning things about standard systems in the way I've been doing...
I don't even find Emacs itself to be equivalently self-documenting and easy to get around in, much less the many systems that Emacs touches.
> I know these things aren't as cool as the LispM?