161–170 of 271 posts
For people using macs, it's probably worthwhile to mention CCL's IDE, which you can easily build from within the CCL sources using (require :cocoa-application), or which you can get for free from the Mac App Store (it's called "Clozure CL"). It's a little bit bare bones and a little bit perpetually unfinished, but it works and it gives you a Lisp-aware environment for editingand running Lisp code, and even has a few…
Earlier quoted context omitted.
which lisp interpreter did you use ?
It baffles me that this notion of Lisp as an interpreted language still persists. Common Lisp is a compiled language for all non toy implementations, and in general Lisps have had compilers for decades.
Earlier quoted context omitted.
Having a good REPL is important, though.
REPL and interpretation are orthogonal concepts. SBCL (most common CL implementation) don't have interpreter at all. It complies into machine code before execution even in REPL.
Earlier quoted context omitted.
> (and it's not even a hidden directory, so it clutters up ~). Well in that case you have two options still: ~/.local/share/common-lisp/source/ or put config file(s) in: ~/.config/common-lisp/source-registry.conf.d/ And keep your lisp source in any arbitrary number of directories. Of course if the symlink farm is working for you, that's fine; it just has issues (some historic with some implementations doing odd thing…
I do need to study the matter. I've found the ASDF docs to be unusually opaque (last time I read them), and my current solution to be Very Simple (and a little Stupid), so I've been content not changing the setup. Thank you for your kind information.
How does Common Lisp compares to Racket nowadays? I've seen a lot of activity but I can't decide which one to try out. I only have time for one of them ATM.
1. Racket is a multi-paradigm programming language. It has Java-style class/object system, a CLOS-like object system(swindle) and a prototype object system (like self and JavaScript). 2. The macro system is arguably the most sophisticated available. 3. Functionsl programming! including '(purely)Functional Data Structures'. 4. Parallelism (futures) 5. concurrency 6. Contracts 7. Typed Racket 8. Pattern matching 9. Mod…
and its only implementation.
1. I use LispWorks, a multi-paradigm programming language (and its implementation) based on Common Lisp. It has CLOS and can use multiple other object-systems. 2. uses procedural macros 3. procedural functions, 3. concurrency, 6 assertions, 7 type declarations, 8 unification 9 systems, 10 conditions 11 reflection 12 arguably excellent tools for creating languages and dsls, 13 prolog 14 rule system 15 database interface 16 OpenGL 17 cross platform and will run on the raspberry pi 18 nice community 19 interface builder 20 delivery as shared libraries and applications, ...
and a long list of other features...
It's commercial and closed software, though.
If emacs is an obstacle to Common Lisp in 2017, maybe what's needed is a Lisp-interaction plugin for vi(m) (or whatever it is that vim uses in lieu of emacs modes). I don't get the hype for modal editing but you can't argue with the data clearly showing emacs users are in the minority.
How does Common Lisp compares to Racket nowadays? I've seen a lot of activity but I can't decide which one to try out. I only have time for one of them ATM.
1. Racket is a multi-paradigm programming language. It has Java-style class/object system, a CLOS-like object system(swindle) and a prototype object system (like self and JavaScript). 2. The macro system is arguably the most sophisticated available. 3. Functionsl programming! including '(purely)Functional Data Structures'. 4. Parallelism (futures) 5. concurrency 6. Contracts 7. Typed Racket 8. Pattern matching 9. Mod…
The statement about macros is more nuanced that you let on, language decisions like being a Lisp-1 w/o a symbol namespace (CL packages) make hygiene a necessity which in turn complicates writing macros. One thing I do like about racket is that it comes with support for writing pattern directed macros, that although possible to write in CL has no built in tools for it. Another point for racket is that it has support for macros with better error reporting (ej the elipsis).
15 is really the main selling point for racket. It is a Language creating toolbox (I forget the term they use for it). It's module system stands out in that regard compared to CL, which has read tables as a way to customize the reader. Racket's solution is more general and extensible in that regard.
16 is not true when compared to CL. The IDE of racket is way behind slime/sly, however it doesn't require setup.
The other big difference is that CL is image based and suited for interactive development while Racket is batch oriented, 'python-style' of interactivity. If you come from Python you will think racket is interactive, but if you come from smalltalk you'll know what you are missing.
As Aiden said, both are great languages, flip a coin.
Earlier quoted context omitted.
In addition to the other problems described, Clojure just breaks the value of Lisp's syntax. Common Lisp does have its irregularities but code littered with Java imports and square brackets might as well just use C formatting and be done with it.
The primary value, to me of Lisp syntax is that code is represented as data structure literals which can be manipulated as easily as any other data structure prior to execution. Clojure has that; it just comes with literals for a few more data structures and uses two of them, vectors and maps in the syntax of built-in forms.
Is it so that the syntax of vectors can be used? Then it has technical consequences.
Is it because of technical issues (arguments are vectors internally) and thus it can be exposed in the syntax, too?
Or both?
Earlier quoted context omitted.
> lists and other seq's as functions in the function position of an x-expression. Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp. Common Lisp was designed such that for the programmer and for the compiler the first el…
Arrays are functions, by definition. They relate inputs to outputs.
Earlier quoted context omitted.
I'll take a stab at this glib comment: 1. You've inherited an application written in Common Lisp 2. Common Lisp has features you find desirable that aren't available in another system 3. You like Common Lisp 4. Common Lisp helps you get the thing you're trying to do, done
1. Because I was forced to? That's not why I'd want to. 2. Examples? 3. Fair enough. Though AlexCoventry's question probably shows that he does not (currently) like Common Lisp, so this answer doesn't give him a reason. 4. Sure, that's true for every language and tool. Choose it when it helps you, don't when it doesn't. But why would CL help me more than another language?
Better than rewriting the whole thing in your pet language.