I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?
How to write Common Lisp in 2017 – an initiation manual
11–20 of 271 posts
Re: How to write Common Lisp in 2017 – an initiation manual
#12Earlier quoted context omitted.
Nope, it has new problems that are (IMO) worse.
I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!
Usually, people tend to see the following problems:
* no native support, hosted language (js java)
* unreadable (java) tracebacks
* no tail call optimization
These are not my problems with Clojure, but then things I often read. I am interested in Common Lisp because of the native support.
Re: How to write Common Lisp in 2017 – an initiation manual
#13I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?
Stability of (most) implementations and solid language standard.
Re: How to write Common Lisp in 2017 – an initiation manual
#14Short answer: don't do that, use Clojure instead. It doesn't have any of listed problems.
I am sure there are plenty of people who have a preferred Lisp. It does drive me nuts how if there is a post on R the top comments are people touting Python as being the bigger player in statistics and data science (Which it isn't) or a ton of other languages.
PS I perfer Racket :)
Re: How to write Common Lisp in 2017 – an initiation manual
#15I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?
You can run the code you wrote 15 years ago, and (hopefully) you will be able to run in 15 years the code you write today.
Re: How to write Common Lisp in 2017 – an initiation manual
#16I'm used to languages like Python, that have a number of files that are modules, and to start a program you run one of them as an entry point. C programs consist of a lot of files that are compiled and linked into a binary executable. Whenever I've tried to learn CL, I couldn't really wrap my head around what the eventual program would be. You build an in-memory state by adding things to it, later dump it to a binary…
Lisp offers a lot of ways to check what there is. You can inspect, search, look at source code, docs, assembly code. All of these things are dynamically inspectable. Tools like Emacs and SLIME make it easier.
You can still look at the files that get loaded. Lisp organizes itself around systems (libraries) and packages (namespaces). It's good to check what packages a system has, then you can check out the symbols provided by a package.
Lisp isn't totally wild-west in the concept of the Lisp image. There is organization to good code.
Re: How to write Common Lisp in 2017 – an initiation manual
#17Ah yes this is exactly what I needed. I was recently trying to start a CL project but I had trouble wading through all the outdated material, especially with regards to including external packages. Thanks for putting this together!
I'm going through a similar process. My caution is that 'package' has a very technical meaning in Common Lisp that is at odds with how 'package' is used in other languages (and a bit at odds with how the author uses it in their tutorial).
A package in Common Lisp is a set of interned symbols. In Common Lisp, systems are more in keeping with an ordinary understanding of packages...but combined with the idea of a build system just for fun.
ASDF is a way for managing systems (but it is worth keeping in mind that Common Lisp does not have any 'official' understanding of systems). ASDF is pretty much a de facto standard by consensus.
Quicklisp is a 'package manager' in the sense that it will go out and fetch a dependency from a repository. But what it fetches is a system: it is usually not a package in Common Lisp's technical sense.
From the Quicklisp FAQ:
How is Quicklisp related to ASDF?
Quicklisp has an archive of project files and metadata about project relationships. It can download a project and its dependencies. ASDF is used to actually compile and load the project and its dependencies.
ASDF is a little like make and Quicklisp is a little like a Linux package manager.
On the other hand, Common Lisp is very stable around ASDF and SLIME and QuickLisp. ASDF was started in 2002. Quicklisp in 2005. SLIME in 2003.
Re: How to write Common Lisp in 2017 – an initiation manual
#18Short answer: don't do that, use Clojure instead. It doesn't have any of listed problems.
I am sure there are plenty of people who have a preferred Lisp. It does drive me nuts how if there is a post on R the top comments are people touting Python as being the bigger player in statistics and data science (Which it isn't) or a ton of other languages. PS I perfer Racket :)
Came here to share my love for Racket. Parameterization, custodians, threading, channels, message inboxes, and the packaging tool is also great. I just recently published my first application to the Racket package repo, and I found it to be the least painful experience so far.
Re: How to write Common Lisp in 2017 – an initiation manual
#19i do not know how to message the guy "Scott" author of page, so i am putting this here.
in the "LispWorks CL" page, under "Implementations", the "Notes" section elicidates a mystery about the Personal Edition not recognizing the lisp init files. This is actually a limitation in LispWorks Personal Edition which is described on the link provided to retrieve said edition.
Re: How to write Common Lisp in 2017 – an initiation manual
#20I'm used to languages like Python, that have a number of files that are modules, and to start a program you run one of them as an entry point. C programs consist of a lot of files that are compiled and linked into a binary executable. Whenever I've tried to learn CL, I couldn't really wrap my head around what the eventual program would be. You build an in-memory state by adding things to it, later dump it to a binary…
I don't know where you got that impression, but CL development is no different than Python development.
Code goes in .lisp files, and then you either load it into the REPL or pass it to the compiler and tell it what the entry point is.
I suppose it's technically possible to develop an entire application at the REPL and then dump to a binary, but I don't think anybody does that any more than they do it in Python.