Python is a horrible language and is hard to write for any real sized project.

Let's say you need to modify a function signature to handle different parameters. Or maybe even rename the function to better reflect it's real purpose. In any compiled language it's dead simple to verify that all users of that function have been updated as well. In python, you what? Grep through the source code and hope you find all of the instances based on the function name? Well what if you passed the function is as a parameter to another function? Well.. you get a runtime error when your code doesn't interpret when running, but by then it's possible that it's already released.

How about logic bugs that can't easily be found?

something = function_call(a) ...
soemthing = function_call(b)

The soemthing is probably a typo.. Good languages will tell you you never declared a variable called soemthing.. Python will just create it for you. Yay.

Or even just something like:
a = "some string"
a.someFunctionThatDoesn'tExist()

You have to unit test every possible code path just to know the damn thing compiles. Duct typing is the tool of the devil that doesn't save any time and in fact causes more problems and just wastes developer time. It's impossible to refactor, large projects are a pain in the ass, and import statements do different things depending on how you declare them (Yes, there is a difference between "import module.submodule" and "from module import submodule" and "from module import submodule as some_other_name").

And whitespace as part of your syntax is just stupid. Oh and Python doesn't have real threading because of it's reliance on a horrible interpreter implementation revolving around the GIL. Oh and you can't have true encapsulation because it's impossible to have private variables in python. And there's not really a thing as a "constant" as it's a pain in the ass to make something immutable.

If you want something that follows the 3 points you just made, use Scala. It's functional, OOP, can be used as a scripting language.. and it's statically typed so you avoid all the pain in the ass shit you run into with python. Oh and it has threading to boot.

Actually memorizing joseki isn't really as important as understanding them. If you blindly use a memorized joseki and don't take into consideration how it effects other parts of the board, you'll put yourself in a disadvantage. Just using standard joseki's in each corner can be bad if they don't work with each other. One of the things I like about Go is that it has both local and whole board thinking to take into consideration. There becomes a sort of intuition of game flow for local battles based on the positions of everything else.

Also, making mistakes in the early part of Go is more correctable than in Chess. Granted in very high level games this becomes less the case, but often in Go even a failed battle will leave some usable aja for later that can be exploited.

Besides memorizing joseki and maybe practicing life and death problems, the middle game and strategy of dividing up territory, performing invasions, chasing your opponent for profit, all are things that aren't really easily memorized. Those are often the things that end up winning games.

As a side note, there are some players who play more moya games that focus less on corners. I heard from someone recently that Takemiya Masaki once said that he would never play the 3-3 position because it felt like the stone was so close to just falling off the board, and his games styled more towards controlling the center. It's a more recent development but one that is still played out and used in professional games. You have to remember that even if you lose territory for 3 of the 4 corners, you very well may also have center influence from those same 3 corners which is also worth something.

As many people have pointed out, you just described the digital equivalent of a library. But furthermore, your later statement about the video game industry is being tried with services like goozex. Granted it's a company that makes $1 per trade (and you have to pay for mailing), but it's the general idea of a video game library where you put your games up for credit to get other games.

The fact that digital libraries are restricted by DRM is so ridiculous. It's sad though that people think about lending ebooks and are conditioned by big business to think about how copyright laws make such a thing wrong completely forget that we've had that ability for centuries with physical books.

I have netflix for movies, but I recently ditched Cable since the service was shoddy anyway.

Now I'm using a pcHDTV HD-5500 capture card in a home-made mythtv box running mythbuntu capturing over the air HD TV from local broadcast. Granted I only get the basic networks like ABC, NBC, CBS, Fox, PBS, and a bunch of channels in Korean and Spanish, but I found that most of what I watch is on the basic channels anyway.

Myth will automatically cut out commercials (partly based on the volume level that those ads run at), so I get free shows with no ads and it's all legal. Plus I'm saving $60 a month now.

Perhaps that's not the best use case for your argument since Doom and Quake were both made by ID software, just like Wolfenstein 3D was. It's not like ID is going to sue itself for making a clone of its own game.

I would like to second this. I picked up Make: Electronics as I am a programmer who's played with robots but never the physical design of circuits and such and I've found the book to be a wonderful introduction.

Going along with it, Make Magazine itself is a neat resource. A subscription gives you digital access to all past issues and there are some neat projects and ideas in it.

Of course just searching the internet for things you want to know more about helps, but the electronics book gives you a good start to get to the point of knowing enough to be able to ask further questions.

There's a followup book called Making Things Talk: http://www.makershed.com/ProductDetails.asp?ProductCode=0596510519 which deals with wireless communication and microcontrollers. A bit thicker than the electronics book and probably the area that you'll be the most interested in.

(I work for Yahoo!, but my opinions are of course not Yahoo's)

Part of the contract with Bing deals with the relevancy of results. Basically Yahoo will only start using Bing's results if they are at least as relevant as Yahoo's current results. After a set time, if Bing does not meet the relevancy requirements then Microsoft has to pay Yahoo for the maintenance of Yahoo's current search infrastructure while Bing improves. The idea I think is that it will give MS a financial incentive to improve relevancy quickly as they'll be losing money on the deal.

So I expect that the results from Bing should improve quite a bit before Yahoo starts using it.

I'm going to say the exact opposite.

Start out working with just a regular programmer's text editor. Vim, EMACS, textedit... something that gives you some syntax highlighting and some basic features but not a full blown IDE.

If you start relying on an IDE from the start, you won't really understand your own code. If you use a wizard to generate code that you work with without knowing what that code does, that's not overly helpful. Also, jumping straight into a debugger as soon as you have a problem is a horrible practice to get into. What if something goes wrong on a production box that you can't easily replicate on your local machine? You can't hook a production machine into a debugger, you have to learn to read the code and trace it yourself. And if you practice Test Driven Development, your unit tests will show you were your bugs are rather than something like System.out.println() everywhere (of which, use a logger).

IDEs are really great, don't get me wrong. I personally use IDEA and coding is much faster than in a plain editor. But be careful of giving yourself some really bad habits by relying on the IDE rather than your own noggin. It should act as a helper, not a substitute for the programmer.

Yes: http://www.wacom.com/cintiq/cintiq-21ux.php

They're a bit expensive, but wacom does have drawing screens with pressure sensitivity, and have for a while now.

Which was also predated by a few thousand years by Go, the one true game which all games derive.

Actually the Kindle 2 (non DX version) now supports PDF files natively without conversion as of a recent software update.

Unfortunately as others have mentioned, PDF is a really shitty format for ebooks. You can't reflow the contents to do things like change the font. Plain text, ePub, or mobipocket are better formats to have ebooks in.

Which really sucks because I already have problems when I try to search for "Go" the board game. Now I'm going to get results from a programming language mixed in as well.

That's not exactly where the problem comes in actually. It has more to do with large datasets.

I know that people have mentioned Oracle and other large DB vendors that make databases that will scale to terabytes (or maybe even petabytes), but as some others have also pointed out: those are REALLY expensive.

I work for a particular purple company that deals with web searches and scalability issues. Even on some of the 'small' apps that run on DB servers eventually run into scalability considerations when reaching a certain size. The main bottleneck that you face is IO latency. While for most applications you will have the bulk of your data sitting on disk and a smaller index for that data sitting in ram so that you can find the tuple your looking for quickly, when the database gets too large that index becomes big enough to no longer fit into ram. When you have to perform a disk seek to access the index, access times go way down.

Also, with systems such as MySQL you can horizontally scale for reads which helps a lot. You add slave machines that replicate the data, and you can even set them up in tiers so as to not put so much strain on your master server. All of your read requests go to a slave that's behind a load balancer, while all of the writes and read critical requests go to your master. Unfortunately when you've fully saturated your master with writes, you can't just add a second master without sharding. Sharding can be a pain as it often requires you to rewrite the data access portion of your application to deal with the sharding details. Also, you can't perform joins over data in two different shards, which means you'll be joining that data in your application. Messy.

The only way to scale write databases in a MySQL setup is vertically, with a bigger box. That works for a little while but eventually that will be saturated as well. What is needed is some way to utilize a lot of commodity (cheap) servers to store and process all of your data, and currently implementing SQL on something like Hadoop has a lot engineering challenges to overcome.