I had "Danny Dunn and the Homework Machine" as a child. I don't think it had a direct influence on my career in AI, but when I had a college job as a computer help desk consultant, I would keep it on my desk, and when a student would ask "This is a really strange question, but ..." and I had heard the same thing multiple times before, I would respond "Hmm, let me consult a reference manual", flip through "Danny" for a bit, and then give the answer that I already knew.
I ran Search for 5 years or so; then ran all of Research for the next 5; then had an increasing smaller portion of a huge growing Research initiative. This past year I enjoyed mentoring startups in ML through the Google for Startups program. But m0gz got it pretty much right.
I agree, tuvistavie! But my default machine has 3.7 installed, and I didn't want to get too far ahead of readers. Sometime next year I'll go to 3.8, and look forward to using ":="
I regret causing confusion here. It turns out that this correlation was true on the initial small data set, but after gathering more data, the correlation went away. So the real lesson should be: "if you gather data on a lot of low-frequency events, some of them will display a spurious correlation, about which you can make up a story."
The diversity numbers are accurate. The numbers are for employees; some of the images depict non-employee visitors, some of whom are people of non-yellow color.
- Yes, the original publication year was 2000. I've added that to the file.
- @HelloNurse: You've got the key point. I provided Lisp code to teach AI; but my goal was to teach AI, not Lisp. As more schools and students were familiar with Python and not with Lisp, I needed to make the switch to keep teaching AI effectively.
- @jonathanstrange: Yes, "batteries included" is key to Python; there is some pain in doing any change; this page attempted to alleviate some of the pain.
- @rauhl: "in the silence a thousand words were said". I'm not sure what words are in that silence. But to me, the words are: Lisp and Python are different ecosystems with different customs. The Lisp community likes to solve lots of problems with macros. The Python community doesn't. For 95% of the usages, neither approach is better than the other, they are just different. For example, in Python, `with` is a statement, and you define custom classes for each usage you think of. In Lisp, you define a macro like `with-open-file` for each usage. The end result in usability and efficiency is similar. In Lisp, you often define macros for custom data types, e.g.
(def-tree T1
root (A B C)
A (D E)
B (E F)
...)
In Python you use a combination of built-in data types (like dicts), custom classes, and ad-hoc parsers of text. Again, the approach is different, but readability and efficiency is similar.
It is certainly true that if you want to define, say, a mock Prolog system, it is easier to do it in Lisp with macros than in Python, where you would need to deal with the far messier `ast.parse` module. Is that where the silent words were? For me the words would be "Lisp is a much better choice if your primary goal is defining a full-blown domain specific language. For most other programming tasks, the two languages offer similar functionality in different way."
You're right! 2.4 was out when I wrote that, so I could/should have used dequeue. But I wanted to use things that I thought readers would be familiar with, and timing wasn't a big issue.
When you say "1) Potential Outcome 1: Both are boys 2) Potential Outcome 2: One boy and one girl 3) Potential outcome 3: Both are girls" you are right that those are three potential outcomes, but they are not equiprobable outcomes. One boy and one girl is twice as probable each of the others.
Good point, tunesmith, I should define a version of `util` that lets you start at your current personal bankroll, rather than at 0, and show how the amount you are willing to pay to play depends on how much you already have.
Very nice find on the patent, emhart. Thanks! It looks like the patent is the same as my `greedy_lock`, except that at each tumbler "the entire word list is scanned"; this is worse than scanning just the words that make it through the previous tumblers. Also, I was a noob at lock terminology; I should replace "dial" with "tumbler".
I worked with Margaret and Saydeen at Higher Order Software for my first job out of college, but I didn't get to work on anything as glamorous as Apollo. We did mostly government contracts; I was there for two years before I decided it was time for grad school.
When I was in grad school a friend in another department said "You guys in CS have much nicer printers; can I mail you my thesis and have you print it out? And how would I mail it?" I said "Sure; Just do 'mail me@school.edu less-than-symbol filename". Later he calls in a panic -- "my thesis file has disappeared! I did what you said ... oh, wait a minute, I might have done greater-than instead of less-than..."
Fortunately for both of us, he had been diligent about making backups and din't lose his entire thesis.
It is great that Hacker News has caught up with this -- Philip has done a great job with the Python Tutor. Next step: user-definable layout for display of different data types.
Let me say that in my opinion, Matt DeBoard has certainly earned the title of "programmer." Welcome to the club, Matt, and you have my appreciation for the hard work you put in. It sounds to me like you're going about it in the right way; I encourage you to keep it up, and I encourage others to do the same (that is: find a way that works for them, not necessarily copy your approach). Please pay no attention to the negativity. As spacemanaki and others have pointed out, Matt is not a complete programmer yet, and he has more to learn. But I think he knows that, and remains open to learning, which is the important point. I've got more than 12 weeks under my belt, but I still feel like I'm learning all the time. My thoughts are summed up by the character of chef Gusteau in the movie Ratatouille: "Anyone can cook." This very pointedly does not mean "everyone can cook" -- it takes a combination of interest, aptitude, and long study to become a chef, and most will not make it -- but it does mean that there is no one route to achieving competence, then expertise, then mastery.
Good question. I think the engineering discipline part is much harder. I'm not sure that is because the problems really are harder: messier, ill-defined, changing over time; or whether it is that the academic community has focused on more well-defined formal/fundamental questions and mostly nailed them, so what we're left with is the harder messier stuff. Certainly it is easier for me to find someone to hire fresh out of college who has excellent CS fundamentals than to find someone with strong engineering discipline. And while my title included "Research", we all work very closely with Engineering.
