Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to write Common Lisp in 2017 – an initiation manual

articulate-lisp.com

Post reply on HN
Print view View original

21–30 of 271 posts

Re: How to write Common Lisp in 2017 – an initiation manual

#21

Post by chaoky »

Scarblac wrote: post #10

I'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…

In Common Lisp, you write to source code files and then use ASDF/Quicklisp to compile/load that project. If you feel the need to create a standalone executable you can dump the image with an entry function specified. It's essentially the same as python, although standalone executable are less prominent than in-image programming.

Re: How to write Common Lisp in 2017 – an initiation manual

#22

Post by SomeHacker44 »

lenkite wrote: post #11

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 ?

Given a reasonable choice, I would almost never use a language like Golang that doesn't enforce memory safety (at least, by default). Null pointers, ugh.

Re: How to write Common Lisp in 2017 – an initiation manual

#23

Post by quickoats »

Scarblac wrote: post #10

I'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 is quite abstract, let us say more so than C, where we can visualize the pointers and memory chunks and operators fairly accurately while programming. Lisp is more symbolic and ethereal; like the ocean full of its interlocking organic forms. One would wonder what lies below the surface upon merely apprehending the calmly undulating surface...

Re: How to write Common Lisp in 2017 – an initiation manual

#24

Post by SomeHacker44 »

sigjuice wrote: post #8
azrazalea wrote: post #4

Earlier 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!

To add to what @macco said: No reader macros. Apparently this extraordinarily powerful tool violates a religious principle with the inventor Rich Hickey.

Re: How to write Common Lisp in 2017 – an initiation manual

#25

Post by yarrel »

I'd replace the first few steps with "Install Roswell" -

https://github.com/roswell/roswell

Roswell will install a Lisp and QuickLisp for you, and give you a single point of entry to install libraries, create and run code, and launch en editor (Emacs with Slime of course).

I can't recommend it highly enough (I'm nothing to do with the project, just a very happy user).

Re: How to write Common Lisp in 2017 – an initiation manual

#26

Post by lispm »

Scarblac wrote: post #10

I'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…

Common Lisp implementations do whatever you want.

> I'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.

You can do that. start a Lisp with a file to load at start, it can then load the dependencies.

> C programs consist of a lot of files that are compiled and linked into a binary executable.

You can do that, too. That's typical when you create a 'system' declaration which describes your software. ASDF would be a tool for that. You then compile the software, load it and dump an image. Some implementations have a more elaborate way to create applications or can create loadable libraries, which you can integrate into other applications.

> You build an in-memory state by adding things to it, later dump it to a binary. How do you get an overview of what there is?

Typically you would work with files. Write the code in files, evaluate the code from there and build the software from time to time as a whole. If you use SBCL, then you get tons of compile time information, type checks, efficiency hints, warnings, ....

Re: How to write Common Lisp in 2017 – an initiation manual

#28

Post by [deleted] »

SomeHacker44 wrote: post #22
lenkite wrote: post #11

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 ?

Given a reasonable choice, I would almost never use a language like Golang that doesn't enforce memory safety (at least, by default). Null pointers, ugh.

[deleted]

Re: How to write Common Lisp in 2017 – an initiation manual

#29

Post by yarrel »

lenkite wrote: post #11

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 ?

I like Go and Guile. I love Common Lisp.

It's an expressive language with a powerful development environment in the form of the REPL plus Slime. I love using Lisp for exploratory programming, as it's so simple to write something that both works now and makes sense later.

It has a wider range of built-in programming paradigms more fully realised than Go or guile. In comparison to CLOS, all other object systems are just kidding. Or you can program functionally or procedurally if you like. This gives you a better toolbox.

It's a mature and stable environment. I can run code from 15 years ago or I can update it to use the latest libraries at my option.

And I just find the regularity of the parentheses has much less of a screeching brakes effect on the experience of the code. It's smoother to read and write.

So I find common Lisp a productive pleasure to use. If I was working on a project other people had to read and maintain I'd use Go, though, as it's easier to apply skills from more common languages to more quickly.

Re: How to write Common Lisp in 2017 – an initiation manual

#30

Post by [deleted] »

lenkite wrote: post #11

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 ?

[deleted]
Post reply on HN