What would you ask Simon Peyton Jones?

I have long aspired to interview Simon Peyton Jones, whom I consider the most articulate and charismatic figure in the functional programming community. What makes him even more remarkable is his approachability; I reached out to him on LinkedIn—thinking, why not?—and he actually responded. I was so astonished that I initially thought the reply might have come from his son, Michael, whom I occasionally encounter due to my involvement with Cardano and Plutus.

For years, I've dreamed of hosting a podcast where I interview my heroes, blending in crowd-sourced questions alongside my own.

I aim to pose truly insightful questions about the developmental journey of Haskell. I'm uncertain whether I need to center the interview around the publication of his most recent project, Verse, to secure his participation.

Additionally, what areas should I research heavily? I am versed in category theory and functional programming. But, I think I would need to read up on lambda calculus to sufficiently talk about it.

However, I am more inclined to delve into the profound insights he offers on deeper topics, as discussed by other equally eloquent Haskell core developers like Phil Wadler on the CoRecursive podcast. To me, some of the finest podcasting I've ever encountered was an episode where Phil Wadler talks about "God's Programming Language" and reads letters between the pioneers of lambda calculus, at one point remarking that "the laws of programming languages aren't invented; they are discovered."

Another remarkable moment in podcasting was this whirlwind episode with John Wiegley, where he discusses some truly otherworldly research he has conducted.

Answering the question raised at the end of Part 1, we take a look at how a hypothetical Strict Haskell would tie the compilers hands despite pervasive purity. We also examine how laziness permits optimizations that come with no intrinsic cost and compare its benefits to a strict language with opt-in laziness.

Part 1:

• Laziness in Haskell — Part 1: Prologue
Series Playlist:

• Laziness in Haskell

— Contact: • Tweag Website: https://www.tweag.io/ • Tweag Twitter: https://twitter.com/tweagio • Alexis King's Twitter: https://twitter.com/lexi_lambda

In the second webinar from our Hackathon series, Fabian Bormann provides an intro into building on Cardano including a list of tools to support you. Next, Mateusz Czeladka discusses how to harness the power of smart contracts with Aiken.

Click the link below to learn more and to register for the Cardano Summit Hackathon. https://summit.cardano.org/hackathon/

We teach you Haskell

In the past few years, we witnessed the development of multiple smart contract languages - Solidity, Viper, Michelson, Scilla etc. These languages need to enable developers to write correct, predictable behavior smart contract code. Each language development effort therefore ends up spending resources into building formal verification toolsets, compilers, debuggers and other developer tools. In this episode, we are joined by Grigore Rosu, Professor of computer science at UIUC [University of Illinois at Urbana-Champaign] for a deep dive into the K framework. The K framework is mathematic logic and language that enables language developers to formally define all programming languages; such as C, Solidity and JavaScript. Once a language is formally specified in the K framework, the framework automatically outputs a range of formal verification toolsets, compilers, debuggers and other developer tools for it. Updates to the language can be made directly in K. This technology has massive implications for smart contract programming language development, and formal verification efforts in the blockchain space. We also cover his efforts to express the Ethereum virtual machine using the K framework, and to develop a new virtual machine technology, called IELE, specifically tailored to the blockchain space. Check out the episode to understand a game changing technology in the formal verification and smart contract safety space.

Topics discussed in this episode:

• Grigore's background with NASA and work on formally verified correct software
• Motivations to develop K framework
• Basic principles behind the operation of K framework
• How K deals with undefined behavior / ambiguities in a language definition
• The intersection of K framework and smart contract technology
• Runtime Verification's collaboration with Cardano
• KEVM and IELE, smart contract virtual machines developed by Runtime Verification
• Broader implications of the K framework for the blockchain industry

cross-posted from: https://programming.dev/post/719255

Back Cover Text

The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process.

Domain-Driven Design fills that need. This is not a book about specific technologies. It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development.

Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and standard patterns provides a common language for the development team. A shift in emphasis—refactoring not just the code but the model underlying the code—in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations.

Specific topics covered include:

• Getting all team members to speak the same language
• Connecting model and implementation more deeply
• Sharpening key distinctions in a model
• Managing the lifecycle of a domain object
• Writing domain code that is safe to combine in elaborate ways
• Making complex code obvious and predictable
• Formulating a domain vision statement
• Distilling the core of a complex domain
• Digging out implicit concepts needed in the model
• Applying analysis patterns
• Relating design patterns to the model
• Maintaining model integrity in a large system
• Dealing with coexisting models on the same project
• Organizing systems with large-scale structures
• Recognizing and responding to modeling breakthroughs

With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.

This development encodes category theory in Coq, with the primary aim being to allow representation and manipulation of categorical terms, as well realization of those terms in various target categories.

"So the rotary fixture plate is done, right? WRONG. I’ve got just one more feature to add to it. A set of material squaring guides. I have an idea for a dovetail clamp that allows for adjustability, but is also self-squaring. I’ve never seen anything quite like it which could either be a good thing or a bad thing. It’s one of those weird things where the mechanism makes sense, but at the same time… doesn’t. So let’s find out, and build a functional prototype!"

I listen to this (now very old) episode often to get inspired.

When John starts talking about compiling to categories, at around 14:40 to around 30:00, it gets REALLY interesting.

*😁😁 Hoping to bring this kind of discussion to the new Formal Methods community. 😁😁 * Here's the work he talked about: Compiling to categories by Conal Elliott

I need someone to get into the weeds on compiling programs to "axiomatized closed categories". What are the implications? What are the ramifications?