thinkingeric

The 'us too' quality of that blog post is disturbing. They don't need to defend their architecture choices against people who naively assume that OO is an appropriate paradigm for all domains. The list of how 'design patterns' are really in there somewhere is particularly off-putting. I didn't like developing for Drupal, but I certainly support their right to do the things in the way they think is best for the problems they are trying to solve.

Ditto that. My first programs were in assembly on the 6502, and I'm thrilled to see it getting this attention. I'm just sorry that I don't still have the KIM-1.

The premise of RWDWS is flawed by assuming that the secondary market in stocks is 'free'. This book was published in 1973, and after the 'analytic' schemes of the 1960s (and continuing in the 70s), it had obvious appeal. What it did not account for was government manipulation of financial markets through (de)regulation. For example, the Monetary Control Act of 1980 and the expansion of IRA coverage under ERTA in 1981 opened the flood gates to the securities markets and intensified the Ponzi-scheme nature of securities 'investing'. Prior to the publishing of RWDWS, it is reasonable to claim that the stock market was a arena for transferring risk, not pretending to be a savings institution. Something else to bear in mind is that there are little or no real alternatives to 'funds', and this exaggerates the influx of capital into them. The idealized view of stock and bond trading fails to fully account for the transaction costs, which are largely hidden, and this 'vigorish' makes it a losing game eventually. The costs associated with funds ('index' or otherwise) are also carefully and skillfully masked, but it is easier to market the diversification arguments. There's a reason that the 'financial industry' is so profitable: http://chartingtheeconomy.com/?p=665 It's an increasingly elaborate wealth transfer mechanism.

"I can just never do anything fun with it"

Writing 'useful and compatible libraries' isn't fun?

Repeated so soon?

http://news.ycombinator.com/item?id=2007504

In my code, where the binding forms would typically be longer than (a 1) or (b 2), they each go on their own line, and the editor will align them by their left parentheses. In those cases where the initialization form needs to be broken into another line, the editor will indent the continuation properly, and the 'terminating' parenthesis is actually a helpful visual cue that the form is done.

I haven't written any Clojure so I'm not sure how my brain would react to non-delimited forms (ie, the implicit pairs). I also don't know how Emacs handles the indentation for these, or whether in more complicated cases, my brain would have to work harder to group the binding forms. I read the Clojure specs on 'let' and it appears to be a somewhat different beast than the CL 'let'. In more complicated cases, it doesn't appear to be an apples-to-apples comparison in terms of parsing the 'shape' of the expressions.

For experienced programmers, the clearest introduction to Common Lisp is the first few chapters of "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp" by Peter Norvig. His writing style is exceptional. Not quite so clear, but also not too dense, is "ANSI Common Lisp" by Paul Graham. Peter Seibel's "Practical Common Lisp" is dense (words per page), but is good for a "now I know a little Lisp, what can I do with it" book to read second. Winston's "Lisp (3rd)" goes from an extremely basic intro to heavy-duty AI without building up to it. But you can get it cheap, so it is worth it for a beginning reference.

As a sidenote, when you first look into Lisp, you hear a lot of kvetching and mocking about parentheses. And indeed, there is a point in the learning curve where you get confused about the proper numbers of parentheses for certain kinds of expressions (so-called 'special forms'). And you see Lisp apologists countering that it's not the parentheses that matter; rather the indentation is what helps you understand the code.

In my experience, what happens is that as you become familiar with these 'special forms', you learn to recognize the visual patterns of indentation and parentheses that are particular to each of these expressions. And once you write a number of them yourself, grokking the code of others is no problem. And as in all languages, a decent editor and syntax coloring is helpful.

"They were not built to solve a business need"

That's not quite correct. It is perhaps more accurate to say they weren't built to solve your primary business need. They certainly solve the problem of getting unskilled people to be productive at some level. And this is not a trivial consideration. It takes a great deal of effort, time, and expertise to design a system that maximizes programmer productivity, such that an ideal minimum number of 'programmer-hours' is all that is required to augment and maintain it. And when you do, it is likely that it requires 'wizard level' programmers to put in those hours. Expertise is expensive, hard to find, and presents a certain replacement risk for an employer.

The alternative is more dumbed-down systems. The code is less elegant or clever, but easier to understand and imitate. And the 'brutish' nature of such code leads to a certain amount of repetition, which requires more 'programmer-hours' to work on. Hence the need for more developers. As many folks have pointed out, programming today is very much a social activity. The systems themselves are partly responsible for this. There is a need for developers to be 'hot swappable'.

And the staffing pressures are partly what are responsible for the popularity of frameworks, for similar reasons. Frameworks are development languages that sit on top of programming languages. In many cases, you barely even need to know the underlying programming language in order to produce fairly sophisticated results. In contrast, to be productive in programming languages, you need to have a fairly deep understanding of your craft and have a good bit of experience in the quirks of that language.

Frameworks are like DSLs for a technical domain. While it can take some time to learn the framework language, you can produce more, faster than if you have to build software from scratch (or using just libraries). But what are you producing? As the author says, they are built for "20,000 or 200,000" developers. Not you. And not your problem. They may solve common problems, but they don't necessarily solve your particular problem in the most appropriate way. You may need to rethink your problem to fit what the framework can accommodate. Or face the staffing dilemma.

Over two decades of programming, I've read most of the books listed in this thread. Some of them contain real pearls, while others are undeservedly popular. In my opinion, each language is suited to (and perhaps designed for) certain kinds of problems. There is no 'general' software design approach. Each language has developed its own idioms and patterns, which are best learned by tracing through production code of competent programmers who are solving problems that are somewhat similar to yours. Most books actually need to be taken with a grain of salt, as they often sound more authoritative and general than they really are.

You can buy historical 'tick data'. Be forewarned, however, that simulations run on this kind of data are not the same as real trading since it doesn't reflect the bid/ask. Also in my opinion and experience, price alone is insufficient data for analysis. Also don't forget to figure in total execution cost as it makes a huge difference in the evaluation of algorithms, not to mention the 'bank roll' necessary to allow any 'edge' to play out. Trading simulations are an engaging software problem, but they aren't such a great approximation of actual trading, at least in my experience.

This is true of practically any endeavor. Mr. Shaw's example applies to learning as well as teaching. Since he plays guitar, he probably appreciates the larger implications of what he's done with LPTHW.

You are fighting a losing battle. Drive and focus are either an integral part of who you are, or they aren't. Enjoy tinkering around, but you should adjust your expectations on the outcome. I know and work with lots of 'dabblers'. They are nice people, but don't have any understanding of what goes into mastering something. Same holds true for musical instruments. Lots of people 'dream' of playing, but have no clue how many thousands of times you have to repeat hand movements and listening until you rise above that and can work on the 'music'. Countless hours, constant trade-offs, and arguably abnormal mental faculties are required.

Build in whatever the people who are going to maintain it after you've moved on are comfortable with .... if you still bear some responsibility at that point.

Practical? Yes. Desirable? Depends on who is going to maintain it.

I have a 3yo and 14mon old. Just about everything revolves around them, except for a precious couple of hours in the evening, when I have to decide between programming etc. and cleaning up. Because of professional demands on my time (tech lead at web dev shop), my wife ends up bearing a much larger share of the responsibilites for the household than either of us would like. If there isn't some kind of professional pot o' gold after all my effort, the inequity will just seem unfair -- and in retrospect I will just look like a typical selfish guy. The fussing seems constant sometimes, which is wearing on the nerves. Although I do spend several hours with the kids everyday (daycare exit to bed time), I'm too tired to be the engaged parent that I thought I would. "Inspiration .... to do more"? Absolutely. The financial pressure has increased tremendously. But these are 'the rough times' .... right?

As a manager I can tell you that I am looking for any clues I can find to mitigate the risk of bringing on a new person. "Experience' means very little if I have no way of assessing what a prospective employee/contractor did in those previous jobs. You need 'evidence' more than you need experience; evidence of your language and problem solving skills; evidence of your communication skills; evidence of your motivation and interests.

Eric