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.
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.
Mark Rosenfelder's "The Language Construction Kit" offers a practical guide for creating fictional languages, emphasizing naturalistic results. It covers core aspects of language design, including phonology (sounds), morphology (word formation), syntax (sentence structure), and the lexicon (vocabulary). The book also delves into writing systems, sociolinguistics, and the evolution of languages, providing a comprehensive framework for crafting believable and complex constructed languages. While targeted towards creating languages for fictional worlds, the kit also serves as a valuable introduction to linguistics itself, exploring the underlying principles governing real-world languages.
Hacker News users discuss the Language Construction Kit, praising its accessibility and comprehensiveness for beginners. Several commenters share nostalgic memories of using the kit in their youth, sparking their interest in linguistics and constructed languages. Some highlight specific aspects they found valuable, such as the sections on phonology and morphology. Others debate the kit's age and whether its information is still relevant, with some suggesting updated resources while others argue its core principles remain valid. A few commenters also discuss the broader appeal and challenges of language creation.
Par is a new programming language designed for exploring and understanding concurrency. It features a built-in interactive playground that visualizes program execution, making it easier to grasp complex concurrent behavior. Par's syntax is inspired by Go, emphasizing simplicity and readability. The language utilizes goroutines and channels for concurrency, offering a practical way to learn and experiment with these concepts. While currently focused on concurrency education and experimentation, the project aims to eventually expand into a general-purpose language.
Hacker News users discussed Par's simplicity and suitability for teaching concurrency concepts. Several praised the interactive playground as a valuable tool for visualization and experimentation. Some questioned its practical applications beyond educational purposes, citing limitations compared to established languages like Go. The creator responded to some comments, clarifying design choices and acknowledging potential areas for improvement, such as error handling. There was also a brief discussion about the language's syntax and comparisons to other visual programming tools.
This proposal introduces an effect system to C2x, aiming to enhance code modularity, optimization, and correctness by explicitly declaring and checking the side effects of functions. It defines a set of effect keywords, like reads and writes, to annotate function parameters and return values, indicating how they are accessed. These annotations are part of the function's type and are checked by the compiler, ensuring that declared effects match the function's actual behavior. The proposal also includes a mechanism for polymorphism over effects, enabling more flexible code reuse and separate compilation without sacrificing effect safety. This mechanism allows for abstracting over effects, so that functions can be written generically to operate on data structures with varying levels of mutability.
The Hacker News comments on the C2y effect system proposal express a mix of skepticism and cautious interest. Several commenters question the practicality and performance implications of implementing such a system in C, citing the language's existing complexity and the potential for significant overhead. Concerns are raised about the learning curve for developers and the possibility of introducing subtle bugs. Some find the proposal intriguing from a research perspective but doubt its widespread adoption. A few express interest in exploring the potential benefits of improved code analysis and error detection, particularly for concurrency and memory management, though acknowledge the challenges involved. Overall, the consensus leans towards viewing the proposal as an interesting academic exercise with limited real-world applicability in its current form.
Summary of Comments ( 16 )
https://news.ycombinator.com/item?id=43137171
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.
The Hacker News post "Ask HN: A retrofitted C dialect?" sparked a discussion with several interesting comments. The original poster was inquiring about the feasibility and potential benefits of creating a C dialect that incorporates modern language features while maintaining compatibility with existing C codebases.
Several commenters pointed out existing projects that attempt to address similar goals. One commenter mentioned Zig, highlighting its focus on being a simpler and more predictable systems programming language compared to C. They emphasized Zig's compile-time execution capabilities and how they can be used to generate optimized code. Another commenter brought up Beef, a language that transpiles to C, emphasizing its goal of adding higher-level features to C development. C2 was also mentioned as a language attempting to improve on C while remaining close to its core principles.
A common theme in the discussion revolved around the complexities and potential pitfalls of trying to "fix" C. One commenter argued that many of the perceived problems with C stem from programmers misusing the language rather than inherent flaws in the language itself. They suggested that focusing on better education and tooling might be a more effective approach than creating a new dialect.
Another commenter questioned the practical benefits of a retrofitted C dialect, arguing that the effort required to create and maintain such a language might outweigh the advantages gained. They also pointed out the challenges of ensuring compatibility with the vast existing C ecosystem.
Some commenters discussed specific features they would like to see in a modernized C dialect, such as improved memory management, better error handling, and more robust type safety. The discussion also touched upon the trade-offs between performance and safety, with some arguing that C's performance characteristics are a key reason for its continued relevance.
Overall, the comments reflect a mix of enthusiasm for the potential of a modernized C dialect and skepticism about its practicality. Several existing projects were highlighted as potential solutions, and the discussion explored various technical challenges and design considerations related to creating such a language.