You know, this really calls for a cartoon-y cliche “light bulb turning on” appearing over byrnema’s head.
It’s interesting the little connections that are so hard to make but seem simple in retrospect. I give it a day or so before you start having trouble remembering what it was like to not see that idea, and a week or so until it seems like the most obvious, natural concept in the world (which you’ll be unable to explain clearly to anyone who doesn’t get it, of course).
SICP is nice if you’ve never seen a lambda abstraction before; its value decreases monotonically with increasing exposure to functional programming. You can probably safely skim the majority of it, at most do a handful of the exercises that don’t immediately make you yawn just by looking at them.
Scheme isn’t much more than an impure, strict untyped λ-calculus; it seems embarrassingly simple (which is also its charm!) from the perspective of someone comfortable working in a pure, non-strict bastardization of some fragment of System F-ω or whatever it is that GHC is these days.
Haskell does tend to ruin one for other languages, though lately I’ve been getting slightly frustrated with some of Haskell’s own limitations...
Sorry for the late reply; I don’t have much time for LW these days, sadly.
Based on some of your comments, perhaps I’m operating under a different definition of group vs. individual rationality? If uncoordinated individuals making locally optimal choices would lead to a suboptimal global outcome, and this is generally known to the group, then they must act to rationally solve the coordination problem, not merely fall back to non-coordination. A bunch of people unanimously playing D in the prisoner’s dilemma are clearly not, in any coherent sense, rationally maximizing individual outcomes. Thus I don’t really see such a scenario as presenting a group vs. individual conflict, but rather a practical problem of coordinated action. Certainly, solving such problems applies to any rational agent, not just humans.
The part about giving undue weight to unlikely ideas—which seems to comprise about half the post—by mis-calibrating confidence levels to motivate behavior seems to be strictly human-oriented. Lacking the presence of human cognitive biases, the decision to examine low-confidence ideas is just another coordination issue with no special features; in fact it’s an unusually tractable one, as a passable solution exists (random choice, as per CannibalSmith’s comment, which was also my immediate thought) even with the presumption that coordination is not only expensive but essentially impossible!
Overall, any largely symmetric, fault-tolerant coordination problem that can be trivially resolved by a quasi-Kantian maxim of “always take the action that would work out best if everyone took that action” is a “problem” only insofar as humans are unreliable and will probably screw up; thus any proposed solution is necessarily non-general.
The situation is much stickier in other cases; for instance, if coordination costs are comparable to the gains from coordination, or if it’s not clear that every individual has a reasonable expectation of preferring the group-optimal outcome, or if the optimal actions are asymmetric in ways not locally obvious, or if the optimal group action isn’t amenable to a partition/parallelize/recombine algorithm. But none of those are the case in your example! Perhaps that sort of thing is what Eliezer et al. are working on, but (due to aforementioned time constraints) I’ve not kept up with LW, so you’ll have to forgive me if this is all old hat.
At any rate, tl;dr version: wedrifid’s “Anything an irrational agent can do due to an epistemic flaw a rational agent can do because it is the best thing for it to do.” and the associated comment thread pretty much covers what I had in mind when I left the earlier comment. Hope that clarifies matters.
Booleans are easy; try to figure out how to implement subtraction on Church-encoded natural numbers. (i.e., 0 = λf.λz.z, 1 = λf.λz.(f z), 2 = λf.λz.(f (f z)), etc.)
And no looking it up, that’s cheating! Took me the better part of a day to figure it out, it’s a real mind-twister.
The history in the paper linked from this blog post may also be enlightening!
It’s also worth noting that Curry’s combinatory logic predated Church’s λ-calculus by about a decade, and also constitutes a model of universal computation.
It’s really all the same thing in the end anyhow; general recursion (e.g., Curry’s Y combinator) is on some level equivalent to Gödel’s incompleteness and all the other obnoxious Hofstadter-esque self-referential nonsense.
Are you mad? The lambda calculus is incredibly simple, and it would take maybe a few days to implement a very minimal Lisp dialect on top of raw (pure, non-strict, untyped) lambda calculus, and maybe another week or so to get a language distinctly more usable than, say, Java.
Turing Machines are a nice model for discussing the theory of computation, but completely and ridiculously non-viable as an actual method of programming; it’d be like programming in Brainfuck. It was von Neumann’s insights leading to the stored-program architecture that made computing remotely sensible.
There’s plenty of ridiculously opaque models of computation (Post’s tag machine, Conway’s Life, exponential Diophantine equations...) but I can’t begin to imagine one that would be more comprehensible than untyped lambda calculus.
I must add that many of the objections I have to using C++ also apply to C, where complexity based problems are obviously excluded. Similarly, any reasons I would actually suggest C is worth learning apply to C++ too.
Using C is, at times, a necessary evil, when interacting directly with the hardware is the only option. I remain unconvinced that C++ has anything to offer in these cases; and to the extent that C++ provides abstractions, I contend that it inhibits understanding and instills bad habits more than it enlightens, and that spending some time with C and some with a reasonably civilized language would teach far more than spending the entire time with C++.
Java and C# are somewhat more tolerable for practical use, but both are dull, obtuse languages that I wouldn’t suggest for learning purposes, either.
Even while using Ruby (and the flexibility of duck-typing) I have discovered that the limitation to single inheritance sometimes requires inelegant work-arounds. Sometimes objects just are more than one type.
Well, the problem isn’t really multiple inheritance itself, it’s the misguided conflation of at least three distinct issues: ad-hoc polymorphism, behavioral subtyping, and compositional code reuse.
Ad-hoc polymorphism basically means picking what code to use (potentially at runtime) based on the type of the argument; this is what many people seem to think about the most in OOP, but it doesn’t really need to involve inheritance hierarchies; in fact overlap tends to confuse matters (we’ve all seen trick questions about “okay, which method will this call?”). Something closer to a simple type predicate, like the interfaces in Google’s Go language or like Haskell’s type classes, is much less painful here. Or of course duck typing, if static type-checking isn’t your thing.
Compositional code reuse in objects—what I meant by “implementation inheritance”—also has no particular reason to be hierarchical at all, and the problem is much better solved by techniques like mixins in Ruby; importing desired bits of functionality into an object, rather than muddying type relationships with implementation details.
The place where an inheritance hierarchy actually makes sense is in behavioral subtyping: the fabled is-a relationship, which essentially declares that one class is capable of standing in for another, indistinguishable to the code using it (cf. the Liskov Substitution Principle). This generally requires strict interface specification, as in Design by Contract. Most OO languages completely screw this up, of course, violating the LSP all over the place.
Note that “multiple inheritance” makes sense for all three: a type can easily have multiple interfaces for run-time dispatch, integrate with multiple implementation components, and be a subtype of multiple other types that are neither subtypes of each other. The reason why it’s generally a terrible idea in practice is that most languages conflate all of these issues, which is bad enough on its own, but multiple inheritance exacerbates the pain dramatically because rarely do the three issues suggest the same set of “parent” types.
Consider the following types:
Tree structures containing values of some type A.
Lists containing values of some type A.
Text strings, stored as immutable lists of characters.
Text strings as above, but with a maximum length of 255.
The generic tree and list types are both abstract containers; say they both implement using a projection function to transform every element from type A to some type B, but leaving the overall structure unchanged. Both can declare this as an interface, but there’s no shared implementation or obvious subtyping relationship.
The text strings can’t implement the above interface (because they’re not parameterized with a generic type), but both could happily reuse the implementation of the generic list; they aren’t subtypes of the list, though, because it’s mutable.
The immutable length-limited string, however, is a subtype of the regular string; any function taking a string of arbitrary length can obviously take one of a limited length.
Now imagine trying to cram that into a class hierarchy in a normal language without painful contortions or breaking the LSP.
I’m interested in where you would put C++ in this picture. It gives a thorough understanding of how the machine works, in particular when used for OO programming.
“Actually I made up the term “object-oriented”, and I can tell you I did not have C++ in mind.”—Alan Kay
C++ is the best example of what I would encourage beginners to avoid. In fact I would encourage veterans to avoid it as well; anyone who can’t prepare an impromptu 20k-word essay on why using C++ is a bad idea should under no circumstances consider using the language.
C++ is an ill-considered, ad hoc mixture of conflicting, half-implemented ideas that borrows more problems than advantages:
It requires low-level understanding while obscuring details with high-level abstractions and nontrivial implicit behavior.
Templates are a clunky, disappointing imitation of real metaprogramming.
Implementation inheritance from multiple parents is almost uniformly considered a terrible idea; in fact, implementation inheritance in general was arguably a mistake.
It imposes a static typing system that combines needless verbosity and obstacles at compile-time with no actual run-time guarantees of safety.
Combining error handling via exceptions with manual memory management is frankly absurd.
The sheer size and complexity of the language means that few programmers know all of it; most settle on a subset they understand and write in their own little dialect of C++, mutually incomprehensible with other such dialects.
I could elaborate further, but it’s too depressing to think about. For understanding the machine, stick with C. For learning OOP or metaprogramming, better to find a language that actually does it right. Smalltalk is kind of the canonical “real” OO language, but I’d probably point people toward Ruby as a starting point (as a bonus, it also has some fun metaprogramming facilities).
ETA: Well, that came out awkwardly verbose. Apologies.
C is good for learning about how the machine really works. Better would be assembly of some sort, but C has better tool support. Given more recent comments, though I don’t think that’s really what XiXiDu is looking for.
Dijkstra’s quote is amusing, but out of date. The only modern version anyone uses is VB.NET, which isn’t actually a bad language at all. On the other hand, it also lacks much of the “easy to pick up and experiment with” aspect that the old BASICs had; in that regard, something like Ruby or Python makes more sense for a beginner.
Well, they’re computer sciencey, but they are definitely geared to approaching from the programming, even “Von Neumann machine” side, rather than Turing machines and automata. Which is a useful, reasonable way to go, but is (in some sense) considered less fundamental. I would still recommend them.
Turing Machines? Heresy! The pure untyped λ-calculus is the One True Foundation of computing!
I’m inclined to agree with your actual point here, but it might help to be clearer on the distinction between “a group of idealized, albeit bounded, rationalists” as opposed to “a group of painfully biased actual humans who are trying to be rational”, i.e., us.
Most of the potential conflicts between your four forms of rationality apply only to the latter case—which is not to say we should ignore them, quite the opposite in fact. So, to avoid distractions about how hypothetical true rationalists should always agree and whatnot, it may be helpful to make explicit that what you’re proposing is a kludge to work around systematic human irrationality, not a universal principle of rationality.
All else equal, in practical terms you should probably devote all your time to first finding the person(s) that already know the private keys, and then patiently persuading them to share. I believe the technical term for this is “rubber hose cryptanalysis”.
Well, I admit that my thoughts are colored somewhat by an impression—acquired by having made a living from programming for some years—that there are plenty of people who have been doing it for quite a while without, in fact, having any understanding whatsoever. Observe also the abysmal state of affairs regarding the expected quality of software; I marvel that anyone has the audacity to use the phrase “software engineer” with a straight face! But I’ll leave it at that, lest I start quoting Dijkstra.
Back on topic, I do agree that being able to start doing things quickly—both in terms of producing interesting results and getting rapid feedback—is important, but not the most important thing.
Hey, maybe they’re Zen aliens who always greet strangers by asking meaningless questions.
More sensibly, it seems to me roughly equally plausible that they might ask a meaningful question because the correct answer is negative, which would imply adjusting the prior downward; and unknown alien psychology makes me doubtful of making a sensible guess based on context.
adjusted up slightly to account for the fact that they did choose this question to ask over others, seems better to me.
Hm. For actual aliens I don’t think even that’s justified, without either knowing more about their psychology, or having some sort of equally problematic prior regarding the psychology of aliens.
I have to disagree on Python; I think consistency and minimalism are the most important things in an “introductory” language, if the goal is to learn the field, rather than just getting as quickly as possible to solving well-understood tasks. Python is better than many, but has too many awkward bits that people who already know programming don’t think about.
I’d lean toward either C (for learning the “pushing electrons around silicon” end of things) or Scheme (for learning the “abstract conceptual elegance” end of things). It helps that both have excellent learning materials available.
Haskell is a good choice for someone with a strong math background (and I mean serious abstract math, not simplistic glorified arithmetic like, say, calculus) or someone who already knows some “mainstream” programming and wants to stretch their brain.
Eh, monads are an extremely simple concept with a scary-sounding name, and not the only example of such in Haskell.
The problem is that Haskell encourages a degree of abstraction that would be absurd in most other languages, and tends to borrow mathematical terminology for those abstractions, instead of inventing arbitrary new jargon the way most other languages would.
So you end up with newcomers to Haskell trying to simultaneously:
Adjust to a degree of abstraction normally reserved for mathematicians and philosophers
Unlearn existing habits from other languages
Learn about intimidating math-y-sounding things
And the final blow is that the type of programming problem that the monad abstraction so elegantly captures is almost precisely the set of problems that look simple in most other languages.
But some people stick with it anyway, until eventually something clicks and they realize just how simple the whole monad thing is. Having at that point, in the throes of comprehension, already forgotten what it was to be confused, they promptly go write yet another “monad tutorial” filled with half-baked metaphors and misleading analogies to concrete concepts, perpetuating the idea that monads are some incredibly arcane, challenging concept.
The whole circus makes for an excellent demonstration of the sort of thing Eliezer complains about in regards to explaining things being hard.
My interpretation was to read “value” as roughly meaning “subjective utility”, which indeed does not, in general, have a meaningful exchange rate with money.