The author details the creation of their own programming language, "Oxcart," driven by dissatisfaction with existing tools for personal projects. Oxcart prioritizes simplicity and explicitness over complex features, aiming for ease of understanding and modification. Key features include a minimal syntax inspired by Lisp, straightforward memory management using a linear allocator and garbage collection, and a compilation process that produces C code for portability. The language is designed specifically for the author's own use case – writing small, self-contained programs – and therefore sacrifices performance and common features for the sake of personal productivity and enjoyment.
Janet's PEG module uses a packrat parsing approach, combining memoization and backtracking to efficiently parse grammars defined in Parsing Expression Grammar (PEG) format. The module translates PEG rules into Janet functions that recursively call each other based on the grammar's structure. Memoization, storing the results of these function calls for specific input positions, prevents redundant computations and significantly speeds up parsing, especially for recursive grammars. When a rule fails to match, backtracking occurs, reverting the input position and trying alternative rules. This process continues until a complete parse is achieved or all possibilities are exhausted. The result is a parse tree representing the matched input according to the provided grammar.
Hacker News users discuss the elegance and efficiency of Janet's PEG implementation, particularly praising its use of packrat parsing for memoization to avoid exponential time complexity. Some compare it favorably to other parsing techniques and libraries like recursive descent parsers and the popular Python library parsimonious, noting Janet's approach offers a good balance of performance and understandability. Several commenters express interest in exploring Janet further, intrigued by its features and the clear explanation provided in the linked article. A brief discussion also touches on error reporting in PEG parsers and the potential for improvements in Janet's implementation.
Xee is a new XPath and XSLT engine written in Rust, focusing on performance, security, and WebAssembly compatibility. It aims to be a modern alternative to existing engines, offering a safe and efficient way to process XML and HTML in various environments, including browsers and servers. Leveraging Rust's ownership model and memory safety features, Xee minimizes vulnerabilities like use-after-free errors and buffer overflows. Its WebAssembly support enables client-side XML processing without relying on JavaScript, potentially improving performance and security for web applications. While still under active development, Xee already supports a substantial portion of the XPath 3.1 and XSLT 3.0 specifications, with plans to implement streaming transformations and other advanced features in the future.
HN commenters generally praise Xee's speed and the author's approach to error handling. Several highlight the impressive performance benchmarks compared to libxml2, with some noting the potential for Xee to become a valuable tool in performance-sensitive XML processing scenarios. Others appreciate the clean API design and Rust's memory safety advantages. A few discuss the niche nature of XPath/XSLT in modern development, while some express interest in using Xee for specific tasks like web scraping and configuration parsing. The Rust implementation also sparked discussions about language choices for performance-critical applications. Several users inquire about WASM support, indicating potential interest in browser-based applications.
A critical vulnerability was discovered impacting multiple SAML single sign-on (SSO) libraries across various programming languages. This vulnerability stemmed from inconsistencies in how different XML parsers interpret and handle XML signatures within SAML assertions. Attackers could exploit these "parser differentials" by crafting malicious SAML responses where the signature appeared valid to the service provider's parser but actually signed different data than what the identity provider intended. This allowed attackers to potentially impersonate any user, gaining unauthorized access to systems protected by vulnerable SAML implementations. The blog post details the vulnerability's root cause, demonstrates exploitation scenarios, and lists the affected libraries and their patched versions.
Hacker News commenters discuss the complexity of SAML and the difficulty of ensuring consistent parsing across different implementations. Several point out that this vulnerability highlights the inherent fragility of relying on complex, XML-based standards like SAML, especially when multiple identity providers and service providers are involved. Some suggest that simpler authentication methods would be less susceptible to such parsing discrepancies. The discussion also touches on the importance of security audits and thorough testing, particularly for critical systems relying on SSO. A few commenters expressed surprise that such a vulnerability could exist, highlighting the subtle nature of the exploit. The overall sentiment reflects a concern about the complexity and potential security risks associated with SAML implementations.
C Plus Prolog is a project that embeds a Prolog interpreter within C++ code, allowing for logic programming within a C++ application. It aims to provide a seamless integration where Prolog predicates can be called directly from C++ and vice-versa, enabling the combination of Prolog's declarative power with C++'s performance and imperative features. The project leverages a modified version of SWI-Prolog, a popular open-source Prolog implementation, and offers a bidirectional interface for data exchange between the two languages. This facilitates the development of applications that benefit from both efficient procedural code and the logical reasoning capabilities of Prolog.
Hacker News users discussed the practicality and niche appeal of C Plus Prolog. Some expressed interest in its potential for specific applications like implementing rule engines or program analysis tools, while others questioned the performance implications of embedding Prolog within C++. One commenter suggested that a cleaner approach might involve interfacing Prolog with a language like Rust. Several pointed out the project's age and apparent inactivity, raising concerns about maintainability and documentation. The potential for improved tooling using C++-based IDEs was mentioned as a possible benefit. Overall, the discussion centered around the specialized nature of the project and the trade-offs involved in its approach.
The author seeks a C-like language with modern features like generics, modules, and memory safety, while maintaining C's performance and close-to-the-metal nature. They desire a language suitable for systems programming, potentially as a replacement for C in performance-critical applications, but with the added benefits of contemporary language design. They are exploring if such a language already exists or whether retrofitting C would be a more viable approach. Essentially, they want the power and control of C without its inherent pitfalls and limitations.
The Hacker News comments discuss the practicality and potential benefits of a "retrofitted" C dialect, primarily focusing on memory safety. Some suggest exploring existing options like Zig, Rust, or Odin, which already address many of C's shortcomings. Others express skepticism about the feasibility of such a project, citing the complexity of C's ecosystem and the difficulty of maintaining compatibility while introducing significant changes. A few commenters propose specific improvements, such as optional garbage collection or stricter type checking, but acknowledge the challenges in implementation and adoption. There's a general agreement that memory safety is crucial, but opinions diverge on whether a new dialect or focusing on tooling and better practices within existing C is the best approach. Some also discuss the potential benefits for embedded systems, where C remains dominant.
Ohm is a parsing toolkit designed for creating parsers in JavaScript and TypeScript that are both powerful and easy to use. It features a grammar definition syntax closely resembling EBNF, enabling developers to express complex syntax rules clearly and concisely. Ohm's built-in support for semantic actions allows users to directly embed JavaScript or TypeScript code within their grammar rules, simplifying the process of building abstract syntax trees (ASTs) and performing other actions during parsing. The toolkit provides excellent error reporting capabilities, helping developers quickly identify and fix syntax errors. Its flexible architecture makes it suitable for various applications, from validating user input to building full-fledged compilers and interpreters.
HN users generally expressed interest in Ohm, praising its user-friendliness, clear documentation, and the power offered by its grammar-based approach to parsing. Several compared it favorably to traditional parser generators like PEG.js and nearley, highlighting Ohm's superior error messages and easier learning curve. Some users discussed potential applications, including building linters, formatters, and domain-specific languages. A few questioned the performance implications of its JavaScript implementation, while others suggested potential improvements like adding support for left-recursive grammars. The overall sentiment leaned positive, with many eager to try Ohm in their own projects.
"Trails of Wind" is a generative art project exploring the visualization of wind currents. Using weather data, the artwork dynamically renders swirling lines that represent the movement and direction of wind across a global map. The piece allows viewers to observe complex patterns and the interconnectedness of global weather systems, offering an aesthetic interpretation of otherwise invisible natural forces. The project emphasizes the ever-shifting nature of wind, resulting in a constantly evolving artwork.
HN users largely praised the visual aesthetic and interactive elements of "Trails of Wind," describing it as mesmerizing, beautiful, and relaxing. Some appreciated the technical aspect, noting the clever use of WebGL and shaders. Several commenters pointed out the similarity to the older "wind map" visualizations, while others drew comparisons to other flow visualizations and generative art pieces. A few users wished for additional features like zooming, different data sources, or adjustable parameters. One commenter raised the concern about the project's longevity and the potential for the underlying data source to disappear.
Mukul Rathi details his journey of creating a custom programming language, focusing on the compiler construction process. He explains the key stages involved, from lexing (converting source code into tokens) and parsing (creating an Abstract Syntax Tree) to code generation and optimization. Rathi uses his language, which he implements in OCaml, to illustrate these concepts, providing code examples and explanations of how each component works together to transform high-level code into executable machine instructions. He emphasizes the importance of understanding these foundational principles for anyone interested in building their own language or gaining a deeper appreciation for how programming languages function.
Hacker News users generally praised the article for its clarity and accessibility in explaining compiler construction. Several commenters appreciated the author's approach of building a complete, albeit simple, language instead of just a toy example. Some pointed out the project's similarity to the "Let's Build a Compiler" series, while others suggested alternative or supplementary resources like Crafting Interpreters and the LLVM tutorial. A few users discussed the tradeoffs between hand-written lexers/parsers and using parser generator tools, and the challenges of garbage collection implementation. One commenter shared their personal experience of writing a language and the surprising complexity of seemingly simple features.
"Zork: The Great Inner Workings" explores the technical underpinnings of the classic text adventure game, Zork. The article dives into its creation using the MDL programming language, highlighting its object-oriented design before such concepts were widespread. It explains how Zork's world is represented through a network of interconnected rooms and objects, managed through a sophisticated parser that interprets player commands. The piece also touches upon the game's evolution from its mainframe origins to its later commercial releases, illustrating how its internal structure allowed for complex interactions and a rich, immersive experience despite the limitations of text-based gaming.
Hacker News users discuss the technical ingenuity of Zork's implementation, particularly its virtual machine and memory management within the limited hardware constraints of the time. Several commenters reminisce about playing Zork and other Infocom games, highlighting the engaging narrative and parser. The discussion also touches on the cultural impact of Zork and interactive fiction, with mentions of its influence on later games and the enduring appeal of text-based adventures. Some commenters delve into the inner workings described in the article, appreciating the explanation of the Z-machine and its portability. The clever use of dynamic memory allocation and object representation is also praised.
The article explores rule-based programming as a powerful, albeit underutilized, approach to creating interactive fiction. It argues that defining game logic through a set of declarative rules, rather than procedural code, offers significant advantages in terms of maintainability, extensibility, and expressiveness. This approach allows for more complex interactions and emergent behavior, as the game engine processes the rules to determine outcomes, rather than relying on pre-scripted sequences. The author advocates for a system where rules define relationships between objects and actions, enabling dynamic responses to player input and fostering a more reactive and believable game world. This, they suggest, leads to a more natural feeling narrative and simpler development, especially for managing complex game states.
HN users discuss the merits and drawbacks of rule-based programming for interactive fiction, specifically in Inform 7. Some argue that while appearing simpler initially, rule-based systems can become complex and difficult to debug as interactions grow, leading to unpredictable behavior. Others appreciate the declarative nature and find it well-suited for IF's logic, particularly for handling complex scenarios with many objects and states. The potential performance implications of a rule-based engine are also raised. Several commenters express nostalgia for older IF systems and debate the balance between authoring complexity and expressive power offered by different programming paradigms. A recurring theme is the importance of choosing the right tool for the job, acknowledging that rule-based approaches might be ideal for some types of IF but not others. Finally, some users highlight the benefits of declarative programming for expressing relationships and constraints clearly.
This blog post explores a simplified variant of Generalized LR (GLR) parsing called "right-nulled" GLR. Instead of maintaining a graph-structured stack during parsing ambiguities, this technique uses a single stack and resolves conflicts by prioritizing reduce actions over shift actions. When a conflict occurs, the parser performs all possible reductions before attempting to shift. This approach sacrifices some of GLR's generality, as it cannot handle all types of grammars, but it significantly reduces the complexity and overhead associated with maintaining the graph-structured stack, leading to a faster and more memory-efficient parser. The post provides a conceptual overview, highlights the limitations compared to full GLR, and demonstrates the algorithm with a simple example.
Hacker News users discuss the practicality and efficiency of GLR parsing, particularly in comparison to other parsing techniques. Some commenters highlight its theoretical power and ability to handle ambiguous grammars, while acknowledging its potential performance overhead. Others question its suitability for real-world applications, suggesting that simpler methods like PEG or recursive descent parsers are often sufficient and more efficient. A few users mention specific use cases where GLR parsing shines, such as language servers and situations requiring robust error recovery. The overall sentiment leans towards appreciating GLR's theoretical elegance but expressing reservations about its widespread adoption due to perceived complexity and performance concerns. A recurring theme is the trade-off between parsing power and practical efficiency.
Summary of Comments ( 104 )
https://news.ycombinator.com/item?id=43970800
Hacker News users generally praised the author's approach of building a language tailored to their specific needs. Several commenters highlighted the value of this kind of "scratch your own itch" project for deepening one's understanding of language design and implementation. Some expressed interest in the specific features mentioned, like pattern matching and optional typing. A few cautionary notes were raised regarding the potential for over-engineering and the long-term maintenance burden of a custom language. However, the prevailing sentiment supported the author's exploration, viewing it as a valuable learning experience and a potential solution for a niche use case. Some discussion also revolved around existing languages that offer similar features, suggesting the author might explore those before committing to a fully custom implementation.
The Hacker News post titled "A programming language made for me" (linking to zylinski.se/posts/a-programming-language-for-me/) generated a moderate amount of discussion, with several commenters engaging with the author's approach to language design.
Several commenters praised the author for taking the initiative to build a language tailored to their specific needs and workflow. They saw this as a valuable exercise in understanding language design principles and appreciated the author's willingness to share their process and rationale. Some saw it as a refreshing alternative to constantly adapting to existing languages that might not perfectly fit a particular problem domain.
A recurring theme in the comments was the tension between creating a language specifically for personal use versus designing one for a wider audience. Some argued that hyper-specialization could limit the language's applicability and hinder collaboration, while others emphasized the benefits of prioritizing individual productivity and enjoyment. One commenter suggested that starting with a personal focus could be a good first step, potentially evolving into a more general-purpose language later on.
There was also discussion around the practicality of maintaining and evolving a personal language. Some commenters questioned the long-term viability of such projects, highlighting the potential challenges of debugging, tooling, and documentation. Concerns were raised about the "bus factor" – the risk of the project becoming unsustainable if the sole developer becomes unavailable.
Technical aspects of the language itself were also discussed, with some commenters offering specific feedback and suggestions. Topics included the choice of syntax, the implementation of certain features, and the potential benefits of incorporating existing language constructs or libraries. One commenter recommended exploring existing niche languages that might already address some of the author's needs.
Finally, some commenters drew parallels to other projects where individuals had created custom tools or languages to solve specific problems, emphasizing the empowering nature of such endeavors. They highlighted the potential for personal projects to lead to unexpected insights and innovations.