rtf

I think the most interesting observation here is on the nature of simulation: nobody can simulate the entire universe without having a spare universe to play with. Something I came up with myself years ago.

The rest of the article is deadweight.

An out-of-left-field option, if your goal is only to make some money working with ML: go into independent game design and create a game around a ML system.

It's not something mainstream gaming would be interested in using because the goals are different - there the development process is enslaved to some well-defined intellectual property, and (with rare exceptions) does not roam freely enough to allow more than a "good-enough AI opponent" - but if you developed a concept and brought it to market yourself, making sure that the result is fun to play and easy to learn, as well as a good use of tech, you have a shot at a decent revenue stream. Probably not enough to live on, but the beauty of independent gaming is that you can keep revising and expanding on an innovative concept, gradually growing your own market over a period of many years.

The only things I really have to do to feel at home in a Gnome desktop:

1. Fool with the mouse movement and screen resolution settings. 2. Set shortcuts for "Show the panel run application dialogue" and "Run a terminal". I use Shift+Win and Shift+Tab for those, respectively.

Once I've done that, I almost never have to use the mouse for non-browsing tasks. I could probably improve on that by changing out the window manager for a keyboard-friendly one, but I'd have to learn something new, and I'd have to maintain the wm setup instead of riding along with whatever the distro wants to do (which is far less likely to break)

Here are some arguments:

Not all macro systems are Lisp macro systems? Languages may have interesting features other than macro systems? Library support may be cleverly piggybacked in from an existing language? (see C -> C++)

The breakthrough for myself as a programmer came from intro CS classes....it may seem odd but I would still recommend going back to the core CS topics of data structures and algorithms, focusing on the implementation - on what kinds of language features might be used to implement these things, and how the language interacts with the hardware. Just pick a promising field of study - encryption, text processing, compression, search, whatever. Choose a common and well-understood algorithm in that field, do all the research you can, implement it, and then try writing something around it.

The key for me was to have some code of a non-trivial complexity to play with. This would be something that you would be willing to rewrite four or five times and really master. Having an interesting application in mind helps one get there, but one can often flip states between "interesting app" and "interesting problem" in programming.

It's not in vogue nowadays, but Knuth's Art of Computer Programming is chock-full of this kind of "programming exercise" and it makes a pretty good reference too.

First of, I second the others. By the time I got around to seriously learning programming and specifically game programming I was using Python/Pygame on a 1 gigahertz machine and it gave me about as much power as a 486 would running optimized C code. (more in some instances, less in others) If you're after concepts and not retro-technical details this is a good route to go.

But as for the questions:

1. Threading is not the answer; it was a missing concept on DOS machines. Interrupt polling is what you want to look at. 2. I recall reading about this but never did it myself. These days you're lucky if both the monitor and graphics card support mode 13h. 3. The term you want is "fast rectangle blit". This is still relevant if you use software rendering.

Poor Wikinews. I keep their RSS around and they've been getting some cool - and different - interviews lately.

The other way to look at it is that Lua has a simple enough binding interface that it's like a "high-level layer on top of C." So you can write C, or write Lua, and slop things around between them as necessary, run multiple interpreters, whatever you feel like.

Python is more focused on extending the language as a singular entity, and (not having actually written extensions) it seems to have more strenuous requirements.

Right now I'm focused on haXe, though, cause with that language, you get several platform options, including a Lua-like interpreter(Neko).

I'm working on a Flash game myself, and it's open source too: http://code.google.com/p/spacecreeps/

The first versions didn't do so hot, but I started a from-scratch rewrite a little over a week ago and it's shaping up into something really nice.

The saying I have for this negative reaction is "people see only what is in front of them." A good concept with poor presentation will be dismissed, and in the case of a language like Arc, presentation could also be defined to include "number of features, immediate utility, etc."

I know my reaction was similar to the crowd, but even so I recognize that it's the wrong thing to look for. If Arc's initial release state could be summed up as "Lisp with some cleaned-up and rearranged features," then it's really not that different from say, Digital Mars D, which is best described as "C++ with some cleaned-up and rearranged features." The difference is, D has a massive compiler backing it, and its scope is unlikely to change. Arc's minimal implementation substance only makes it easier to change tack midway.

I've only gradually learned to restrain my sense of ego and take a similarly minimal approach with my own projects(indie games) - my newest process is to always start the final implementation with a text console interface. Besides encouraging better architecture in preparing for a later graphical interface, it's easier to debug the key elements this way than to have "stuff moving on the screen" at 30 or 60FPS and get frustrated figuring out which of those frames is the one where you're getting an error, let alone what routine is causing the problem.

Now I'm wondering to myself if there's a graph or chart somewhere that plots people's adsense returns.

(goes looking)

Cotton shirt and vinegar. Works like a charm.

When I want "coder background music" I just listen to a psytrance onine radio station.

I find this very amusing. Something about it implying the bold statement that no hacker is lesser than Paul Graham, and then audaciously posting it on Paul Graham's site.

The more I learn about development - and the more I work on real projects - the more I realize that we're perpetually at the "apprentice" level. By that, I mean that we're writing new code with no standardized solution. With few exceptions, old problems eventually get packaged up in a preexisting library or app, so unless you're fanatical about reinventing wheels(a good student exercise), all programming problems eventually involve a stage of research; maybe several stages, as once you get far along one track you realize the structure of the code, which probably looked OK at one point, is now completely wrong and get the urge to rewrite. The old "write one to throw away" adage.

And indeed, once you've rewritten three+ times, you've probably figured out a nearly optimal structure for the particular problem, but most production code can never get there. The perceived cost of rewrites is very high, and it's hard to know, in a strict business sense, whether it's the right thing to do.

That's why I think experience can only help so much.

I think it is quite mistaken to put brevity above everything else. For a 100-year language, presumably with corresponding 100-year codebases, surely the promotion of readable and refactorable source code would be the key. Macro systems already provide a means toward brevity - whatever the language itself does becomes inconsequential given that.