Posts

Building High-Stakes Domain-Specific Languages: A Retrospective

I have designed and led designs of Domain Specific Languages (DSLs) in high-demand industries from semiconductor physics and algorithmic trading to distributed ledgers and industrial security. The systems that depend on the DSLs have powered industry-standard CAD tools, secured critical infrastructure, and driven core technologies acquired by global leaders. A key early lesson: mathematically clean domain invariants guarantee simplicity, safety, and scalability. Below is a selection of these projects. Whether you are an organization seeking strategic architectural guidance, or an engineer looking to master advanced language design in my upcoming workshop, this portfolio illustrates the  power of a well-engineered DSL. Design Rule Checker (DRC) Domain and Context:  Validating and finalizing integrated circuits masks in microelectronics (my first role). DSL: The DSL specifies 2d mask operations. Input is given set of masks (e.g. made by CAD automation or human layout ...

PMDL Informal Language Specification

PMDL (Physical Model Description Language) is a modeling language I designed for circuit and semiconductor devices. I implemented it as part of my PhD at the ETHZ  (see Litsios, J., 1996. A modeling language for mixed circuit and semiconductor device simulation, Hartung-Gorre).  It was built as a subset of the C programming language to remain simple and familiar, meaning it retains basic C syntax but does not support pointers or full hierarchical models. I had Gemini summarize the language specs below. The reason I bring it up is that the language vertex , edge , face , and element specifiers are actually tying the language semantics to the  k -simplices of a 3D spatial manifold ! And that is a pretty useful thing to know, and something I will bring up again in this blog. FYI: Dessis, which I developed during my PhD and was later acquired by Synopsys to become the number one TCAD device simulator, was my PhD's principal activity. My DSL development compiled to code run i...

DSL as domain reference truth

 I have always been a very visual thinker, I tend to think in images and feelings, and less in words. Therefore having just reread my  Why Use Arrows and PowerPoint to Express Software Designs?  blog, which is all about using visual props to help you design systems, and remembering how ineffective these visual representations were in helping me share my ideas, I find myself needing to accept that my carefully crafted "invariants as drawings" approach have really mostly only helped me, and definitely were unable to express enough to others to drive a software development! The bright side of this story, is as much as at Actant, as later a Elevence, we had the insights to center development around a DSL. The team then having the freedom to express the needed properties in the DSL, I having the freedom to ask for something non-obvious by describing the expected behaviors, not the invariants, and especially not as visual projections that lack reading instructions. The bigger s...

The Engine of Approximated Certainty: An Introduction to High-Performance Software Engineering

Building advanced software systems by trial and error is a fast track to bankruptcy. Today, the cost of generating code has plummeted, but the cost of ensuring trust and verifiability has skyrocketed. To survive this economic squeeze, we can no longer rely on outdated, informal development cycles. Over the last few weeks, I have documented the mechanics, psychology, and processes behind a "zero-fail" methodology I have used for over fifteen years. I call it High-Performance Software Engineering . This post serves as your router and introduction to the series. It breaks down the six foundational pillars of this methodology and points you to the deep-dive articles that explain how to make it a reality. The Engine: A Product and DSL-Driven Process High-Performance Software Engineering completely bypasses the traditional Agile cycle of translating features into stories and stories into code. Because human translation always results in lost intent and bloated latency, we change th...