In Java Object System (JOS), code and data are usually mixed together in classes.
In Common Lisp Object System (CLOS), code is stored in generics while data is stored in classes.
It seems to me that a program designed in the spirit of CLOS is inherently less complex than a program designed in the spirit of JOS.
By complexity, I mean the effort it takes to understand the system, like it is defined in Out of the Tar Pit) seminal paper.
For example, imagine that we take a UML diagram where objects contain both code and data and that we split each object into a code object and a data object. The resulting diagram is made of two "almost disjoint" diagrams.
The diagram below illustrates an example of such a split. In this diagram, Object-Oriented means JOS while Data-Oriented means CLOS:
https://preview.redd.it/hnwjl7ha6yk61.png?width=1300&format=png&auto=webp&s=9e7e352957edb570785ea9137b0cfd39396d1ab4
I believe that the resulting diagram is simpler than the original one. Now I'd like to prove it, not necessarily for the general case. At least, I'd like to have a formal metric that measure the complexity of a UML diagram.
Here are my questions:
- Is there a metric that measures the complexity of a UML diagram?
- Is my belief that CLOS is less complex than Java Object System correct?
- Are there other ways to illustrate the inherent simplicity of CLOS?
Hey Lispers,
This one was a quick holiday project of mine, which I'm sharing with you -- cl-wol: Wake on LAN (WoL) system for Common Lisp.
Happy holidays!
Hello,
I have come to love common lisp more and more as I work with it, in fact I have considered ditching the POSIX core utilities for sbcl + come libraries, but there is no issue I can not seem to get past which not only makes it impossible to ditch core utilities but also extremely hard to even develop with common lisp over other languages.
I have run into an issue time and again where I need to something like killing a process, getting full permissions of a file, get the PID of a process I did not start, etc. and the solution I find every time is to make a call to a userland program like ps or pkill. While of course I know how to work with these and I do not mind using them when I am just in an sbcl session this do become an annoyance when I am rolling an actual program or script. First, not every system will have pkill some servers do not have it and on some of my workstations I do not have it as I use killall and while I could replace pkill with killall in my scripts that also does not work as not all systems have that! You get where I am going with this: I do not want to make assumptions about what the userland I am working with has or does not have nor do I want to force it to conform with certain dependencies. I have looked at UIOP and even OSIcat and while they do solve many problems with using common lisp on UNIX-like operating systems for some reason, for some unholy demonic reason, they never include anything for process management or getting file permissions in the UNIX dialect. This has made it very very very hard to work with common lisp and it is driving me crazy.
Does anyone know of a solid time tested library that provides a well rounded and full set of calls for working with UNIX-like operating systems?
Hey Lispers,
This is a new Common Lisp system I have been working on during my spare time, which finally reached a state when I can share it with the community.
A short summary of the clingon system and the features it currently supports.
- Native support for sub-commands
- Support for command aliases
- Short and long option names support
- Short options may be collapsed as a single argument, e.g.
-xyz - Long options support both notations -
--long-opt argand--long-opt=arg. - Automatic generation of help/usage information for commands and sub-commands
- Out of the box support for
--versionand--helpflags - Support for various kinds of options like
string,integer,boolean,switches,enums,list,counter, etc. - Sub-commands can lookup global options and flags defined in parent commands
- Support for options, which may be required
- Options can be initialized via environment variables
- Single interface for creating options using
CLINGON:MAKE-OPTION - Generate documentation for your command-line app
- Support for shell completions
You can find more details in the clingon repo along with a good amount of documentation to get you started.
Let me know what you think. Thanks!
Hi r/lua! I'd like to announce the release of a library that implements Common Lisp-like condition system for Fennel language and Lua runtime - fennel-conditions.
Since this subreddit is about Lua, I understand that this may not be very relevant, as it doesn't target Lua language directly, rather the Lua runtime, via custom compiler, but I hope this still may be interesting, as this library provides alternative ways of error handling, which are mostly unique to Common Lisp.
If this library will receive a lot of interest from Lua users, I will consider porting it in such way that it can be used from Lua directly. (It is possible right now, but you would not want to write all that code by hand which is generated by macros provided in this library).
First, a bit about what Fennel is. Fennel is a Lisp-like language and a surface syntax for Lua, that compiles directly to Lua code. Fennel itself has no runtime, and is more a compiler rather than a language, but it provides a lot of additional facilities via macros, like table comprehensions, or pattern matching, and other things. Macros also allow to extend the language with new syntactic constructions, and this library is an example of that.
What is a condition system?
Condition system is something that is also known as resumable exception model, but it doesn't stop there in Common Lisp. It's a powerful control flow system, which also provides error handling. This library implements only the error handling part, but it's still pretty significnat part.
The condition system is implemented by introducing a dynamic scope. Lua doesn't have dynamic scope OOTB, but it does have tables, which can act as a dynamic scope. This library then maintains this dynamic scope state via various macros, like handler-case, restart-case, handler-bind, and so on.
Condition is an object, which can indicate that something happened. It can be any object, e.g. string, or table, but this library provides its own condition object type, which is based on the table, but has inheritance semantics. But condition objects by itself can't do anything, and the meat of this library is its own implementation of error function, which implements resumable exception point. Additionally there are non-error condition signaling functions like warn and signal. They provide the same resumable exception points, but do not interrupt flow of the pro
For those like me who preordered the above book, it looks like the ebook is now available. I didn't see any notification from Apress to let me know. Looking forward to diving in...when my paper copy arrives (I'm old-fashioned that way).
Hey Lispers,
I'm looking for a distributed file system / database for a Common Lisp project. Something like IPFS/OrbitDB or GUN.
Requirements:
- Accessible from the browser
- Reasonably complete, functioning CL API
I see that cl-ipfs-api2 is available. I would prefer a license milder than GPL if possible.
What are my options?
Hey Lispers,
Wanted to share with you another Common Lisp system I've been working on -- cl-bcrypt.
This one was made possible thanks to the work done by glv2 and the recently added support in ironclad for bcrypt and bcrypt-pbkdf.
Lisp is quickly becoming my favorite language and I feel like I've learned just enough to start having questions about the development process for lisp. It's obvious to me that the way lisp turns code into machine-code is a lot different than, say, C++ or Python.
It's my understanding that lisp (specifically SBCL) is essentially an "interpreted" and "compiled" language at once. This is because it uses image-based builds; where instead of shipping a program, you are pretty much shipping a modified version of lisp suited to your problem.
Of course I could be completely wrong. What I want to know is:
- How does CL compilation process differ from Python or C++
- How does this change the development process
- Why is it useful to do it this way
In other words:
Suppose I've built a program that runs heavy simulations of physical equations in C++ and Common-Lisp. Given these programs do the same thing, what more/less can I do with the Common-Lisp version?
Hey Lispers,
I've been using Common Lisp off and on for the last few months and after spending some time with the language I'm ready with my first Common Lisp project - cl-migratum.
As part of my daily activities I need to work with various databases such SQLite, MySQL, PostgreSQL and some graph databases where different teams or projects usually use a different database. The common thing between them is that all of them use some kind of database schema migration and most of the times this means different tools, different naming conventions for migrations files, etc.
I thought it would be much easier for me, if I could use a simple common interface for all these different projects and list/apply/view migrations while staying in the REPL, so that's where the idea of cl-migratum came from. I've looked at the existing implementations of schema migration libraries in Common Lisp, but could not find one that would be flexible enough for my needs, so I've started one.
I'm sharing this with you with the hope that someone else finds it useful.
I'd also appreciate any feedback on the code in general -- coding style, design, documentation, or anything else that you think might be useful for someone fairly new to Common Lisp that should be aware of.
I also got a copy of PCL book and I'm halfway through it, so once I manage to finish it I'd need a new book. What would you recommend me?
Thanks!
