4 ms·

I'm tackling a significant lisp project right now, and the thing that holds me up right now is that the code is difficult to organize. Python, java, rust, go et

I'm tackling a significant lisp project right now, and the thing that holds me up right now is that the code is difficult to organize. Python, java, rust, go etc have well-defined patterns to figure out where code lives and where you might expect certain behaviors to occur. With lisp you can really shoot yourself in the foot very easily by using abstractions that are difficult to follow and are spread out across many files.

freilanzer 3y ago
If there's one language in existence where you can shoot yourself in the foot using abstractions it's Java. It produces spider webs of dependencies, hierarchies, etc.
- breather 3y ago
  Right, but that's predictable and straightforward to manage. Lisp is far less structured, meaning there are far fewer guidelines or clear indications of intent built into the organization of the program. Or at least, there's enough complexity it's much more difficult to internalize than Java, even with all its verbose warts.
vindarel 3y ago
> the code is difficult to organize we can simply do `(defpackage :mypackage (:use :cl))` then `(in-package :mypackage)`. Since they don't have to follow file hierarchy, we are free. That's good for the long term, and general flexibility. But it's different, sure. Good luck!
- breather 3y ago
  I mean, separating files (or modules or libraries or whatever) seems somewhat orthogonal to my point—where you expect to find behavior, and what behavior you expect, rather depends on how you use lisp.
mark_l_watson 3y ago
I like to compose programs from small one purpose Common Lisp libraries, each is a Quicklisp project. I used to write larger monolith CL projects, but I like my newer approach better. Off topic, but I take the same approach for my personal Python and Racket projects also.
kagevf 3y ago
Lately, I've been creating protocols that are meant to be the interface for some kind of entity, such as "user", "utility", "configuration", "auth", and so on. The logistics of that are to use defgeneric for the protocol interface, defmethod in the same package, but can be over-ridden with a more specific defmethod in another package if necessary. I still export regular functions too, but I look to the defgenerics as the main entry points for a particular package. To (sort of) enforce some separation, I try to keep these packages self-contained in their own system (defsystem). I mean, it's one approach, but my advice would be to take some time to come up with what would work for your appication and CL is flexible enough it can probably support it.

freilanzer 3y ago

If there's one language in existence where you can shoot yourself in the foot using abstractions it's Java. It produces spider webs of dependencies, hierarchies, etc.

breather 3y ago
Right, but that's predictable and straightforward to manage. Lisp is far less structured, meaning there are far fewer guidelines or clear indications of intent built into the organization of the program. Or at least, there's enough complexity it's much more difficult to internalize than Java, even with all its verbose warts.

vindarel 3y ago

> the code is difficult to organize we can simply do `(defpackage :mypackage (:use :cl))` then `(in-package :mypackage)`. Since they don't have to follow file hierarchy, we are free. That's good for the long term, and general flexibility. But it's different, sure. Good luck!

breather 3y ago
I mean, separating files (or modules or libraries or whatever) seems somewhat orthogonal to my point—where you expect to find behavior, and what behavior you expect, rather depends on how you use lisp.

mark_l_watson 3y ago

I like to compose programs from small one purpose Common Lisp libraries, each is a Quicklisp project. I used to write larger monolith CL projects, but I like my newer approach better. Off topic, but I take the same approach for my personal Python and Racket projects also.

kagevf 3y ago

Lately, I've been creating protocols that are meant to be the interface for some kind of entity, such as "user", "utility", "configuration", "auth", and so on. The logistics of that are to use defgeneric for the protocol interface, defmethod in the same package, but can be over-ridden with a more specific defmethod in another package if necessary. I still export regular functions too, but I look to the defgenerics as the main entry points for a particular package. To (sort of) enforce some separation, I try to keep these packages self-contained in their own system (defsystem). I mean, it's one approach, but my advice would be to take some time to come up with what would work for your appication and CL is flexible enough it can probably support it.