Users care more about convenience than privacy, open protocols, quality, or long-term financial stability at least at the very beginning.
Furthermore, the "at least at the very beginning" qualifier can be dropped. Due to network effects the very beginning is all there is.
(This behaviour actually makes perfect sense. When first trying out an app the most likely outcome is that it doesn't work for you, so you don't want to spend more than a few minutes researching it and setting it up.)
Open protocol designers need to be aware of this when competing against centralized products. It has to be a top strategic consideration. If it's even a secondary consideration that's disastrously too low and the protocol won't succeed on the market.
One way to think about this is a convenience gage, analogous to the weather gage from the age of sail. Don't think about convenience as a fixed attribute of the protocol. That would rule out the part of the solution space that has better privacy, standardization, quality, and financial stability for the entities involved, but is a hair less convenient for users. Rather, think about convenience as a mutable attribute of the situation. Design a protocol that starts surprisingly convenient and has a mechanism for ratcheting new user convenience down once the network effect of the protocol is active.
xkcd
did and just pick some random letters.
not-spam-[0-9a-zA-Z]+.com
format
domain-ID
format for names
domain-[0-9a-zA-Z]+.com
[0-9a-zA-Z]+
part not to be human meaningful, but this
isn't required
The project began because I wanted to…
...
… not always be forced into a POSIX-y filesystem model. That involves thinking of where to put stuff, and most the time I don’t even want filenames. If I take a bunch of photos, those don’t have filenames (or not good ones, and not unique). They just exist. They don’t need a directory or a name. Likewise with blog posts, comments, likes, bookmarks, etc. They’re just objects.
"Al, the trouble is there is nothing for the guys down there to do while heat-treat is cookin' the parts. You load up one of the damn furnaces, shut the doors, and that's it for six or eight hours, or however long it takes. What are they supposed to do? Stand around and twiddle their thumbs?"
"I don't care what they do between times as long as they get the parts in and out of the furnace pronto," I say. "We could have done almost another batch of parts in the five hours of waiting for people to finish what they were doing elsewhere and change loads."
"All right," says Bob. "How about this: we loan the people to other areas while the parts cook, but as soon as the time is up, we make sure we call them back immediately so—"
"No, because what is going to happen is everybody will be very conscientious about it for two days, and then it'll slip back to the way it is now," I say. "I want people at those furnaces standing by, ready to load and unload twenty-four hours a day, seven days a week.
[...]
"You bet," says Bob. "But you know you're taking about two, maybe three people per shift."
"Is that all?" I ask. "Don't you remember what lost time on a bottleneck costs us?"
I sit there marveling that we're going to reduce the efficiency of some operations and make the entire plant more productive. They'd never believe it on the fifteenth floor.
SpaceX has a different design philosophy than most other launch providers. Most launch providers optimize for performance efficiency, SpaceX optimizes for cost efficiency.
example:
The Ariane 5 uses different engines for their first and second stages while the Falcon 9 uses the same engines for their first and second stage. Using different engines for the lower and upper stages is pretty standard among launchers because having one engine designed to operate in the lower atmosphere and one engine designed to operate in the upper atmosphere/vacuum leads to better performance and is one of the reasons the Ariane 5 high performance delivering payloads to GTO relative to the Falcon 9. However, from a manufacturing perspective it is much more expensive to build two different engines than it is to just use one type of engine which is part of the reason a Falcon 9 launch is around three times cheaper than an Ariane 5 launch.
"[...] But Admiral, all this emphasis on personnel and training is a terrific drain on us. You wouldn't believe how much time goes into it. It just isn't efficient use of all this high-powered technical talent you've recruited. Not to mention your own time".
"Efficiency isn't the objective, Dunford, effectiveness is. Don't confuse effectiveness with efficiency. I'm convinced that the only way to be effective, to make a difference in the real world, is to put ten times as much effort into everything as anyone else thinks is reasonable. It doesn't leave time for golf or cocktails, but it gets things done."
End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.
11a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
11b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
Teamwork is sorely needed throughout the company. Teamwork requires one to compensate with his strength someone else's weakness, for everyone to sharpen each other's wits with questions. Unfortunately, the annual rating defeats teamwork. Teamwork is a risky business. He that works to help other people may not have as much production to show for the annual rating as he would if he worked alone.
It is fundamentally the confusion between effectiveness and efficiency that stands between doing the right things and doing things right. There is surely nothing quite so useless as doing with great efficiency what should not be done at all.
The most popular Haskell implementation is the Glasgow
Haskell Compiler (GHC).
Core
is one of it's intermediate representations.
👤Simon Marlow and 👤Simon Peyton Jones in The Architecture of Open Source Applications (Volume 2):
- Haskell is a very large source language. The data type representing its syntax tree has literally hundreds of constructors.
- In contrast
Core
is a tiny, principled, lambda calculus. It has extremely few syntactic forms, yet we can translate all of Haskell intoCore
.
...
All of GHC's analysis and optimisation passes work on
Core
. This is great: becauseCore
is such a tiny language an optimisation has only a few cases to deal with. AlthoughCore
is small, it is extremely expressive—System F was, after all, originally developed as a foundational calculus for typed computation. When new language features are added to the source language (and that happens all the time) the changes are usually restricted to the front end;Core
stays unchanged, and hence so does most of the compiler.
The code itself, docs and source:
data Expr b
= Var Id
| Lit Literal
| App (Expr b) (Arg b)
| Lam b (Expr b)
| Let (Bind b) (Expr b)
| Case (Expr b) b Type [Alt b]
| Cast (Expr b) CoercionR
| Tick CoreTickish (Expr b)
| Type Type
| Coercion Coercion
Some referenced definitions (I've dropped some comments and deriving clauses from both code snippets):
type Arg b = Expr b
data Alt b
= Alt AltCon [b] (Expr b)
data AltCon
= DataAlt DataCon -- ^ A plain data constructor: @case e of { Foo x -> ... }@.
| LitAlt Literal -- ^ A literal: @case e of { 1 -> ... }@
| DEFAULT -- ^ Trivial alternative: @case e of { _ -> ... }@
👤Trygve Reenskaug invented model-view-controller, but claims his vision was different from the one that was implemented in Smalltalk-80. It's through the latter that we got modern MVC so Trygve's perspective isn't talked about much anymore.
I'm interested in and appreciative of both versions. This page tries to gather the key resources and writing involved in order to serve as a base for more subjective discussion elsewhere.
For a long time there was virtually no public information about MVC, even in Smalltalk-80 documentation.
In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
One result of this endeavour was the Model-View-Controller architecture that I developed as a visiting scientist at Xerox PARC in 1978/79. Its purpose was to bridge the gap between the user’s mind and the computer held data. The centre of this solution was the Model that was a representation of the user’s domain information. The View was an editor that enabled the user to inspect and modify this information. The Controller coordinated the capabilities of several Views making it a comprehensive tool that the user applied in the performance of specific tasks.
The original MVC was later modified in Smalltalk-80 to become a technical solution that separated input, output and information. The most important participant in the original MVC architecture, the user’s mind, was somehow forgotten.
The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints.
I first heard about the different strains of MVC from 👤Manuel J. Simoni, thank you!
The hourglass model and narrow waist design are the same thing. The "narrow waist" refers to the neck of an hourglass.
According to this video the original source is 👤Jon Postel splitting up the design of TCP and IP.
It quotes Postel in IEN # 2 from 1977:
We are screwing up in our design of internet protocols by violating the principle of layering. Specifically we are trying to use TCP to do two things: serve as a host level end to end protocol, and to serve as an internet packaging and routing protocol. These two things should be provided in a layered and modular way. I suggest that a new distinct internetwork protocol is needed, and that TCP be used strictly as a host level end to end protocol.
At 3:47 in the video the speaker describes Postel drawing an hourglass and using the term "narrow waist" (emphasis mine):
The starting point for the Internet was John saying, "The structure of our world is this: there's only one piece-- that thing in the middle-- that has to be everywhere. Everything else is sitting on individual hosts or individual wires. The thing that has to be everywhere you want it to be absolutely bulletproof, you want it to be really simple, and you want it to be a foundation that you can build on above and below. And the foundation's not going to ever change, because if it changes everything that rests on it is going to have to change and that's going to really stifle the innovation". So John drew an hourglass and said, "Look this is the way the world should be shaped. We get a narrow waist in the center which has to be everywhere. Above it we can put our transport protocols more the better lots of experimentation. Below it we can put lots of different interfaces the more the better lots of experimentation. In the middle we're going to do this thing that's going to be as simple as we can possibly make it and we're never going to let it change."
So the original hourglass metaphor seems to be for systems that (1) have layered architectures, (2) follow a complex-simple-complex layering, and (3) hope not to have to change the simple layer much.
I heard about the Van Jacobson video above while reading the article The Internet Was Designed With a Narrow Waist.
Or: Small Trees, Large Graphs
A design pattern used in large systems where less constrained global structure is layered over more constrained local structure.
The best example is the World Wide Web. It's a gigantic digraph of links, but individual webpages are much more constrained HTML trees.
It doesn't have to be this way. There could be a hierarchical portal that classifies all sites Yahoo-style, and the sites themselves could be made of little collections of freefloating cards. But that feels inside-out.
Another example is Unix filesystems. These are big leaf-valued trees with arrays of bytes for nodes. We've tightened the level of constraint a tick, but the same pattern is here.
There's an analogy to this in nature. Trillions of cells doing all kinds of highly specified things come together to make John Smith, who's a lot less constrained in his actions than a cell is.
But this is a design pattern not a law and so doesn't have to be followed. A flipped example (though this isn't a large system) is a computer game save manager. It's probably a list, which is a lot more constrained than the game instances it holds. But this is the right choice because a list removes energy from that level and directs it downwards. A game isn't supposed to be about the save manager, it's supposed to be about the items in it.
One thing that can be done with this idea is to imagine new systems. Sort the organization strategies you're interested in by how constrained they are, then iterate through them looking for interesting combinations. 3D space containing 2D spaces? This makes me think of a space flight game with plantetary land battles. But it could be used for more that that.
And there are all kinds of other options:
Maybe there's a pair in there that will be useful for one of your projects someday.
This must have been discussed a fair amount already, but Google isn't helping. If you have leads 📝contact me.
The title is inspired by 🎞️Constraints Liberate, Liberties Constrain which is an unrelated but wonderful video.
👤Manuel J. Simoni found a great quote about the original Model-View-Controller architecture, which is different from the one we know today. In it 👤Trygve Reenskaug writes:
One result of this endeavour was the Model-View-Controller architecture that I developed as a visiting scientist at Xerox PARC in 1978/79. Its purpose was to bridge the gap between the user’s mind and the computer held data. The centre of this solution was the Model that was a representation of the user’s domain information. The View was an editor that enabled the user to inspect and modify this information. The Controller coordinated the capabilities of several Views making it a comprehensive tool that the user applied in the performance of specific tasks.
(From the forward to 📜Naked objects (thesis))
By Smalltalk-80 the meaning of MVC had already changed to model-output-input separation we know today.
More reading:
a universal document converter
Pandoc has a modular design: it consists of a set of readers, which parse text in a given format and produce a native representation of the document (an abstract syntax tree or AST), and a set of writers, which convert this native representation into a target format. Thus, adding an input or output format requires only adding a reader or writer. Users can also run custom pandoc filters to modify the intermediate AST.
Because pandoc’s intermediate representation of a document is less expressive than many of the formats it converts between, one should not expect perfect conversions between every format and every other. Pandoc attempts to preserve the structural elements of a document, but not formatting details such as margin size. And some document elements, such as complex tables, may not fit into pandoc’s simple document model. While conversions from pandoc’s Markdown to all formats aspire to be perfect, conversions from formats more expressive than pandoc’s Markdown can be expected to be lossy.
Input -> IR
step though, you'd just end up with a
gargantuan IR. So maybe this distinction was good?
"Cattle" can only be used in the plural and not in the singular: it is a plurale tantum. Thus one may refer to "three cattle" or "some cattle", but not "one cattle". "One head of cattle" is a valid though periphrastic way to refer to one animal of indeterminate or unknown age and sex; otherwise no universally used single-word singular form of cattle exists in modern English, other than the sex- and age-specific terms such as cow, bull, steer and heifer.
SpaceX has a different design philosophy than most other launch providers. Most launch providers optimize for performance efficiency, SpaceX optimizes for cost efficiency.
example:
The Ariane 5 uses different engines for their first and second stages while the Falcon 9 uses the same engines for their first and second stage. Using different engines for the lower and upper stages is pretty standard among launchers because having one engine designed to operate in the lower atmosphere and one engine designed to operate in the upper atmosphere/vacuum leads to better performance and is one of the reasons the Ariane 5 high performance delivering payloads to GTO relative to the Falcon 9. However, from a manufacturing perspective it is much more expensive to build two different engines than it is to just use one type of engine which is part of the reason a Falcon 9 launch is around three times cheaper than an Ariane 5 launch.