Steve Losh's blog post explores leveraging the Common Lisp Object System (CLOS) for dependency management within Lisp applications. Instead of relying on external systems, Losh advocates using CLOS's built-in dependent maintenance protocol to automatically track and update derived values based on changes to their dependencies. He demonstrates this by creating a depending macro that simplifies defining these dependencies and automatically invalidates cached values when necessary. This approach offers a tightly integrated, efficient, and inherently Lisp-y solution to dependency tracking, reducing the need for external libraries or complex build processes. By handling dependencies within the language itself, this technique enhances code clarity and simplifies the overall development workflow.
Common Lisp saw continued, albeit slow and steady, progress in 2023-2024. Key developments include improved tooling, notably with the rise of the CLPM build system and continued refinement of Roswell. Libraries like FFI, CFFI, and Bordeaux Threads saw improvements, along with advancements in web development frameworks like CLOG and Woo. The community remains active, albeit small, with ongoing efforts in areas like documentation and learning resources. While no groundbreaking shifts occurred, the ecosystem continues to mature, providing a stable and powerful platform for its dedicated user base.
Several commenters on Hacker News appreciated the overview of Common Lisp's recent developments and the author's personal experience. Some highlighted the value of CL's stability and the ongoing work improving its ecosystem, particularly around areas like web development. Others discussed the language's strengths, such as its powerful macro system and interactive development environment, while acknowledging its steeper learning curve compared to more mainstream options. The continued interest and slow but steady progress of Common Lisp were seen as positive signs. One commenter expressed excitement about upcoming web framework improvements, while others shared their own positive experiences with using CL for specific projects.
OpenLDK is a project that implements a Java Virtual Machine (JVM) and Just-In-Time (JIT) compiler written entirely in Common Lisp. It aims to be a high-performance JVM alternative, leveraging Lisp's metaprogramming capabilities for dynamic code generation and optimization. The project features a modular design, encompassing a bytecode interpreter, a tiered JIT compiler using a method-based compilation strategy, and a garbage collector. OpenLDK is considered experimental and under active development, focusing on performance enhancements and broader Java compatibility.
Commenters on Hacker News express interest in OpenLDK, primarily focusing on its unusual implementation of a Java Virtual Machine (JVM) in Common Lisp. Several question the practical applications and performance implications of this approach, wondering about its speed and suitability for real-world projects. Some highlight the potential benefits of Lisp's dynamic nature for tasks like debugging and introspection. Others draw parallels to similar projects like Clojure and GraalVM, discussing their respective advantages and disadvantages. A few express skepticism about the long-term viability of the project, while others praise the technical achievement and express curiosity about its potential. The novelty of using Lisp for JVM implementation clearly sparks the most discussion.
Macintosh Allegro Common Lisp (MCL) was a popular Lisp development environment for the classic Mac OS. Developed by Franz Inc., it offered a full-featured implementation of Common Lisp, including an integrated development environment (IDE) with a compiler, debugger, and inspector. MCL leveraged the Macintosh interface, offering a graphical user interface and utilizing features like QuickDraw for graphics. It was known for its performance and robust capabilities, making it a favored choice for AI research and development on the Mac platform during the late 80s and 90s. Though no longer actively developed, it represents a significant chapter in the history of Lisp on the Mac.
Hacker News users discuss Macintosh Allegro Common Lisp, with several expressing nostalgia for the environment and its impressive capabilities for the time. One commenter recalls its speed and the powerful IDE, noting its use in AI research. Another highlights its foreign function interface, enabling integration with existing Mac Toolbox code. Some lament the closed-source nature and the eventual decline of MCL, while others suggest exploring modern open-source Lisp options like SBCL or CCL. The high cost of MCL is also mentioned. One user points out the existence of a free version with limitations. The thread overall expresses appreciation for MCL's historical significance in the Lisp and Mac communities.
Maxima, a powerful computer algebra system (CAS), is now accessible directly in web browsers thanks to a project leveraging Embedded Common Lisp (ECL) compiled to WebAssembly (WasM). This allows users to perform complex symbolic computations, including algebra, calculus, and numerical analysis, without any local installation. The browser-based interface provides a REPL (read-eval-print loop) for interactive calculations and utilizes MathJax for displaying formatted mathematical expressions. This project makes Maxima's capabilities more readily available, eliminating the need for dedicated software or server-side setups.
Commenters on Hacker News express excitement about Maxima running in the browser via WASM and ECL. Several highlight the potential for educational uses and interactive symbolic computation in web environments. Some discuss the performance overhead of WASM and suggest improvements, like pre-compilation for faster startup. The ability to share computational documents easily and integrate with other web technologies is praised. A few users mention other similar projects, including one using ClojureScript and another involving a Python CAS in the browser. The general sentiment is positive, with commenters intrigued by the possibilities this opens up for accessibility and collaborative mathematical work. One commenter expresses interest in building symbolic computation directly into a browser rather than running it as a VM.
Driven by a desire to learn networking and improve his Common Lisp skills, the author embarked on creating a multiplayer shooter game. He chose the relatively low-level Hunchentoot web server, using WebSockets for communication and opted for a client-server architecture over peer-to-peer for simplicity. Development involved tackling challenges like client-side prediction, interpolation, and hit detection while managing the complexities of game state synchronization. The project, though rudimentary graphically, provided valuable experience in game networking and solidified his appreciation for Lisp's flexibility and the power of its ecosystem. The final product is functional, allowing multiple players to connect, move, and shoot each other in a simple 2D arena.
HN users largely praised the author's work on the Lisp shooter game, calling it "impressive" and "inspiring." Several commenters focused on the choice of Lisp, some expressing surprise at its suitability for game development while others affirmed its capabilities, particularly Common Lisp's performance. Discussion arose around web game development technologies, including the use of WebSockets and client-side rendering with PixiJS. Some users inquired about the networking model and server architecture. Others highlighted the clear and well-written nature of the accompanying blog post, appreciating the author's breakdown of the development process. A few commenters offered constructive criticism, suggesting improvements like mobile support. The general sentiment leaned towards encouragement and appreciation for the author's technical achievement and willingness to share their experience.
Summary of Comments ( 2 )
https://news.ycombinator.com/item?id=43176358
Hacker News users discussed the complexity of Common Lisp's dependency system, particularly its use of the CLOS dependent maintenance protocol. Some found the system overly complex for simple tasks, arguing simpler dependency tracking mechanisms would suffice. Others highlighted the power and flexibility of CLOS for managing complex dependencies, especially in larger projects. The discussion also touched on the trade-offs between declarative and imperative approaches to dependency management, with some suggesting a hybrid approach could be beneficial. Several commenters appreciated the blog post for illuminating a lesser-known aspect of Common Lisp. A few users expressed interest in exploring other dependency management solutions within the Lisp ecosystem.
The Hacker News post titled "Depending in Common Lisp – Using the CLOS dependent maintenance protocol (2022)" has generated a modest number of comments, offering some interesting perspectives on dependency management in Common Lisp and comparing it to other systems.
One commenter highlights the elegance and power of the CLOS dependent maintenance protocol, arguing that it represents a sophisticated approach to dependency tracking and update propagation, surpassing the capabilities of many other dependency systems. They emphasize the seamless integration with the object system and the ability to define custom dependency relationships.
Another comment draws a parallel between the described Common Lisp system and the reactive programming paradigm, observing that the automatic update mechanism resembles the behavior of reactive frameworks. They suggest that this inherent reactivity simplifies complex application logic by automatically handling state changes and updates.
A separate comment chain discusses the trade-offs between the dynamic nature of Common Lisp and the static approaches found in languages like Java. Some argue that the dynamic nature allows for greater flexibility and rapid prototyping, while others express concerns about the potential for runtime errors and debugging challenges. The discussion touches on the benefits of both approaches, acknowledging the value of static analysis for catching errors early but also recognizing the power of dynamic systems for adapting to changing requirements.
One commenter questions the necessity of a separate dependency system within Common Lisp, proposing that the core language features already provide sufficient mechanisms for managing dependencies. They suggest that leveraging macros and functions can achieve similar results without introducing additional complexity. This sparks a brief discussion about the merits of specialized dependency management tools versus relying on fundamental language constructs.
Finally, a few comments provide additional context by mentioning related libraries and tools in the Common Lisp ecosystem, further enriching the understanding of dependency management in this context. They offer pointers to alternative approaches and resources for those interested in exploring the topic further.