These screenshots are from Battlefield 2 (“Gulf of Oman”). They're really pretty, and military games are my vice, but it's also definitely creepy to look at these right now.
From a reddit thread on lemonodor comments that miss the point:
A couple of years back, I was reading Lisp In Small Pieces at my in-laws'. A relative of a relative got very interested and started asking me questions about it. I was surprised since I didn't even know that he programmed. After a minute or two, my wife realized the truth of the situation and broke in to mention that the Lisp I was reading about was a programming language. You see, the fellow I was talking to is a speech therapist. He was just as surprised that I was reading about lisps as I was that he cared.
Part of what was funny about it was how many words we shared but which had subtly different meanings. "interpreter", "syntax", "semantics", "symbols", etc. I was able to confuse him pretty badly without even trying.
We were late and a little rushed, and the tiny alley containing the cafe is kind of tricky to get to, so we unintentionally spent some time touring the industrial areas of downtown LA, including some of the larger homeless encampments (which are visible from space).
I don't really know the jazz vocabulary, but these guys are clearly good musicians, and it was interesting without being wanky and inaccessible (you can download music from their site). Finally, the beer was crisp (downloads not yet available).
“Running a Hatchery for Replicant Hackers”, the New York Times on Y Combinator:
“It's like Rob De Niro wants to start an acting school,” Mr. Yuen said. “Do you want to join it? You get to work with him every week, you might even get a small little movie deal out of it at the end.”
“Y Combinator comes down to two kids in a room with two computers and ramen noodles for a summer,” said Chris Sacca, a principal of new business development at Google and a speaker at Y Combinator's one-day start-up school conference in October at Harvard. “It takes ambitious geeks and puts them in a situation with no distraction and expects audacious outcomes from them. The reason we like it is that that is what Google is.” Indeed, Google has made acquisition overtures to one of the companies that was formed during the summer session, which the founders turned down.
Mr. Graham is more focused on creating cool products — that is, coding as art — than developing revenue models and protecting intellectual property. Thus, Y Combinator may not be as good at teaching participants how to build self-sustaining companies than it is preparing them to sell, or flip, their businesses. For Silicon Valley corporate war chests, acquisitions are often made for technical talent as well as product, which generally has to be rebuilt if it is kept at all. The whispered acquisition rate for companies is about $1 million to $2 million per technical employee.
SWIG, the automatic multi-language foreign interface generator, supports CFFI as of version 1.3.28. ACL, CLISP and UFFI were already supported.
I've used SWIG with Python to create nice interfaces to C libraries, but it really only gets you about 30% of the way there. Another 30% is writing type maps and things within the SWIG framework, and the last 40% is hand coding. I'm sure the exact proportions depend on the circumstances, but I've heard other Pythoneers say they prefer hand-rolling interfaces to using SWIG, so I don't think it's too far from typical.
dnm was in town last week, so Lori and I made sure he had enough steak, spaetzle, cake, pie and milkshakes to get him through the ordeal. God are we wholesome.
Dan and I had some quality geek out time where we got worked up over PBMs for the modern age, Roombas and helicopters.
Another day, another Peter Coffee eWeek article on Lisp:
Like anything that's been around for several decades, LISP carries the baggage of what “everyone knows” about it that is no longer true.
“Everyone knows,” for example, that LISP is an interpreted language and, therefore, too slow for production applications—except that modern LISPs can compile functions for run-time speeds competitive with those of C or C++ programs in algorithmically complex tasks.
The January release of Franz's Allegro Common LISP 8.0 puts developers on notice that “exotic” programming tools, long relegated to research environments, are becoming more viable options for mainstream applications.
The 8.0 version reflects performance-enhancing improvements so startling that if it played baseball, we'd expect a congressional probe.
Older versions of the Allegro environment fell short of competing development tools, even by the lower standards of bygone times. Version 8's source editor, debugger and other coding aids, however, have pulled abreast of the rising standard of the high-end Java environments that are LISP's most likely competitors.
Way to go, Franz. The release of ACL 8.0, with AllegroCache, a Linux IDE, a new high-level Windows COM interface, Windows scripting support and more, is a notable achievement. And little things like RSS feeds for ACL patches and for the LispWire site make me happy (though the LispWire feed should be auto-discoverable, and the Atom feed, at least, contains double-escaped HTML).
I am sad to report, however, that ACL 8.0 does in fact crash constantly (not really) on OS X in the same way SBCL does.
Nick Levine says next year's International Lisp Conference will be in England:
Following the success of our last conference, the Association of Lisp Users is now planning its next event. The venue will be one of the historic colleges in the centre of Cambridge, England and the conference will probably be held in March or April 2007.
There's a questionnaire, too.
I haven't decided yet whether the last one was worth going to.
This morning I was sitting at my desk when I noticed the room had become oddly dark, and orange. I peeked out the window and saw that the sky was smudged and the sun was an alien red that meant something more than the typical smog was at work.
OSHKOSH, Wis., Jan 23, 2006 (BUSINESS WIRE) -- Oshkosh Truck Corporation (NYSE:OSK) announced today that it has unveiled an unmanned version of its Palletized Load System (PLS) vehicle at the U.S. Army Tactical Wheeled Vehicle Component Technology Demonstrations in Yuma, Ariz. Showcasing the immediate application of the technology for the U.S. Army fleet, Oshkosh is demonstrating a real-world mission scenario as the driverless truck transports cargo between destinations seven miles apart in the Arizona desert. The unmanned navigational kit being applied to the PLS was tested at the 2004 and 2005 DARPA Grand Challenge races, and has undergone additional testing in desert environments, similar to those in the Middle East. Oshkosh is partnered with Rockwell Collins (NYSE:COL) and the University of Parma, Italy, on the development this unmanned navigational kit.
The gaming-oriented Artificial Intelligence Interface Standards Committee has some great working group names. Of course there are the old standbys:
But then there are a few fun ones:
World interfacing! Though I wish someone with a little poetic sensibility had been called in, so we could have the Working Group on the Thick Membrane Separating One Universe From Another or the Working Group on God's API or the Working Group on Cross-Worlding: How Do We Make It Less Dirty? (OK, maybe I don't have any poetic sensibility either.)
“Please teach me web frameworks for Python!” Guido cries, and goes on to critique various web frameworks for Python [via Gavin] and talk about his requirements (and gets seven pages of comments from people pushing one framework or another).
I haven't done web stuff in a while, but Guido's discussion of requirements was kind of interesting:
Before I post this, let me attempt at a brief classification of the features that every web framework needs.
- Independence from web server technology. You should be able to run the same application under Apache, as a CGI script, as a stand-alone server (e.g. BaseHTTPServer or Zope's or Twisted's built-in server), etc. (The Java Servlet API does this really well IMO -- I used it at Elemental.) This should include logging and basic error handling (an API to generate any HTTP error, as well as a try/except around application code that returns a 500 error code if the application code fails.
- Templating with reuse. Every web application needs to mix computed data (in which category I include data retrieved from a database) with HTML mark-up, and often a lot of the HTML markup is common for many pages (e.g. global navigation).
- Cookie handling. For authentication, preferences, sessions, etc.
- Query parsing. The bread and butter of form handling.
- URL dispatch. You've got to be flexible in how URL paths are mapped to callables. Zope's URL-to-object mapping is extremely flexible. Django's approach is nice too.
I expect everything else is optional. You can write your own SQL (as we did at Elemental), use an object-relational mapping library (like Django or RorR), or use an object database like Zope. You can even persist things directly to the filesystem (just make sure it's being backed up :-). While every dynamic website eventually develops authentication needs, there are many different existing approaches to authentication, and I suspect that it's not particularly hard to do this as part of the application. Some frameworks go wild on predefined CSS and HTML templates. (I believe Plone does this -- if you see a site with frequent use of 1-pixel rectangular borders and a calendar widget in the margin, you can bet it's somebody's first Plone project.)
Please set me straight. What did I miss? Where is the WSGI standard implementation?
In a followup post, Guido refines his thoughts a bit:
Maybe the current crop of Python web frameworks (as well as Rails BTW) have it all wrong. Maybe the WSGI folks are the only ones who are "getting" it.
ISTM that, contrary to what Rails and its many imitators seem to think, a framework shouldn't be an all-or-nothing proposition. For example, in the case of my Google starter project, I need to roll my own solutions for authentication and persistence (since these must hook into internal Google infrastructure), but I really need a better templating approach than %(name)s. So I should be able to use Django's templates, or Cheetah. I really want to look into Cheetah -- the example I saw on web.py looks "right". (web.py itself OTOH gets an "F", for undocumented code with too much magic behavior. upvars(), bah.)
Maybe we need more standardization efforts like WSGI, that let you plug in different animals, or roll your own, for various pieces of useful web functionality: for example URL dispatch, templates, persistence, authentication, sessions, forms, style sheets, i18n, and client-side scripting (AJAX or not).
Not that I'm particular keen on WSGI -- it reminds me of a trip to East Berlin in the mid '80s.
The “Black & White” app at potatoland.com [via information aesthetics] reads the data at the CNN website as a bitstream, and moves the black square horizontally for 0 bits and the white square vertically for 1 bits. Additionally, the squares attract one another.
It reminded me of chaos game representation (CGR), which is based on the chaos game, and was developed by H. Joel Jeffrey, an old professor of mine. In the standard chaos game, you start by drawing a random point inside a polygon. You then choose a vertex at random and draw the next point at some arbitrary fraction of the distance between the last point and the chosen vertex. When you continue this process long enough, you get stuff like this, depending on the polygon and other parameters you choose:
In CGR, instead of choosing random vertices, you select a vertex based on some input stream you want to analyze. You can turn any one dimensional sequence, e.g. English text or the C. elegans genome, into a fancy graphic.
I played around with CGR (a long time ago, which is why the following screenshots look all Mac OS 7ish).
Here are some simple CGRs that folded their input alphabet into only 4 characters, arranged at the vertices of a square—which was enough to distinguish highly structured input from unstructured input (click on a thumbnail to see a larger image):
|Random digits 0-3, uniform distribution||Lisp source|
|C++ source code||Email text|
The following CGRs are based on an alphabet containing ASCII characters from code 32 through 126, which consists of the alphabet in upper and lower case and punctuation. The characters are arranged in a circle, with consecutive characters a little more than 90 degrees apart (so if the image were the face of a clock, and “A” were at 12:00, “B” would be at about 3:01).
|Random digits 0-9 with a uniform distribution. The square shape is due to the digits being clustered in four places 90 degrees apart on the circle.||Random digits 0-9, non-uniform distribution; Digits 0-4 are twice as likely as 5-9.|
|Lisp source code. Lots of dashes, semicolons, parentheses and spaces.||C source code.|
|Email text.||Random text, letters [A-Za-z] and spaces, with spaces making up one tenth of the text.|
|Random text, letters [A-Za-z] and spaces, spaces comprising one third of the text.||Random text, letters [A-Za-z] and spaces, where spaces make up two thirds of the text.|
The ancient code I used to generate these images is cgr.lisp. It'll run as-is in MCL, but should be easy to port to any Lisp or graphics library.
I'm looking forward to watching the Super Bowl at Nat's place.