Posts

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 was my research effort...

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...

The Engine of Ambiguity: Building Teams Around the Trusted Process

Introducing "Trusted Engineering Processes" During my CS studies, I spent two summers at the CSEM (Centre Suisse d'Electronique et de Microtechnique) , first improving their Design Rule Checker , then rewriting it. This was my first encounter with a rare breed of individuals: engineers who possess an almost pathological commitment to rigor, whose value lies not just in their raw intellect, but in the absolute predictability and safety of their methodology. Recently, in the context of blogging about how these engineers succeed , I thought it would be good to talk specifically about individuals and team formation for what I call "trusted processes," as collectively, we heavily rely on the innovation built by these individuals. It is, however, not the easiest task! In Deep Tech Servant Leader in Ten Rules , I presented team dynamics from its leadership perspective. How do we present it from a team perspective? Here things become a bit complicated. We have the follo...