Stories with Tag LSP

• Postgres Language Server: Initial Release

  permalink

  Posted: 2025-03-29 09:13:43

  Verbose tl;dr

  The Postgres Language Server, now in its initial release, brings rich IDE features like auto-completion, hover hints, go-to-definition, and diagnostics to PostgreSQL development. Built using Rust and Tree-sitter, it parses SQL and PL/pgSQL, offering improved developer experience within various code editors and IDEs via the Language Server Protocol (LSP). While still early in its development, the project aims to enhance PostgreSQL coding workflows with intelligent assistance and real-time feedback.

  The Postgres Language Server, now available in its initial release, introduces robust language support for PostgreSQL within various code editors and Integrated Development Environments (IDEs). This server leverages the power of the pg_query library to parse PostgreSQL SQL queries and provide developers with valuable features that enhance productivity and code quality. Specifically, this release supports:

  • Syntax Highlighting: The server color-codes different parts of SQL queries based on their syntactic roles (keywords, identifiers, literals, etc.), improving readability and making it easier to spot syntax errors.
  • Completion Suggestions: As the user types a query, the language server offers context-aware suggestions for keywords, table names, column names, functions, and other database objects. This autocomplete functionality speeds up development and reduces typos.
  • Hover Tooltips: By hovering over a database object (e.g., a table name or function call), the user can access detailed information, including the object's definition, data type, and associated comments, directly within their editor.
  • Go-to Definition: Clicking on a database object allows developers to jump directly to its definition within their project or connected database. This facilitates navigation and understanding of the database schema.
  • Diagnostics and Error Reporting: The language server performs real-time analysis of SQL queries and flags potential errors or inefficiencies, such as syntax errors, misspelled object names, or ambiguous references. This early feedback helps prevent bugs and improves query quality.
  • Formatting: The server can automatically format SQL queries according to predefined style rules, ensuring consistent code formatting across a project.

  Developed by the Supabase community, the Postgres Language Server is implemented in Rust, promising performance and reliability. The project is released under the permissive MIT license, encouraging community contributions and wider adoption. While this initial release represents a significant step forward, the project roadmap outlines plans for future enhancements, including support for more advanced features like query planning insights, refactoring tools, and integration with additional database systems. The project is available for use with various editors and IDEs through language server client extensions, enhancing the development experience for PostgreSQL users.

  • Postgres
  • PostgreSQL
  • Language Server
  • LSP
  • SQL
  • Database
  • IDE
  • Code Completion
  • Syntax Highlighting
  • diagnostics
  • Supabase
  • Open Source
  • Software Development
  • Programming Tools

  Summary of Comments ( 30 )
  https://news.ycombinator.com/item?id=43513996

  Verbose tl;dr

  Hacker News users generally expressed enthusiasm for the Postgres Language Server, praising its potential and the effort put into its development. Some highlighted its usefulness for features like auto-completion, go-to-definition, and hover information within SQL editors. A few commenters compared it favorably to existing tools, suggesting it could be a superior alternative. Others discussed specific desired features, such as integration with pgTAP for testing and improved support for PL/pgSQL. There was also interest in the project's roadmap, with inquiries about planned support for other PostgreSQL features.

  The Hacker News post titled "Postgres Language Server: Initial Release" sparked a discussion with several insightful comments. Many commenters expressed enthusiasm for the project and its potential.

  One commenter highlighted the utility of the language server, especially for features like "go to definition" and autocompletion, noting how helpful these can be when working with complex SQL queries or stored procedures. They emphasized that such tools can significantly improve developer productivity.

  Another user pointed out the increasing demand for and adoption of language servers across different programming ecosystems, positioning this Postgres language server as a valuable addition to this trend. They appreciated the project's contribution to making database development more streamlined.

  A different commenter discussed the challenges of implementing a language server for SQL, mentioning the complexities of parsing SQL dialects correctly. They lauded the project for tackling this difficult task. They also expressed hope for future support of specific database features like functions and procedures, understanding that a robust language server requires handling various database objects.

  Someone shared their positive experience with the language server within their preferred editor, Neovim, coupled with the nvim-lspconfig plugin. They served as a real-world example of the project's practical application.

  The practicality of the language server was further echoed by another commenter who specifically appreciated its assistance with recalling column names, a common pain point in database development.

  A user with a deeper understanding of language servers touched upon the intricacies of the Language Server Protocol (LSP) and its role in facilitating features like autocompletion. They underscored the importance of correctly implementing the LSP specifications for seamless integration with different editors and IDEs.

  Finally, a commenter discussed the potential benefits for users of pgAdmin, a popular Postgres administration tool, suggesting that integration with pgAdmin would significantly enhance its functionality. They envisioned the language server features directly assisting users within the pgAdmin interface.

  Overall, the comments reflect a positive reception of the Postgres Language Server, with users highlighting its potential to enhance productivity, address common database development challenges, and integrate well with existing tooling. Several commenters also expressed anticipation for future developments and wider adoption of the project.

• Inheritance and Subtyping

  permalink

  Posted: 2025-01-29 19:51:12

  Verbose tl;dr

  The blog post "Inheritance and Subtyping" argues that inheritance and subtyping are distinct concepts often conflated, leading to inflexible and brittle code. Inheritance, a mechanism for code reuse, creates a tight coupling between classes, whereas subtyping, focused on behavioral compatibility, allows substitutability. The author advocates for composition over inheritance, suggesting interfaces and delegation as preferred alternatives for achieving polymorphism and code reuse. This approach promotes looser coupling, increased flexibility, and easier maintainability, ultimately leading to more robust and adaptable software design.

  Nicolas Frankel's blog post, "On Inheritance," delves into the nuanced relationship between inheritance and subtyping, arguing that while often conflated, they are distinct concepts that should be treated as such. Frankel begins by establishing the common understanding of inheritance as a mechanism for code reuse, where a subclass inherits properties and methods from its superclass, thereby avoiding redundant code. He acknowledges the convenience this provides, especially in object-oriented programming. However, he proceeds to dissect the potential pitfalls of overusing inheritance for this purpose.

  The core argument revolves around the Liskov Substitution Principle (LSP), a cornerstone of solid object-oriented design. The LSP dictates that objects of a subtype should be substitutable for objects of their supertype without altering the correctness of the program. Frankel emphasizes that adherence to the LSP is crucial for maintaining predictable and reliable software. He illustrates how inheritance solely for code reuse can easily violate the LSP, leading to unexpected behavior and difficult-to-maintain code. Examples are provided demonstrating how seemingly innocuous modifications in a subclass, driven by the desire to reuse code, can inadvertently break the contract established by the superclass, thereby violating the LSP.

  Frankel then introduces the concept of subtyping, contrasting it with inheritance. He posits that subtyping is fundamentally about establishing an "is-a" relationship, where the subtype truly represents a specialized version of the supertype, adhering fully to the supertype's contract. This implies that any behavior expected of the supertype is also guaranteed by the subtype. He argues that while inheritance can be a mechanism for achieving subtyping, it's not the only mechanism, nor does it guarantee subtyping. Other methods, such as composition and interface implementation, can achieve subtyping without the tight coupling inherent in inheritance.

  The blog post further explores the implications of violating the LSP, highlighting the fragility and brittleness it introduces into a codebase. Changes in one part of the system can ripple through seemingly unrelated parts due to the tight coupling created by improper use of inheritance. This fragility hinders maintainability and extensibility, increasing the risk of introducing bugs and making future modifications more complex and time-consuming.

  Frankel concludes by advocating for a more thoughtful approach to inheritance, urging developers to prioritize subtyping and adherence to the LSP over the mere convenience of code reuse. He suggests considering composition and interfaces as alternative mechanisms for achieving code reuse and polymorphism while maintaining the integrity of the type system. The post ultimately champions a design philosophy where inheritance is reserved for situations where a true "is-a" relationship exists, thereby ensuring robust, maintainable, and predictable software.

  • inheritance
  • subtyping
  • object-oriented programming
  • OOP
  • programming
  • Software Development
  • software engineering
  • design patterns
  • Liskov Substitution Principle
  • LSP
  • class hierarchy
  • polymorphism
  • code reuse
  • Software Design

  Summary of Comments ( 17 )
  https://news.ycombinator.com/item?id=42870216

  Verbose tl;dr

  Hacker News users generally agree with the author's premise that inheritance is often misused, especially when subtyping isn't the goal. Several commenters point out that composition and interfaces are generally preferable, offering greater flexibility and avoiding the tight coupling inherent in inheritance. One commenter highlights the "fragile base class problem," where changes in a parent class can unexpectedly break child classes. Others discuss the nuances of Liskov Substitution Principle and how it relates to proper inheritance usage. One user specifically calls out Java's overuse of inheritance, citing the infamous AbstractSingletonProxyFactoryBean. A few dissenting opinions mention that inheritance can be a useful tool when used judiciously, especially in domains like game development where hierarchical relationships are naturally occurring.

  The Hacker News post titled "Inheritance and Subtyping," linking to Nicolas Fränkel's blog post on the same topic, has generated a moderate discussion with several insightful comments. Many of the comments revolve around the nuances of inheritance, subtyping, and composition, and their practical implications in software design.

  One compelling comment thread delves into the Liskov Substitution Principle (LSP) and its importance in ensuring that inheritance is used correctly. Commenters discuss the challenges of adhering to the LSP in real-world scenarios, particularly when dealing with mutable objects and side effects. They highlight the importance of careful consideration when overriding methods and the potential pitfalls of violating the principle, such as unexpected behavior and difficult-to-debug issues. The discussion also touches on the trade-offs between inheritance and composition, suggesting that composition can be a more robust and flexible approach in many cases.

  Another commenter emphasizes the distinction between "is-a" and "has-a" relationships, which are often conflated when discussing inheritance. They argue that inheritance should strictly represent an "is-a" relationship, where the subclass is a true subtype of the superclass, fulfilling all the contracts of the parent class. Using inheritance for code reuse when a "has-a" relationship is more appropriate can lead to brittle and difficult-to-maintain code.

  Several comments explore the idea that inheritance is often misused or overused, leading to complex and tightly coupled systems. They advocate for favoring composition over inheritance as a general principle, arguing that composition provides greater flexibility, modularity, and testability. This perspective aligns with the blog post's argument that inheritance should be used judiciously and only when it truly represents a subtype relationship.

  One commenter offers a practical example of the challenges of inheritance, describing a scenario where a subclass needs to modify the behavior of a superclass method in a way that violates the LSP. They discuss potential workarounds and highlight the complexity that can arise from such situations.

  There's also a discussion on the role of interfaces and abstract classes in facilitating polymorphism and decoupling. Commenters suggest that interfaces, by defining contracts without implementation details, can be a more effective way to achieve polymorphism than inheritance. Abstract classes can be useful for providing default implementations, but should still be used with caution.

  Overall, the comments on the Hacker News post reflect a nuanced understanding of the complexities of inheritance and subtyping. They offer valuable insights into the challenges and best practices associated with these concepts, and provide a platform for a thoughtful discussion on their appropriate use in software design. They generally agree with the author's premise that inheritance should be used sparingly and with careful consideration of the LSP and the "is-a" relationship.