This paper introduces Deputy, a dependently typed language designed for practical programming. Deputy integrates dependent types into a Lisp-like language, aiming to balance the power of dependent types with the flexibility and practicality of dynamic languages. It achieves this through a novel combination of features: gradual typing, allowing seamless mixing of typed and untyped code; a hybrid type checker employing both static and dynamic checks; and a focus on intensional type equality, allowing for type-level computation and manipulation. This approach makes dependent types more accessible for everyday tasks by allowing programmers to incrementally add type annotations and leverage dynamic checking when full static verification is impractical or undesirable, ultimately bridging the gap between the theoretical power of dependent types and their use in real-world software development.
This post explores the power and flexibility of Scheme macros for extending the language itself. It demonstrates how macros operate at the syntax level, manipulating code before evaluation, unlike functions which operate on values. The author illustrates this by building a simple infix macro that allows expressions to be written in infix notation, transforming them into the standard Scheme prefix notation. This example showcases how macros can introduce entirely new syntactic constructs, effectively extending the language's expressive power and enabling the creation of domain-specific languages or syntactic sugar for improved readability. The post emphasizes the difference between syntactic and procedural abstraction and highlights the unique capabilities of macros for metaprogramming and code generation.
HN commenters largely praised the tutorial for its clarity and accessibility in explaining Scheme macros. Several appreciated the focus on hygienic macros and the use of simple, illustrative examples. Some pointed out the power and elegance of Scheme's macro system compared to other languages. One commenter highlighted the importance of understanding syntax-rules as a foundation before moving on to more complex macro systems like syntax-case. Another suggested exploring Racket's macro system as a next step. There was also a brief discussion on the benefits and drawbacks of powerful macro systems, with some acknowledging the potential for abuse leading to unreadable code. A few commenters shared personal anecdotes of learning and using Scheme macros, reinforcing the author's points about their transformative power in programming.
A new Common Lisp implementation, named ALisp, is under development and currently supports ASDF (Another System Definition Facility) for system management. The project aims to create a small, embeddable, and efficient Lisp, drawing inspiration from other Lisps like ECL and SBCL while incorporating unique ideas. It's being developed primarily in C and is currently in an early stage, but the Savannah project page provides source code and build instructions for those interested in experimenting with it.
Hacker News users discussed the new Common Lisp implementation, with many expressing interest and excitement. Several commenters praised the project's use of a custom reader and printer, viewing it as a potential performance advantage. Some discussion revolved around portability, particularly to WebAssembly. The project's licensing under LGPL was also a topic of conversation, with users exploring the implications for commercial use. Several users inquired about the motivations and goals behind creating a new Common Lisp implementation, while others compared it to existing implementations like SBCL and ECL. A few comments touched on specific technical aspects, such as the choice of garbage collection strategy and the implementation of the condition system. Some users offered helpful suggestions and expressed a desire to contribute.
The blog post details the author's process of livecoding graphics in Common Lisp using a combination of Quicklisp libraries, specifically cl-cairo2 and Qtools. They leverage the REPL's interactive nature to rapidly iterate and experiment with visual elements, modifying code and seeing immediate results in a Cairo graphics window. The author explains their setup and workflow, emphasizing the advantages of Lisp's dynamic environment for this type of creative coding, showcasing how functions can be redefined and tweaked on-the-fly to manipulate shapes, colors, and other graphical parameters. This approach allows for a fluid and exploratory development experience, turning the coding process itself into a performative act.
HN users generally praised the author's technical skill and the visual appeal of the live coding demo. Some expressed interest in learning more about Common Lisp and the specific libraries used. A few commenters discussed the practical applications of live coding graphics, suggesting uses in game development, generative art, and data visualization. One commenter pointed out the potential accessibility issues related to color choices in the examples. Another highlighted the historical precedent of Lisp machines and their graphical capabilities, connecting the demo to that lineage. The perceived complexity of Common Lisp was also mentioned, with some users acknowledging its steep learning curve but also its power and flexibility.
Guy Steele's "Growing a Language" advocates for designing programming languages with extensibility in mind, enabling them to evolve gracefully over time. He argues against striving for a "perfect" initial design, instead favoring a core language with powerful mechanisms for growth, akin to biological evolution. These mechanisms include higher-order functions, allowing users to effectively extend the language themselves, and a flexible syntax capable of accommodating new constructs. Steele emphasizes the importance of "bottom-up" growth, where new features emerge from practical usage and are integrated into the language organically, rather than being imposed top-down by designers. This allows the language to adapt to unforeseen needs and remain relevant as the programming landscape changes.
Hacker News users discuss Guy Steele's "Growing a Language" lecture, focusing on its relevance even decades later. Several commenters praise Steele's insights into language design, particularly his emphasis on evolving languages organically rather than rigidly adhering to initial specifications. The concept of "worse is better" is highlighted, along with a discussion of how seemingly inferior initial designs can sometimes win out due to their adaptability and ease of implementation. The challenge of backward compatibility in evolving languages is also a key theme, with commenters noting the tension between maintaining existing code and incorporating new features. Steele's humor and engaging presentation style are also appreciated. One commenter links to a video of the lecture, while others lament that more modern programming languages haven't fully embraced the principles Steele advocates.
This post provides a brief introduction to fundamental Emacs Lisp concepts. It covers basic data types like numbers, strings, and booleans, explaining how to manipulate them with built-in functions. The post also introduces lists, a crucial data structure in Lisp, showcasing their use in function definitions and data representation. It delves into defining functions with defun, demonstrating argument handling and return values. Finally, the post touches upon special forms like if and let for control flow and variable scoping, ultimately aiming to equip readers with the foundational knowledge needed to understand and write simple Emacs Lisp code.
HN users largely praised the article for its clarity and accessibility in explaining Emacs Lisp fundamentals. Several commenters highlighted its usefulness for beginners, with one calling it the best introduction they'd seen. Some appreciated the focus on practical examples and the author's clear writing style. A few pointed out minor typos or suggested additional topics, like dynamic scoping. One user mentioned using the article as a basis for an Emacs Lisp presentation, further demonstrating its perceived value within the community. The overall sentiment was overwhelmingly positive, indicating the article successfully fills a need for a concise and understandable guide to Emacs Lisp.
The author draws a parallel between blacksmithing and Lisp programming, arguing that both involve a transformative process of shaping raw materials into refined artifacts. Blacksmithing transforms metal through iterative heating, hammering, and cooling, while Lisp uses functions and macros to mold code into elegant and efficient structures. Both crafts require a deep understanding of their respective materials and tools, allowing practitioners to leverage the inherent properties of the medium to create complex and powerful results. This iterative, transformative process, coupled with the flexibility and expressiveness of the tools, fosters a sense of creative flow and empowers practitioners to build exactly what they envision.
Hacker News users discussed the parallels drawn between blacksmithing and Lisp in the linked blog post. Several commenters appreciated the analogy, finding it insightful and resonating with their own experiences in both crafts. Some highlighted the iterative, feedback-driven nature of both, where shaping the material (metal or code) involves constant evaluation and adjustment. Others focused on the power and expressiveness afforded by the tools and techniques of each, allowing for complex and nuanced creations. A few commenters expressed skepticism about the depth of the analogy, arguing that the physicality of blacksmithing introduces constraints and complexities not present in programming. The discussion also touched upon the importance of mastering fundamental skills in any craft, regardless of the tools used.
Autology is a Lisp dialect designed for self-modifying code and introspection. It exposes its own interpreter and data structures, allowing programs to analyze and manipulate their own source code, execution state, and even the interpreter itself during runtime. This capability enables dynamic code generation, on-the-fly modifications, and powerful metaprogramming techniques. It aims to provide a flexible environment for exploring novel programming paradigms and building self-aware, adaptive systems.
HN users generally expressed interest in Autology, a Lisp dialect with access to its own interpreter. Several commenters compared it favorably to Rebol in terms of metaprogramming capabilities. Some discussion focused on its potential use cases, including live coding and creating interactive development environments. Concerns were raised regarding its apparent early stage of development, the lack of documentation beyond the README, and the potential performance implications of its design. A few users questioned the practicality of such a language, while others were excited by the possibilities it presented for self-modifying code and advanced debugging tools. The reliance on Python for its implementation also sparked some debate.
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.
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.
Clojure offers a compelling blend of practicality and powerful abstractions. Its Lisp syntax, while initially daunting, promotes code clarity and conciseness once mastered. Immutability by default simplifies reasoning about code and facilitates concurrency, while the dynamic nature allows for rapid prototyping and interactive development. Leveraging the vast Java ecosystem provides stability and performance, and the focus on functional programming principles encourages robust and maintainable applications. Ultimately, Clojure empowers developers to build complex systems with elegance and efficiency.
HN commenters generally agree with the author's points on Clojure's strengths, particularly its simple, consistent syntax, powerful data structures, and the benefits of immutability and functional programming for concurrency. Some discuss practical advantages in their own work, citing increased productivity and fewer bugs. A few caution that Clojure's unique features have a learning curve and can make debugging more challenging. Others mention Lisp's historical influence and the powerful REPL as key benefits, while some debate the practicality of Clojure's immutability and the ecosystem's reliance on Java. Several commenters highlight Clojure's suitability for specific domains like data processing and web development. There's also discussion around tooling, with some praise for Clojure's tooling and others mentioning room for improvement.
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.
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.
Parinfer simplifies Lisp code editing by automatically managing parentheses, brackets, and indentation. It offers two modes: "Paren Mode," where indentation dictates structure and Parinfer adjusts parentheses accordingly, and "Indent Mode," where parentheses define the structure and Parinfer corrects indentation. This frees the user from manually tracking matching delimiters, allowing them to focus on the code's logic. Parinfer analyzes the code as you type, instantly propagating changes and offering immediate feedback about structural errors, leading to a more fluid and less error-prone coding experience. It's adaptable to different indentation styles and supports various Lisp dialects.
HN users generally praised Parinfer for making Lisp editing easier, especially for beginners. Several commenters shared positive experiences using it with Clojure, noting improvements in code readability and reduced parenthesis-related errors. Some highlighted its ability to infer parentheses placement based on indentation, simplifying structural editing. A few users discussed its potential applicability to other languages, and at least one pointed out its integration with popular editors. However, some expressed skepticism about its long-term benefits or preference for traditional Lisp editing approaches. A minor point of discussion revolved around the tool's name and how it relates to its functionality.
Summary of Comments ( 1 )
https://news.ycombinator.com/item?id=44041515
Hacker News users discuss the paper "The Lisp in the Cellar: Dependent Types That Live Upstairs," focusing on the practicality and implications of its approach to dependent types. Some express skepticism about the claimed performance benefits and question the trade-offs made for compile-time checking. Others praise the novelty of the approach, comparing it favorably to other dependently-typed languages like Idris and highlighting the potential for more efficient and reliable software. A key point of discussion revolves around the use of a "cellar" for runtime values and an "upstairs" for compile-time values, with users debating the elegance and effectiveness of this separation. There's also interest in the language's metaprogramming capabilities and its potential for broader adoption within the functional programming community. Several commenters express a desire to experiment with the language and see further development.
The Hacker News post titled "The Lisp in the Cellar: Dependent Types That Live Upstairs [pdf]" links to a PDF describing a programming language called Deputy. The discussion in the comments section is relatively brief, with a focus on the practicality and implications of the presented ideas.
One commenter expresses skepticism about the overall benefit of dependent types, questioning if the added complexity is worth the effort and if the advantages primarily apply to specific niches like formal verification. They seem to imply that for general-purpose programming, the trade-offs might not be favorable.
Another commenter points out a perceived similarity between Deputy's approach and the concept of gradual typing. They suggest that Deputy seems to be striving for a system where dependent types can be introduced incrementally, allowing developers to choose where and when to apply the stricter typing discipline.
A third comment delves into the technical details of Deputy's type system, highlighting its use of elaboration and normalization. They specifically mention that values are normalized during elaboration, comparing this approach to how Agda, another dependently typed language, handles type checking. They also raise a question about the implementation of large eliminations, a technical aspect related to how dependent types are handled in practice.
Finally, someone notes the irony in the paper's title, "The Lisp in the Cellar: Dependent Types That Live Upstairs," by pointing out that historically, Lisp has often been associated with more academic or advanced programming concepts, while dependent types are now being brought into that same realm. This comment focuses on the shifting perceptions and adoption of these programming paradigms.
While there are other comments, they are largely short expressions of interest, questions about specific technical details, or requests for clarification. The comments summarized above represent the most substantial points of discussion and offer insights into the community's reaction to the Deputy language and its features.