slithy

The relationship between graphical user interfaces and interfaces to libraries

A click on a button is analogous to a function or method call with void arguments.

Filling out a small form (comprising selecting from a dropdown, typing into a text box, checking a checkbox) and then clicking on a button like 'submit' is analogous to a function or method call with a few (enum, string, bool) arguments.

Dragging one (subpart of) an object onto another (subpart of) an object can be analogous to a binary function where both arguments are domain objects, or a method on a domain object with one argument which is a domain object.

In graphical user interfaces, there are lot of different ways to represent what the user is currently attending to. The tab key usually steps a keyboard focus through a form - this is state, but it's not state of the application, so much as state of the user's interaction with the application. The other sort of tabs (such as browsers universally now have) store state, at least which tab is currently active, and for browser tabs, the set of tabs and where they are pointing is also part of the state. Windows represent user attention even more richly.

If you have a cursor, such as the keyboard focus that the tab key increments, or the 'currently selected object' in many drawing programs, then many functions can take "the thing pointed to by such and such (global) cursor" as an implicit additional argument.

So even though 'cast fireball at mob' is conceptually a one-argument function, in combination with a 'currently selected mob' cursor and appropriate mutations such as 'select the mob in front of me', 'cycle the currently selected mob to the left', 'cycle the currently selected mob to the right', it can become a zero argument function.

In porting a GUI to an API, you want to find the cursors and modes and similar 'state of the interaction' concepts in the GUI, and replace them with concepts more convenient in programming languages, such as variables.

In HotDraw, a prototypical drawing application, there are two primary "cursors" - the currently selected tool, and the currently selection, which might be one or more objects. You might click the rectangle tool, then click and drag between two locations on the canvas to create a rectangle.

The first action, moving the currently selected tool cursor to the rectangle tool, we don't directly model in the API. The second action, clicking and dragging in the canvas, is reasonably modeled by a an argument taking four integers.


  rectangle_tool.create(x1, y1, x2, y2)


You might also click the rectangle, then press delete. If we replace the current selected object with a variable, then we could do.


  r = rectangle_tool.create(x1, y1, x2, y2)
  r.delete()
slithy

the pong tutorial in clickteam's the games factory 2


  1. create a new game (control-n)
  2. click on it to see the properties on the left
  3. change the background color to black (settings/background color/black)
  4. switch to the frame editor (control-m)
  5. add an active object (alt-i, o, act, tab, enter, click)
  6. change movement to bouncing ball
  7. change speed to 40
  8. switch to the event editor (control-e)
  9. based on the ball, create a new condition, position, select all arrows pointing away from the center
  10. based on the ball, create a new action, movement, bounce
  11. go back to the frame editor (control-m)
  12. add a paddle to the playarea (alt-i, o, act, tab, enter, click)
  13. clone the paddle to somewhere else?
  14. select both paddles
  15. set their movement to eight directions
  16. change the right paddle's player property to 2
  17. change the game's properties - runtime options/player controls/player 2 should be wasd
  18. change back to the event editor (control-e)
  19. add a condition, based on one of the paddles, collision with / another object / the ball
  20. use the same action, bounce
  21. do the same thing with the other paddle (or drag the event you just made down to event 3 and change the other paddle instead)
  22. change the original bounce condition to not bounce when hitting left and right
  23. add a new condition that, if the ball leaves the play area on the left or right, it gets centered in the screen
  24. add a new condition that, if the ball leaves the play area on the left, the number of lives for player 1 gets decreased
  25. add a new condition that, if the ball leaves the play area on the right, the number of lives for player 2 gets decreased
  26. add a new condition that, if player 1's lives are zero, then storyboard controls / end the application
  27. add a new condition that, if player 2's lives are zero, then storyboard controls / end the application
  28. switch to the frame editor (control-m)
  29. insert a lives object (alt-i, o, liv, tab, enter, click)
  30. clone the lives object, place it above player 2 and change it to player 2
  31. -- TODO: add a background
  32. -- TODO: add sounds to the events



require 'framework'

-- create a new game (control-n)
the_game = new_game()
-- change the project default frame 1 to a black background
the_frame = the_game.frames[1]
the_frame.background = BLACK
-- make an active object
ball = new_active{ x = 320, y = 240 }
-- give the active object the 4-direction movement
ball.movement = BOUNCING_BALL
ball.movement.speed = 40
table.insert(the_frame.objects, player)
-- if the ball leaves the frame via the top or bottom, it instead bounces
table.insert(the_frame.events,
  new_event(ball:position{LEAVE_TOP, LEAVE_BOTTOM}):add_action(ball:movement(BOUNCE))
)
paddle_1 = new_active{ x = 100, y = 240 }
paddle_1.movement = EIGHT_DIRECTIONS
paddle_2 = new_active{ x = 540, y = 240 }
paddle_2.player = 2
the_game.runtime_options.player_controls.player[2] = WASD
table.insert(the_frame.events,
  new_event(paddle_1:collision_with(another_object(ball))):add_action(ball:movement(BOUNCE))
)
table.insert(the_frame.events,
  new_event(paddle_2:collision_with(another_object(ball))):add_action(ball:movement(BOUNCE))
)
-- if the ball leaves the play area on the left or right, it gets centered in the screen
table.insert(the_frame.events,
  new_event(ball:position{LEAVE_LEFT, LEAVE_RIGHT}):add_action(ball:position{x = 320, y = 240})
)
-- if the ball leaves the play area on the left, lives for player 1 gets decreased
table.insert(the_frame.events,
  new_event(ball:position{LEAVE_LEFT}):add_action(the_game.player[1]:subtract_lives(1))
)
-- if the ball leaves the play area on the right, lives for player 2 gets decreased
table.insert(the_frame.events,
  new_event(ball:position{LEAVE_LEFT}):add_action(the_game.player[2]:subtract_lives(1))
)
-- if player 1's lives are zero, then end the game
table.insert(the_frame.events,
  new_event(the_game.player[1]:lives_equal_zero()):add_action(the_game:end())
)
-- if player 2's lives are zero, then end the game
table.insert(the_frame.events,
  new_event(the_game.player[2]:lives_equal_zero()):add_action(the_game:end())
)
]]
--[[ TODO
-- switch to the frame editor (control-m)
-- insert a lives object (alt-i, o, liv, tab, enter, click)
-- clone the lives object, place it above player 2 and change it to player 2
-- TODO: add a background
-- TODO: add sounds to the events
]]

the_game:run()
slithy

the scrolling tutorial in clickteam's games factory 2

Design an API by imitating a GUI design success? This is based on a tutorial for games factory 2's scrolling.
  1. control-n to start a new project
  2. in workspace, click on frame 1, then in properties, click on 'virtual width', and change the default (640) to larger (6400)
  3. switch to frame editor (control-m)
  4. make a quickbackground object, something to see (alt-i, o, quick, tab, enter, click)
  5. make an active object (alt-i, o, act, tab, enter, click)
  6. give the active object the 8-direction movement (properties/movement/type/eight directions)
  7. switch to the event editor (control-e)
  8. make an always condition (alt-i, d, right-click on the special computer with a question mark, select always)
  9. right click on the intersection between always and storyboard controls (a chess knight in front of a chess board), and select scrollings/center window in frame
  10. in the dialog, pick 'relative to', click active, edit x and 7 to 0, ok
  11. test it by running it F7
If you take that tutorial, and try to render it in lua-esque syntax, you might get something like this.

require 'framework'

-- start a new project
the_game = new_game()
-- change the project default frame 1 to a larger-than-default virtual width
the_frame = the_game.frame[1]
the_frame.virtual_width = 6400
-- add something to see
table.insert(the_frame.objects, new_quickbackground{ x = 100, y = 200 })
-- make an active object
player = new_active{ x = 200, y = 300 }
-- give the active object the 8-direction movement
player.movement = EIGHT_DIRECTIONS
table.insert(the_frame.objects, player)
table.insert(the_frame.events,
  new_event(ALWAYS, center_window_in_frame{relative_to = player, x = 0, y = 0})
)

the_game:run()

Can I develop a framework where this syntax works? Yes, sortof - using SDLFW (which is a young libsdl-bound-to-lua thing), I made something that sortof works: https://dl.dropboxusercontent.com/u/22170444/crude_scrolling.zip
slithy

infrequently asked questions about accounting

I am fascinated by some infrequently asked questions about accounting.

One is "What is the relationship between accounting and dead-reckoning logs as kept by ancient sailors?".

Another is "Why do accountants denominate all their accounts in cash?".

I think I have a possible answer to the second. It has to do with some contingent facts about business, which have been stable for so long that they seem to be necessary.

In business, you have various stores of value, and generally you have a "metabolic cycle" or "value cycle", which (if you're a going concern) is, in essence, over-unity. This is Marx's MCM, but it's more complicated if you are trying to investigate a specific business specifically; you might rent a truck and hire a driver and buy gasoline and maintenance and then exchange a promise to pick up and drop off a load at certain points for another promise to pay, and then go to the start point, exchange a receipt for a load, go to another place, exchange a load for a receipt, and then exchange the pair of receipts for money.

In most of your stores of value, there is a carrying cost. If you own a truck, then you're vulnerable to a novel risk of your truck being stolen, or breaking down, or trucks in general being made illegal, or something. Therefore, as you grow (over unity remember?), you're probably not going to want to spread your value evenly among your various stores of value. Instead, you're going to want to minimize your "work in progress", and put most of your growth at the store of value with the lightest carrying cost.

Cash (or cash equivalents) is generally the store of value with the lightest carrying cost. In unusual real world situations, something else (barrels of oil?) might be the store of value with the lightest carrying cost, the one that as you grow you want to keep most of your growth in, and so you might want to "recognize revenue" when you complete a cycle from barrels of oil back to over-unity barrels of oil. In other situations (a trader in the USD/EUR currency exchange market?), your "utility" might be a combination of two stores of value.

That is, the accounting has ALWAYS been in units of utility. It's simply an artifact of the historical / contingent fact that businesses want to keep their growth in cash, that accountants denominate accounts in units of money. If you want a new accounting, trying to grow something other than money, you can still use a lot of existing ideas from accounting. For example, if you have an uncertain venture, you might put the potential downside into your balance sheet immediately, and only if and when it pays off, cancel it out.
slithy

programming as casting metaphor

There are various metaphors people use for programming; one example is "programming is like writing", another is "programming is like construction", mathematics, analysis, craft. More extreme examples are dreaming or cultivation.

To add to this list, I would like to analogize programming to casting - pouring molten metal into the space between two (or in general several) molds, often made of a sand/clay mixture.

* The metal is analogous to code.
* The heat applied to the metal is analogous to the programmers, who (temporarily) "inhabit" the code, and understand it deeply, making it flexible.
* The sand is analogous to requirements documentation.
* The clay is analogous to customer or business representatives, who "inhabit" the requirements documentation and bind it together into a cohesive whole.
* The two (usually) halves of the mold are analogous to the two (usually) major interfaces from the system to the external world - e.g. a system might interface to the customer (who purchases items from the system) and a warehouse.
* The sprues, gates and runners which are necessary to cast, but also need to be removed from the final product are analogous to the build system and unit tests.
* The machining of the final product is analogous to the deployment.

The analogy extends to typical kinds of defects:

* A misrun occurs when the molten metal does not fill out all of the requirements.
* A cold shut occurs when the frontier of the molten metal pauses or dwells during pouring, and the programmers have to go back to forgotten code.
* Mold mismatch is a requirements error that comes from lack of alignment between the different facets dictating requirements.
* A sand inclusion can occur when requirement documents detach from being owned by the customer, becoming "lost purposes" that are owned and served by the programmers, complicating the system unnecessarily.
* A run out is when requirements are so faulty that the programmers start writing code based on imaginary requirements.
* A pipe is a void that occurs near the sprue feeding new code into the project; these can occur when a feature that needs to be done last is not done at all.
* Mechanical damage can occur during the machining / deployment.
* Bubbles and porosity are the classic bugs and they generally occur at so-called "hot spots", which are portions of the code base that are frequently touched and changed by programmers.

To some extent, even the solutions that foundry workers use to deal with these problems sound pretty reasonable. For example, if you're experiencing porosity defects at hot spots, you might consider using chillers, which would be project management prioritizing getting programmers OUT of the hot spots, so that they solidify sooner. Or if your business requirements people are emitting bubbles of hot air when they interact with your programmers trying to write code, you might bake them (gently expose them to programmers who are not trying to write code) for a while beforehand to dry them out.
slithy

geometry and self-replication

Inspired by cp4space's blog about the geometry of self-replication: http://cp4space.wordpress.com/2013/08/21/langtons-loops/

I've been obsessing about how, or in what sense, technologies are critters (not just memes) that replicate in the context of human beings.

There's a standard "biblical" self-replicating loop, where a physical book, dropped into an environment with sufficient literate humans, blank books and writing implements, can (accidentally) be read by a human and (perhaps) persuade the human that it would be a good idea to copy out the book (exactly) onto a new book.

A machine, such as a pump, can also self-replicate. At first I was thinking about a path involving a human disassembling the pump into parts, then using the parts as patterns in casting (perhaps sand casting) replacement parts. However, this cycle doesn't actually close - one generation might work well enough, but there is noise and shrinkage, which means that you can't keep doing it one generation after another into the future.

If the part had something like G-Code printed on it, then that could obviously close the loop. (This is recognizably a quine, like the virus protein shell and the data inside it.) The human could obey the G-Code on some standard set of machining equipment - perhaps if we're being low-tech for intuition-boosting, the G-code might instruct the human interpreter in a sequence of ruler and compass constructions, which, executed in wax or wood and then sand-cast, recreate the part. However, parts do not generally come with G-Code printed on them, or even schematics.

Schematics printed on the part would require competent machinists to be available in the context, but at least a schematic is digital.

Still, the dimensions of a part ARE visible - if you carefully measure a part that you have, and make some reasonable guesses, you can generally recover the (digital) schematic of the part. For example: http://halfbakedmaker.org/?p=27122

This suggests a very geeky variant of telephone. The originator picks a irrational number with a formula, something like cos(1)*ln(Pi)^2. They compute it out to 8 digits or so (0.70801566) and add a little random noise to it. They send the noisy number to their neighbor, who puts it into something like the inverse symbolic calculator, and guesses which formula it is (balancing concerns like simplicity, aesthetics, and nearness to the number that they received). Then they compute it out, add noise to it, and send the number onward.

I think human beings must have a form of teleology sensors in our cognitive apparatus. Something about seeing the plan or mechanism behind an action, or even a device. It might be a combination of empathy and affordance sensors - the ability to see what you might be able to do with a thing.
slithy

bond graph modeling of businesses and economies

In bond graph modeling, the simplest way that two subparts of the whole can be connected is called a bond. The bond has a "typical power direction", pointing from one part to the other, represented by a arrowhead (traditionally, actually a half-arrowhead). It also has a "causal stroke", which can be on the same end of the bond as the arrowhead or the opposite end.

Someone called Brewer suggested that bond graphs could be used for economic modeling. The bond represents repeated sales of something from one entity to another entity. The arrowhead indicates which entity is selling and which is buying. The causal bond indicates which side is setting the price (the other side gets to set the order rate e.g. units per year). Brewer's papers are hard to find, but I think I understand essentially what was in them.

A simple model of a firm might have three "ports" - bonds piercing the envelope of the firm. One port is selling the finished product to customers. Another port is buying raw inputs from the raw market. The third port might be buying tools or machinery necessary to transform raw goods into finished goods. Internal to the firm, there might be stockpiles of raw and/or finished goods. The stockpile acts as a component that integrates order flow (or difference in order flow). That is, the raw stockpile contains the integral of the raw purchases minus the raw used up. The business might have a rule for setting the price based on the level in the stockpile. This kind of component is called a "C" component in bond graph modeling; in the electrical domain it would be a capacitor, and in the mechanical domain it would be a spring.

For simplicity, let's assume that we run the machinery continuously. That means that the machinery sets a work rate, how fast raw is transformed into finished. If finished is more valuable than raw, then the machinery accumulates profit. If we continuously reinvest the profit in more machinery, then the level of machinery is the integral of the difference in price between finished and raw. This kind of component is called an "I" component; in the electrical domain it would be an inductor, and in the mechanical domain it would be a mass with inertia.

If this firm starts buying a lot of raw (and possibly machinery), the raw and machinery markets may shift. If we simply model increased demand immediately causing increased price (via elasticity), then we can model the raw market as a curve that given a price, tells what the rate of supply be. In the opposite direction, we could model the machinery market as a curve that given a rate of purchases, tells what the price is. This kind of component is called an "R" component. In the electrical domain it would be a resistor, and in the mechanical domain it would be some kind of friction.

The bond graph that I'm discussing looks like this: https://docs.google.com/file/d/0B4wLmpoLANIBOWNjd0pSNnpZT0k/edit?usp=sharing

Doran and Parberry wrote an "Emergent Economies" paper, and Lars Doucet reimplemented it and published his code. http://www.gamasutra.com/blogs/LarsDoucet/20130603/193491/BazaarBot_An_OpenSource_Economics_Engine.php

The example of "an economy" in that paper has essentially five sectors, farmers, woodcutters, miners, refiners, and blacksmiths, and five goods, food, wood, ore, metal, tools. Roughly speaking, the farmers produce food using wood as a raw material, and the woodcutters produce wood using food as a raw material, but both depend on tools being ambiently available. So given tools, the farmer-woodcutter loop is a over-unity engine of growth. Similarly, the miners produce ore, the refiners turn ore into metal, and the blacksmiths turn metal into tools, but all depend on food being ambiently available. So given food, the miner-refiner-blacksmith loop is another over-unity engine of growth.


It would be straightforward to duplicate the bond graph above five times and wire it together to form a bond graph model of the whole (tiny) economy. I think trying to "polish" the bond graph model against an agent-based simulation of that economy would be interesting; they're very different formalisms.
slithy

(no subject)

Galileo had an argument against Aristotle's law of gravity.
Aristotle's law of gravity was that objects fall at a speed proportional to their weight.
Galileo's argument against it was something like:
"Consider two things connected together only loosely. On the one hand, considering them as the aggregate thing, they should fall fast. On the other hand, considering them as two separate things, they should fall slow. What would the tension in the last strand of twine be like? This is weird."

This is a kind of argument from continuity - Aristotle's law has a discontinuity as you go from a single barbell-shaped object to two adjacent objects nearly touching. If we believe that the laws of nature ought to be continuous with respect to that transformation, then we can reject Aristotle's law from the armchair.

One thing you can do with a circuit is draw its signal flow graph. For some simple circuits, drawing the signal flow graph is follow-your-nose easy. For some very slightly more complicated circuits, you get arguments like this:

Consider a current source (Sf) wired up in parallel with two other branches. The first branch has a resistor (R1) and a voltage source (Se1), while the second branch is similar (R2, Se2).

Trying to draw the signal flow graph (in the time domain), we might say:
1. Start at the current source, Sf.
2. Let x be the current through the 1 branch. (Note, we could have gone the other way).
3. Then Sf-x is the current through the 2 branch.
4. So (Sf-x)*R2 is voltage across R2.
5. So (Sf-x)*R2+Se2 is the voltage across the whole circuit.
6. So (Sf-x)*R2+Se2-Se1 is the voltage across R1.
7. So ((Sf-x)*R2+Se2-Se1)/R1 is the current through the 1 branch, that is, x.
8. Solving for x, we find that x==(Sf*R2+Se2-Se1)/(R1+R2).

(This is called an algebraic loop in bond graph terms).

This process of predicting what the circuit will do is not "shaped like the circuit". It involves steps that are contingent on feeling stuck, it has asymmetries where the circuit has symmetries, it's nonmechanical. We could make the final symbol-juggling almost arbitrarily hard by introducing nonlinearities, but apparently the circuit can juggle those symbols essentially instantaneously. This cannot be how the circuit itself computes its behavior.

Perhaps it was foolish of me to believe that the human process of solving the easy circuits was analogous to the circuits' method of computing its behavior.

If we spread the circuit far enough apart, the connections between the pieces will need to be modeled with transmission lines. In order for the constitutive laws to be continuous with respect to whether we model the circuit as containing transmission lines or not, the transients in the transmission-line variant of the circuit ought to die out quickly. Furthermore, the transients can probably be viewed as computing the answer to the set of constitutive equations, perhaps by iterative relaxation (Jacobi or Gauss-Seidel methods?)



I think this might be a 7th or 14th order differential equation, depending on how you model transmission lines (or whether you count a complex number as one or two degrees of freedom)? Regardless, it probably converges toward a steady state pretty rapidly in a lot of reasonable models of transmission lines.

That is, the circuit laws don't care exactly how you parse the circuit, because they're continuous with respect to "nearly the same" parses, even though I personally feel more confident in solving a single linear equation than computing the steady-state behavior of a differential equation.
slithy

dataflow / class diagram duality

Class diagrams in UML (for my purposes) have boxes, two kinds of arrows (isa and hasa) between boxes, and methods, which are essentially strings, inside the boxes. Class diagrams correspond to object-oriented code in that each box probably has a section of code corresponding to it, each method probably has a section of code corresponding to it, and each arrow leaving a box indicates a collaborator that will need to be considered.

Objects can be encoded into functional languages like ML or Haskell by an object-closure correspondence. Where the object-oriented code creates a new object, the functional code would define a new functional value, using a lambda. Where the object-oriented code invokes a method on an object, the functional code calls a function value. In order to model method dispatch, the functional code might call a function value representing the object as a whole, passing a known-at-compile-time value of an enumerated type as an argument, and then call the returned (function) value with the arguments of the method, something like this:


  v(PRINT)('hello %s', {'world'});


If you have functional code, but you need object-oriented code, then you can go the other way. (This is called defunctionalization, and the experts to google and read are Danvy and Reynolds.) For each function value constructed in the source code, you need a constructor, and usually a class. (Multiple constructors on the same class is possible, but dubious if you're shoehorning, and unlikely if you're not shoehorning.) The lexically-scoped variables Then you need to study the dataflow, and find out where the function value will be consumed (applied). That will give you your method name. Generally the dataflow looks like a river - several tributaries coming together to one port where the river ends. In statically typed object-oriented languages like C++ or Java, that means that you will need an interface (or pure virtual abstract class, same difference), corresponding to the consumption point. Then each of the origin points will need to declare that they implement that interface.

tl;dr - you can recognize "wannabe-functional" code in an OO language from the class diagram - it has a bunch of one-method classes, often in little groups (an interface and its several concrete implementations).
slithy

calibration as a business model

A startup needs to do a couple things. First and most importantly, it needs to create some value for the customer. Subsidiary second and third goals are to capture that value (the startup wants to be "sticky") and to create some sort of barrier to other businesses entering.

Calibration is a process of doing something moderately easy, just a little finicky, "forward" many times, in order to gain the ability to "magically" do it backward. For example, if you have a balance, some gram weights and a wine glass, then you can pretty easily fill the wine glass with 10 grams of wine and take a picture. If you repeatedly, and carefully do this for 12, 14, 20, 100 grams, then you can build a database of images of wine glasses tagged with how many grams of wine are in it. Then you could use that database to go backward from an image to the information of much wine is in it.

First: The "magical" quality of the backward direction fits well with creating some value for the customer.

Second: By offering the calibration as a service, the startup might well be able to capture that value.

Third: The expense of creating the database is actually good, because it forms a (small) barrier to other businesses entering.

To use this "calibration" template to generate ideas for businesses, you need find a problem that people actually want solved, that is relatively easy to do "backward" - which is still hard, but perhaps easier than the initial problem of "an idea for a business". Perhaps one could accumulate a personal library of techniques like this calibration template, something like a personal, business-focused variant TRIZ.