This project introduces "SHORTY," a C++ utility that aims to make lambdas more concise. It achieves this by providing a macro-based system that replaces standard lambda syntax with a shorter, more symbolic representation. Essentially, SHORTY allows developers to define and use lambdas with fewer characters, potentially improving code readability in some cases by reducing boilerplate. However, this comes at the cost of relying on macros and introducing a new syntax that deviates from standard C++. The project documentation argues that the benefits in brevity outweigh the costs for certain use cases.
Marijn Haverbeke's 2012 JS1k winning entry, "Bouncing Beholder," is a concise JavaScript demo that fits within 1 kilobyte. It features a 3D rendering of the iconic Beholder monster from Dungeons & Dragons, smoothly rotating and bouncing off the edges of the canvas. The demo utilizes clever optimizations and mathematical shortcuts to achieve the 3D effect and animation within the tight size constraint, showcasing efficient coding and creative use of limited resources.
Commenters on Hacker News largely praised the "Bouncing Beholder" demo for its impressive technical achievement within the 1k size limit. Several noted the clever use of techniques like sine waves and bitwise operations to create the animation and sound effects. Some recalled the nostalgic appeal of demoscene culture and the technical ingenuity it fostered. A few discussed the evolution of JavaScript and browser capabilities since 2012, highlighting how challenging such a demo would have been at the time. The creator even chimed in to answer questions about the development process and optimization tricks used, sharing further insight into the intricacies of the code.
The blog post showcases an incredibly compact WebAssembly compiler written in just a single tweet's worth of JavaScript code. This compiler takes a simplified subset of C code as input and directly outputs the corresponding WebAssembly binary format. It leverages JavaScript's ability to create typed arrays representing the binary structure of a .wasm
file. While extremely limited in functionality (only supporting basic integer arithmetic and a handful of operations), it demonstrates the core principles of converting higher-level code to WebAssembly, offering a concise and educational example of how a compiler operates at its most fundamental level. The author emphasizes this isn't a practical compiler, but rather a fun exploration of code golfing and a digestible introduction to WebAssembly concepts.
Hacker News users generally expressed appreciation for the conciseness and elegance of the WebAssembly compiler presented in the tweet. Several commenters pointed out that while impressive, the compiler is limited and handles only a small subset of WebAssembly. Some discussed the potential educational value of such a minimal example, while others debated the practicality and performance implications. A few users delved into technical details, analyzing the specific instructions and optimizations used. The overall sentiment leaned towards admiration for the technical achievement, tempered with an understanding of its inherent limitations.
Justine Tunney's "Lambda Calculus in 383 Bytes" presents a remarkably small, self-hosting Lambda Calculus interpreter written in x86-64 assembly. It parses, evaluates, and prints lambda expressions, supporting variables, application, and abstraction using a custom encoding. Despite its tiny size, the interpreter implements a complete, albeit slow, evaluation strategy by translating lambda terms into De Bruijn indices and employing normal order reduction. The project showcases the minimal computational requirements of lambda calculus and the power of concise, low-level programming.
Hacker News users discuss the cleverness and efficiency of the 383-byte lambda calculus implementation, praising its conciseness and educational value. Some debate the practicality of such a minimal implementation, questioning its performance and highlighting the trade-offs made for size. Others delve into technical details, comparing it to other small language implementations and discussing optimization strategies. Several comments point out the significance of understanding lambda calculus fundamentals and appreciate the author's clear explanation and accompanying code. A few users express interest in exploring similar projects and adapting the code for different architectures. The overall sentiment is one of admiration for the technical feat and its potential as a learning tool.
Summary of Comments ( 14 )
https://news.ycombinator.com/item?id=43629380
HN users largely discussed the potential downsides of Shorty, a C++ library for terser lambdas. Concerns included readability and maintainability suffering due to excessive brevity, especially for those unfamiliar with the library. Some argued against introducing more cryptic syntax to C++, preferring explicitness over extreme conciseness. Others questioned the practical benefits, suggesting existing lambda syntax is sufficient and the library's complexity outweighs its advantages. A few commenters expressed mild interest, acknowledging the potential for niche use cases but emphasizing the importance of careful consideration before widespread adoption. Several also debated the library's naming conventions and overall design choices.
The Hacker News post discussing the "shorty" C++ header for terser lambdas generated a moderate amount of discussion, mostly focused on the potential downsides and alternatives to the approach.
Several commenters expressed concern over the readability and maintainability of code using
shorty
. One commenter argued that while brevity can be good, excessive terseness can harm readability, especially for those unfamiliar with theshorty
syntax. They suggested that the potential gains in character count are outweighed by the increased cognitive load required to understand the code. Another user echoed this sentiment, pointing out that C++ is already a complex language, and adding more cryptic syntax likeshorty
further exacerbates the issue. They questioned the real-world benefit, suggesting that saving a few keystrokes is not worth the potential confusion.The discussion also touched upon the potential for namespace pollution and name clashes. One commenter pointed out the risk of unintended consequences when using generic short names like those provided by
shorty
, especially in larger projects. They suggested that more descriptive lambda names, even if longer, are generally preferable for clarity.Alternatives to
shorty
were also proposed. One user mentioned using an editor snippet or macro to achieve similar brevity without introducing new syntax. Another suggested leveraging existing C++ features likeauto
and structured bindings to simplify code without sacrificing readability. A commenter highlighted the benefits of refactoring complex logic into separate functions, thereby reducing the need for lengthy lambdas in the first place. They argued this approach often leads to more organized and understandable code.A few comments briefly acknowledged the potential usefulness of
shorty
in specific, limited contexts, such as competitive programming or code golfing, where character count is paramount. However, the general consensus seemed to be that for most practical applications, the potential drawbacks ofshorty
outweigh its benefits. There was a clear preference for maintaining code clarity and readability over achieving extreme terseness.