The New York Times article explains why SimCity is one of the ten most important video games of all time:
SimCity helped establish the genre known as god games, in which players take on an omnipotent role, controlling the game world rather than simply participating in it. It also broke convention by refusing to establish criteria for winning, leaving the decision of what constituted success up to the player.
SimCity was selected by Mr. Bittanti, a researcher at the Humanities Lab at Stanford who works with Mr. Lowood. The game is "one of the most important art works of the 20th century," Mr. Bittanti said, adding: "It completely reinvented the whole notion of games. And then it transcended the game world to become a cultural phenomenon."
SimCity and its four follow-ups have sold 17 million copies, and the franchise it spawned, the Sims, has sold 85 million copies.
Constructionism (in the context of learning) is inspired by constructivist theories of learning that propose that learning is an active process wherein learners are actively constructing mental models and theories of the world around them. Constructionism hold that learning can happen felicitously when people are actively making things in the real world. Constructionism is connected with experiential learning and builds on some of the ideas of Jean Piaget.
At the Game Developer's Conference, SJ Klein (Director of Content for the One Laptop Per Child project) gave the keynote address at the Serious Games Summit. He explained the philosophy behind the project, and asked developers to join in the project to develop a game platform, games, tools and courseware to distribute to classrooms and homes of some two billion children across the globe.
SJ Klein said: "Existing games are nice, and cute," but games for things like learning language are the "gem they're targeting."
Most importantly, Klein said in a direct plea to the serious game developers in front of him, the project needed frameworks and scripting environments -- tools with which children themselves could create their own content.
Developing reusable libraries that kids can use to write their own game is just what the OLPC project needs. It's best to write the libraries in pure Python, if performance isn't an issue. High performance libraries should be written in C or C++, and packaged as Python modules. The preferred way of drawing is with the Cairo library, which you can call from Python. You can also write C modules that get passed a Cairo context that they can draw with.
In the case of SimCity, I'm planning on factoring it out into reusable components, like the tile engine (written in C since it must deal with a lot of pixels and run fast), the sprite engine (which would be easiest to write in Python since it will simply call Cairo to do the rendering), map overlay (Python, for the same reason), graph display (ditto Python), etc. Then it will be possible to use those components in other games and toys, like using the tile engine for a cellular automata lab.
The OLPC needs all different kinds of game toolkits to support various games geanras, like a card game toolkit, a board game toolkit, a platform game toolkit, a space invaders game toolkit, a pong game toolkit, a simcity game toolkit, etc.
Pygame will be a useful imaging library, especially for full-screen bitmap-oriented and 3d games. But games that require user interface components and scalable outline graphics will be easy to draw with Cairo. It would be great to be able to draw in a pygame full screen context with Cairo, to have the best of both worlds.
Squeak and eToys are currently included with the OLPC. And it is a wonderful way for kids to learn to program games, as well as for programmers to learn about Alan Key's revolutionary ideas! It's purpose is to inspire people, expose them to Smalltalk's unique ideas, the possibilities of visual programming systems, and point the way for future development. But the mainstream of software development on the OLPC will be done in Python.
Alan also talked about the $100 laptop project; he is on the OLPC advisory board. Apparently Python is specifically involved. There was little Python content to Alan's talk, which is fine by me -- Keynotes like this one are supposed to challenge or tickle the audience, not necessarily to confirm their world view. Alan did end by expressing the hope that a system like he demonstrated will be implemented in Python; apparently (or just for the occasion:-) Alan believes that Python has a much larger mindshare than Smalltalk or Squeak, and that because of this a similar environment in Python will have a greater chance of succeeding than the current Squeak one. Also, the $100 laptop already has Python, and Alan is of course hoping that a Squeak-like environment will be part of it, so this appears expedient. (At the Shuttleworth summit in April I believe Alan also suggested that Squeak is suffering from its extremely simple graphics model; apparently it cannot benefit from graphics accelerator cards because of its platform-independent architecture. [Update: this is incorrect, see responses below.] Python on the other hand already has bindings to OpenGL and DirectX, for example.)
The idea is to re-implement the ideas of Squeak and other educational constructionist visual programming systems in Python, deeply integrated with the OLPC's Sugar user interface, and based on its libraries like GTK/Cairo/Pango, etc. Alan Kay writes on the Sugar mailing list:
Guido knows that I've been advocating that the Python folks should do Etoys or a very Etoys like environment in Python (and that the rest of the OLPC be given an objectification and media and scripting integration that is Etoys like).
However, there are simply zillions of things left to be done everywhere for OLPC so the first round of SW on the XO will be more of a gathering of "suggestive" features and abilities (of which Etoys is just one). That seems fine to me.
Viewpoints Research (our little non-profit) doesn't have any "ego or identity" staked around whether the children's authoring environment is Python based or Squeak based. I have said many times that, if the general integrative base of XO is to be Python, then the Etoys-like authoring should be based in Python also.
However, I will personally fight to the death to make sure that there is a children's authoring environment that allows even young children to do simulation style programming with very rich media objects.
For now, that is Etoys. It could be a suitable object-oriented Logo with media objects (this is essentially what Etoys is). It could be some better design (let's do one). The base could be Javascript (if implemented on top of an integrated environment of sufficient power), Python (ditto), Ruby (ditto), etc. Whatever it is, it has to be above high thresholds, not a hack or a gesture.
Besides the programming the children use to learn important ideas in math and science, they also need to be able to see how their own computer world is structured by being able to "pop the hood" on practically everything they use. Perhaps it is OK for high school children to see the current code (but I don't think so). I think there needs to be a wrapping on the entire set of facilities that uses the same conventions that 9 year olds do th
It would be a great idea to sell the OLPC retail to software developers and people in developed countries at a premium price to subsidize them for kids in developing countries. That was the most commonly request people made at the OLPC booth at the game developer's conference.
But the reason they aren't currently selling the OLPC retail yet is that it takes a huge amount of effort and overhead to manage something like that, and the OLPC organization is small and focused on delivering them to the target countries by the millions, at no margin. Managing retail sales would distract from the more important goal of rolling out the laptop to children.
Eventually some other organization might buy a million or so of them and sell them retail, but nothing like that is planned or announced yet, as far as I know.
It's not because they want to keep the laptop away from us, it's because they want to get them to the real target audience as soon as possible.
Software developers can send email to the project describing what software they want to port to it, and if you qualify they will send you one right away for free. I applied for one around christmas, to port SimCity, and it arrived by fedex in just a few days. I don't believe they will ask for them back, since the beta units will soon be obsolete anyway, after they make the next run of them.
They are however putting a lot of effort into making the software development environment available to external developers, so you can develop software without having the actual laptop. You can install the software on a Linux system and run it much faster than it runs on the OLPC, because the "emulation" does not slow it down signifigantly, and your Linux box probably has a much faster processor and lots more memory than the actual machine. There is nothing special about the screen from a software point of view -- it's just a 1200x900 16 bit display from X11's point of view. Get your software running in the development environment on a regular Linux laptop, then make it run as fast as possible, and consume as few resources as possible. Once you can demonstrate a working application on the OLPC under emulation, and need to test it against the actual hardware, you chances of receiving an actual unit to test it on are much higher.
"The bottom line is that our mission is learning, not laptops. While we will be working with a commercial partner at some point for both machines and interesting parts--we've been looking at models where by the commercial side can help drive down the cost for the kids--our immediate priority is the non-commercial machine." -Walter Bender
The software sees the screen as a 1200x900 16 bit color framebuffer (and draws on it via X11). There is a button that rotates the screen, and the software does notice the aspect ratio changing between 1200x900 and 900x1200, thanks to window resize events propogated through the window manager. The hardware automatically converts it to monochrome and reduces the color resolution (called "swizzling"). So the color/monochrome "mode" is invisible to the software. You just keep drawing in color at the same full resolution, and the user can switch between reflective monochrome, and color with various brightnesses. So a 3D renderer would just draw in full color, and not concern itself with the monochrome mode or down-rezing the color. I don't know what the refresh rate is, but it look solid and animates smoothly.
a) Are you going to keep it in Tcl/Tk, or is it a complete rewrite in Python and (insert toolkit here)?
The TCL/Tk version will be open source (GPL), so you can do what you want with that, but it's using an old hacked version of TCL/Tk circa 1992. It's stable and playable, but it would be a lot of work to upgrade it to the most recent version of TCL/Tk, and I believe the effort would be better spent converting it to Python and then working on that instead. I plan on porting it to Python by using SWIG, so it will be possible to plug it into other languages that SWIG supports, like Lua.
b) Will this version be usable/portable outside of the OLPC (both leagally and technically)?
The TCL/Tk version will legally and technically run outside of the OLPC. The Python version that I'm developing will use libraries like GTK, Cairo and Pango which run on the OLPC and also work well on other platforms, but it will also use some other libraries that only make sense on the OLPC. The primary goal of my efforts will be supporting the OLPC, but other people can work on supporting other platforms, or even porting OLPC specific libraries so they work on other systems.
c) How faithful is this version to "reference" SimCity (Let's say either the Win31 or Mac versions)?
It's faithfully based on the original Mac version of SimCity "Classic" (before they added the word "Classic" after releasing SimCity 2000). I also have the old terrain editor code, which would be nice to update and integrate into the new code base. It would be great to dig up the old tile sets (European city, moon city, etc), but I don't currently have a copy of them. I have cleaned up and reorganized the code a lot, fixed some bugs, optimized the hell out of it, and replaced the random number generator. I've totally rewritten the user interface and graphics code. But functionally the simulator and is almost exactly the same as Mac SimCity. The save file format is the same, so you can use Mac and PC cities. The only change to the simulator that I can remember was to make the helicopter attracted to the monster so it blows up more often!
SJ Klein and I just had a productive meeting with Charles Norman at EA to discuss the details of SimCity for the OLPC, and it's looking very good!
It's not officially announced or available yet, but EA is very supportive of the idea, and is just crossing their eyes and dotting their tease (or something to that effect), and Will Wright gave us permission to demonstrate SimCity on the OLPC at the game developer's conference.
If you're at GDC, please come by the OLPC booth at the expo and play with it!
I've done the first basic cut of porting the X11/TCL/Tk based multi player version of SimCity to run on the OLPC, and the next step is to integrate it with Python and Sugar in a deep way, that will make SimCity scriptable in Python, enable all kinds of interesting hooks and plug-ins, and result in a set of reusable general purpose components for building games.
For example, the next step I've taken is to rewrite pie menus in Python with Cairo and Pango, so SimCity and other applications can use them:
http://www.donhopkins.com/drupal/node/128
The point is not just to port a game to the OLPC, but rather to use SimCity and other games to drive the development of an open framework to enable and teach kids to program their own games!
The goal is to enable the open source community to renovate SimCity and take it in new educational directions, by applying Seymour Papert's ideas about constructionist education, Alan Kay's ideas about interactive user interfaces and object oriented programming, Ben Shneiderman's ideas about direct manipulation and info visualization, and many exciting ideas about multi player games, blogging, storytelling, game mods, player created content, and lessons learned from World of Warcraft, The Sims, Spore, etc.
Thanks to John Gilmore for getting the ball rolling by suggesting that EA make the original version of SimCity free for the OLPC, and for supporting the development of great free software and tools like GCC, and to Charles Norman for guiding the process through EA, educating people about open source, and making it actually happen, and of course to "Will Wright Code for Food" for creating SimCity it in the first place, and putting his Will Power into making SimCity open source for the OLPC project!
-Don
PS: Here is some stuff about the multi player X11/TCL/Tk version of SimCity:
The Dumbold Voting Machine for The Sims enables the simulated people in your virtual dollhouse to vote!
It's an interactive "get out the vote" public service message, in the form of a free downloadable Sims object.
This Sims object is an electronic voting machine that lets your Sims vote between four candidates: Kerry, Bush, Nader and Badnarik.
I've included informative text in this Sims object, which it displays in illustrated dialogs to educate players about electronic voting machines.
A major side-show is the "Monkey" item on the pie menu, which activates all kinds of cool easter eggs, and displays lots of in-game information and news about electronic voting machines.
Please give this Dumbold Voting Machine a good pounding on, and tell me if you have any problems (besides the usual problems endemic to electronic voting machines, which I've programmed into this Sims object on purpose).
At first look, it appears to be a fully functional voting machine. But it actually has a lot of fatal bugs and hidden features, just like real electronic voting machines!
Highlights of Cheats, Bugs and Easter Eggs (Illustrations are here)
The Dumbold Voting Machine is programmed with cheats, bugs and easter eggs, which you can discover and read about by playing around with it. It demonstrates and simulates some alarming problems with real world electronic voting machines, with many surprising effects and subtle interactions:
Baxter the Chimpanzee Erases the Voting Log.
When you put the voting machine into debug mode and clear the votes, you will see a dialog with the hillarious picture and story of Baxter the Chimpanzee. In your web browser, you can watch the funny monkey movie showing Baxter erasing the voting log! Now your Sims can monkey around with the electronic Dumbold Voting Machines, go bananas hacking the system, fling poo and corrupt the election results just like the pros!
Vote or Die!
P. Diddy, lately a.k.a. Citizen Combs, says: "'You all are the X-factor, the wild card," Combs said. "`History is being made here. Our revolution has begun." "Young voters in this country are throwing away their power to have a say about education, healthcare, and any issue that affects them." Combs explains. "These things affect your life, so - Vote or Die!" (If you select Vote, you live. If you select Die, you either get electrocuted, or burst into flames, then you die.)
You punched out the screen!
Hey!!! You're supposed to touch the screen, not punch it! Next time, please don't take out your frustration with the lousy choice of candidates by punching the screen. That's not the way to get your vote counted. (Your Sim breaks the voting machine screen. You can repair it if you're skilled enough, but you might want to keep a handyman on call during the election!)
Osama Bin Laden Scares the Piss Out of You!!!
Osama Bin Laden wants to scare you into voting for George W Bush, because Bin Laden is grateful to Bush for outsourcing the job of hunting him down to Osama's good friends, the Afghan warlords. Bush's policies have strengthened Bin Laden's cause, and George W Bush says he's not worried about Osama Bin Laden. Bush and Bin Laden both want you to vote in response to your of fears, not in pursuit of your hopes. "Americans all know that Osama Bin Laden doesn't pick our president. The Supreme Court does." -Bill Maher (Your Sim empties their bladder, pisses their pants, and then runs away screaming!)
Accidentally Voting for Pat Buchanan.
When you select one of the four official candidates, sometimes it "accidentally" pops up an illustrated dialog asking for confirmation that you want to vote for Pat Buchanan! If you foolishly select "Yes", the voting machine breaks!
Seriously: So what if "properly coded PHP" is still useful? It's not as useful or as easy to properly code as other languages, so why do you persist in using an inferior, defective language like PHP? Properly sealed lead and asbestos are "still useful" in constructing new houses, but you certainly should not use them! The fact that something's "still useful" does not negate the fact that it's still foolish to use it, if you have a better alternative.
The problem with using a pull parser like XMLReader from a language like PHP that doesn't support generators, is that it's difficult to write the rest of your XML processing stack using the efficient event-driven pull processing approach. The parser is only the first step of an XML processing pipeline, and while it's nice to have a pull parser, it's much nicer if you can write the rest of the templating system and XML processing pipeline in that style, as well. Which is extremely difficult to do in PHP, because it lacks generators. Why should only the parser be efficient, and not the rest of the program?
You claim you understand what generators are. Then do you think they could be implemented in PHP by a good programmer? How? Do you consider yourself a good PHP programmer, or will you pass on explaining on how to implementen generators in PHP?
Not having the attention span to understand the issues is not an excuse for being wrong -- it just means your opinions aren't valuable because you refuse to put the time into learning. If these issues bore you so much, then perhaps you shouldn't be programming computers, and just flip burgers instead?
"Stop the Blah", huh? So you've stuck your fingers in your ears and you're chanting "ya ya ya ya ya" because you refuse to listen to what I say, since you can't come up with any better arguments? Why can't you answer any of the questions I've asked you? If you incapable of answering any of the questions I've brought up, then you're conceding my points, thank you.
You're the one who accused me of not knowing about MVC or templating, so I gave you some references to my experience. You're the one who brought the subject up by making false accusations. Do you retract what you said about me not understanding MVC or templating?
If Smarty's {math} isn't a good idea to use, as documented by the Smarty manual, then why does it exist? Either Smarty is supporting "bad" features that you should not use, or your premise that "math is bad" is wrong.
Of course PHP is a horrible language because it's rife with stupid half-baked ideas that they threw into the language but that are a bad idea to actually use (register_globals, magic_quotes_gpc, addslashes, all the other half-assed attempts at quoting sql strings, etc.) But math is not one of those mistakes. Do you think it's OK for Smarty to have features that you claim are bad ideas, just because that's typical of the PHP culture?
My point is that you are dead wrong about math being bad in templates. You're just attempting to apologize for Smarty by repeating what you believe is the "conventional wisdom", and that conventional wisdom is dead wrong.
What references can you give me that prove your point that you should not use math in templates? Did Alan Kay ever stand up and said "I invented OOP and MVC, and I say that views should not use math"? I gave you a reference to a paper I wrote with Ben Shneiderman (who is a user interface and hypermedia researcher whose name you should recognize if you know anything about the subject), published in the peer reviewed ACM journal of Hypermedia, which clearly describes why it's useful to have math in templates (for calculating the condition for conditional text). What is your counter-argument, or do you prefer to avoid answering that question because you can't? Claiming your too bored is conceding my point.
You keep trying to avoid addressing the arguments, by claiming you're too bored to respond, or twisting my words. I never accused you of saying a good and easy template engine needs a language that supports generators, so why are you denying that you said it, if I never implied you did? You can't win an argument by repeating the other person's point as if it's your own, as if I accused you of claiming the point I was trying to make. That only works in Bugs Bunny cartoons.
What I do accuse you of implying is that a good PHP programmer could implement generators (by saying that I wasn't a good enough PHP programmer to implement Kid in PHP), which means you have no idea what generators are, even though I pointed you to a perfectly good explanation of what they are. Did you read the explanation? Do you still believe that a PHP programmer can implement generators in PHP, or not? Do you think you're such a great PHP programmer that you could implement a templating system as efficient and easy to program as Kid, with or without generators?
So how do you propose a PHP programmer implement a good templating system without generators? I previously listed the advantages that generators have over the SAX based even call-back method, which as you know, if you've ever tried using it, is a total pain in the ass and hard to program. I also listed the advantages that generators have over parsing the entire document into a DOM tree, which is a total waste of memory, and extremely inefficient. Generators enable you to 1) process arbitrarily sized XML documents efficiently, 2) write straightforward code that uses conditionals and loops 3) keep temporary state in local variables instead of having to store it in object fields between event handler invocations. So which programming techniques do you suggest PHP programmers use to get around the problems that generators solve so nicely?
Ignoring smarty is not an option for me. I know how bad it is because I'm working on a project that uses it, and I have read the source code to understand how it works. So I have every right to complain about it.
Of course I'm answering your posts -- you're just ignoring my answers.
What point did you make that I didn't address? Just because you don't understand what I'm saying doesn't mean it means "blah". Go read the article on generators. You implied that a good PHP programmer could implement generators in PHP, and you are totally wrong. You obviously don't know what generators are. I provided a reference. Did you read the article I refered you to about generators? Do you understand them now? Do you still maintain that a good PHP programmer could implement generators without hacking the PHP interpreter source code in C? Or do you concede my point?
And now you are misquoting me: I never said "an easy XML template engine can only be done with generators". I said templating languages should have well designed syntax and semantics, but Smarty has neither, while Kid has both. I also said that generators make it much easier to implement efficient elegent XML processing tools (note that implementing a templating language is very different than using it: graphical designers don't have to understand or use generators in order to use Kid), and you haven't been able to counter that argument because you don't even understand what generators are, even though I provided a reference. Are you too lazy to learn? Then concede my point. The ball's in your court and the burden of proof is on you.
Are you contesting my claim that generators are extremely useful for implementing efficient XML processing pipelines? Or do you accept my point? Are you arguing that syntax doesn't matter? That semantics doesn't matter? Or do you accept my point that both matter? Are you arguing that Smarty has good syntax and semantics, or do you accept my point that it sucks?
What templating languages have you implemented, and have you published any papers about them so I can read about your design? Have you read the paper about the HyperTIES markup language I implemented in 1987 and published with Ben Shneiderman in 1991? Have you ever read any other papers written by Dr. Shneiderman, or even heard of the field of human computer interaction, or read the ACM journal of Hypermedia? Have you even heard of ACM? Do you have any problems with the points that peer reviewed paper made about markup language design? I linked to the source code and documentation that I wrote, so you can look at that and make comments on it. So what are your comments on the points I made? Silence?
"If you don't want to answer my points just don't", but that "makes you look very stupid". I am addressing your arguments point by point, and you're totally ignoring every point I'm making. Why is that? Can you answer any of these questions I've asked, or are you just frustrated that you made a lot of stupid arguments about topics that you don't know much about, and you're trying to run away from the argument without answering any questions?
You accused me of not knowing what MVC was, and I told you when I first started using it, and refered you to some criticism I wrote about it. What are your comments on that? More silence? I addressed your incorrect accusation, and asked you when you learned MVC and if you had any criticism of it or just accept it blindly, but you refused to answer. More silence that makes you look stupid.
Face it: Smarty is a piece of shit, and you're trying to apologize for it by making ridiculous statements like "don't use math in templates". You are full of shit, and I refered you to papers I wrote years ago to answer your posts and rebut your points! Don't blame me if you're too lazy to read them or too ignorant to understand them.
You're wrong that I don't want to answer your posts. I have, but you just ignored me. Can't you defend your statments? Why can't you answer my questions point by point, instead of ignoring them all?
You still don't get it. A pull parser is not the same thing as generators. Generators are a programming language construct which is extremely useful for implementing pull parsers, and modular telescoping XML processing pipelines, like the Kid templating system.
Go read the link about generators that I provided. Then please explain how you would implement generators in PHP. You can't, because it's a language feature that can't be implemented at the PHP script level. It required modifying how the PHP interpreter works. Let me say this again: it is impossible to implement generators in PHP code, no matter how good a PHP programmer you are -- you have to rewrite the PHP interpreter which is written in C, to implement generators. Generators enable your processing modules to run in parallel, each with its own return stack and local variables (i.e. co-routines). PHP absolutely cannot do that.
If you don't believe that, then you don't understand how generators work, so go back and read the article again. Then try to convince the PHP designers to add generators to PHP: good luck!
Python supports generators, because they are built into the interpreter. They are a fairly new feature from Python 2.3, described in PEP 255: Simple Generators. The Python interpreter C code had to be modified to support them, and it was done because generators are so useful (especially for processing XML).
Other more powerful languages like Scheme do not have to have their interpreters modified in order to support generators, because they already have more powerful programming constructs (like continuations) that can be easily and efficiently used to implement generators.
But since PHP does not support continuations or co-routines, it is absolutely impossible to implement generators (or Kid-like templating systems) in PHP, no matter how great a PHP programmer you are.
Perl is a write-only language, because its designer believes it's OK for syntax to be extremely complex, subtly nuanced, haphazard and inconsistent, which I strongly disagree with.
Both is important.
Grammars "is" important, too.
it's not the syntax that matters
Both syntax AND semantics are important. If you screw up either one of them, you've made a mistake. Smarty is so horribly bad because it totally screws up BOTH syntax and semantics. Kid is so wonderfully elegant because it has both excellent syntax and semantics.
Your words suggest that you (and the PHP designers you're talking about) are thinking in terms of syntax, and ignoring the semantics. Quibbling about what character to use to syntactically represent namespaces should not hold up such an important issue of language design. PHP should have had namespaces from day one, but now it's way too far down the road of "globalism," with millions of programs depending on thousands of global variables and functions, so adding namespaces to PHP now would just be closing the barn door years after the horse left the barn. It's laughable that they'd be so concerned about figuring out the perfect syntax of namespaces, and it has taken them so long to decide, that even after 13 years PHP still does not have namespaces!
My point is that when you THINK about programming, you should no be thinking about what characters you're going to have to type in order to enter the program into a text editor. If you are are thinking at such a low syntactic level, and not thinking about the semantics of your program, then you are a shallow programmer. But if all you have to do is write a program that barfs out some HTML and substitutes a few variables, then you can get away with being a shallow programmer, like most PHP programmers. And there's nothing wrong with that. But shallow programmers should not try to design their own languages, because the results are usually disasterous. Both PHP and Smarty exhibit the pathetic symptoms of having been designed by and for shallow programmers, more worried about syntax than semantics. Their attempts to make it simple on the surface result in deep and subtle complexity.
How about using "." for namespaces, like Java or Python? Oh, that's used for string concatination. Then how about "::" (four times as many dots). Oh that doesn't work for some obscure reason. How about... PHP syntax is in a never-ending spiral of unintended consequences! It was never planned. It's just a lame immitation of a bunch of other poorly chosen languages' syntax, without understanding or implementing their semantics. For example, PHP's references aping C++, PHP's class system aping Java, etc.
It's hard to figure out how to put namespaces or any other syntax into PHP without breaking a lot of existing code and creating subtle nuanced special cases, because PHP's syntax is not consistent like Python, nor extensible like Lisp.
PHP's simplicity is only an illusion, because it gets extremely complex and convoluted under the surface, while Python has true simplicity that goes deep. Lua and Lisp are even simpler and deeper.
A templating language's support for math functions does not get in the way of designers using it. They don't need to know math in order to use it. Your argument that designers don't deserve to be able to use math even when they need it is ridiculous. Maybe your designers are mathematically illiterate, and your templates are extremely simple, but don't try to force your low standards on the rest of the world. There is nothing about supporting math that makes a templating language hard to use.
In fact Smarty does support some math functions, but not all of the functions supported by PHP. So are you actually arguing that Smart goes to far in its support for math?
Since when were you the final authority of which functions view logic should be allowed to call? I often need to round a number to a particular number of decimal places in the view, so why are you arguing that I shouldn't be able to?
As for your guess that I don't know MVC: I've writing user interface toolkits since 1986, when I developed pie menus for the X10 "uwm" window manager, and I've been regularly using OOP and MVC since at 1987 or so. When and how did you learn about object oriented programming and MVC? Do you know enough about MVC to offer any criticism of it, or do you just blindly accept it as a given without questioning it?
The hypermedia formatting and templating language I developed around 1987 was called the "HyperTIES Markup Language" for Sun workstation version of the HyperTIES hypermedia browser, while I was working for Ben Shneiderman at the University of Maryland Human Computer Interaction Lab. I implemented the first version in Forth, and it had full access for Forth expressions, conditionals, loops, etc. We implemented the second version in C, and it had a full set of mathematical and string processing functions, as well as the ability to define macros, conditionals, loops, etc.
You should read the paper we published in 1991, because it gives a good explanation of why templating languages should support macros, math and string processing functions. One reason is conditional text. The conditions must be able to evaluate conditional expressions, which need to be able to call math and logic fuctions, as well as many other utility functions that are useful for authoring conditional text.
Have you published or can you reference any peer reviewed papers that support your point that templating languages should not support math? But it seems like you don't know templating languages, anyway.
To achieve effective formatting we created the Hyperties Markup Language (HML) in 1988. It includes standard markup language features and conditional text to easily customize the document based on user actions. Although traditional Generalized Markup Languages, the Interleaf document preparation system, and scripting languages such as Hypertalk enable authors to specify conditional appearance of text, we feel that this feature should appear as a regular part of hypertext systems. Our empirical studies have shown that by limiting the amount of text on the
You're such an apologist. Avoid math, indeed. You sound like a pull-string Barbie doll: "Math is hard!".
I don't need you to lecture me on what functions I should or should not be calling in my templates, thank you. And I don't need Smarty to restrict me arbitrarily to a few specific functions. (That was the problem with Zope's horribley lame "restricted Python".) If you look at the Smarty source code right after the other code I quoted, you will see that's exactly what it does: it has a list of math functions you're allowed to call, but it won't let you call any others (unless you can trick the parser into letting you call them, which is easy because Smarty's parser is so stupid).
Your statement "I don't know if they've found a symbol for namespaces yet" illustrates how some people think about languages in shallow terms of surface syntax, while others think in terms of deep semantics. Namespaces are a semantic issue. The syntax you use for them is not important. Unfortunately most of the PHP designers and programmer are shallow "syntax oriented" thinkers who can only visualize a concept if they know what characters to type to represent it, and they think that once they've designed a syntax (or imitated a syntax of an existing language, like PHP's references imitate C++, but don't share any of the semantics), they're done. They they spend the next 10 years fixing thousands of bugs and security holes that popped up because they didn't think the semantic issues through. That's why PHP is such a totally fucked up mess.
Forcing the programmer to create a dummy object, just to select for real objects of the same type, is a horrible kludge, which is wasteful and imposes unnecessary and obnoxious restrictions on the design and implementation of your objects, and clutters up the code and memory with unnecessary crap. Of course that would not occur to you if you were just trying to ape the surface syntax of ActiveRecord by putting a "Z" in front of it, giving a screencast promising it, and declaring yourself done with the design phase.
Python's Kid template system is proof that you're wrong about XML template systems always being a pain in the ass. I've used it to write a whole lot of complex templates, and I'm very happy with it, and will continue using it. I've also used XSLT, TAL/METAL/TALES in Plone, and Smarty in PHP, and they are all total pains in the ass which I hope to avoid ever using in the future. If you had some perspective on other templating systems, you'd know that hiding commands in processing instructions or cdata is NOT the only way to make them easier. Designing clean simple consistent yet powerful XML based languages is the way to make them easier, and that's what Kid is. OpenLaszlo is another example of a well designed XML based programming language that is easy to use because it's well designed.
At least I'm criticizing and complementing systems that I've actually used. You're just making wild guesses about things you know nothing about, and your guesses are wrong.
I know Smarty translates templates into PHP -- I've read the source code and used it. Kid translates templates into Python, and I've read that source code and used it too. Kid's approach to XML processing is a much more elegent, efficient, better designed than Smarty's ad-hoc string parsing based approach, by a long shot. Go back and read the source code to both systems yourself, and use them for non-trivial projects like I have, before shooting your mouth off about them when you don't know what you're talking about.
Again: Why bother implementing an extremely bad languge like Smarty in a very bad language like PHP? You can't argue that Smarty's syntax is any better than PHP or XML. So why use Smarty at all? Why not just stick with pure PHP? There is no need for Smarty. It doesn't solve any problems that PHP doesn't already solve. It just introduced another fucked-up quirky syntax you have to learn, which makes PHP even harder to use.
And no your could not implement a system like Kid in PHP easily or efficiently, because it's based on XML event handling using Python's generators, which PHP does not support. Kid transformations are easy to write because they use generators with "yield" and "next" in co-routines running in parallel, to efficiently produce and consume XML events, so you can write straightforward procedural code with local variables, conditionals and loops, without writing SAX-like handlers and putting all temporary state into objects. Generators are a language feature that is extremely useful for efficiently processing XML, and they can't be implemented by a library: they have to be built into the language. PHP does not have generators, and I doubt it ever will.
Generator:
In computer science, a generator is a special routine that can be used to control the iteration behaviour of a loop. A generator is very similar to a function that returns an array, in that a generator has parameters, can be called, and generates a sequence of values. However, instead of building an array containing all the values and returning them all at once, a generator yields the values one at a time, which requires less memory and allows the caller to get started processing the first few values immediately. In short, a generator looks like a function but behaves like an iterator.
In Python, a generator can be thought of as an iterator that contains a frozen stack frame. Whenever the iterator's next() method is called, Python resumes the frozen frame, which executes normally until the next yield statement is reached. The generator's frame is then frozen again, and the yielded value is returned to the caller.
Smarty is purely string based, and not at all XML compliant, and makes no guarantees about the validity of its input or output. XMLReader's detailed description is "This class can be used to parse XML documents and build an array with structure and data.
My point exactly: Of course they will never fix it! Move on to other languages than PHP, because PHP will always suck, and never be fixed.
But if you have to lie about what I said in order to make your straw-man argument, then I pity you too. Have you looked up the meaning of the word "verbatim" yet? I truly pity a person who is as illiterate as yourself.
Who are you, Gorak, the prehistoric ice man from 1996??! How long have you been frozen in a cave, if you're just getting over the impression that XML is the latest fad? What was it like having Steve Irwin jam his thumb up your butthole?
Slashdot Mirror
If you look carefully, you'll notice that's a cast on his left arm. He broke it skiing. Fortunately he didn't break his design arm.
-Don
The New York Times article explains why SimCity is one of the ten most important video games of all time:
SimCity exemplifies Seymour Papert's ideas about Constructionist Learning:
The OLPC (One Laptop Per Child) project is based on Seymour Papert's ideas about Learning Learning by fun immersive play, and his experience teaching the Logo programming language to elementary school students: Constructionist Learning and Constructivism are central to the goals of the OLPC.
At the Game Developer's Conference, SJ Klein (Director of Content for the One Laptop Per Child project) gave the keynote address at the Serious Games Summit. He explained the philosophy behind the project, and asked developers to join in the project to develop a game platform, games, tools and courseware to distribute to classrooms and homes of some two billion children across the globe.
SJ Klein said: "Existing games are nice, and cute," but games for things like learning language are the "gem they're targeting." Most importantly, Klein said in a direct plea to the serious game developers in front of him, the project needed frameworks and scripting environments -- tools with which children themselves could create their own content.
-Don
Developing reusable libraries that kids can use to write their own game is just what the OLPC project needs. It's best to write the libraries in pure Python, if performance isn't an issue. High performance libraries should be written in C or C++, and packaged as Python modules. The preferred way of drawing is with the Cairo library, which you can call from Python. You can also write C modules that get passed a Cairo context that they can draw with.
In the case of SimCity, I'm planning on factoring it out into reusable components, like the tile engine (written in C since it must deal with a lot of pixels and run fast), the sprite engine (which would be easiest to write in Python since it will simply call Cairo to do the rendering), map overlay (Python, for the same reason), graph display (ditto Python), etc. Then it will be possible to use those components in other games and toys, like using the tile engine for a cellular automata lab.
The OLPC needs all different kinds of game toolkits to support various games geanras, like a card game toolkit, a board game toolkit, a platform game toolkit, a space invaders game toolkit, a pong game toolkit, a simcity game toolkit, etc.
Pygame will be a useful imaging library, especially for full-screen bitmap-oriented and 3d games. But games that require user interface components and scalable outline graphics will be easy to draw with Cairo. It would be great to be able to draw in a pygame full screen context with Cairo, to have the best of both worlds.
-Don
Squeak and eToys are currently included with the OLPC. And it is a wonderful way for kids to learn to program games, as well as for programmers to learn about Alan Key's revolutionary ideas! It's purpose is to inspire people, expose them to Smalltalk's unique ideas, the possibilities of visual programming systems, and point the way for future development. But the mainstream of software development on the OLPC will be done in Python.
Guido Van Rossum writes about Alan Kay's talk on his blog:
The idea is to re-implement the ideas of Squeak and other educational constructionist visual programming systems in Python, deeply integrated with the OLPC's Sugar user interface, and based on its libraries like GTK/Cairo/Pango, etc. Alan Kay writes on the Sugar mailing list:
It would be a great idea to sell the OLPC retail to software developers and people in developed countries at a premium price to subsidize them for kids in developing countries. That was the most commonly request people made at the OLPC booth at the game developer's conference.
But the reason they aren't currently selling the OLPC retail yet is that it takes a huge amount of effort and overhead to manage something like that, and the OLPC organization is small and focused on delivering them to the target countries by the millions, at no margin. Managing retail sales would distract from the more important goal of rolling out the laptop to children.
Eventually some other organization might buy a million or so of them and sell them retail, but nothing like that is planned or announced yet, as far as I know.
It's not because they want to keep the laptop away from us, it's because they want to get them to the real target audience as soon as possible.
Software developers can send email to the project describing what software they want to port to it, and if you qualify they will send you one right away for free. I applied for one around christmas, to port SimCity, and it arrived by fedex in just a few days. I don't believe they will ask for them back, since the beta units will soon be obsolete anyway, after they make the next run of them.
They are however putting a lot of effort into making the software development environment available to external developers, so you can develop software without having the actual laptop. You can install the software on a Linux system and run it much faster than it runs on the OLPC, because the "emulation" does not slow it down signifigantly, and your Linux box probably has a much faster processor and lots more memory than the actual machine. There is nothing special about the screen from a software point of view -- it's just a 1200x900 16 bit display from X11's point of view. Get your software running in the development environment on a regular Linux laptop, then make it run as fast as possible, and consume as few resources as possible. Once you can demonstrate a working application on the OLPC under emulation, and need to test it against the actual hardware, you chances of receiving an actual unit to test it on are much higher.
Here is why they are not for individual sale, and here is information about where the Retail Sales Model fits into the whole concept of a $100 laptop. This article describes why One Laptop per Child Has No Plans to Commercialize XO Computer.
"The bottom line is that our mission is learning, not laptops. While we will be working with a commercial partner at some point for both machines and interesting parts--we've been looking at models where by the commercial side can help drive down the cost for the kids--our immediate priority is the non-commercial machine." -Walter Bender
-Don
The software sees the screen as a 1200x900 16 bit color framebuffer (and draws on it via X11). There is a button that rotates the screen, and the software does notice the aspect ratio changing between 1200x900 and 900x1200, thanks to window resize events propogated through the window manager. The hardware automatically converts it to monochrome and reduces the color resolution (called "swizzling"). So the color/monochrome "mode" is invisible to the software. You just keep drawing in color at the same full resolution, and the user can switch between reflective monochrome, and color with various brightnesses. So a 3D renderer would just draw in full color, and not concern itself with the monochrome mode or down-rezing the color. I don't know what the refresh rate is, but it look solid and animates smoothly.
-Don
Great questions! I'll try to answer:
a) There is already a Linux-capable SimCity: Yes!
b) We are talking about SimCity Classic: Yes!
c) The end result will be OSS: Yes!
d) It will be scriptable in Python: Yes!
a) Are you going to keep it in Tcl/Tk, or is it a complete rewrite in Python and (insert toolkit here)?
The TCL/Tk version will be open source (GPL), so you can do what you want with that, but it's using an old hacked version of TCL/Tk circa 1992. It's stable and playable, but it would be a lot of work to upgrade it to the most recent version of TCL/Tk, and I believe the effort would be better spent converting it to Python and then working on that instead. I plan on porting it to Python by using SWIG, so it will be possible to plug it into other languages that SWIG supports, like Lua.
b) Will this version be usable/portable outside of the OLPC (both leagally and technically)?
The TCL/Tk version will legally and technically run outside of the OLPC. The Python version that I'm developing will use libraries like GTK, Cairo and Pango which run on the OLPC and also work well on other platforms, but it will also use some other libraries that only make sense on the OLPC. The primary goal of my efforts will be supporting the OLPC, but other people can work on supporting other platforms, or even porting OLPC specific libraries so they work on other systems.
c) How faithful is this version to "reference" SimCity (Let's say either the Win31 or Mac versions)?
It's faithfully based on the original Mac version of SimCity "Classic" (before they added the word "Classic" after releasing SimCity 2000). I also have the old terrain editor code, which would be nice to update and integrate into the new code base. It would be great to dig up the old tile sets (European city, moon city, etc), but I don't currently have a copy of them. I have cleaned up and reorganized the code a lot, fixed some bugs, optimized the hell out of it, and replaced the random number generator. I've totally rewritten the user interface and graphics code. But functionally the simulator and is almost exactly the same as Mac SimCity. The save file format is the same, so you can use Mac and PC cities. The only change to the simulator that I can remember was to make the helicopter attracted to the monster so it blows up more often!
-Don
SJ Klein and I just had a productive meeting with Charles Norman at EA to discuss the details of SimCity for the OLPC, and it's looking very good! It's not officially announced or available yet, but EA is very supportive of the idea, and is just crossing their eyes and dotting their tease (or something to that effect), and Will Wright gave us permission to demonstrate SimCity on the OLPC at the game developer's conference.
If you're at GDC, please come by the OLPC booth at the expo and play with it!
I've done the first basic cut of porting the X11/TCL/Tk based multi player version of SimCity to run on the OLPC, and the next step is to integrate it with Python and Sugar in a deep way, that will make SimCity scriptable in Python, enable all kinds of interesting hooks and plug-ins, and result in a set of reusable general purpose components for building games.
For example, the next step I've taken is to rewrite pie menus in Python with Cairo and Pango, so SimCity and other applications can use them:
http://www.donhopkins.com/drupal/node/128
The point is not just to port a game to the OLPC, but rather to use SimCity and other games to drive the development of an open framework to enable and teach kids to program their own games!
The goal is to enable the open source community to renovate SimCity and take it in new educational directions, by applying Seymour Papert's ideas about constructionist education, Alan Kay's ideas about interactive user interfaces and object oriented programming, Ben Shneiderman's ideas about direct manipulation and info visualization, and many exciting ideas about multi player games, blogging, storytelling, game mods, player created content, and lessons learned from World of Warcraft, The Sims, Spore, etc.
Thanks to John Gilmore for getting the ball rolling by suggesting that EA make the original version of SimCity free for the OLPC, and for supporting the development of great free software and tools like GCC, and to Charles Norman for guiding the process through EA, educating people about open source, and making it actually happen, and of course to "Will Wright Code for Food" for creating SimCity it in the first place, and putting his Will Power into making SimCity open source for the OLPC project!
-Don
PS: Here is some stuff about the multi player X11/TCL/Tk version of SimCity:
Multi Player SimCity for X11 is now available from DUX Software!
http://art.net/~hopkins/Don/simcity/simcity-announ cement.html
Screen snapshots:
http://www.donhopkins.com/home/images/SimCity-For- X11.gif
http://www.donhopkins.com/home/images/SimCity-Indi go.gif
http://www.donhopkins.com/home/images/SimCity-NCD. gif
http://www.donhopkins.com/home/images/SimCity-Sun. gif
X11 SimCity Demo Video:
http://www.donhopkins.com/home/movies/X11SimCityDe mo.mov
Video Tape Transcript of X11 SimCity Demo:
http://art.net/~hopkins/Don/simcity/x11-demo.html
Video Tape Transcript of Toronto Usenix Symposium Keynote Address:
http://art.net/~hopkins/Don/simcity/keynote.html
Bedlam in SimCity:
http://www.art.net/~hopkins/Don/simcity/simcity-re view.html
PPS: 15 y
And 12% for Pat Buchanen!
-Don
Dumbold Voting Machine for The Sims
The Dumbold Voting Machine for The Sims enables the simulated people in your virtual dollhouse to vote!
It's an interactive "get out the vote" public service message, in the form of a free downloadable Sims object.
This Sims object is an electronic voting machine that lets your Sims vote between four candidates: Kerry, Bush, Nader and Badnarik.
I've included informative text in this Sims object, which it displays in illustrated dialogs to educate players about electronic voting machines.
A major side-show is the "Monkey" item on the pie menu, which activates all kinds of cool easter eggs, and displays lots of in-game information and news about electronic voting machines.
Please give this Dumbold Voting Machine a good pounding on, and tell me if you have any problems (besides the usual problems endemic to electronic voting machines, which I've programmed into this Sims object on purpose).
At first look, it appears to be a fully functional voting machine. But it actually has a lot of fatal bugs and hidden features, just like real electronic voting machines!
Highlights of Cheats, Bugs and Easter Eggs (Illustrations are here)
The Dumbold Voting Machine is programmed with cheats, bugs and easter eggs, which you can discover and read about by playing around with it. It demonstrates and simulates some alarming problems with real world electronic voting machines, with many surprising effects and subtle interactions:
Baxter the Chimpanzee Erases the Voting Log. When you put the voting machine into debug mode and clear the votes, you will see a dialog with the hillarious picture and story of Baxter the Chimpanzee. In your web browser, you can watch the funny monkey movie showing Baxter erasing the voting log! Now your Sims can monkey around with the electronic Dumbold Voting Machines, go bananas hacking the system, fling poo and corrupt the election results just like the pros!
Vote or Die! P. Diddy, lately a.k.a. Citizen Combs, says: "'You all are the X-factor, the wild card," Combs said. "`History is being made here. Our revolution has begun." "Young voters in this country are throwing away their power to have a say about education, healthcare, and any issue that affects them." Combs explains. "These things affect your life, so - Vote or Die!" (If you select Vote, you live. If you select Die, you either get electrocuted, or burst into flames, then you die.)
You punched out the screen! Hey!!! You're supposed to touch the screen, not punch it! Next time, please don't take out your frustration with the lousy choice of candidates by punching the screen. That's not the way to get your vote counted. (Your Sim breaks the voting machine screen. You can repair it if you're skilled enough, but you might want to keep a handyman on call during the election!)
Osama Bin Laden Scares the Piss Out of You!!! Osama Bin Laden wants to scare you into voting for George W Bush, because Bin Laden is grateful to Bush for outsourcing the job of hunting him down to Osama's good friends, the Afghan warlords. Bush's policies have strengthened Bin Laden's cause, and George W Bush says he's not worried about Osama Bin Laden. Bush and Bin Laden both want you to vote in response to your of fears, not in pursuit of your hopes. "Americans all know that Osama Bin Laden doesn't pick our president. The Supreme Court does." -Bill Maher (Your Sim empties their bladder, pisses their pants, and then runs away screaming!)
Accidentally Voting for Pat Buchanan. When you select one of the four official candidates, sometimes it "accidentally" pops up an illustrated dialog asking for confirmation that you want to vote for Pat Buchanan! If you foolishly select "Yes", the voting machine breaks!
News about Black Box Voting.
News about CalTech-MIT/Voting Technology Project.
News about Diebold
The Python reference manual.
Seriously: So what if "properly coded PHP" is still useful? It's not as useful or as easy to properly code as other languages, so why do you persist in using an inferior, defective language like PHP? Properly sealed lead and asbestos are "still useful" in constructing new houses, but you certainly should not use them! The fact that something's "still useful" does not negate the fact that it's still foolish to use it, if you have a better alternative.
-Don
And how many PHP applications are NOT FAULTY?
Not many!
-Don
The problem with using a pull parser like XMLReader from a language like PHP that doesn't support generators, is that it's difficult to write the rest of your XML processing stack using the efficient event-driven pull processing approach. The parser is only the first step of an XML processing pipeline, and while it's nice to have a pull parser, it's much nicer if you can write the rest of the templating system and XML processing pipeline in that style, as well. Which is extremely difficult to do in PHP, because it lacks generators. Why should only the parser be efficient, and not the rest of the program?
You claim you understand what generators are. Then do you think they could be implemented in PHP by a good programmer? How? Do you consider yourself a good PHP programmer, or will you pass on explaining on how to implementen generators in PHP?
Not having the attention span to understand the issues is not an excuse for being wrong -- it just means your opinions aren't valuable because you refuse to put the time into learning. If these issues bore you so much, then perhaps you shouldn't be programming computers, and just flip burgers instead?
-Don
"Stop the Blah", huh? So you've stuck your fingers in your ears and you're chanting "ya ya ya ya ya" because you refuse to listen to what I say, since you can't come up with any better arguments? Why can't you answer any of the questions I've asked you? If you incapable of answering any of the questions I've brought up, then you're conceding my points, thank you.
-Don
You're the one who accused me of not knowing about MVC or templating, so I gave you some references to my experience. You're the one who brought the subject up by making false accusations. Do you retract what you said about me not understanding MVC or templating?
If Smarty's {math} isn't a good idea to use, as documented by the Smarty manual, then why does it exist? Either Smarty is supporting "bad" features that you should not use, or your premise that "math is bad" is wrong.
Of course PHP is a horrible language because it's rife with stupid half-baked ideas that they threw into the language but that are a bad idea to actually use (register_globals, magic_quotes_gpc, addslashes, all the other half-assed attempts at quoting sql strings, etc.) But math is not one of those mistakes. Do you think it's OK for Smarty to have features that you claim are bad ideas, just because that's typical of the PHP culture?
My point is that you are dead wrong about math being bad in templates. You're just attempting to apologize for Smarty by repeating what you believe is the "conventional wisdom", and that conventional wisdom is dead wrong.
What references can you give me that prove your point that you should not use math in templates? Did Alan Kay ever stand up and said "I invented OOP and MVC, and I say that views should not use math"? I gave you a reference to a paper I wrote with Ben Shneiderman (who is a user interface and hypermedia researcher whose name you should recognize if you know anything about the subject), published in the peer reviewed ACM journal of Hypermedia, which clearly describes why it's useful to have math in templates (for calculating the condition for conditional text). What is your counter-argument, or do you prefer to avoid answering that question because you can't? Claiming your too bored is conceding my point.
You keep trying to avoid addressing the arguments, by claiming you're too bored to respond, or twisting my words. I never accused you of saying a good and easy template engine needs a language that supports generators, so why are you denying that you said it, if I never implied you did? You can't win an argument by repeating the other person's point as if it's your own, as if I accused you of claiming the point I was trying to make. That only works in Bugs Bunny cartoons.
What I do accuse you of implying is that a good PHP programmer could implement generators (by saying that I wasn't a good enough PHP programmer to implement Kid in PHP), which means you have no idea what generators are, even though I pointed you to a perfectly good explanation of what they are. Did you read the explanation? Do you still believe that a PHP programmer can implement generators in PHP, or not? Do you think you're such a great PHP programmer that you could implement a templating system as efficient and easy to program as Kid, with or without generators?
So how do you propose a PHP programmer implement a good templating system without generators? I previously listed the advantages that generators have over the SAX based even call-back method, which as you know, if you've ever tried using it, is a total pain in the ass and hard to program. I also listed the advantages that generators have over parsing the entire document into a DOM tree, which is a total waste of memory, and extremely inefficient. Generators enable you to 1) process arbitrarily sized XML documents efficiently, 2) write straightforward code that uses conditionals and loops 3) keep temporary state in local variables instead of having to store it in object fields between event handler invocations. So which programming techniques do you suggest PHP programmers use to get around the problems that generators solve so nicely?
Ignoring smarty is not an option for me. I know how bad it is because I'm working on a project that uses it, and I have read the source code to understand how it works. So I have every right to complain about it.
-Don
Of course I'm answering your posts -- you're just ignoring my answers. What point did you make that I didn't address? Just because you don't understand what I'm saying doesn't mean it means "blah". Go read the article on generators. You implied that a good PHP programmer could implement generators in PHP, and you are totally wrong. You obviously don't know what generators are. I provided a reference. Did you read the article I refered you to about generators? Do you understand them now? Do you still maintain that a good PHP programmer could implement generators without hacking the PHP interpreter source code in C? Or do you concede my point?
And now you are misquoting me: I never said "an easy XML template engine can only be done with generators". I said templating languages should have well designed syntax and semantics, but Smarty has neither, while Kid has both. I also said that generators make it much easier to implement efficient elegent XML processing tools (note that implementing a templating language is very different than using it: graphical designers don't have to understand or use generators in order to use Kid), and you haven't been able to counter that argument because you don't even understand what generators are, even though I provided a reference. Are you too lazy to learn? Then concede my point. The ball's in your court and the burden of proof is on you.
Are you contesting my claim that generators are extremely useful for implementing efficient XML processing pipelines? Or do you accept my point? Are you arguing that syntax doesn't matter? That semantics doesn't matter? Or do you accept my point that both matter? Are you arguing that Smarty has good syntax and semantics, or do you accept my point that it sucks?
What templating languages have you implemented, and have you published any papers about them so I can read about your design? Have you read the paper about the HyperTIES markup language I implemented in 1987 and published with Ben Shneiderman in 1991? Have you ever read any other papers written by Dr. Shneiderman, or even heard of the field of human computer interaction, or read the ACM journal of Hypermedia? Have you even heard of ACM? Do you have any problems with the points that peer reviewed paper made about markup language design? I linked to the source code and documentation that I wrote, so you can look at that and make comments on it. So what are your comments on the points I made? Silence?
"If you don't want to answer my points just don't", but that "makes you look very stupid". I am addressing your arguments point by point, and you're totally ignoring every point I'm making. Why is that? Can you answer any of these questions I've asked, or are you just frustrated that you made a lot of stupid arguments about topics that you don't know much about, and you're trying to run away from the argument without answering any questions?
You accused me of not knowing what MVC was, and I told you when I first started using it, and refered you to some criticism I wrote about it. What are your comments on that? More silence? I addressed your incorrect accusation, and asked you when you learned MVC and if you had any criticism of it or just accept it blindly, but you refused to answer. More silence that makes you look stupid.
Face it: Smarty is a piece of shit, and you're trying to apologize for it by making ridiculous statements like "don't use math in templates". You are full of shit, and I refered you to papers I wrote years ago to answer your posts and rebut your points! Don't blame me if you're too lazy to read them or too ignorant to understand them.
You're wrong that I don't want to answer your posts. I have, but you just ignored me. Can't you defend your statments? Why can't you answer my questions point by point, instead of ignoring them all?
-Don
You still don't get it. A pull parser is not the same thing as generators. Generators are a programming language construct which is extremely useful for implementing pull parsers, and modular telescoping XML processing pipelines, like the Kid templating system.
Go read the link about generators that I provided. Then please explain how you would implement generators in PHP. You can't, because it's a language feature that can't be implemented at the PHP script level. It required modifying how the PHP interpreter works. Let me say this again: it is impossible to implement generators in PHP code, no matter how good a PHP programmer you are -- you have to rewrite the PHP interpreter which is written in C, to implement generators. Generators enable your processing modules to run in parallel, each with its own return stack and local variables (i.e. co-routines). PHP absolutely cannot do that.
If you don't believe that, then you don't understand how generators work, so go back and read the article again. Then try to convince the PHP designers to add generators to PHP: good luck!
Python supports generators, because they are built into the interpreter. They are a fairly new feature from Python 2.3, described in PEP 255: Simple Generators. The Python interpreter C code had to be modified to support them, and it was done because generators are so useful (especially for processing XML).
Other more powerful languages like Scheme do not have to have their interpreters modified in order to support generators, because they already have more powerful programming constructs (like continuations) that can be easily and efficiently used to implement generators.
But since PHP does not support continuations or co-routines, it is absolutely impossible to implement generators (or Kid-like templating systems) in PHP, no matter how great a PHP programmer you are.
-Don
Perl is a write-only language, because its designer believes it's OK for syntax to be extremely complex, subtly nuanced, haphazard and inconsistent, which I strongly disagree with.
Grammars "is" important, too.
Both syntax AND semantics are important. If you screw up either one of them, you've made a mistake. Smarty is so horribly bad because it totally screws up BOTH syntax and semantics. Kid is so wonderfully elegant because it has both excellent syntax and semantics.
Your words suggest that you (and the PHP designers you're talking about) are thinking in terms of syntax, and ignoring the semantics. Quibbling about what character to use to syntactically represent namespaces should not hold up such an important issue of language design. PHP should have had namespaces from day one, but now it's way too far down the road of "globalism," with millions of programs depending on thousands of global variables and functions, so adding namespaces to PHP now would just be closing the barn door years after the horse left the barn. It's laughable that they'd be so concerned about figuring out the perfect syntax of namespaces, and it has taken them so long to decide, that even after 13 years PHP still does not have namespaces!
My point is that when you THINK about programming, you should no be thinking about what characters you're going to have to type in order to enter the program into a text editor. If you are are thinking at such a low syntactic level, and not thinking about the semantics of your program, then you are a shallow programmer. But if all you have to do is write a program that barfs out some HTML and substitutes a few variables, then you can get away with being a shallow programmer, like most PHP programmers. And there's nothing wrong with that. But shallow programmers should not try to design their own languages, because the results are usually disasterous. Both PHP and Smarty exhibit the pathetic symptoms of having been designed by and for shallow programmers, more worried about syntax than semantics. Their attempts to make it simple on the surface result in deep and subtle complexity.
How about using "." for namespaces, like Java or Python? Oh, that's used for string concatination. Then how about "::" (four times as many dots). Oh that doesn't work for some obscure reason. How about ... PHP syntax is in a never-ending spiral of unintended consequences! It was never planned. It's just a lame immitation of a bunch of other poorly chosen languages' syntax, without understanding or implementing their semantics. For example, PHP's references aping C++, PHP's class system aping Java, etc.
It's hard to figure out how to put namespaces or any other syntax into PHP without breaking a lot of existing code and creating subtle nuanced special cases, because PHP's syntax is not consistent like Python, nor extensible like Lisp.
PHP's simplicity is only an illusion, because it gets extremely complex and convoluted under the surface, while Python has true simplicity that goes deep. Lua and Lisp are even simpler and deeper.
-Don
A templating language's support for math functions does not get in the way of designers using it. They don't need to know math in order to use it. Your argument that designers don't deserve to be able to use math even when they need it is ridiculous. Maybe your designers are mathematically illiterate, and your templates are extremely simple, but don't try to force your low standards on the rest of the world. There is nothing about supporting math that makes a templating language hard to use.
In fact Smarty does support some math functions, but not all of the functions supported by PHP. So are you actually arguing that Smart goes to far in its support for math?
Since when were you the final authority of which functions view logic should be allowed to call? I often need to round a number to a particular number of decimal places in the view, so why are you arguing that I shouldn't be able to?
As for your guess that I don't know MVC: I've writing user interface toolkits since 1986, when I developed pie menus for the X10 "uwm" window manager, and I've been regularly using OOP and MVC since at 1987 or so. When and how did you learn about object oriented programming and MVC? Do you know enough about MVC to offer any criticism of it, or do you just blindly accept it as a given without questioning it?
The hypermedia formatting and templating language I developed around 1987 was called the "HyperTIES Markup Language" for Sun workstation version of the HyperTIES hypermedia browser, while I was working for Ben Shneiderman at the University of Maryland Human Computer Interaction Lab. I implemented the first version in Forth, and it had full access for Forth expressions, conditionals, loops, etc. We implemented the second version in C, and it had a full set of mathematical and string processing functions, as well as the ability to define macros, conditionals, loops, etc.
Here is a description (including links to the source code) of the HyperTIES Hypermedia Browser and Emacs Authoring Tool for NeWS, and also a paper we published about HyperTIES in the ACM journal "Hypermedia" Volume 3, Issue 2 (1991): Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser [reference].
You should read the paper we published in 1991, because it gives a good explanation of why templating languages should support macros, math and string processing functions. One reason is conditional text. The conditions must be able to evaluate conditional expressions, which need to be able to call math and logic fuctions, as well as many other utility functions that are useful for authoring conditional text.
Have you published or can you reference any peer reviewed papers that support your point that templating languages should not support math? But it seems like you don't know templating languages, anyway.
You're such an apologist. Avoid math, indeed. You sound like a pull-string Barbie doll: "Math is hard!".
I don't need you to lecture me on what functions I should or should not be calling in my templates, thank you. And I don't need Smarty to restrict me arbitrarily to a few specific functions. (That was the problem with Zope's horribley lame "restricted Python".) If you look at the Smarty source code right after the other code I quoted, you will see that's exactly what it does: it has a list of math functions you're allowed to call, but it won't let you call any others (unless you can trick the parser into letting you call them, which is easy because Smarty's parser is so stupid).
-Don
Your statement "I don't know if they've found a symbol for namespaces yet" illustrates how some people think about languages in shallow terms of surface syntax, while others think in terms of deep semantics. Namespaces are a semantic issue. The syntax you use for them is not important. Unfortunately most of the PHP designers and programmer are shallow "syntax oriented" thinkers who can only visualize a concept if they know what characters to type to represent it, and they think that once they've designed a syntax (or imitated a syntax of an existing language, like PHP's references imitate C++, but don't share any of the semantics), they're done. They they spend the next 10 years fixing thousands of bugs and security holes that popped up because they didn't think the semantic issues through. That's why PHP is such a totally fucked up mess.
Forcing the programmer to create a dummy object, just to select for real objects of the same type, is a horrible kludge, which is wasteful and imposes unnecessary and obnoxious restrictions on the design and implementation of your objects, and clutters up the code and memory with unnecessary crap. Of course that would not occur to you if you were just trying to ape the surface syntax of ActiveRecord by putting a "Z" in front of it, giving a screencast promising it, and declaring yourself done with the design phase.
-Don
Python's Kid template system is proof that you're wrong about XML template systems always being a pain in the ass. I've used it to write a whole lot of complex templates, and I'm very happy with it, and will continue using it. I've also used XSLT, TAL/METAL/TALES in Plone, and Smarty in PHP, and they are all total pains in the ass which I hope to avoid ever using in the future. If you had some perspective on other templating systems, you'd know that hiding commands in processing instructions or cdata is NOT the only way to make them easier. Designing clean simple consistent yet powerful XML based languages is the way to make them easier, and that's what Kid is. OpenLaszlo is another example of a well designed XML based programming language that is easy to use because it's well designed.
At least I'm criticizing and complementing systems that I've actually used. You're just making wild guesses about things you know nothing about, and your guesses are wrong.
I know Smarty translates templates into PHP -- I've read the source code and used it. Kid translates templates into Python, and I've read that source code and used it too. Kid's approach to XML processing is a much more elegent, efficient, better designed than Smarty's ad-hoc string parsing based approach, by a long shot. Go back and read the source code to both systems yourself, and use them for non-trivial projects like I have, before shooting your mouth off about them when you don't know what you're talking about.
Again: Why bother implementing an extremely bad languge like Smarty in a very bad language like PHP? You can't argue that Smarty's syntax is any better than PHP or XML. So why use Smarty at all? Why not just stick with pure PHP? There is no need for Smarty. It doesn't solve any problems that PHP doesn't already solve. It just introduced another fucked-up quirky syntax you have to learn, which makes PHP even harder to use.
And no your could not implement a system like Kid in PHP easily or efficiently, because it's based on XML event handling using Python's generators, which PHP does not support. Kid transformations are easy to write because they use generators with "yield" and "next" in co-routines running in parallel, to efficiently produce and consume XML events, so you can write straightforward procedural code with local variables, conditionals and loops, without writing SAX-like handlers and putting all temporary state into objects. Generators are a language feature that is extremely useful for efficiently processing XML, and they can't be implemented by a library: they have to be built into the language. PHP does not have generators, and I doubt it ever will.
Smarty is purely string based, and not at all XML compliant, and makes no guarantees about the validity of its input or output. XMLReader's detailed description is "This class can be used to parse XML documents and build an array with structure and data.
My point exactly: Of course they will never fix it! Move on to other languages than PHP, because PHP will always suck, and never be fixed.
But if you have to lie about what I said in order to make your straw-man argument, then I pity you too. Have you looked up the meaning of the word "verbatim" yet? I truly pity a person who is as illiterate as yourself.
-Don
What are you doing back on Web 3.0? My web goes to 11.0!
-Don
Who are you, Gorak, the prehistoric ice man from 1996??! How long have you been frozen in a cave, if you're just getting over the impression that XML is the latest fad? What was it like having Steve Irwin jam his thumb up your butthole?
-Don