Actually, discovered ledger-cli here last week (thanks HN). It's amazing. Abstracting currency to the concept of commodity + price files makes it trivial to track your shares in 401k, and have the current market value print on the balance report. Handles lots. Recurring transactions support period specifications like "every two weeks starting on 2013/10/01". Maps payee's to accounts, and supports payee aliases. Pretty much anywhere you type a string you can also use a regex. State is a text file and the program does not alter state; just reads it and prints out a report. Finally, it provides a CSV convert which makes it easy to convert an export from your bank to a list of double entry transactions (./convert bk_download.csv >> trx.dat).
I found it interesting how radically different his teaching premise is from the current U.S. public school approach. From the preface:
I thought to address them to the most intelligent in the class and to make sure, if possible, that even the most intelligent student was unable to completely encompass everything that was in the lectures.
If I recall the introduction correctly, the lectures were kindof a failed pedagogical experiment because of this - it worked well for the best students, but the mediocre/worse students did a fair amount worse than in previous years. I don't think Caltech continued to teach the first two years in the Feynman style after this.
But regardless, the lecture series is a wonderful overview on the actual physics, even if it doesn't work that well as a straight textbook.
Failed experiment or no, it's probably the single most influential set of undergraduate physics classes ever taught. Grad students attened these classes too, and nearly everyone in the field has a copy of these lectures sitting on the shelf.
They're not a singular reference, but they're really good. His rachet and pawl lecture is timeless.
These lectures are awesome if you have already encountered the material and want to start over from scratch really internalizing it this time. If you use them as a first-time learner you are likely to be pretty confused.
As a family friend once said to me, when I was a student (I studied physics before switching to Computer Science): "The Feynman Lectures are wonderful. While you are actually physically reading them, you feel as if you understand."
It is -- but you still do have to be aware if the objects in your collection are also immutable... if so, you may end up with an "immutable" list of 5 objects, and down the line it will still have those 5 objects, but the objects themselves may have completely different internal data.
Referring partly to your parent comment... it's instructive to look at the String implementation.
It's immutable, but they have to jump through a few hoops to do it properly... internally, a String has a private char array. An array is not immutable, so the code has to be very careful to never expose that char array externally.
Because of that, calling toCharArray() will copy the internal array and return the copy -- that one's fairly obvious. But less obviously, a String constructed with a char array must also make a copy... otherwise the calling code might then modify the array after creating the String with it.
So sure, immutable objects are possible, and widely encouraged in Java, but they're easy to do wrongly/incompletely.
The models certainly contributed. (Note: I have read this far in the book.)
The modeling error in question was independence; that is, if you have five mortgages, each with a 5% change of default, then these can be packaged up as an AAA security as follows: you only lose your money if all five default. A bit riskier package is that you lose if 4/5 default. And so on, each with different returns.
If they are independent, the p(default) = 1/20^5. If they are dependent, it is 1/20. Now multiple mortgage pool size by a 100 or 1,000 or 10,000 (?) and see how far off the estimated risk is. :)
Now combine this with a 30-to-1 leverage when buying these "AAA" securities.
(This was quite a good problem to work through with my daughter to see what that little "independence" assumption means. :)
His main point here was that modeling failures are typically due to out-of-sample conditions; when the housing bubble broke, the markets were might more tightly coupled across the country than the modelers assumed. While they could have seen this kind of dependence if they looked to Japan, there was no such precedence in the US in recent history.
This is a beginner mistake which I have a hard time believing the entire mortgage market failed to spot.
My personal belief is that they knew of the flaw of the models but did not care since their personal incentives were more profitable if the model was not fixed.
As Michael Lewis found in the Big Short. His Liar's Poker (from the 80's) explains the mentality. As he says in the former, he thought the latter would be the be-all end-all.
But the kids in Business School would constantly write him and ask him for new ways to rig the game.
> (A) assume the comments are correct and skip reading what the code does?
Yes, unless I was working on that particular piece of code. There's often far too much code in a code base to waste time reading it all, and reading the comments can provide quick understanding.
> The first seems awfully risky to me and poor advice to any programmer trying to write solid code.
Why? Bad code is bad code. Writing bad comments (or no comments) means you're writing bad code. Don't write bad code, and then write documentation to help yourself think through why it's not bad code, and tests to both help you think through it, and verify that it's not bad.
The historical bit about NASA using event-sourced design for the Apollo Program (1969) was pretty interesting. He gives IBM big props for hitting 2,300 transactions/second in the mid-60's (with IMS aka DB1).
@17:15
"We've forgetting a lot of this good stuff in our modern designs."
@17:34
"Transaction queues, pulling things off, uncontended, and processing them."
@17:50
"Some of the systems we have today are woeful and can't even get close to that, considering the hardware we have today, and it's ... how we are writing contended designs"
The Plan 9 web pages are really good (if dense).
If you write in Go, check out github.com/rminnich/go9p.
For a deep dive, "A Cached WORM File System" is a good read [http://doc.cat-v.org/plan_9/misc/cw/].