Long-haired programmer; loves cats and dogs but doesn't have any.
Bangbangcon is wonderful. Each talk hits hard, motivating me to move in different directions.
For example, after Charles Chamberlain’s talk about the jq programming language, I would love to study jq and implement some lovely and/or clever and/or useful code in it. But after Jan Mitsuko Cash’s talk about flocking, I want to study flocking, and try bringing other techniques, like Mike Cook’s stuff to the problem of setting the parameters of flocking in order to yield distinct effects. But after Scott Vokes’s talk about how keyboards work, (and particularly Limor Fried’s talk) I want to do more embedded things! But then after talking with Walt Mankowski about COBOL, I want to write COBOL, and really coherently analyze what aspects of COBOL are excellent, what aspects are excellent solutions to problems that are less salient now, and what aspects of COBOL are simply mistakes.
I have been obsessed with bond graphs for a long time, so maybe I could instead work with that.
Bond graphs are a technique for organizing a particular kind of mathematical model of a particular kind of phenomenon.
The type of mathematical model is sometimes called “ODE”, or “state space model”, or “lumped element model”. The type of phenomenon is when there is a locally-conserved quantity that you want to take special care of - usually energy. These sound complicated, but they’re REALLY common.
Techniques that sound like they are “bigger” or “better” - like “partial differential equations” or “finite element modeling”, tend to assume that you can do ODE modeling. That is, you cannot escape ODEs or state spaces or lumps by fleeing into continuous space.
When you are modeling, you want to “cut at the joints”. That is, you want to partition the whole into subparts which are nearly decoupled. The bond graph trick, which is from electronics, is to expect the math to be able to capture the remaining coupling as the conserved quantity (usually energy) traveling, over time from one subpart into the other. That is, if you make a modeling decision (such as to cut component Foo apart from component Bar), then the model should have a variable or formula, which is the power (power is energy per unit time) flowing from Foo to Bar or vice versa.
Moreover, (and this is still the bond graph trick) that power should be expressed by two variables, which multiply to form power - one part determined by the model of Foo and one part determined by the model of Bar. In electronics, these are the voltage and the current.
Two specific examples from electronics:
The bond graph trick is FROM electronics, but it’s more broadly applicable. In particular, force and velocity of a point in mechanical engineering work exactly analogously.
Business bond graphs lean on a different conserved quantity - cost. If you divide a business situation into two components, then the flow of cost from one to the other is expressed as a price of some transaction, determined by one component, and a rate of transactions of that type, determined by the other component.
Opinions expressed are solely my own and do not express the views or opinions of my employer.