Stories with Tag live coding

• Graphics livecoding in Common Lisp

  permalink

  Posted: 2025-04-23 17:48:20

  Verbose tl;dr

  The blog post details the author's process of livecoding graphics in Common Lisp using a combination of Quicklisp libraries, specifically cl-cairo2 and Qtools. They leverage the REPL's interactive nature to rapidly iterate and experiment with visual elements, modifying code and seeing immediate results in a Cairo graphics window. The author explains their setup and workflow, emphasizing the advantages of Lisp's dynamic environment for this type of creative coding, showcasing how functions can be redefined and tweaked on-the-fly to manipulate shapes, colors, and other graphical parameters. This approach allows for a fluid and exploratory development experience, turning the coding process itself into a performative act.

  Kevin Gal's blog post, "Graphics livecoding in Common Lisp," details his exploration and implementation of a livecoding environment for generating visuals using Common Lisp. He begins by outlining the core concept of livecoding, where code modifications instantaneously affect the output, creating a dynamic feedback loop that fosters creative exploration and experimentation. He emphasizes the appeal of this real-time interaction for artistic endeavors, particularly within the realm of generative art.

  Gal proceeds to describe his chosen tools and approach. He leverts Common Lisp's dynamic nature and the Quicklisp library manager for rapid prototyping and iteration. Specifically, he employs the CEPL library along with SDL2 and OpenGL for rendering graphics. CEPL's particular strength lies in its ability to redefine functions on-the-fly, a crucial feature for achieving the seamless updates characteristic of livecoding. This allows him to modify the code defining the visuals while the program is running, seeing the changes reflected immediately in the output window.

  The post then delves into the technical details of his setup. He explains how he structures his Lisp code, using a combination of functions and global variables to manage the graphical elements. He also details how he uses CEPL to redefine functions, effectively "hot-patching" the running program with new code as he types it. He highlights the benefits of Common Lisp's interactive development environment, such as the REPL, for facilitating this livecoding workflow.

  The author then shares practical examples and demonstrations of his livecoding process. He showcases how he can manipulate shapes, colors, and animations in real-time by modifying the Lisp code. He walks through the process of building up a visual scene incrementally, tweaking parameters and functions on-the-fly to achieve the desired aesthetic effect. This allows him to explore different visual possibilities quickly and intuitively, taking advantage of the immediate feedback provided by the livecoding environment.

  Finally, Gal reflects on his experience and future directions. He expresses his satisfaction with the responsiveness and flexibility of his livecoding setup, noting how it empowers him to create generative art in a more fluid and interactive manner. He also discusses potential improvements and extensions, including exploring different rendering libraries and integrating sound generation into the livecoding workflow. He closes by emphasizing the potential of Common Lisp as a powerful tool for creative coding and live performance.

  • Common Lisp
  • live coding
  • Graphics Programming
  • computer graphics
  • Lisp
  • Creative Coding
  • Visualization
  • Real-time Graphics
  • programming
  • Software Development

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

  Verbose tl;dr

  HN users generally praised the author's technical skill and the visual appeal of the live coding demo. Some expressed interest in learning more about Common Lisp and the specific libraries used. A few commenters discussed the practical applications of live coding graphics, suggesting uses in game development, generative art, and data visualization. One commenter pointed out the potential accessibility issues related to color choices in the examples. Another highlighted the historical precedent of Lisp machines and their graphical capabilities, connecting the demo to that lineage. The perceived complexity of Common Lisp was also mentioned, with some users acknowledging its steep learning curve but also its power and flexibility.

  The Hacker News post titled "Graphics livecoding in Common Lisp," linking to Kevin Gal's blog post about livecoding graphics in Common Lisp, has generated a moderate amount of discussion with a number of insightful comments.

  Several commenters express enthusiasm for the elegance and power of Common Lisp for this kind of work, particularly its interactive development environment and the REPL. One commenter highlights the "joy" of using Lisp for livecoding, contrasting it favorably with other languages. Another commenter specifically praises the ability to redefine functions on-the-fly without restarting the application, a key feature enabling livecoding.

  The discussion touches upon the specific libraries and tools used by the author, including CEPL, SLY, and Quicklisp. Commenters share their experiences with these tools and offer alternative suggestions. One commenter suggests using a library like cl-cairo2 for 2D drawing or a game library like Trial for a potentially smoother experience. Another commenter mentions using similar setups with Common Lisp and OpenGL for 3D graphics programming.

  Some commenters delve into the technical details of livecoding and image processing, discussing double-buffering techniques and how to handle window resizing events. One commenter specifically mentions a technique of using a dedicated thread for rendering to avoid blocking the main thread during intensive graphical operations.

  A couple of comments reflect on the historical context of Lisp and its influence on other livecoding environments, including Smalltalk. One comment points out the rich history of Lisp machines and their emphasis on interactive programming, which paved the way for modern livecoding techniques.

  The comments also branch into related areas, such as generative art and music, and the potential of Common Lisp for creating these types of interactive experiences.

  While the general tone is positive and appreciative of the author's work, there are a few constructive criticisms. One comment notes the potential performance bottlenecks of Common Lisp for graphics-intensive applications and suggests exploring other languages or libraries for optimization. Another comment points out the relative niche status of Common Lisp in the contemporary programming landscape, which may limit its adoption for livecoding graphics.

  Overall, the comment section provides valuable insights and perspectives on livecoding graphics with Common Lisp, touching upon both its advantages and its potential limitations. The commenters' collective knowledge and experience enrich the discussion and offer valuable pointers for anyone interested in exploring this area further.

• Discovery Coding

  permalink

  Posted: 2025-01-29 00:53:30

  Verbose tl;dr

  Discovery Coding is a software development approach prioritizing exploration and experimentation over rigid upfront planning. It emphasizes building small, functional prototypes to rapidly test ideas and gain a deeper understanding of the problem domain. This iterative process allows for continuous learning and adaptation, enabling developers to discover the best solutions organically, rather than being constrained by initial assumptions. The core principle is to treat coding as a tool for investigation, using it to uncover insights and refine the direction of the project as development progresses. This approach embraces uncertainty and recognizes that the best path forward often emerges through experimentation and discovery.

  The blog post "Discovery Coding" by Jimmy Miller articulates a distinct approach to software development that prioritizes exploration and iterative refinement over meticulous upfront planning. Miller argues against the conventional waterfall model, which emphasizes rigid sequential phases of requirements gathering, design, implementation, testing, and deployment. He posits that this traditional method often fails to account for the inherent uncertainties and evolving nature of software projects, leading to mismatches between envisioned solutions and actual user needs.

  Instead, Miller advocates for a more agile and adaptive methodology he terms "Discovery Coding." This approach champions the idea of embarking on coding activities relatively early in the project lifecycle, not as a means of immediately constructing the final product, but rather as a tool for discovering and clarifying the problem space itself. Through the act of writing code, experimenting with different approaches, and confronting technical constraints, developers gain a deeper understanding of the challenges and opportunities inherent in the project. This iterative process of building, testing, and learning allows for the emergence of more robust and well-informed solutions that genuinely address user requirements.

  Discovery Coding, according to Miller, embraces the notion of building "throw-away code"—prototypes and experimental implementations that are not intended for production but serve as valuable learning instruments. These exploratory coding endeavors help uncover hidden complexities, validate assumptions, and refine the overall design. This iterative experimentation enables developers to make more informed decisions about the final implementation, ultimately leading to a more effective and user-centered product. The process is akin to sculpting, where the artist chips away at the raw material, progressively revealing the final form through continuous refinement.

  Miller emphasizes that Discovery Coding is not synonymous with haphazard or unstructured development. While it encourages flexibility and exploration, it still requires careful consideration of architectural principles and maintainability. The key distinction lies in the willingness to adapt and iterate based on the insights gained during the discovery process. This adaptability allows for course correction and optimization throughout the development lifecycle, leading to a more resilient and well-suited final product. Essentially, Discovery Coding prioritizes learning through experimentation and embraces the inherent fluidity of the software development process.

  • coding
  • programming
  • discovery
  • exploration
  • learning
  • Education
  • interactive
  • experimentation
  • javascript
  • Web Development
  • Visualization
  • Creative Coding
  • Generative Art
  • live coding

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

  Verbose tl;dr

  HN users generally praise the "discovery coding" approach described in the linked article. Several commenters share their own experiences with similar workflows, emphasizing the benefits of iterative exploration and experimentation for learning and problem-solving. Some highlight the importance of setting aside dedicated time for this type of coding, contrasting it with the pressure of deadline-driven work. Others suggest tools and techniques that can facilitate discovery coding, like using Jupyter notebooks or focusing on visual outputs. A few caution against over-reliance on this method for larger projects, advocating for more structured planning when necessary. There's also a discussion on how this relates to different learning styles and the potential downsides, such as getting lost in tangents or feeling unproductive.

  The Hacker News post titled "Discovery Coding" has generated a lively discussion with a variety of viewpoints on the presented coding style. Several commenters find the approach intriguing and resonate with the author's experiences. Some express skepticism and raise concerns, while others offer alternative perspectives or share their own related practices.

  A significant thread discusses the balance between upfront design and emergent design. One commenter argues that the described method might lead to accidental complexity if not managed carefully, while another suggests that it can be highly effective for certain types of problems, particularly those involving complex domains or uncertain requirements. The author of the article engages in this thread, clarifying their stance and explaining how they mitigate the risks of over-complication.

  Another key point of discussion revolves around the role of testing and refactoring in this "discovery coding" process. Several commenters emphasize the importance of rigorous testing to ensure that the evolving codebase remains stable and functional. They also highlight the need for continuous refactoring to address emerging design flaws and maintain code quality. Some suggest specific testing strategies and refactoring techniques that could be beneficial in this context.

  The comments also touch upon the applicability of this approach in different team settings and project scales. Some commenters express doubts about its feasibility in larger teams or projects with strict deadlines, while others argue that it can be adapted and applied effectively with appropriate communication and collaboration practices. The discussion also explores the potential benefits and drawbacks of this style for individual developers versus teams.

  Several commenters share their own personal experiences with similar coding styles, offering anecdotal evidence both in support and against the author's approach. Some describe their own variations on the technique, while others share examples of situations where it proved particularly useful or problematic.

  A few comments express skepticism towards the novelty of the approach, suggesting that it is simply a rebranding of existing iterative development practices. However, others argue that the article provides a valuable articulation of a specific coding style and offers practical insights for developers.

  Finally, some comments focus on specific aspects of the article, such as the choice of terminology or the examples provided. These comments offer constructive feedback and suggest improvements to the article's clarity and presentation.