|
|
I may have only done three classes, but already I’ve rediscovered that there is one principal to working efficiently: automate and systematize whatever you can. Practicing this mantra allows a course to run much smoother, reducing headaches and prepratory time. I’ve compiled a short list of tips, each of which I learned the hard way:
- Make sure, at the beginning, that you have a way of broadcasting messages to all students.
- According to Murphy’s Law, you will regret not figuring this out just at the moment that you have to notify all students of some inevitable emergency. More realistically, you simply forgot to mention some time sensitive information during the regular class session, but it would be too late to wait for the next one.
- Separate work and personal email.
- Make up a new Gmail or Yahoo address for each class that you teach. The accounts are free and the separation reduces the chance that you will accidentally miss a student email (say, because they forgot to put the ‘CS 101′ tag in the subject line). It also means that you don’t reveal your personal email to the troublesome students that you hope to never see again. The very few students that are worth keeping in touch with on a more personal level, will feel among a priveledged elite when you grant them knowledge of your personal email.
- Have a well defined late-work policy.
- In every class that I have taught, someone always had some issue that prevented them from doing their homework that week. I expect that every class I ever do will follow this pattern. Build some flexibility into your policy. If you don’t have to provide immediate feedback, allow a one-time only, no questions asked, 2 day late submission. If you do have to provide immediate feedback, consider -20% for each day late.
- Have a course web page.
- The webpage should contain: schedule, contact info, assistance info, grading policies/rubric, tip/hint section for homeworks, project guidelines. Make it clean and stylish. If you don’t know html, go with Google Pages. Having a tips/hints page for each project was of enormous help in reducing email assistance load for the last compilers class. When student runs into a tricky part of the assignment and sends you a question in email, you can post your response on the tips page. If you get the same question, reply with a link to the page so that you get them used to checking it before sending email.
- Learn them how to learn.
- For each project they run into, help them to build a problem solving process. Give pointers to time management strategies, debugging strategies, study strategies, etc. Each difficulty on each assignment should be discussed as a learning opportunity. Review what approaches didn’t work, and why; for the reasons are more informative than the results.
- Automate grading.
- As much as is possible: write a script that downloads, unpack, unit tests each submission. Even better, if they can submit to an auto-testing website before they turn it in to you. Then, they have feedback during development, and they don’t get the little things wrong (like “I forgot my makefile”). Write a script that automatically sends out email to individuals of their score. Have assignments with clear rubrics, so that grading becomes a quick series of checking off boxes.
I don’t like them.
I’ve ranted before about how the Web is a festering polyglot made horrific by Postel’s Law. Many, including Tim Bray, advocate more knowledge at the client end, when an error occurs in parsing the steaming pile of HTML that forms today’s Web pages. I almost fell in line with this reasoning, because more information is better, right? I thought a draconian policy would so irritate customers that businesses would be quick to fix it, and expend much effort on prevention. So, all the Web becomes well-formed.
Oh how wrong I was!
Jeff Atwood recounts an interesting tale at http://diveintomark.org/archives/2004/01/14/thought_experiment:
Imagine that you posted a long rant about how this is the way the world should work, that clients should be the gatekeepers of wellformedness, and strictly reject any invalid XML that comes their way. You click ‘Publish’, you double-check that your page validates, and you merrily close your laptop and get on with your life.
A few hours later, you start getting email from your readers that your site is broken. Some of them are nice enough to include a URL, others simply scream at you incoherently and tell you that you suck. (This part of the thought experiment should not be terribly difficult to imagine either, for anyone who has ever dealt with end-user bug reports.) You test the page, and lo and behold, they are correct: the page that you so happily and validly authored is now not well-formed, and it not showing up at all in any browser. You try validating the page with a third-party validator service, only to discover that it gives you an error message you’ve never seen before and that you don’t understand.
You pore through the raw source code of the page and find what you think is the problem, but it’s not in your content. In fact, it’s in an auto-generated part of the page that you have no control over. What happened was, someone linked to you, and when they linked to you they sent a trackback with some illegal characters (illegal for you, not for them, since they declare a different character set than you do). But your publishing tool had a bug, and it automatically inserted their illegal characters into your carefully and validly authored page, and now all hell has broken loose.
You desperately jump to your administration page to delete the offending trackback, but oh no! The administration page itself tries to display the trackbacks you’ve received, and you get an XML processing error. The same bug that was preventing your readers from reading your published page is now preventing you from fixing it! You’re caught in a catch-22. … All the while, your page is completely inaccessible and visibly broken, and readers are emailing you telling you this over and over again.
…
Here’s the thing: that wasn’t a thought experiment; it all really happened. It’s a funny story, actually, because it happened to Nick Bradbury, on the very page where he was explaining why it was so important for clients to reject non-wellformed XML. His original post was valid XHTML, and his surrounding page was valid XHTML, but a trackback came in with a character that wasn’t in his character set, and Typepad didn’t catch it, and suddenly his page became non-wellformed XML.
The moral of the story is actually not about well-formedness and draconian client validation, but one of security. It should not be possible for somebody else to break your system. The mechanism by which we include foreign content into our pages in fundamentally broken. HTML systems usually function as templated string processing, a practice which results in the above problems. It’s an issue of content injection and a lack of sandboxing, that’s only masquerading itself as one of well-formedness and validation. Embedded languages shall never escape this quagmire.
The success of Salman Kahn’s Academy and other instances of disruptive education, have started me thinking about how computer science education might scale. Let’s first analyze how Kahn is organizing the learning experience.
First: Have a huge collection of videos. Kahn’s library has been organically grown. Each video introduces only a single topic, through the use of an example. The videos are never longer that 15 minutes, so the example and explanation have to be concise and straightforward. Any context or motivation for the topic/idea need to be embedded in the example itself, and do not warrant their own digression. Extended lecture is one of the least effective mechanisms for learning, so the short video format works well. Additionally, the video only has to be made once, and it can be repeated as often as necessary for every student.
Second: Map out the dependencies. Once the video library grew large enough it has to be organized. Some subjects, such as mathematics, have a clear dependency chain of topics. But all subjects can be broken down and categorized into a network of interdependent topics. This web is not necessarily topologically order-able, but an ordering roughly corresponding to historical development likely minimizes the forward references and digressions to another leaf that occur when two seemingly unrelated topics need to be introduced before they are later unified. The mapping itself has a visualization.
Third: Merit badges for topic understanding. If the discipline itself can be broken down into separate topics, then you can develop exercises that test each individual concept. Mastery of each topic can be measured by performance on the topic exercises. Each time a student can prove the ‘get it’ a merit badge can be awarded that unlocks access to the more abstract, more complex, more involved topics that follow. This ensures that each student builds the skills needed before they continue. Everyone can develop mastery at their own pace, and we don’t have to keep a strict schedule. Understanding and development become the focus while examination and assessment are de-emphasized. You can visualize your achievements and progress in the topic dependency visualization.
Fourth: Lack of penalization for failure. Each student is allowed to develop at their own pace, watch the topic video as many times as necessary, and try the exercises as many times as necessary until they ‘get it’. No ‘Fail’ or other negative mark appears on your permanent record just because you were unable to keep pace with the rest of the class and the teachers schedule. You are free to go back and review topics that you have forgotten, and will likely do so because the video is less than 15 minutes. Understanding the material to collect merit badges becomes its own reward.
That sounds like a wonderful system! And it works out quite nicely for subjects that have short, simple exercises that can assess individual isolated topics. But for subjects other than math/science I’m not sure that it works quite as well. There might be issues scaling this educational framework.
Apply the above organization to Computer Science. We get something like CodeAcademy. It doesn’t have a graphical visualization of the dependency map of topics, but it does have a way to track and share your progress. The exercises are simple, but I find them too knowledge-based. Yes, you can easily learn how for loops work, and the interface encourages exploration. But, it doesn’t teach the most important part of programming skill: design trade-offs and decision making.
An automated system is pretty good at teaching the basics: types, variables, memory, assignments, loops, conditionals, etc. Yes, it can be gamed and deceived, but if you do that you’re probably have more understanding than the automated assessment expects. But it’s not good at giving design feedback. The exercises don’t scale. It doesn’t have a way for me to learn the GoF Design Patterns. It doesn’t have a library of common solutions for common problems in that particular language. It doesn’t tell me that I have to practice good indentation and naming lest I confound myself. It doesn’t tell me that I should make many small functions with good names, that I should handle edge cases first to get the out of the way, that I should prefer local variables over global variables. In short, it allows me to acquire coding habits (like use of global variables and flags that control loops) that work on small exercises but will ultimately prevent me from becoming a professional developer.
If we are going to automate our education by breaking it up into small pieces, we have to make sure that we also teach how those pieces interconnect. It’s not enough to know all the different Lego pieces, I also have to know how to assemble them together. Unfortunately, design issues are much fuzzier. The trade-offs are trickier. The feedback is more about understanding explanation and reasons why vs rote knowledge and brute-force logic.
People tend to ignore their designs until they run into maintenance problems, and only then do they begin to desire and learn about code organization and design. Only when they’ve created complexity beyond their capacity to manage it, do they feel a need for a way out. So, our educational system has to have built into it, a mechanism for waiting on the student to be ready for the knowledge. For example, as Steve Yegge recounts in his reading of Fowler’s book on Refactoring, even smart developers that continually practice their craft can be blind for years before realizing this need.
I’ll quit with a question: How can you automate feedback about design trade-offs and code organization?
Again, I spent far too much time looking at different keyboards. This time around, however, I can see that some people are progressing toward my latest ideal: The multi-touch surface with re-configurable keys. Mostly, I want to record all the cool things that I came across.
What’s wrong about what I currently have
Right now, the best board that I have is the Kinesis Freestyle. But I find it inadequate because the ESC key is too far away (VIM habits) and the qwerty letter ‘b’ is on the wrong hand. I’m a still in the process of switching to emacs, but since I use dvorak some of the keybidings are a bit off. For example, C-x is, for me Caps-Lock-b to a qwerty user. But that’s a stretch for the right hand, so I often type the x with my left hand. Kinesis freestyle doesn’t let me do that.
A review of what I found
First, and most awesomest, there’s Jason Giddings kickstarter project: Multi-Touch keyboard and Mouse. Although, design-wise, it’s really, really slick, I wouldn’t use it myself because I need the tactile feedback of actual buttons.
Second, there’s Steve Isaac’s and Brad Melmon’s kickstart project: Touchfire: The Screen-Top Keyboard for iPad. I really liked this project, because they showed a little taste of what they had to go through during development. They had some trouble with the polarity of the iPad speaker magnets in different models, which upset the magnetic attachments which keep the board in place. The had to develop and find a silicone rubber that would allow capacitive fingers to be sensed by the touch screen. The keys on the board had to be of a particular shape, it looked like they tested about 50 different variations. This one is most interesting to me because, I too have to figure out how to get keys to rest on top of a touch sensitive screen. Again, I wouldn’t use it myself, because I don’t care for the iPad.
 Hackaday had an article about The magic keyboard which is composed of two magic trackpads. This is coming close to what I envision. The board is split, and each side is a multi-touch sensitive surface. Only three things missing: repositionable physical keys, software to configure the board, and large surface for each hand.
Hackaday also had an article about a teardown of the AXiS-49, a music keyboard. Most interesting here are the buttons. It seems that the board can be cloned, using cherry MX switches.
 Hackaday had another article on a really crazy keyboard made of microswitches. This guy really went overboard. His only regret is placing the keys a little bit too far apart, not optimizing for finger travel distance.
 Hackaday also had an article on the Humble Hacker Keyboard. This story is most inpiring, because the guy went through all the trouble (about $2k) of getting custom manufacturing. The build log mentions some of the places where he had to go to source the different parts.
Solving the touch sensitivity.
It seems that there are two paths to take:
- Frustrated internal Reflection.
Drawback here is that it requires a camera to visualize the presses. Also, creating keys that you can rest your hands on, but not activate the sensor might be difficult. Would look very slik though, as shown by the Keyboard and Mouse combo above.
- Capacitive MultiTouch.
The most promising project here is OpenMT which creates a flexible, open source multitouch surface. Still going to be alot of work to build it though. Perhaps there are pre-made ones that I can just order and play with. Will also have to figure out a way to have keys rest on the surface, yet still activate the capacitive sensor when struck.
My best bet with the keys is probably the Cherry MX’s, because they have a plunger that will descend past the base of the key itself, as shown by the AXiS-49 clone. The tip of the plunger will have to be a plastic that has capacitive response, while the surrounding part of the key base will have to be something like a sticky silicon rubber. This way the keys can be repositioned, yet maintain that position over time. I admit, it would be really cool to have a glass version. Especially, if that means you can make yourself several glass plates, and sawp them out for different applications. Some gamer keyboards target that desire.
Also, at CGO I met Hassan Chafi, who is working on a graph-based Domain Specific Language. Even though I never seem to find time that I can explicitly devote to studying them, DSL’s are, to me, an compulsively fascinating topic. A day or so after the discussion it occurred to me that we need some metrics by which a DSL can be measured. Now, in the general purpose language field Wirth has come up with what is, in my opinion, a very elegant metric: language complexity can be measured by the size of the self-hosting compiler. That works great for general purpose languages that have to do string processing, parsing, data structures, traversals, modeling, etc. Each of which is a component of the self-hosting compiler. But it works less well for a DSL, because the focus on particular domain means they aren’t general purpose.
In the case of a DSL for graphs though, I think the case is clear: It should run graph algorithms well. But which ones? And how do you measure expressibility? It took a couple of days for the answer to arrive in my head. I had at one point encountered a wonderful paper on On variants of shortest-path betweenness centrality and their generic computation by Ulrik Brandes. This paper provides a dozen related graph algorithms. It is presented in a way that emphasizes the changes between the base centrality algorithm and each variant. This style of presentation helps to measure how well the DSL allows similar algorithmic changes.
So I think it’s a good start to answer the general question, “How to measure the effectiveness of a DSL?”, with a case study. Make a list representative of what you wish to do, and try it out, looking for patterns and variations on a theme.
I attended CGO 2012. The speakers were universally boring, but the conversations that you have with other attendees can be quite interesting. For example, I have been thinking that the hodge-podge babel of languages that makes up web applications should be replaced with something more lispy. William Maddox, currently at Adobe, shares the same opinion and was able to introduce me to two really interesting projects.
The first, Meta-HTML, comes from the inventor of Bash, Brian Fox. It runs server-side and implements a full language within the html tags themselves. It uses the CGI abstraction to run mostly independant of the web server. Installation is as simple as placing the interpreter in your PATH (thanks to unix #!). What’s fascinating are the language ideas: The angle brakets become what parens are to Lisp, the tag names become function names, spaces separate positional arguments, and attributes (which use the attr = "value" syntax) become keyword arguments.
The second, curl, comes from MIT in 1998 and is now hosted (and under active development) by a Japanese company, SCSK. It’s a complete document description language and includes dynamic content. Formatting directives (and many other cool stuff) is implemented via libraries and built-in functions. The calls are just like lisp but use curly braces rather than parens. Not only was this what I had originally envisioned, it goes much farther! You can type variables as dynamic in which case they will automatically update content whenever that variable is updated. (Dataflow, just like cells in a spreadsheet). You can also code up your own threads! So you can code a watching circuit that will update content, say every 5 seconds. They have an development environment (unfortunately Windows 7 only).
The keynote speaker at CGO 2012 (Chris Lattner, LLVM) put some crazy thoughts into my head.
Want compiler to know about:
- memory disjointness
- aliasing
- Usage of data structures (array of struct vs struct of arrays)
- whether arithmetic is done on a pointer (and the bounds)
- invariants (in loops and between methods)
A language needs to be able to express some of these concerns. Not just because the analysis within the compiler benefits from having the data, but that programmers themselves should be documenting these properties. A great programmer knows about the analysis the compiler can perform. A great programmer knows about the assumptions that such analysis requires. And a great language supports the great programmer by allowing her to express these properties within the code itself.
Creating a language that supports these higher-level descriptions allows other programmers to see why a certain portion of code is structured the way that it is. It helps them from innocently re-structuring the code so that the compiler’s analysis fails (and performance is lost). It makes more clear what you shouldn’t say as a programmer.
I’m not familiar with Eiffel, so I may be completely out of place with this example. But, it seems to me that Eiffel’s choice to allow the programmer to express explicitly, in source the invariants of their programs has two distinct benefits: (1) the compiler has more information to work with during program analysis, (2) the programmers are encouraged to think more deeply about their code’s structure. Much compiler research has tried to investigate “How much can we do this automatically (so that we don’t have to change existing code and so that programmers don’t have to learn anything new)?” I’m using Eiffel as an example of why these objectives are actually harmful. In my experience as a programmer, knowing more has always helped. I desire a language that encourages me to know more, and the best encouragement is to have linguistic support for describing higher-level properties. In Eiffel’s case it’s program invariants, but why not include also some of those things in the list above?
The compiler shouldn’t be a magic black box! It should be a tool that yields increasing benefit the more a programmer devotes to learning how to use it. The benefits should build on each other incrementally, so that even though complete mastery takes 10 years, each incremental step is worth taking.
Dear Hugo Salinas Price,
In your article, Second Thoughts on the ‘Thought Experiment, you raised a sequence of 5 items which together form an objection which led you to believe that the Thought Experiment had to “go back to the drawing board”. I think, that with a small adjustment, this objection can be overcome. I treat each of the 5 points separately, in order that the case is full bodied.
- With the certainty that Utah State taxes are payable with silver dollars at the value quoted by the State Treasury, the residents of Utah would know that there is a “final buyer” for the coins.
Interesting that you find it necessary for a single large institution, in this case the state of Utah, to support the use of silver coins in order that widespread adoption be achieved. Despite your other writings in support of a “grass-roots” movement toward precious metal coins, you assume here that no such movement would be achievable without a large “final buyer”. I actually agree with this implicit assumption. Most of the populace does not know about all the forces trying to influence them. Indeed there are far too many!
However, insofar as a large institution is necessary for supporting the widespread adoption of silver coins, that institution does not necessarily have to be the state. Indeed, I could imagine a consortium of businesses willing to sell their wares and services in exchange for silver coins. If this consortium were large enough, it could establish the use of silver coins at the consumer level.
- The residents of Utah would be able to purchase these silver dollars for less that the Utah Treasury quoted value, on the US market, and tender them in payment at the quoted value. Thus, they would be able to get a discount on their payment of taxes.
The payment of taxes is but once a year. And although, I and many others would like to receive a discount on these coercive obligations, such a measure would introduce an unnecessarily cyclical aspect to the silver coin market. Demand for the coins would peak during tax season, and stagnate during the rest of the year. Unfortunately, under your proposed system of value quoting, it’s the yearly peak that would determine the quote.
Far better, I think, for goods and services to be paid in terms of silver coin. For these are items which I use more often. For example, If all the people in my apartment complex were to pay their monthly rent in silver coin, the price would be far less cyclical. As the demand and exchange of coins shall take place on a predictable, frequent, and stable schedule. Should the landlord accept silver at the quoted value, then it is the landlord which gives the discount. Not the state. In this manner the loss can be distributed and more easily borne. Indeed, as long as the landlord is interested in saving silver coins over the equivalent fiat, the discount will be granted as a “convenience of market conversion”.
- The proposed measure would draw silver dollars from the rest of the US, to Utah, where the silver dollars could be used to pay taxes with an effective discount.
This is an issue about Utah relative to the rest of the United States. Yes, silver dollars would be amassed by that institution which receives them as payment. If this were to be the state of Utah, then it would begin to amass coins in its treasury relative to other states. When the fiat Fed Reserve Note finally reach its intrinsic value, then Utah will find that it weathered the storm better than its neighbors. As good as this can be for Utah residents, it will likely breed resentment and discord to the Union itself.
However, if a multi-state consortium of businesses began to amass silver coins because they chose to accept such coins in exchange for goods and services, then it is the businesses in the consortium which will do well relative to others. Society is much more comfortable in disparity between businesses than in disparity between political regions. The sooner businesses join the bandwagon the better they shall do during a hyperinflation.
- The State Treasury, in that event, would bulge with silver dollars obtained at an overvalued price.
Is this a problem because the state has a limited budget? That the treasury can only afford to purchase so much at a discount before it runs out of … ? Or is it a problem of storage?
Any business which wishes to allow its customers to use silver coin for payment will be giving those customers a discount relative to the equivalent fiat. This discount should actually encourage the use of silver as payment. Effectively driving it into circulation. The business itself can choose to hoard the silver, or again turn it around and use it for payment of materials and employee salaries. Hopefully, enough businesses are within the consortium, that each is doing business with each other. In this situation the discount occurs at the interface between fiat and silver (the end customer) but all inter-business transactions would naturally occur via silver coins and so do not receive any net discount. Carrying out the inter-business transaction via silver coins (because they appear at a discount to fiat) will also lessen the need for centralized storage. Coins in circulation do not need a giant vault for warehousing.
Unlike the state, businesses actually produce something of value for their customers. So they can afford to discount some of their goods and services, with knowledge that, because they produce, they will not go bankrupt. For especially large businesses and those that would be severely hurt by hyperinflation, it would be a wise and prescient investment to participate in an early conversion to silver coins. Even though the discount might eat some of today’s profits, helping to prevent currency collapse is quite possibly the most responsible decision an owner could make to ensure continued operation of the business. Also, if the discount actually threatened the solvency of the business, it could then raise both fiat and silver prices, still keeping an apparent discount to its customers.
- Individuals wishing to own silver dollars would want to receive payment in Federal Reserve Notes, and purchase silver dollars at the US market price, which would be lower than the price quoted by the State Treasury.
Just as the state treasury is depleted by paying employees in Federal Reserve Notes while collecting silver coins at a discounted rate, so would any business in my proposed consortium fare poorly by paying its employees in fiat while its own products are purchased with silver. All businesses within the consortium will have to make some accounting changes in order that the difference between silver and fiat not drive it to insolvency. A business in this situation actually has more options than the state: it could retract by firing the lower performing employees, it could raise prices to pass this new operational cost on to customers, it could apply the same kind of discount to salaries that it does to customers, it could pay employees in silver only. If a silver mint or bank were in the consortium then it could broker a deal that would “share the loss”. The bank still remains interested in joining the consortium, because it will see an increase in its customer base, being one of the few and early places where consumers can change their fiat for coins in order to receive price discounts at other businesses.
Throughout my arguments I refer to a “consortium of businesses.” For you, of course, the most natural consortium would be those businesses which are under your influence. In so far as you still act as a guidance counselor or advisor, I think that you will be more successful converting the country to silver coin if you offer the silver coin discount on monthly bills to the subscribers to both your television and financial services first. Your businesses already touch the lives of more people, and on a daily basis, than the government could ever hope to reach. Don’t wait for the politicians. If you have the influence, use it now. Save the country and your businesses from currency collapse together.
Just read this interesting post[Polycentric Order: First Draft of Anarchic Iceland] about Icelandic history. Apparently, from 930 CE to 1096 CE, they had a tribal form of government with no really official rules. Just that the chieftans met for 2 weeks of each year to resolve disputes and re-establish boundaries. The rest of the people subscribed to different chieftans, as they saw fit.
Most importantly, an individual’s subscription to be bound by a specific chieftan’s rule was not based on geography. That is: the chieftancies were not determined via geographic boundaries. So, explicit war did not exist, because there wasn’t any physical territory to stake and claim. Individuals within the society commingled as they saw fit, and chieftains were obligated (via market forces) to serve their clients.
The situation changed in 1000 CE, with a Christian invader, who took hostage chieftan’s relatives until they might switch to the Christian religion. Eventually, through this coercive mechanism, Christianity became a rule of law (no chiefdom would allow you to remain unpledged) and churches established a geographical tax. With the new tie to the land, rulers now had a supply of funding (not subject to market forces) which they could use in the traditional statist manner: land grabs, war, etc. So long the stable anarchy, and welcome the violent and disruptive state!
The article concludes with an interesting lesson:
The lesson here, which is the same lesson that can be culled from other anarchistic societies, is that the Icelanders needed a theory of anarchy. They were living in anarchy, and it was truly glorious especially given the natural resources of Iceland, but they weren’t anarchists. They didn’t understand why their system worked so well, that it worked because of the infinite fallback and negative feedback mechanisms that are inherent in human interaction.
Without understanding this, it is inevitable that a stateless society will stumble into archon rule. For a stateless society to be maintained, it must have a widely accepted theory of anarchy and the ability to identify and oppose archons, and not be fooled when archons claim that they need them to fight other archons, and never to compromise with archons. The artificial man of the state is immortal, and waited 70 years to impose Christianity, another 96 years to impose the tithe, and another 168 years rule over Iceland altogether.
So anarchism, though immensely flexible in it’s distribution organization, does not necessarily have a built-in immunity against other (more coercive) forms of social assembly. Like the ideal democracy, it also requires a body of dedicated and informed participants.
Left open is the question: “How well could anarchy work today? Does it scale?” The free market seems to scale well. With proper rules of thumb and customary practices, the principles of the free market ought to be extensible to judicial and enforcement enterprises. Iceland had a good run with such a system (although 2 weeks per year would obviously not be enough as population expands), can we go back and try it again?
Note: David Friedman is one of the few people that I know to have investigated systems of law and enforcement through free market mechanisms.[Exploring Liberty: The Machinery of Freedom]
Through Denning’s Presentation Great Principles of Computing I heard of this fascinating tale regarding Buridan’s ass.
It refers to a hypothetical situation wherein an ass is placed precisely midway between a stack of hay and a pail of water. Since the paradox assumes the ass will always go to whichever is closer, it will die of both hunger and thirst since it cannot make any rational decision to choose one over the other.
What’s more interesting than the philosophy behind the donkey’s dilemma, are the actual applications:
Leslie Lamport calls this result Buridan’s principle, and states it as: A discrete decision based upon an input having a continuous range of values cannot be made within a bounded length of time.
…
A version of Buridan’s principle actually occurs in electrical engineering. Specifically, the input to a digital logic gate must convert a continuous voltage value into either a 0 or a 1 which is typically sampled and then processed. If the input is changing and at an intermediate value when sampled, the input stage acts like a comparator. The voltage value can then be likened to the position of the ass, and the values 0 and 1 represent the bales of hay. Like the situation of the starving ass, there exists an input on which the converter cannot make a proper decision, resulting in a metastable state. Having the converter make an arbitrary choice in ambiguous situations does not solve the problem, as the boundary between ambiguous values and unambiguous values introduces another binary decision with its own metastable state.
I think that it might be possible to turn this into an Information uncertainty principle, analogous to that of the physicist’s quantum uncertainty principle.
Specifically, an observer of a Turing machine calculation can only be in one of two scenarios:
- uncertain about the decision a computation will take within a given (determined) time, or
- certain about the decision, but uncertain about the time it takes to decide.
If the knowledge trade-off between two extremes can be quantified, in the same way that ħ quantifies the quantum uncertainty trade-off between position and momentum, we might really have something substantial!
|
|
