136 karma · joined June 14, 2007
My wife read lots of books. I read a few. With a few exceptions, the books have been a waste of time and money. So many of the books in this genre have the feel of the Learn Blub in 21 Days line of programming books. Accept from the get-go that parenting is hard, there are no silver bullets, and you are going to spend a lot of time and energy if you want to do a good job, and filter anything you read from that perspective.
Nevertheless, we did find some helpful books. The most useful books we have are a reference book given to us by our pediatrician and a book about baby sign language (The following link is to the revised edition, which is not the one we have, but it's cheaper on amazon http://www.amazon.com/Baby-Signs-Revised-Linda-Acredolo/dp/B...).
We went through a lot of "the book says" conversations early on, especially related to getting her to sleep. The thing to realize here is that it is up to you how to do it. There's a book out there that will support your position, and many of the books are contradictory. So, in the end, you'll end up having to decide what you think is right. The book many parents find useful is merely the one that reinforces their opinion, and they will use that book to appeal to authority in the passive-aggressive conversations that all new parents seem wont to have.
I had trouble finding what I felt like were unbiased opinions on sleep in particular. This book: http://www.amazon.com/Healthy-Sleep-Habits-Happy-Child/dp/03... was helpful, mostly because it more or less laid out three approaches and passed few, if any, value judgements on going to the baby vs. letting her cry herself to sleep.
In the end, I decided I couldn't stand to let her cry, so we settled on developing a very predictable routine at bedtime, and it has worked well. We have had our bumpy patches, particularly during illnesses, teething, and major milestones, but in general my child looks forward to bedtime and naps.
The sign language seems somewhat controversial among our peers, but we are in the less progressive southeastern US. The common fear is that it will retard speech. I just wanted to be able to communicate with my child, and it has made for a pleasant experience so far. She seems to be developing vocbulary at an above normal rate. I don't necessarily attribute that to signs, but it is at least one counterexample to the fear of significant speech retardation.
Techniques for finding a global optimum of a numerical function are expensive, time-consuming, and often find worse solutions before they find the best one. Do this in a startup, and your local-optimum-seeking competition will crush you.
Seems to me that thinking there is a better solution that your users don't know about (which led you to the local optimum) is exactly the lack of humility that Paul was warning against.
I also wonder if honesty might be another word for the skill in question - i.e., being honest with yourself about what works, what doesn't, and what's truly necessary.
Microsoft reputedly engages in a fair amount of this kind of inane patent activity.
The best hack I know for getting more done in the same amount of time is to exercise intensely for 45 minutes to an hour every other day. It's best for me when my muscles reach exhaustion during the workout. I need about 30 minutes to an hour to recover, but my mind feels sharper and my enthusiasm is much greater for the rest of the day and the following day. I try to go first thing in the morning.
There's obvious health benefits, but I think the biggest benefit for me is psychological/emotional.
Thanks for the question! I think it may have inspired me to increase my waning dedication to exercise.
The most interesting things I've ever done started with questions that began "I wonder if..."
Except that scalpels aren't really all that extensible.
See, I told you it was a black hole...
Except pg isn't selling anything, he's just letting you see and use what's ostensibly made his life easier.
I'd modify your simile to something more accurate, but modifying similes is a black hole.
You could ask on comp.lang.lisp if you wanted some really well-informed opinions wrt the impact of Arc on CL, but I wouldn't advise it unless your skin is thick and flame-resistant.
But mostly I just wanted to say that I thought the postscript was funny:
Windows Vista is flopping, and Mario Kart will be out for the Wii soon. I think the future will be okay.
Yes, Lisp is used to make toy programs like the software running on the $100 million 1998 Deep Space 1 probe.
Their final top-level function is:
(define (sqrt x)
(fixed-point-of-transform (lambda (y) (- (square y) x))
newton-transform
1.0)
Good luck figuring that out. I'm sure it was fun to decompose the problem into those functions, but in production two years from now some programmer is going to be in a world of pain when he has to add a feature to that program.That's only hard to read if you don't know Lisp. And the function names are quite descriptive if you understand numerical methods. If the hypothetical developer doesn't understand fixed points and Newton's method, he shouldn't be modifying that sqrt function anyway.
There might be a good point about obfuscation via abstraction somewhere in SICP, but this example isn't it. Even if it were, it has less to do with the language itself and more to do with the developer that designed the abstraction.
I suspect Mr. Kestleloot is simply ill-informed.
Seems to me that if you release early, you'll get more interesting[1] feedback while your app is in a nascent stage and you can more easily change direction.
[1] By interesting, I'm mean that the feedback on a more fully developed release is more likely to be of the window-dressing, change-this-font-to-helvetica-16 type, while feedback for the early release will often be directed at adding desirable features.
would be funnier.
http://www.amazon.com/Kinesis-Advantage-USB-Keyboard-black/d...
You can work hard at anything. Playing an instrument isn't something I consider work, but it takes hard work to become one of the top musicians in the world.
Consistently trying to be the best at something rather than just accepting mediocrity is important, and not a lot of people have that drive. It's the kind of thing that keeps you from having to tar roofs for a living.
>You make the rest of us wish we were still there.
You must have me confused with someone else. I'm not a student.
The biggest problem was that the best players in the world weren't playing in the XFL. Div I-A college football doesn't have that problem. The lower divisions do, though. I doubt many Div I-AA or Div II coaches are making $1MM.
The average joe can watch weekly football games and judge for himself whether a team looks disciplined and prepared.
CEO performance is documented in complex financial reports released once a quarter. The reports aren't as readily available as nationally televised football games, and the connection to the CEO's contributions isn't as immediately obvious. Also, recent history is replete with incidents where the bottom unexpectedly dropped out of a company because of unbeknownst-to-the-public mistakes or transgressions committed under the CEO's watch.
I think public perception about the differences in transparency is what drives distrust in CEO's but not in college coaches.
Of course, there are other outlets for working hard, but for many Americans, high school and later college present the most obvious and most consistent opportunities to do so. In fact, the author may have even learned how to work hard in college if he didn't already have that ethic.
OTOH, there is no excuse for sloppy programming under the mantra of iterative development. Code is usually better when you've taken a little time to think about how to solve the problem at hand.
I do think that Dijkstra's expectations are a bit lofty for the general population of programmers, though. For a large class of us, the biggest problem is just getting started. For me, it's a lot easier to get into flow by tinkering with some part of a program than to try to put the whole thing together in my mind. By the end, I usually have a large chunk of the app in my head. The expectation that every keystroke must be perfect from the outset would be enough to discourage me from even starting.
For the last ten years, I've programmed user interfaces for folks with high school educations to run complex chemical plants and refineries, and I've seen that an easy-to-understand interface has at least as much importance as the algorithms that underly the interface.
Funny, I assumed the opposite. A lot of his comics about relationships resonate with the self image I had before I married.
The killer part of the app is that it offers the ability to bet online and get quick gratification. Draftmix hits the action player's sweet spot, and I suspect apps in this area will drastically outperform their season-long counterparts. Anyone familiar with gambling economics knows that the action players and casual gamers drive the economy.
The argument about skill vs. chance in the comments of the TechCrunch article is interesting. I think it's easy to make a compelling argument that success in the short term format might require more skill than season long formats, but legislators have demonstrated that compelling arguments hold less value than one might think they should.
http://www.newscentre.bham.ac.uk/press/2007/10/24Oct07Turing...
http://www.nature.com/news/2007/071024/full/news.2007.190.ht...
The second link is particularly informative.
"I asked him why he'd worked on it. He said he'd seen it as a nice puzzle. That at first he was pretty sure the Turing machine's behavior was simple enough that he could prove that it wasn't universal. But then, as he studied it, he realized that there were little bits of behavior that were more complicated. And it was with these that he managed to show universality."
Just another data point in favor of tinkering, I guess.
Also, the less skilled programmer is going to have a hard time winning projects when his proposals are double the budget and four times the schedule length of yours.
That was the point I was trying to make, apparently unsuccessfully.
>If you don't use Lisp, or if you don't use S-expressions, you will need to lex and parse the configuration file just to read it, compiler or no compiler.
Any time you build a lexer and a parser, you are building a compiler (I'm using a broader meaning of compiler - not necessarily one that outputs bytecode). There are many XML-to-HTML compilers, for example.
Lisp macros compile DSL's to Lisp. That's why a Lisp programmer rarely needs to think about lexing and parsing. It is automatic and implied if you address the problem in the right way. It's also why the concepts of data and programs are necessarily conflated in Lisp.