This post explores a shift in thinking about programming languages from individual entities to sets or families of languages. Instead of focusing on a single language's specific features, the author advocates for considering the shared characteristics and relationships between languages within a broader group. This approach involves recognizing core concepts and abstractions that transcend individual syntax, allowing for easier transfer of knowledge and the development of tools that can operate across multiple languages within a set. The author uses examples like the ML language family and the Lisp dialects to illustrate how shared underlying principles can unify seemingly disparate languages, leading to a more powerful and adaptable approach to programming.
This blog post, titled "From Languages to Language Sets," delves into the intricacies of language server protocol (LSP) implementation and the challenges faced when attempting to support multiple programming languages concurrently within a single editor or Integrated Development Environment (IDE). The author meticulously outlines the progression of their thought process and the evolution of their approach to this multifaceted problem. They begin by describing the initial, naive approach of simply including distinct language servers for each individual language they desired to support. This straightforward method, while conceptually simple, quickly reveals its shortcomings due to the substantial resource consumption and performance overhead associated with running multiple servers simultaneously, particularly as the number of supported languages grows.
The author then transitions to exploring a more sophisticated solution involving the development of a "language server multiplexer," or language set server. This server acts as a central intermediary, intelligently routing requests from the client (the editor or IDE) to the appropriate language server based on the context of the request, such as the file type or programming language being edited. This architectural shift brings about several advantages. First, it reduces the resource footprint by avoiding the need to run all language servers concurrently. Only the necessary servers are activated based on the active project or files being edited. Second, it simplifies the client-side implementation by providing a unified interface for interacting with multiple language servers. The client no longer needs to be aware of the individual servers or manage their lifecycle. Instead, it interacts solely with the multiplexer, which handles the complexities of server selection and communication.
The post proceeds to elaborate on the implementation details of this multiplexer, explaining how it determines the correct language server to invoke based on the file extension and other relevant contextual information. The author carefully articulates the process of mapping file extensions to specific language servers and highlights the flexibility afforded by this approach. This adaptable mapping system allows for easy addition and removal of language support without requiring significant changes to the core architecture. Furthermore, the author discusses the nuances of handling requests for files with ambiguous or unsupported file extensions, ensuring graceful degradation of functionality in such scenarios.
Finally, the post concludes by reflecting on the benefits and drawbacks of the proposed language set server approach. It reiterates the advantages of reduced resource consumption, simplified client-side integration, and improved maintainability. The author also acknowledges potential limitations, such as the added complexity of implementing and maintaining the multiplexer itself. However, they ultimately argue that the benefits outweigh the costs, particularly in scenarios where support for a wide array of programming languages is a critical requirement. The overall message underscores the importance of thoughtful architectural design when building complex systems like language servers and emphasizes the value of moving beyond simplistic solutions to achieve greater efficiency and scalability.
Summary of Comments ( 20 )
https://news.ycombinator.com/item?id=43360287
The Hacker News comments discuss the concept of "language sets" introduced in the linked gist. Several commenters express skepticism about the practical value and novelty of the idea, questioning whether it genuinely offers advantages over existing programming paradigms like macros, polymorphism, or code generation. Some find the examples unconvincing and overly complex, suggesting simpler solutions could achieve the same results. Others point out potential performance implications and the added cognitive load of managing language sets. However, a few commenters express interest, seeing potential applications in areas like DSL design and metaprogramming, though they also acknowledge the need for further development and clearer examples to demonstrate its usefulness. Overall, the reception is mixed, with many unconvinced but a few intrigued by the possibilities.
The Hacker News post "From Languages to Language Sets" sparks a discussion around the linked gist, which proposes the idea of "language sets" – combining multiple programming languages for different parts of a project based on their strengths. The comments section is moderately active, containing a mix of agreement, disagreement, and explorations of related concepts.
Several commenters express enthusiasm for the idea, highlighting the potential benefits of using specialized languages for specific tasks. One commenter points out how this approach mirrors existing practices, such as using SQL for database interactions within a larger application written in a different language. They argue that explicitly recognizing and formalizing these "language sets" could lead to better tool development and more structured project organization. Another commenter emphasizes the productivity gains that could be achieved by choosing the right language for each job, rather than being constrained by a single language's limitations. They also suggest that improved tooling around language sets could simplify the process of integrating different languages.
Others express skepticism or raise concerns. One commenter questions the novelty of the idea, suggesting that it simply describes the status quo of using multiple languages within a project. They argue that the term "language set" doesn't add much to the existing understanding of polyglot programming. Another commenter raises the issue of increased complexity when managing multiple languages, particularly regarding tooling, debugging, and team communication. They acknowledge the potential benefits but caution against overlooking the practical challenges.
The discussion also delves into related topics. One commenter mentions the concept of "internal DSLs" (Domain-Specific Languages) and suggests that creating small, specialized languages within a larger project could be a more effective alternative to full-blown language sets. Another commenter draws parallels to the microservices architecture pattern, arguing that language sets could be seen as a similar approach applied to programming languages rather than services.
Overall, the comments reflect a mixed reception to the idea of "language sets." While some see it as a valuable way to formalize and improve existing polyglot programming practices, others question its novelty and express concerns about increased complexity. The discussion also touches upon related concepts like internal DSLs and microservices, enriching the conversation around the central theme of choosing the right tools for the job.