arakyd
I program in C#, and lambdas and delegates are nice (I can't use expression trees because the company I work for standardizes on .NET 2.0). But the system is too gnarly, still verbose as fuck, and nowhere near as nice as Lisp (as Krishnan freely admits). This just increases the need for sophisticated developer tools and makes things more obscurantist, not less. C# is just another variation on Java, i.e. a way to drag Elvis types 10% closer to Lisp without depriving them of their oh so precious ALGOL syntax.
Fuck the priesthood, seriously.
I blame Alan Kay for inventing a new paradigm and then not explaining how it was supposed to be used (it's like Lisp meets biology!), thus allowing it to be taken over by others who filled the vacuum with a multitude of their own (usually half-baked) ideas bastardized implementations, and "software architect" positions.
The best thing about Forth is that it's the distilled result of decades of iteration on a complete programming environment by a great programmer. I don't know of any other examples of this. The worst thing about Forth is that it will probably die with Chuck and be mostly lost.
The Cartoon Guide to Statistics is an excellent way to go from zero to a good overview of the basics with a minimum of hard math. After that, if you're mostly interested in applying basic techniques to your own stuff, you want a good undergrad textbook. I don't have any good recommendations here, unfortunately. If you have a good math background (or are motivated to get it) and you want to keep going, Statistical Models; Theory and Practice by David A. Freedman (http://www.amazon.com/review/R2XUNM92KYU7BB) has the math, the philosophy, the hands on analysis of studies, and the exercises to put you in a better position to evaluate statistical research than some people who produce it.
The problem is not having to deal with software APIs, the problem is the sheer size of the stack and the sheer number of accumulated assumptions that are built into it. Moving more pieces into hardware might improve the stack's overall integrity and reduce bugs, but it won't do much to reduce the size.
The real issue, IMHO, is that no one wants to admit that the general reuse problem is hideously, horrifyingly difficult. The biggest problems it causes are diffuse and long term, and in the short term everyone can do things faster by hacking together their old code with someone else's 95% solution library, so that's what everyone does. Putting enough thought into each new application to really do it right tends to be hard to justify on a business level, and most programmers have neither the inclination nor the skill to do it anyway. It's so ingrained that even people who are frustrated with the way things are think that a different operating system or language would solve the problem. It wouldn't - it would only start the process again, with at best a percentage reduction in stack size and corresponding percentage increase in time to frustration. I think it boils down to the fact that code reuse is basically a 2^n problem, and the bigger and more opaque the stack gets the harder it is to cheat that 2^n.
The only potential solution I've seen is what Chuck Moore is doing with Forth chips. He's now at the point where he can design and manufacture chips that are cheap and simple in design but are very good at running Forth very quickly. Of course the tradeoffs are (perhaps necessarily) as horrifying as the reuse problem in that it demands a lot more from programmers in general, and in particular requires them to learn a radically different way of doing things than they are used to while at the same time strongly discouraging reuse at the binary and source levels. In other words, he's spent decades designing a small core language and hardware to run it, and that's really all you should be reusing (along with data transfer protocols). Needless to say, no desktop or web or server programmer (or said programmer's boss or company) is ever going to go for this unless problems with reuse become far worse than they are now. (Even then the supply of cheap programmers might grow fast enough to keep masking the problem for a long time.) Most programmers are not very good, managers like it that way, and most of the smarter programmers are nibbling around the edges or looking for a silver bullet.
In short, there are no easy solutions. If you don't like the direction software is going, think about becoming an embedded systems programmer.
Confusion about this stuff is a sign that you didn't really understand it the first time. Believe me, I've been (am still) there...
A few planes have been built with the Coanda effect in mind (http://en.wikipedia.org/wiki/Boeing_YC-14), but in general it isn't very important.
Jeff's post and your comment both confuse me on this point - I can't figure out when either of you are talking about quality of implementation (when I read "code" I think implementation) and when you're talking about quality of user experience. I'm not even sure if you and Jeff are saying the same thing. Jeff spends most of his post talking about bad user experiences caused by programs written by people who are probably not experts, but then he ends by saying that all programmers should hate their own code. I, and most people on HN apparently, interpret this to mean that we should all hate the quality of our implementations. Not only is this weird on it's face (surely many people who read Jeff's blog, let alone HN, have seen worse code than what they usually write themselves), but it doesn't seem to follow from the rest of the post. My reading of your comment leads me to believe that you dislike all code/implementations on general principle, but I can't tell if you even refer to the user experience at all. The second to last sentence seems to, but I can't figure out how the rest of the comment relates to it because the rest of the comment seems to be purely about implementation (except for the reference to the Wizard of Oz, which is completely ambiguous in that regard as far as I can tell).
My experience seems to be different than yours. I might have thought of software as magic when I was exposed to computers for the very first time, but as soon as I learned a little bit about how they worked none of it was really "magic" any more. A good user experience might be smooth, or quick, or intuitive, or even delightful, but I don't see it as magic. Occasionally I see something and I don't know how it was done, and it that case I want to know. I want to look under the covers, just like I wanted to know how computers worked. The connotations of "magic" hardly arise, because I immediately move past the "I can't believe that works!" stage to the "how does it work?" stage. I assume (or in the case of computers, know) there is machinery under the covers even before I see it, and I want to see it. There is nothing necessarily repulsive about the machinery to me, and in fact the machinery has its own beauty that is largely independent of the user experience. My ideal piece of software delivers a fantastic user experience with beautiful machinery, but I understand that beauty in one part does not necessarily imply beauty in the other. The user experience is generally more important than the quality of the code, but there is no law that says code has to be repulsive. We seem to disagree about that.
I would not say that my own code was the worst I've ever seen, but I am always dissatisfied with it and with the user experience it delivers because I always think it could be better. I completely agree with Jeff's Parnas quote, and I also agree that Jeff is probably an incompetent programmer in the judgement of Parnas and others like him. So I maybe I agree with Jeff's intended point. On the other hand, I think Jeff has delivered some pretty good user experiences, and I think many programmers who really don't produce great code and/or create a net increase in programmer demand can and do deliver decent, or even fantastic, user experiences. (This is probably one of the reasons why we have so many incompetent programmers and don't live in Parnas's ideal world. Relatively incompetent programmers can still deliver good user experiences, so in the short term it's expedient to deliver software that way. In the long term, we have a shit ton of deeply stacked shit and all the really good programmers are spending their time making shit shoveling tools instead of advancing the state of the art, but hey. Just another tradeoff.)
Speaking for myself, I know I'm an incompetent programmer who would not have a job in my own ideal world, but my goal is to not be that guy, and I would prefer not to hire that guy, or the guy who has never seen worse code than his own, doesn't make a clear distinction between his own level of skill and the level of skill displayed by crapware developers, does not aspire to write anything terribly ambitious from a technical standpoint, and in fact has nightmares about it. I enjoy programing, and I am more suspicious of people who say they hate software than I am of people who say that their own code is not the worst they've ever seen.
The fact that Swoopo promotes itself as an auction/shopping site and lists "strategy" as part of the experience skates uncomfortably close to the "no fraud" clause listed in that link, although offering discounts to losing bidders would seem to give them a solid "it's only gambling if you choose to treat it that way" out.
Day 163: Project complete. Strength nearly gone. Must.. complete... evaluation.... Data structures, godawful... string handling, non-existent... writing a brainfuck interpreter, gigantic pain in the ass.... Conclusion: this better get me laid. Oh sh.. signal lost
A code of moral behavior for intelligent robots will be developed. Isaac Asimov’s Three Laws are insufficient (especially for military).
http://www.robotictechnologyinc.com/index.php/EATR:
At the sixth (System of Systems) level, which has not yet been implemented, the 4D/RCS serves as an overarching intelligent control and decision system for (all or part of) a manifold of distributed unmanned and manned platforms, unattended sensors and weapons, and control centers.
Ambitious!
The article points fingers in a lot of directions, but it does spend quite a bit of time on Cassano. Maybe you pick him out if you're going to pick out one guy at AIG, but this was clearly a case of everyone involved carefully ignoring things that might have upset the money flows.
In the end there are some winners, and a lot of people left holding the bill (mostly taxpayers). Coincidentally, the winners, by and large, happen to be the ones with the most political influence. See: http://fora.tv/2009/06/01/Michael_Lewis_The_End_of_Wall_Stre...
From http://www.benbest.com/cryonics/CryoFAQ.html#_VQ_: What is the chance that cryonics will work ?
The chance that cryonics will work depends greatly upon the conditions under which a person is cryopreserved. [...] Probability estimates of future technology cannot be anything other than guesswork, although molecular repair technology does appear to be inevitable. [...] Rather than passively attempting to calculate probability, a person is better advised to realized that preparation to prevent potential problems will greatly affect the probability of success for that person and his/her loved-ones. The chance that cryonics will work also depends greatly upon how much money and effort is put into the technologies and organizational enhancements that can make cryonics work. [...]
From http://www.alcor.org/sciencefaq.htm: What can scientists disagree on about cryonics?
[...] The likelihood that technologies capable of the required analysis, repair, and tissue regeneration will be developed.
The practicality of maintaining cryopreserved people long enough for such technologies to be developed. [...]
The ethics of not cryopreserving people until cryonics is proven to work.
There certainly is plenty of discussion about vitrification, but that is a relatively small part of the equation. Looking at Robin Hansen's post again, he links another breakdown of the total chance of success at http://www.alcor.org/Library/html/WillCryonicsWork.html. These are the only two attempts I know of, and they do a pretty good job of showing how speculative the whole thing is and how much variation that produces in the estimates.
Cryonics advocates are by and large not very interested in trying to justify estimates that give a reasonable chance of success (I'll make an exception for Robin Hansen), and would rather talk about the importance of participation and securing more funding based on the fact that the probability of success is non-zero, and pro-life-esque ethical arguments about the value of human life.
Actually, no. When the Great Flux fluxes and the flux that is you goes away, it is not exactly the same thing as when the flux that is you fluxes and the flux that is some property of you goes away. Let's not interpret Taoism as yet another rationalization of death.
I guess I like them because I'm a twentysomething who's coming out of my own quarterlife crisis. It really is pathetic, but the problem is that even though you realize how pathetic it is while you're in it, you don't know what to do about it, so the realization just makes it worse. Being a human being is so fun sometimes. I guess that's why we have comedians like Woody Allen....