Slashdot Mirror

I took a double take too. It's the same Peter Norvig all CS guys with some AI background should recognize by name. Google is one company that deserves to employee PhDs, and I'm sure guys like Norvig do well in Google's research environment.

I wonder where they got these ideas?

Teach Yourself Programming in 10 years by Peter Norvig has always been the all time favorite. I think every budding programming to read it.


-http://uthcode.sarovar.org

All of the Lisp hackers have been left out. What I don't understand is why not even the mention of Paul Graham (bayesian spam filtering, yahoo stores) or Peter Norvig (AIAMA & PAIP).

Some choice quotes:

• " If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and through stock options is no doubt much richer than I'll ever be.
  
• "This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along. Alan Perlis put it more succinctly: "Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers".

Personally, as a person who contracts and hires hackers, my experience is similar to Norvig's. The best people I've worked with have often not gotten a degree or gone to a "no-name state school."

On a separate point, the worst developers I've ever had to work with were MIT grads. Arrogant pricks who neither understood engineering nor teamwork. People who have been in the industry longer than I have said MIT hackers have long had reps for not playing well with others. Other "top" schools aren't that much different.

There is a good presentation on how the dynamic languages make the patterns trivial/unnecessary; written by Peter Norvig. Check out http://norvig.com/design-patterns/

I'm not really sure what your goal here is. Are you wanting to write a compiler for the sheer joy of writing a compiler? That's a good goal, for sure, and I recommend that every programmer write a compiler or two during their careers, or at least some interpreters.

On the other hand, maybe you want to extend an existing language because you need some specific language feature. Also a good goal, but I do want to caution you to evaluate existing languages first; you may find that some language does what you want, or makes it easy to write a language library that does what you want.

Or maybe you want to write an interpreter to script a bigger program. Then I'd say that you may be better off using something that's already there.

In the first case, if you want to learn how to write a compiler, I generally recommend writing Scheme, or some other simple Lisp. Scheme has advantages in that its parse tree representation is obvious (that's why Lisp looks like it does), the structure of an interpreter and of a compiler are quite similar, and it covers the fundamentals of compilers without burdening you with a bunch of cruft. (If this is your first compiler, you may want to leave out continuations and garbage collection for now.) The very excellent book Structure and Interpretation of Computer Programming has what you need: chapter 4 is about writing interpreters (for Scheme, some modified Schemes, and Prolog), and chapter 5 is all about writing a compiler. All the code in SICP is in Scheme, but the book starts from the beginning with (+ 1 1).

SICP may be too academic for your taste, so you may prefer Paradigms of Artificial Intelligence Programming instead. It uses Common Lisp, and has a little bit more practical feel that SICP. Chapter 22 is about writing a Scheme interpreter, and chapter 23 is about writing a Scheme compiler. Unlike SICP, PAIP doesn't cover the garbage collector. PAIP uses Common Lisp, and although it has enough of an introduction to be a "refresher" for somebody already familiar with Lisp, it's not really suitable for learning the language.

It's really simple to write Lisp in Lisp. Indeed, a month ago I wrote one for a comp.lang.lisp post, just to get a silly quine to work! That's why I keep talking about Lisp and Scheme: it's easy to do.

If Scheme isn't your thing, then Pascal may be a good alternative. Don't try to get fancy with heap allocation, pointers, objects, and other new add-ons; I'd start with plain old Wirth-designed Pascal, and get fancy later if you want. Pascal is really designed for a classroom setting. I have a dim memory of Ada being used for this purpose in some books, but I can't speak very authoratively there.

Of course, the definitive book on writing compilers is the Dragon Book. But you may want to be familiar with some basic CS theory about FSMs first.

Now, that's if you want to learn about compilers for the joy of learning about compilers. But what if you just need one particular language feature for your problem, and that's why you want to write a compiler? Well, then I'd suggest you make sure you've looked at a lot of different languages first. Some languages have surprising features that may let you write a small in-language library to do what you need, instead of needing to extend the compiler.

Lisp is a good candidate for this. John Foderaro once described Lisp as "a programmable programming language". You can alter the language to suit the problem at hand, instead of having to work the other way around. At work now, I use Lisp as a bridge between two very different programming languages because I can extend it in both directions to cover what I nee

Seriously, Bush is the worst president in the last 50 years. This is widely accepted and discussed; it's not my simple-minded view. He does things that no one would tolerate in the person running the company they work for, let alone a powerful country, like completely ignoring all the facts presented to him and making calls based on unfounded instinct.

So how the hell did he get elected? A combination of:

1. People, especially people over 50, who blindly vote for "their" party candidate.
2. A bizarre, misguided group who regard Bush as having high morals. I'm as dumbfounded as anyone here, but just watch how often this comes up in analyses.
3. A similarly bizarre, misguided group who seem to think that Iraq was responsible for the 9/11 attacks and Bush is keeping them from attacking us again.
4. Voting for the status quo is safer than a new guy.
5. Nobody really liked Kerry all that much. The anti-Bush people latched onto him because he's all we had.

This is a good argument for changing how a president is elected. For a good read, see Peter Norvig's Hiring a President.

A sad day indeed.

In the same vein, with the advantage of being free, is The Gettysburg PowerPoint Presentation.

I agree with the others who have said that for the most part, I would be prejudiced against any attorney with the bad taste to use PowerPoint.

D

It is okay to take your time to learn how to become an expert. If you want to be proficent, do not expect to become an instant expert. Read Teach Yourself Programming in Ten Years to understand why we (IT professionals and IT fans) should remember to take the time to become good at what we do, rather than fall into the false trap of "Internet Time" for everything we do, and produce quick, (cheap) crap.

If you just want to be a network user, or are starting your learning of networking, this might be a useful book. But if you are going to be a System Administrator or Network Administrator go further.

In broad terms, I agree with you; I really hate to see text flying in and stuff like that. If you don't want it there when you load the slide, just make it appear or at least fade in quickly. Motion is distracting. (I did my last (and only major) PowerPoint presentation with white text on a black background.)

That said, saying they're never useful is almost as silly. For instance, I think the effect in the video demo they have up at 1:00 is pretty cool. Leaving that up on the screen as you wait for your presentation to start would, I think, be neat. And maybe do a really fancy, eyecandyish transition when you are making a change of subject. Sorta like how movie edits are made; most changes of angle are just cuts, but most changes of scene have a fade or dissolve or something. So they aren't without their use.

Not terribly related except on the matter of PowerPoint, but if you haven't already, be sure to download and run through the Gettysburg Address, PowerPoint style.

Peter Norvig, another Lisp guru, has written about this topic.

The Gettysburg Powerpoint Presentation

Because as this shows, breaking coherent paragraphs up into sentences and further mashing them into keywords, makes works far more accesible.

Good precis is a skill, and a creative and demanding one at that. A computer will no more likely do a good summary of a lengthy text, than it could write a novel.

Actually, the sites you are listing are just misinformation written by Lisp trolls. Read Peter Norvig's comparison of Lisp and Python instea for a real balanced opinion. (Norvig is the director of search quality at Google, and they use Python)

The idea behind page rank is that the links determine the significance of the site. If the current implementation of page rank is being abused then I'm sure Google will make attempts to change the implementation to prevent the abuse. Whether or not they succeed is anyone's guess.

No, actually, it's Peter Norvig's guess. He's the Director of Search Quality for Google, and staying one step ahead of the link farms and Google bombers is what he and his team do for a living.

It also has very good advice for becoming an accomplished programmer.

Looks like you re-discovered Norvig's law.

By the way, Lisp vs Python comparison by the famous AI hacker Peter Norvig is way better as it's more objective (less biassed) and it has very important details and very clear examples.

Norvig's Law !!!
Any technology that surpasses 50% penetration
will never double again
(in any number of months).

I also prefer the eager over the prima-donna. But not every skilled, experienced programmer acts like a prima-donna. An experienced, talented programmer who doesn't have a big ego will produce more quality work faster than an unskilled eager programmer. And I've worked with plenty of eager unskilled prima-donnas, too, and they poison the pool just as fast as the skilled ones.

Learning to program well takes a lot of time. A college degree or self-study can make for a good start, but programming well takes five to ten years to learn well, and you only learn it from experience and working with people who know more than you do.

See Peter Norvig's excellent article Teach Yourself Programming in Ten Years and some comments on Philip Greenspun's blog.

More important than programming skill or knowledge of the latest cool languages is business experience. You might dream in XML but if you don't know accounts payable from payroll you won't be much use to a company working on accounting software. Without a degree I routinely get hired over people with more technical credentials because I know more about the business domain.

I've worked overseas, too. You'll have all of the same problems as here, with culture shock on top of that. The shock can range from mild (Canada, Australia) to extreme (India). If you can't get a job here, no foreign company will take the risk of sponsoring you. The people who get hired overseas are hired because they have unique skills and experience. Do you really think a four-year degree will make you exceptional in Bangalore?

Take it or leave it, but I've been employed without a break as a programmer/analyst for 26 years, without a degree, and I've worked at big companies like Nike and Apple that always put degree requirements in their job postings. In decreasing order of importance here's what you need to get a job:

1. Good network of friends/contacts, preferably people who have jobs. Don't pass up opportunities to socialize and meet people. To get a job you have to get an interview, and you get interviews a lot faster through contacts than you do replying to ads. A good recruiter can help, too, but you will have to work with a lot of them to find a few who have contacts and aren't sleazy.

2. Social/presentation/communication skills. Learn to write and type accurately. Join Toastmasters or a speech/debate club until you can comfortably talk to an audience. Look people in the eye when they talk to you. I can't even count how many interviewees I've seen sabotage themselves with social awkwardness and an apparent inability to communicate with other members of their species. How you present yourself is the single most important factor in most hiring decisions, and I'm not talking about which tie to wear.

3. Business domain expertise. This mostly comes from experience. Don't be too cocky, learn from the people you work with about their jobs. Learn the lingo. I've been hired over a room full of other programmers just because I know what LTL means in the trucking business.

4. Technical skills. A talented programmer can get at least conversant with a new language or technology in a few days. Some things (relational databases, web architecture, compiler design) take considerably longer and are best learned from a mentor. But employers are often happy to supply technical training or let you learn on the job if you are otherwise a good fit in the organization -- a good fit with the people.

5. Don't whine. No one cares about your unmet expectations or how your cubicle is too small. Make yourself useful to the employer before you demand to use a Mac. And when you're job hunting you aren't in a strong position to make demands, like "I only work with open source software" or "I only want to work on new projects in Java." You'll probably have to shovel shit for a while before you get to pick and choose. The boom is over and all t

Here's the famous, early take on PowerPoint being bad.

What if Abe had use Powerpoint to "present" the Gettysburg Address?

When you read this title and your first thought is about Norvig's General Problem Solver, you know that you've had enough of the CS courses and you should definitely move on...

When you read this title and your first thought is about Norvig's General Problem Solver, you know that you've had enough of the CS courses and you should definitely move on...

Civil War Special - Lincoln delivers Gettisburg Address in GAP jeans.

Tufte makes this point in his presentations. He thinks it's fine for use as a slide projector, but terrible for building the images.

The classic example: Gettysburg

"either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days."

"Let's analyze what a title like Learn (this_language) in Three Days could mean:"

"* Learn: In 3 days you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in that environment. In short, you won't have time to learn much. So they can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing."

"* (this_language): In 3 days you might be able to learn the syntax of (this_language) (if you already knew a similar language), but you couldn't learn much about how to use the syntax. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using (this_language) syntax, but you couldn't learn what (this_language) is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of (this_language) (or more likely, something like Visual Basic or JavaScript) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task."

"* in Three Days: Unfortunately, this is not enough, as the next section shows."

http://www.norvig.com/21-days.html

For a decent Lisp-Python comparison check out Peter Norvig's page. It's intended for Lisp programmers coming to Python, but seems to also help a bit for those travelling in the other direction.

A Powerpoint presentation is a presentation made by a PHB or wannabe-PHB for PHBs. They are usually made with the assistance of one of Powerpoint's "wizards". These "wizards" suggest topics, colors schemes, and fonts, and Powerpoint itself makes it easy to add multi-level bullet points. The end result is to reduce any presentation to a mind-numbing exercise with the same overall structure as every other Powerpoint presentation, with dozens of sentence fragment bullet points interspersed with nonsensical charts and graphs.

A good example of a typical Powerpoint presentation is Peter Norvig's Gettysburg Powerpoint presentation

The reliance on bullet points to convey information can be particularly disruptive when presenting data. Take for example an image from a complex scientific experiment with several relevant points. In the non-Powerpoint approach the speaker simply displays the image and talks through it. In the Powerpoint approach the speaker displays a Powerpoint slide with the bullet points, and flips back and forth between the Powerpoint slide and the image, reading the bullet point, explaining it using the image, back to the next bullet point, explaining it on the image, etc. The funniest part is when the PHB asks a question, he wants the speaker to go back to the Powerpoint slide, not the data image.

That being said, Perl is at least useful for many things ("practical," I believe it's called).

Python is useful for many things as well, as evidenced by the number of people who use it, including Boeing, Disney, Hewlett-Packard, Industrial Light & Magic, Intel, JPL, Lawrence Livermore Labs, NASA, and Yahoo. Programmers at places like these are usually allowed to make their own decsions about their tools, and they chose Python. These guys are good. They don't use tools that they don't like. This is not to say that Python is their only scripting language. I know NASA makes good use of TCL, and probably uses Perl as well.

Peter Norvig says "Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." Norvig is director of search quality at Google. Look at his home page (www.norvig.com/. When a guy who writes AI books talks up a language, it means something. I'm not saying it means everything. It's another piece of data to put on the scales.

Finally, I note that the Google jobs page mentions Perl 11 times and Python 15 times, for what it's worth. I didn't read the job descriptions.

You're quite right, no message is effectively delivered unless with PowerPoint. Like this.

(the subject is flamebait and overstated, but it did get you to read this, didn't it?)

According to Peter Norvig and Greg Sullivan, most of the patterns in the Gang of Four book are there to show users of common OO languages the canonical ways of getting around design flaws in those languages.

Norvig says 16 of 24 patterns either vanish completely or are significantly easier to implement in a dynamic OO language like CLOS or Dylan; Sullivan implements a tiny OO language in Scheme and uses it to implement all 24 patterns, with similar results.

Go read the papers before modding me down, huh?

No, really, Teach Yourself Programming in Ten Years.

if you know how to program, you can learn a new language in an afternoon, and get to be an expert after a month or so working with it.

It's easy to get to the point where you can write working and useful code in a given language if you are a good programmer, but not to the point where your code is elegant.

For a more general take on this, read Teach yourself Programming in Ten Years.

ObLink:
Teach Yourself Programming in Ten Years

I've recently found this essay which I've found to be insightful.

Richard Gabriel thinks design patterns are important, but he also believes that the patterns found in the Gang of Four book for C++ and Java programmers mainly help losers lose less.

Propoganda
Design Patterns in Dynamic Programming
"Design Patterns" Aren't (google cache link)

Yes, definitely overrated. A lot of the patterns in the GoF book are implicit in other programming languages, as Peter Norvig has pointed out.

I don't think Design Patterns is a good theoretical grounding, it really belongs to a much narrower field inhabited by C++ and Java programming. Even as practitioner's guide I have a lot of problems with it, but I don't know of anything better, though I like Martin Fowler's Refactoring book, I find it more useful and it has the advantage of not pretending to be particularly profound.

Based on my software development expierience (17 years) I can tell, that there is no clear borders between models of software development process organization. Every team is uniq. Therefore, there is no universal models. But there are rules:

• Rules to control access (based on ID, groups, roles, files, directories, branches, tags, schedules etc).
• Rules to replicate distributed repositories. Rules to roll-out new versions.
• Rules to resolve conflicts
• Even rules to create "smart" diffs
• and, of course, rules to "report" (if CVSWeb would be made with XSLT).

Peter Norvig on the benefits of the Microsoft Powerpoint Autocontent Wizard.

.

Nothing teaches code like code.

Nonsense. This book has nothing to do with IT fundamentals, OO or otherwise. As many people have pointed out, at best it can be regarded as a roll-your-own appendage to cover the flaws of current mainstream languages. This situation does not apply in academia - they can use any language they like.

When people say "Linux is ready for the desktop" I stop listening. They've been saying that for years and I'm still keeping Linux as far away from my aging mother as possible. However, when you say "Linux is ready for schools," I'll agree. Honestly, I don't see why high school students would need more than the most basic word processing needs (unless you're taking a vocational class to get an office job or something, in which case MS Office is required - but that's an exception, not the norm).

The way I see it, schools need the following kinds of software:

1. Basic word processing software, in case a student needs to type up a paper. Abiword or Staroffice should work fine.
2. Web browser for "research." Mozilla and Konqueror are more than adequate.
3. Specific "educational" software - that is, programs that teach typing, multimedia foreign language stuff, and perhaps some sort of math/graphics program to use instead of a graphing calculator (matlab and mathematica are far too complex to put into a high school calculus course - you'll spend days just figuring out how to use the damned things).

Point is, this third class of programs is OS-agnostic and these are the type of programs which "itch" - eg, you won't find me spending my free time writing tax software, but writing a learn-to-type program might be lots of fun.

As for MS Access, I'd say keep that as far away from students as possible. When the non-geek types see Access, they figure it's just like Excel with some more programming stuff thrown in. Access stunts the understanding of relational databases and basic set theory. Same thing for Powerpoint - we don't need a generation who can only communicate in bullet points.

Norvig & Pitman have a lot of good things to say about coding style and commenting style. They deal specifically with Lisp, but one can easily generalize the first several parts of the presentation to any language. A couple of my favorite points:

It's All About Communication
Expression + Understanding = Communication
Programs communicate with:
o Human readers
o Compilers
o Text editors (arglist, doc string, indent)
o Tools (trace, step, apropos, xref, manual)
o Users of the program (indirect communication)

Some things to notice:
o People's style changes over time.
o The same person at different times can seem like a different person.
o Sometimes that person is you.

I think there seem to be fewer patterns in Lisp, because Lisp needs them less. Lispers tend to dismiss patterns because of presentations like this one by Peter Norvig, in which he shows that roughly two-thirds of the patterns in the Gang of Four book deal with techniques that are unnecessary in Common Lisp.

Lisp does have patterns, but Lisp hackers tend to implement them as macros, automating their application rather than forcing everyone to know and re-enter them to use them. That's the difference between:

// Please forgive any Java errors here
// I don't use this pattern enough to get it right
// without a compiler to check it...
try {
FileInputStream myfile = new FileInputStream(filename);
// Mess with file...
}
finally {
myfile.close();
}

and

(with-open-file (myfile filename)
;; Mess with file...
)

They do the same thing - guarantee that myfile gets closed no matter what - but the Lisp way requires less typing and is less prone to errors.

Give me just one example so I can begin to take you seriously.

I not a devotee of purely functional languages, but check out this essay on the role of patterns in Lisp. The author was a research scientist at Sun is presently head of research at Google. If it doesn't convince you, nothing will!

What a beautiful expression of the Lisp way, and the critical role of macros.

Those interested in patterns and Lisp should read Peter Norvig's essay on patterns in dynamic languages, notably Lisp. Norvig was a senior scientist at Sun, is now head of reseach at Google, and knows what he's talking about. Non-Lispers will find his thoughts a revelation, I suspect.

Graham's book is the definitive work on Common Lisp's macro facility, itself one of the prime features that make Common Lisp (not Scheme; there's a big difference) the most powerful language on the planet.
If your only exposure to Lisp has been a one-semester course that covered Scheme, you don't know Common Lisp. Try it before you judge it. Open-source versions are CMUCL for most Unix/Linux platforms and OpenMCL for Linux/PPC and Darwin/MacOSX. The full language spec and reference is online.

Now if somebody would just write as good a book for CLOS...