You are absolutely wrong about Smarty, which is a horribly conceived and implemented disaster. Don't be such a yapping apologist, just because you managed to throw together your home page in PHP without knowing any other languages.
I am speaking from experience, having had to use PHP and Smarty, and having read the source code to Smarty in an vain attempt to figure out how it worked and why it was so difficult to get it to do even the simplest things correctly. I've been much happier using other better designed templating systems, which I will describe below.
After this point, the discussion about the tags comes from shopt open tags to "then what should I use for templating?!? and people would go "Wooo! Smarty! Go with Smarty!", and would make me slap people senseless just for saying that. Just as hating PHP for number of damn good reasons, I have a number of hating Smarty to go along with it. Brace yourself, because here it goes:
1. Smarty is programming language
2. Smarty is overkill in majority of cases
3. Speed: Smarty isn't a solution. it's the major problem.
and here go the details about stated points above:
1. Most people would argue, that Smarty is a good solution for templating. I really can't see any valid reasons, that that is so. Specially since "Templating" and "Language" should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is "better for designers, since they don't need to learn PHP!". Wait. What? You're not learning one programming language, but you're learning some other? What's the point in that, anyway? Do us all a favour, and just *think* the next time you issue that statement, okay?
2. I think, that "overkill" is an understatement. You're trying to disguise simple outputting in a complex set of classes,which implements a programming language inside of it -- Definitively overkill". "But it does caching". No, not really. "Caching", in the terms of Smarty is nothing else than converting that template code into PHP. See? I told you there is no point in using Smarty. It doesn't make your life easier. It doesn't make developer's life easier, and it doesn't make server's life easier.
3. The previous paragraph says it all about the speed slugs in Smarty, but I feel the urge to recap that:
1. "caching" mechanism sucks. It's not a proper caching. It's just a conversion of one interpreted language to another one. and in very unoptimized way. If you want to do the proper cachin, go with APC, Zend optimiser or EAcellerator.
2. The implementation of one interpreted language in another interpreted language does nothing but slow everything down
I use Drupal for my home page, so I know first hand that it sucks, and why. My dislike for PHP comes from hands on experience, writing and reading PHP code, not just reading web pages about it. PHP is not my only programming language, so I don't lack the perspective to compare it to other alternatives.
Python has a wide range of templating systems, some of which are much better than Smarty, and a few of which are almost as bad (but none are worse).
Zope uses DTML, which is unstructured and messy but gets the job done. It also has TAL and METAL, which are cleaner and more powerful, but an incredible pain in the ass to use, and extremely verbose and clumsy. I've written a lot of DTML, TAL and METAL, and I don't want to ever use them again, because I've found much better Python based templating systems since then.
TurboGears uses Kid, which is a very nicely designed an implemented templating system that provides a thin XML veneer on top of Python, and doesn't try to reinvent its own p
There are many practical, clean, simple and easy to learn programming languages, much better than PHP, that are great to learn as a first programming language.
Learning Lua will enable you to write your own World of Warcraft mods, and increase your chances of writing your own game or getting a job in the game industry, as well as enabling you to script all kinds of applications like Adobe Lightroom and WireShark. Lua is an extremely well designed and implemented, efficient and powerful programming language, which will open your mind in the same way Lisp does, instead of corrupting it like PHP and BASIC.
And of course Python is also extremely useful to learn as a first language, for all the same reasons as Lua, and also the fact that it has a huge library of mature, solid, powerful modules (unlike PHP's PEAR, a collection of buggy, poorly though out modules, hacked together by ametuers).
For all the complaints about various PHP extensions, there are also many complaints about the PHP language design and implementation itself.
Take, for example, magic_quotes_gpc. That is the stupidest flaw ever, which should have never been in any rationally designed language in the first place, and it makes programming in PHP a LOT more obnoxious and error prone.
Don't blame Perl for PHP's mistakes. It was idiotic of the PHP designers to foolishly ape the mistakes of Perl (and later the mistakes of Java, when PHP5 tried to express PHP's dynamic interpreted language's OOP system in the SYNTAX of a Java's static complied language OOP system, resulting in a horrible impedance mismatch, and many subtle inconsistencies and gotchas). That is called "Cargo Cult Programming Language Design".
The REASON that most of the code in PEAR is crap, is because PHP encourages and supports crappy programming, which is precisely WHY it should not be taught as a first programming language.
If you're a PHP programmer, you're irresponsible if you're not already aware of its flaws, because you have not educated yourself by reading any of the following well publicized articles. Once you understand the flaws of PHP, you can't honestly make the statement that it's a well designed language suitable for teaching programming to kids.
1. Bad recursion
2. Many PHP-modules are not thread safe
3. PHP is crippled for commercial reasons
4. No namespaces
5. Non-standard date format characters
6. Confusing licenses
7. Inconsequent function naming convention
8. Magic quotes hell
9. Framework seldom used
10. No Unicode
11. Slow
Then there is the mind-set of the PHP language designers and community, which is deeply flawed.
Ian Bicking's "PHP Ghetto" article
sums up the problem with PHP's design and community pretty well:
I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.
He perfectly summarizes the yapping of the PHP apologists when he says:
Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better."
He summarizes:
In short, PHP sucks because, PHP's authors are prone to confuse "pragmatism" (a fine design goal, if done well) with "adding random features without considering how they impact the language as a whole." Thus, its authors have found it necessary to correct obvious flaws in both minor and major releases, with the result that the recent PHP5 breaks with the past to an unprecedented degree while still leaving many fundamental flaws un-addressed. I don't know if this is because they didn't recognize those flaws, or more likely, because they were willing to impose "requires a lot of pain to upgrade" but not "requires a complete re-write."
There is also a lot of great stuff about why PHP is so bad on
http://www.ranting-wolf.info/category/technology/programming/php/
including a concise description of why the "Smarty" templating system is such a horribly ill conceive and terribly implemented idea.
And if you're still not convinced the design of PHP is deeply flawed, because language design is HARD and should only be attempted on purpose by experienced people, here's what the Father of PHP Rasmus Lerdorf himself said in an
ITConversations interview,
quoted in
"Why PHP sucks, Part III":
"I don't know how to stop it, there was never any intend to writ
There are so many reasons not to start with PHP, that I'm not even going to start listing them here. PHP is a HORRIBLE first language, and a horrible second, third or forth language. It corrupts minds, and makes it harder to learn other languages. It's a lot worse than corrupting someone by teaching BASIC as a first language.
You should be ashamed of yourself for suggesting teaching PHP to a kid.
-Don
Linux is only free if your time is worthless.
on
Linux Needs More Haters
·
· Score: 1, Interesting
Cool! That was the same year I started there. I don't know your real name, but we may have known each other. You can email me if you like at dhopkins@DonHopkins.com.
Were you on the Ruby project? (The port of the HyperCard clone PLUS to NeWS.) After giving up on Sun, I went to work with Arthur van Hoff at the Turing Institute, to develop his "GoodNeWS" aka "HyperNeWS" aka "HyperLook" system, which was a from-the-ground-up reimplmentation of HyperCard in PostScript, with a network client interface (like an AJAX user interface builder), and I ported SimCity to that platform, writing the user interface in PostScript, and integrating TNT widgets so you could cut and paste and edit them in the user interface builder.
Arthur is visiting his mom in Amsterdam, and I'm going to see him this week! At Marimba, he wrote a system called "Bongo" that was a lot like HyperLook, written in Java. Never went anywhere though -- it got steamrolled by Java Beans (which never turned into a viable user interface framework anyway, but just got used on the server).
Somewhere I still have a copy of ptape.ps, which makes a window in the shape of a piece of paper tape (that TTYs and old computers used for storage) with binary holes for ASCII characters punched into it. You can type text into it and it reshapes the window to be longer with more holes. Totally useless but fun to write!
Speaking of obscure programming languages: I used to work with Don Woods at Sun Microsystems, where we wrote a user interface toolkit in object oriented PostScript. (TNT: The NeWS Toolkit -- for the James Gosling's Network extensible Windows System.)
Anybody old and perverted enough to remember the infamous "HyperCard Smut Stack"?
I still associate nipples with the "ping" sound.
Years ago I was recounting how cool HyperCard was to a group of people at some dot-com trade show, and when I mentioned the HyperCard Smut Stack, one guy (Chuck Farnham) said "oh, I wrote that". My jaw dropped and my eyes bugged out, not only because I happened to run into the author after all those years, but also because he would actually admit to it!
But as it turns out, Chuck has no shame. He used to do bizarre live stunts on Live 105, a San Francisco Bay Area radio station, on the shock jock Alex Bennett Show. He's infamous for some of his other exploits (this is just the tip of the iceberg, most of the other stuff is really not safe for work, let alone live radio):
During his days at Live 105 Alex would have stuntman Chuck Farnham cover himself with food to feed the homeless. This allowed Alex to get around the San Francisco Mayor Frank Jordan's ban on feeding the homeless without a permit.
Sorry to break this to you, but ALL computer programming languages are "made up". First you make up a language, then you implement it, then you use it. It's not like they just dig programming languages out of the ground like coal.
In 1989, Arthur van Hoff developed a HyperCard-inspired system called GoodNeWS, written in PostScript, for James Gosling's NeWS window system. Arthur later went on to work at Sun on Java, wrote the Java compiler in Java, the AWT gui toolkit, and the HotJava web browser.
GoodNeWS was later renamed HyperNeWS, then later HyperLook.
I went to Glasgow to work with Arthur at the Turing Institute, to develop HyperLook into a product, and I used it to develop the first Unix version of SimCity.
HyperLook was really wonderful, because it combined the strengths of HyperCard with the superior graphics and programmability of PostScript, and the network communication model currently known as AJAX.
Here is just the stuff about HyperLook -- the article goes on further to discuss and compare other technologies I think are interesting and applicable to the OLPC's constructionist education project.
Ideas for Sugar development environment from HyperLook SimCity
I love the ideas behind Smalltalk, EToys and HyperCard, and would like
to combine them with ideas from visual programming languages like Robot
Odyssey, KidSim, Klik-and-Play, SimAntics, Body Electric/Bounce,
Max/MSP/Jitter, etc.
Here are some ideas about HyperLook and other systems, that could be
applied to Sugar:
HyperLook was a PostScript-based user interface development environment
for the NeWS window system, which Arthur van Hoff created at the Turing
Institute in Glasgow.
http://www.donhopkins.com/home/catalog/hyperlook/
The NeWS window system was like AJAX, but with:
1) PostScript code instead of JavaScript code
2) PostScript graphics instead of DHTML graphics, and
3) PostScript data instead of XML data.
It had a unified programming/graphics/data/networking model based on
NeWS's extended multi-threaded object-oriented dialect of PostScript,
instead of a hodge-podge of accidental technologies. (Although I will be
the first to admit the X11/NeWS merge was quite a hodge-podge and
huge-kludge!)
NeWS had an object system based on the simple dynamic ideas of
Smalltalk, implemented with the PostScript dictionary stack, supporting
multiple inheritance and runtime modification of objects and classes.
http://www.donhopkins.com/home/catalog/hyperlook/HyperLookInfo10.g
Generation of Bits
Tales of shame and degradation in the Big Idea Lab
by Hunter S. Negroponte
Too Many Bits
The other day I was thanking my good friend Former President Bush (or ``George'' as I call him) for pulling some strings to get my brother out of that Iran-Contra mess, and he asked me if I knew any hot technologies he could sink his Presidential Pension into. In my opinion, the smart money is on filters. It's getting so you can't read Usenet without seeing that ``Dave Jordan'' Ponzi letter followed by forty replies from dickless wannabes threatening to mail-bomb the poster's sysadmin for the ``innapropriate post.'' Of course, I personally have my staff of Elegant British Women pre-edit my.newsrc for me (God how I envy the British), but that option is not open to the unwired masses outside the Media Lab.
One way to eliminate the blather while keeping the First Amendment intact is to create active ``Filter Agents,'' as I like to call them, that presort my Netnews articles and eliminate the tiresome pseudo-commercial posts. Can you imagine what the net's raw content will look like when all the half-literate morons in the U.S. can publish any text that their tiny minds ooze? The very thought makes me want to refill my glass with the '56 Chateau Lafite. America's Intelligentsia will need some serious Digital Butlers guarding our Offramp on the Digital Highway's Mailing Lists (damn metaphors) when this comes to pass.
The Big Lie
Media Lab critics (there have been a few) have occasionally questioned the practical application of our work. Well, have you heard about the Holographic Television? No longer a device found only in the back of comic books, we've actually made this sucker work. An honest-to-god motion-picture hologram, produced in the Media Lab basement on a 2000 pound holography table by computers, lasers and mirrors spinning at 30,000 RPM. It's real! It works! Life Magazine even came in to photograph it in action (of course, they had to fill the room with smoke so the lasers would show up on film). Practical application? Sure, it requires a 2000 pound air-suspended rock table and a Connection Machine II to run, but hell, everyone knows the price of computing power and 2000 pound rock tables is cut in half every year. My point, however, is more mundane: we have created a demo literally from smoke and mirrors, and the Corporate World bought it. Even my good friend Penn (or ``Penn,'' as I call him) Jillette would be proud.
In fact, I'm a few points up on Penn. You may have heard of the Interactive Narrative work that is proceeding in the lab. Folks, I'll be honest with you for a moment. I know as well as you do that it's a stinking load of horseshit. Roger Ebert said ``Six thousand years ago sitting around a campfire a storyteller could have stopped at any time and asked his audience how they wanted the story to come out. But he didn't because that would have ruined the story.'' You think Hollywood would have learned this lesson from the monster ``success'' that Clue, the Movie enjoyed several years ago. But no! I've repackaged the ``Choose your own Adventure'' novels of childhood as Digital Information SuperHighway Yadda Yadda crap, and again, they bought it! Sony right this minute is building an interactive movie theater, with buttons the audience can push to amuse themselves as the story progresses. Dance for me, Corporate America! I'm SHIT-HOT!
Why, just the other day I listened to a member of my staff explain to potential sponsors that we had spent $US 4,000,000 of Japanese sponsor dollars to construct a widescreen version of ``I Love Lucy'' from the original source. And HE SAID IT WITH A STRAIGHT FACE! CAN YOU FUCKING BELIEVE THAT? Boy, I bet those Nips wish they had their money back now! Earthquake? No, we can't do much to rebuild your city, but we SURE AS HELL can give you a 1.66:1 cut of Lucy to fit all those busted
I wrote The Sims character animation for Maxis, and also a tool called "SimShow" that we released before the The Sims release date.
SimShow enabled players to view and create their own character skins, so that when The Sims was finally released, there were already web sites publishing hundreds of characters for the game. (Many of them would have been impossible for EA to legally publish themselves, like Spiderman, Star Trek characters, etc.)
The Sims was much to complex to release a demo version, because it required a critical mass of objects to work. We could not release a stripped down version with only a few objects or levels, like most other video games. Instead, by releasing a tool to create content instead of a hamstrung demo, it improved the game when it was eventually released, instead of delaying it.
That approach worked quite well for The Sims, so it's no wonder that EA is repeating it with Spore.
Maxis was working with NASA on SimMars, while I was there working on The Sims.
It was eventually canceled after The Sims shipped and sucked up all the resources into the franchise.
But some of the ideas from SimMars ended up in one of The Sims expansion packs and Spore.
From wikipedia:
In The Sims: Vacation, there was an arcade game titled SimMars and it had a detailed description about the game. This may or may not have been the real premise of the game:
"Direct mankindâ(TM)s first mission to the red planet! Launch rockets and deploy robot probes! Deploy teams to search for alien resources! Establish and run a network of specialized colonies to create a self-sufficient civilization! Provide your colony with food, shelter, and power! Fast, furious, adrenaline-pumping action!"
As of May 12, 2000, Maxis has stated that "SimMars is on hold and we do not have staff at Maxis currently working on the game. With the phenomenal success of The Sims, we've decided to move resources to support that franchise as well as other titles that we haven't even announced yet."
Some elements of SimMars are used in the upcoming Maxis game Spore.
I call bullshit. The so-called "sad dearth" of free software on the Pocket PC includes a vast amount of free software than will never run on the iPhone. And there's an enormous market of commercial software for the Pocket PC. The iPhone doesn't even have a GPS, so it's useless for running apps like TomTom Navigator (which is the reason I got my iPAQ phone), even if it was theoretically possible for TomTom to support Apple's closed platform.
Now I know the answer: NO! Because it's licensed under GPL 3.
It's a lot easier to port software to the Windows CE on the PocketPC, anyway. And then I can give it away for free, instead of charging for it and forking over money to Apple.
Both BitTorrent DNA and Red Swoosh have JavaScript APIs for starting, monitoring and controlling BitTorrent downloads. The actual BitTorrent client runs in a service process, which you talk to through "http://127.0.0.1:port#".
The JS libraries just rewrite the URL of the file you want to torrent so it goes through the proxy. They also allow you to monitor and control the progress of the downloads via a ReST interface to the proxy that returns json or xml.
The JS libraries both support putting links into the page that are automatically rewritten to download via BitTorrent. You can use the status monitoring interfaces to display a progress bar and give the user feedback about the download process.
Another approach is to develop an XPCOM plug-in that wraps one of the bittorrent libraries like libtorrent.
That gives you a lot more direct control over the library from JavaScript. But I think it's safer to have all that complex code and volumous data running in its own separate process, and not bloating up and slowing down Firefox.
Talking to the BitTorrent client in a separate process via http makes it very easy to use from JavaScript, and that does not bloat or slow down Firefox itself.
I'm developing a system for TomTom to distribute digital maps (on the order of 1 or 2 gigabytes each) via BitTorrent. It will save a lot in bandwidth costs, because we distribute millions of maps over the internet. By their very nature, digital maps work well with BitTorrent because people in the same geographical regions all want to download the latest map of their region at the same time.
I was very happy to hear the announcement from BitTorrent and Comcast, that Comcast wouldn't be fucking with BitTorrent streams any more, because that would interfere with our customers' legitimate use of the internet services and content they're paying for.
If you're going to be in Amsterdam for ApacheCon, here's something fun to do at night, to keep from getting bored:
The Korsakoff is by far the best place in Amsterdam to find long haired freaks like Linux programmers and system administrators, with great music and wild dancing. It's at Lijnbaansgracht 161, clockwise from Leidseplein, open every night, till 4:00 AM! I had a great time there last night -- it's best on Friday and Saturdays of course.
Korsakoff Syndrome:
Korsakoff's syndrome (Korsakoff's psychosis, amnesic-confabulatory syndrome), is a degenerative brain disorder caused by the lack of thiamine (vitamin B1) in the brain. The syndrome is named after Sergei Korsakoff, the neuropsychiatrist who popularized the theory.
There are six major symptoms of Korsakoff's syndrome:
1. anterograde amnesia and
2. retrograde amnesia, severe memory loss
3. confabulation, that is, invented memories which are then taken as true due to gaps in memory sometimes associated with blackouts
4. meager content in conversation
5. lack of insight
6. apathy - the patients lose interest in things quickly and generally appear indifferent to change.
I'm working with the OLPC project to develop the open source version of Micropolis (SimCity) for the OLPC, in C++ and Python, and we're looking for students who want to work on it for the Summer of Code.
The source is portable C++ and Python code, and compiles and runs on Linux, Mac and Windows. It uses GTK, Cairo and Pango to draw graphics and text.
Here is the Micropolis project home on Google Code, and some development ideas on my web site.
I've been working on the MicropolisCore code in my spare time, and just checked in some changes to support map editing and multiple views. More details are in the news and development plan.
This would be the perfect input device for PSI Menus! Instead of Linear Thinking Menus (where you always think downward, but for a different distance to select for each menu item), PSI Menus let you think in different directions to select different items.
-Don
Re:It's fine that the source is closed, for them..
on
Spore Hands-On Preview
·
· Score: 1
Sorry to break it to you, kiddo, but cross platform development IS hard, and has always been hard long before Microsoft ever existed.
You obviously have absolutely no idea what you're talking about, if you think that's all there is to cross platform programming.
And for your information: Sun ruined Java, not Microsoft.
-Don
Re:It's fine that the source is closed, for them..
on
Spore Hands-On Preview
·
· Score: 1
Supporting WINE is a great idea, which I agree with!
EA is paying Transgaming to port Spore to the Mac with Cider, which is based on WINE.
There are some silly people who argue that WINE and similar technologies are evil because it is an easy way out that prevents companies from doing native Linux ports of games.
But harsh reality is that those ports would have never happened in the first place without WINE, because companies don't have years of spare have time to waste and wads of money to flush down the toilet -- not even a Linux-friendly company like Loki, who couldn't be bothered to pay their employees for all the time they put in because of their unswerving faith in the goodness of Linux.
Most companies already weren't doing native Linux ports of games, before WINE was ever an issue.
The few companies that were foolhardy enough to try publishing games on Unix (like DUX, who I worked for in the early 90's), or Linux (like Loki, who entered the market years later), didn't make nearly enough money to pay for all the work and expenses and licensing fees.
Those shrill arguments against WINE only make sense in a universe that we do not live in, where Windows is not important, and big public companies take huge risks and spend large amounts of money even though there will be no return on investments just because they love Linux, and everyone has a free flying pink pony who can sing, and whose farts smell like raspberry cream sherbet.
The existence of WINE is very very low on the long list of reasons companies don't natively port games to Linux.
High on the list is the fact that there is a MUCH bigger and viable market for Mac applications that Linux desktop applications, so development effort goes towards that instead. Technologies like Cider solve the porting problem quite well (although they require development and bug fixing, since Windows is a moving target, and games can be very quirky and system dependent). It costs money to develop products like Cedega and Cider, and it makes sense for a company like EA to license it instead of putting their own effort into adapting open source software like WINE, since EA requires Transgaming's support and development effort, and they're using it to publish a proprietary game that presumably they're going to make money off of.
It's much better to have Windows games and other applications that run on Linux with WINE or Cedega, and Mac with Cider, than not having those Windows games and applications running on Linux and Mac at all.
-Don
Re:It's fine that the source is closed, for them..
on
Spore Hands-On Preview
·
· Score: 0
Complaining about how bad Windows is DOES NOT MAKE LINUX ANY EASIER TO USE. When I criticize Linux, that does not mean I'm endorsing Windows or the Mac. Get over it.
There are so many mediocre choices of Linux desktop environments and user interfaces, and they are all so different and incompatible, that there is absolutely no consistency, and you end up with a bunch of antagonistic applications opened on the same screen that all disagree about cut and paste, drag and drop, mouse tracking, menus, keyboard shortcuts, internationalization, accessibility, interprocess communication, defaults, configuration, color management, etc. How you could possibly claim that the Linux desktop has any kind of consistency is beyond me. Maybe you just read about Linux on slashdot but don't actually use it yourself?
From The X-Windows Disaster, which I wrote 16 years ago, but shamefully STILL applies to Linux desktops:
X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards. [...]
One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the rig
Slashdot Mirror
You are absolutely wrong about Smarty, which is a horribly conceived and implemented disaster. Don't be such a yapping apologist, just because you managed to throw together your home page in PHP without knowing any other languages.
I am speaking from experience, having had to use PHP and Smarty, and having read the source code to Smarty in an vain attempt to figure out how it worked and why it was so difficult to get it to do even the simplest things correctly. I've been much happier using other better designed templating systems, which I will describe below.
You should read Wolf's Rants about PHP: Truth about short open tags and Smarty.
I use Drupal for my home page, so I know first hand that it sucks, and why. My dislike for PHP comes from hands on experience, writing and reading PHP code, not just reading web pages about it. PHP is not my only programming language, so I don't lack the perspective to compare it to other alternatives.
Python has a wide range of templating systems, some of which are much better than Smarty, and a few of which are almost as bad (but none are worse).
Zope uses DTML, which is unstructured and messy but gets the job done. It also has TAL and METAL, which are cleaner and more powerful, but an incredible pain in the ass to use, and extremely verbose and clumsy. I've written a lot of DTML, TAL and METAL, and I don't want to ever use them again, because I've found much better Python based templating systems since then.
TurboGears uses Kid, which is a very nicely designed an implemented templating system that provides a thin XML veneer on top of Python, and doesn't try to reinvent its own p
There are many practical, clean, simple and easy to learn programming languages, much better than PHP, that are great to learn as a first programming language.
Learning Lua will enable you to write your own World of Warcraft mods, and increase your chances of writing your own game or getting a job in the game industry, as well as enabling you to script all kinds of applications like Adobe Lightroom and WireShark. Lua is an extremely well designed and implemented, efficient and powerful programming language, which will open your mind in the same way Lisp does, instead of corrupting it like PHP and BASIC.
And of course Python is also extremely useful to learn as a first language, for all the same reasons as Lua, and also the fact that it has a huge library of mature, solid, powerful modules (unlike PHP's PEAR, a collection of buggy, poorly though out modules, hacked together by ametuers).
-Don
For all the complaints about various PHP extensions, there are also many complaints about the PHP language design and implementation itself.
Take, for example, magic_quotes_gpc. That is the stupidest flaw ever, which should have never been in any rationally designed language in the first place, and it makes programming in PHP a LOT more obnoxious and error prone.
Don't blame Perl for PHP's mistakes. It was idiotic of the PHP designers to foolishly ape the mistakes of Perl (and later the mistakes of Java, when PHP5 tried to express PHP's dynamic interpreted language's OOP system in the SYNTAX of a Java's static complied language OOP system, resulting in a horrible impedance mismatch, and many subtle inconsistencies and gotchas). That is called "Cargo Cult Programming Language Design".
The REASON that most of the code in PEAR is crap, is because PHP encourages and supports crappy programming, which is precisely WHY it should not be taught as a first programming language.
-Don
If you're a PHP programmer, you're irresponsible if you're not already aware of its flaws, because you have not educated yourself by reading any of the following well publicized articles. Once you understand the flaws of PHP, you can't honestly make the statement that it's a well designed language suitable for teaching programming to kids.
First there is this classic article, Edwin Martin's "What I don't Like about PHP", which goes into detail about the following fundamental flaws:
Then there is the mind-set of the PHP language designers and community, which is deeply flawed. Ian Bicking's "PHP Ghetto" article sums up the problem with PHP's design and community pretty well:
Jonathan Ellis' "Why PHP sucks" article makes a lot of good points and links to many other sites with more information to back up the claim that PHP sucks.
He perfectly summarizes the yapping of the PHP apologists when he says: Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better."
He summarizes:
There is also a lot of great stuff about why PHP is so bad on http://www.ranting-wolf.info/category/technology/programming/php/ including a concise description of why the "Smarty" templating system is such a horribly ill conceive and terribly implemented idea.
And if you're still not convinced the design of PHP is deeply flawed, because language design is HARD and should only be attempted on purpose by experienced people, here's what the Father of PHP Rasmus Lerdorf himself said in an ITConversations interview, quoted in "Why PHP sucks, Part III":
There are so many reasons not to start with PHP, that I'm not even going to start listing them here. PHP is a HORRIBLE first language, and a horrible second, third or forth language. It corrupts minds, and makes it harder to learn other languages. It's a lot worse than corrupting someone by teaching BASIC as a first language.
You should be ashamed of yourself for suggesting teaching PHP to a kid.
-Don
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
-Don
Cool! That was the same year I started there. I don't know your real name, but we may have known each other. You can email me if you like at dhopkins@DonHopkins.com.
Were you on the Ruby project? (The port of the HyperCard clone PLUS to NeWS.) After giving up on Sun, I went to work with Arthur van Hoff at the Turing Institute, to develop his "GoodNeWS" aka "HyperNeWS" aka "HyperLook" system, which was a from-the-ground-up reimplmentation of HyperCard in PostScript, with a network client interface (like an AJAX user interface builder), and I ported SimCity to that platform, writing the user interface in PostScript, and integrating TNT widgets so you could cut and paste and edit them in the user interface builder.
Arthur is visiting his mom in Amsterdam, and I'm going to see him this week! At Marimba, he wrote a system called "Bongo" that was a lot like HyperLook, written in Java. Never went anywhere though -- it got steamrolled by Java Beans (which never turned into a viable user interface framework anyway, but just got used on the server).
Somewhere I still have a copy of ptape.ps, which makes a window in the shape of a piece of paper tape (that TTYs and old computers used for storage) with binary holes for ASCII characters punched into it. You can type text into it and it reshapes the window to be longer with more holes. Totally useless but fun to write!
-Don
Speaking of obscure programming languages: I used to work with Don Woods at Sun Microsystems, where we wrote a user interface toolkit in object oriented PostScript. (TNT: The NeWS Toolkit -- for the James Gosling's Network extensible Windows System.)
-Don
Anybody old and perverted enough to remember the infamous "HyperCard Smut Stack"?
I still associate nipples with the "ping" sound.
Years ago I was recounting how cool HyperCard was to a group of people at some dot-com trade show, and when I mentioned the HyperCard Smut Stack, one guy (Chuck Farnham) said "oh, I wrote that". My jaw dropped and my eyes bugged out, not only because I happened to run into the author after all those years, but also because he would actually admit to it!
But as it turns out, Chuck has no shame. He used to do bizarre live stunts on Live 105, a San Francisco Bay Area radio station, on the shock jock Alex Bennett Show. He's infamous for some of his other exploits (this is just the tip of the iceberg, most of the other stuff is really not safe for work, let alone live radio):
-Don
Sorry to break this to you, but ALL computer programming languages are "made up". First you make up a language, then you implement it, then you use it. It's not like they just dig programming languages out of the ground like coal.
-Don
In 1989, Arthur van Hoff developed a HyperCard-inspired system called GoodNeWS, written in PostScript, for James Gosling's NeWS window system. Arthur later went on to work at Sun on Java, wrote the Java compiler in Java, the AWT gui toolkit, and the HotJava web browser.
GoodNeWS was later renamed HyperNeWS, then later HyperLook. I went to Glasgow to work with Arthur at the Turing Institute, to develop HyperLook into a product, and I used it to develop the first Unix version of SimCity.
HyperLook was really wonderful, because it combined the strengths of HyperCard with the superior graphics and programmability of PostScript, and the network communication model currently known as AJAX.
I've written down some Ideas for Sugar development environment from HyperLook SimCity, with lots of links and illustrations, relating it with many different programming languages, user interface systems and applications that have inspired me.
Here is just the stuff about HyperLook -- the article goes on further to discuss and compare other technologies I think are interesting and applicable to the OLPC's constructionist education project.
Ideas for Sugar development environment from HyperLook SimCity
I love the ideas behind Smalltalk, EToys and HyperCard, and would like to combine them with ideas from visual programming languages like Robot Odyssey, KidSim, Klik-and-Play, SimAntics, Body Electric/Bounce, Max/MSP/Jitter, etc.
Here are some ideas about HyperLook and other systems, that could be applied to Sugar:
HyperLook was a PostScript-based user interface development environment for the NeWS window system, which Arthur van Hoff created at the Turing Institute in Glasgow. http://www.donhopkins.com/home/catalog/hyperlook/
I helped develop HyperLook into a commercial product, with a editable user interface development environment, as well as a redistributable non-editable runtime, and I used it to port SimCity to Unix, and develop other components and applications . http://www.donhopkins.com/home/catalog/hyperlook/ http://www.donhopkins.com/home/catalog/hyperlook/HyperLook-SimCity.gif
HyperLook was inspired by HyperCard, but it additionally provided a client/server programming model, and more powerful graphics and scripting based on NeWS's object oriented dialect of PostScript. http://www.donhopkins.com/home/catalog/hyperlook/TalkInterfacing.gif
The NeWS window system was like AJAX, but with:
1) PostScript code instead of JavaScript code
2) PostScript graphics instead of DHTML graphics, and
3) PostScript data instead of XML data.
It had a unified programming/graphics/data/networking model based on NeWS's extended multi-threaded object-oriented dialect of PostScript, instead of a hodge-podge of accidental technologies. (Although I will be the first to admit the X11/NeWS merge was quite a hodge-podge and huge-kludge!) NeWS had an object system based on the simple dynamic ideas of Smalltalk, implemented with the PostScript dictionary stack, supporting multiple inheritance and runtime modification of objects and classes. http://www.donhopkins.com/home/catalog/hyperlook/HyperLookInfo10.g
Generation of Bits
Tales of shame and degradation in the Big Idea Lab
by Hunter S. Negroponte
Too Many Bits
The other day I was thanking my good friend Former President Bush (or ``George'' as I call him) for pulling some strings to get my brother out of that Iran-Contra mess, and he asked me if I knew any hot technologies he could sink his Presidential Pension into. In my opinion, the smart money is on filters. It's getting so you can't read Usenet without seeing that ``Dave Jordan'' Ponzi letter followed by forty replies from dickless wannabes threatening to mail-bomb the poster's sysadmin for the ``innapropriate post.'' Of course, I personally have my staff of Elegant British Women pre-edit my .newsrc for me (God how I envy the British), but that option is not open to the unwired masses outside the Media Lab.
One way to eliminate the blather while keeping the First Amendment intact is to create active ``Filter Agents,'' as I like to call them, that presort my Netnews articles and eliminate the tiresome pseudo-commercial posts. Can you imagine what the net's raw content will look like when all the half-literate morons in the U.S. can publish any text that their tiny minds ooze? The very thought makes me want to refill my glass with the '56 Chateau Lafite. America's Intelligentsia will need some serious Digital Butlers guarding our Offramp on the Digital Highway's Mailing Lists (damn metaphors) when this comes to pass.
The Big Lie
Media Lab critics (there have been a few) have occasionally questioned the practical application of our work. Well, have you heard about the Holographic Television? No longer a device found only in the back of comic books, we've actually made this sucker work. An honest-to-god motion-picture hologram, produced in the Media Lab basement on a 2000 pound holography table by computers, lasers and mirrors spinning at 30,000 RPM. It's real! It works! Life Magazine even came in to photograph it in action (of course, they had to fill the room with smoke so the lasers would show up on film). Practical application? Sure, it requires a 2000 pound air-suspended rock table and a Connection Machine II to run, but hell, everyone knows the price of computing power and 2000 pound rock tables is cut in half every year. My point, however, is more mundane: we have created a demo literally from smoke and mirrors, and the Corporate World bought it. Even my good friend Penn (or ``Penn,'' as I call him) Jillette would be proud.
In fact, I'm a few points up on Penn. You may have heard of the Interactive Narrative work that is proceeding in the lab. Folks, I'll be honest with you for a moment. I know as well as you do that it's a stinking load of horseshit. Roger Ebert said ``Six thousand years ago sitting around a campfire a storyteller could have stopped at any time and asked his audience how they wanted the story to come out. But he didn't because that would have ruined the story.'' You think Hollywood would have learned this lesson from the monster ``success'' that Clue, the Movie enjoyed several years ago. But no! I've repackaged the ``Choose your own Adventure'' novels of childhood as Digital Information SuperHighway Yadda Yadda crap, and again, they bought it! Sony right this minute is building an interactive movie theater, with buttons the audience can push to amuse themselves as the story progresses. Dance for me, Corporate America! I'm SHIT-HOT!
Why, just the other day I listened to a member of my staff explain to potential sponsors that we had spent $US 4,000,000 of Japanese sponsor dollars to construct a widescreen version of ``I Love Lucy'' from the original source. And HE SAID IT WITH A STRAIGHT FACE! CAN YOU FUCKING BELIEVE THAT? Boy, I bet those Nips wish they had their money back now! Earthquake? No, we can't do much to rebuild your city, but we SURE AS HELL can give you a 1.66:1 cut of Lucy to fit all those busted
I wrote The Sims character animation for Maxis, and also a tool called "SimShow" that we released before the The Sims release date.
SimShow enabled players to view and create their own character skins, so that when The Sims was finally released, there were already web sites publishing hundreds of characters for the game. (Many of them would have been impossible for EA to legally publish themselves, like Spiderman, Star Trek characters, etc.)
The Sims was much to complex to release a demo version, because it required a critical mass of objects to work. We could not release a stripped down version with only a few objects or levels, like most other video games. Instead, by releasing a tool to create content instead of a hamstrung demo, it improved the game when it was eventually released, instead of delaying it.
That approach worked quite well for The Sims, so it's no wonder that EA is repeating it with Spore.
-Don
The GPL version of SimCity Classic from Maxis is called "Micropolis", and is available on Google Code.
There's an old version based on TCL/Tk, which runs on the OLPC, Linux, and also on the Mac with X11.
And I'm in the process of rewriting it in C++/Python/GTK/Cairo/Pango, which runs on Windows, Mac OS/X and Linux (including the OLPC of course).
Lots more stuff about it on my web site.
-Don
Maxis was working with NASA on SimMars, while I was there working on The Sims.
It was eventually canceled after The Sims shipped and sucked up all the resources into the franchise.
But some of the ideas from SimMars ended up in one of The Sims expansion packs and Spore.
From wikipedia:
-Don
I call bullshit. The so-called "sad dearth" of free software on the Pocket PC includes a vast amount of free software than will never run on the iPhone. And there's an enormous market of commercial software for the Pocket PC. The iPhone doesn't even have a GPS, so it's useless for running apps like TomTom Navigator (which is the reason I got my iPAQ phone), even if it was theoretically possible for TomTom to support Apple's closed platform.
-Don
Some free software on the PocketPC: apache, vim, X11 server, kaffe, gcc, openssh http://www.wince-devel.org/ http://ppc.palmopensource.com/ http://www.freewareppc.com/ http://lifehacker.com/software/pocket-pc/11-killer-freebies-for-your-pocket-pc-209413.php http://www.tuxtops.com/?q=node/188
I keep getting asked if I'll port SimCity (Micropolis) to the iPhone.
Now I know the answer: NO! Because it's licensed under GPL 3.
It's a lot easier to port software to the Windows CE on the PocketPC, anyway. And then I can give it away for free, instead of charging for it and forking over money to Apple.
-Don
Both BitTorrent DNA and Red Swoosh have JavaScript APIs for starting, monitoring and controlling BitTorrent downloads. The actual BitTorrent client runs in a service process, which you talk to through "http://127.0.0.1:port#".
The JS libraries just rewrite the URL of the file you want to torrent so it goes through the proxy. They also allow you to monitor and control the progress of the downloads via a ReST interface to the proxy that returns json or xml.
The JS libraries both support putting links into the page that are automatically rewritten to download via BitTorrent. You can use the status monitoring interfaces to display a progress bar and give the user feedback about the download process.
Another approach is to develop an XPCOM plug-in that wraps one of the bittorrent libraries like libtorrent. That gives you a lot more direct control over the library from JavaScript. But I think it's safer to have all that complex code and volumous data running in its own separate process, and not bloating up and slowing down Firefox.
Talking to the BitTorrent client in a separate process via http makes it very easy to use from JavaScript, and that does not bloat or slow down Firefox itself.
-Don
Here's a practical, legal use of BitTorrent:
I'm developing a system for TomTom to distribute digital maps (on the order of 1 or 2 gigabytes each) via BitTorrent. It will save a lot in bandwidth costs, because we distribute millions of maps over the internet. By their very nature, digital maps work well with BitTorrent because people in the same geographical regions all want to download the latest map of their region at the same time.
I was very happy to hear the announcement from BitTorrent and Comcast, that Comcast wouldn't be fucking with BitTorrent streams any more, because that would interfere with our customers' legitimate use of the internet services and content they're paying for.
-Don
If you're going to be in Amsterdam for ApacheCon, here's something fun to do at night, to keep from getting bored:
The Korsakoff is by far the best place in Amsterdam to find long haired freaks like Linux programmers and system administrators, with great music and wild dancing. It's at Lijnbaansgracht 161, clockwise from Leidseplein, open every night, till 4:00 AM! I had a great time there last night -- it's best on Friday and Saturdays of course.
Korsakoff Syndrome: Korsakoff's syndrome (Korsakoff's psychosis, amnesic-confabulatory syndrome), is a degenerative brain disorder caused by the lack of thiamine (vitamin B1) in the brain. The syndrome is named after Sergei Korsakoff, the neuropsychiatrist who popularized the theory.
There are six major symptoms of Korsakoff's syndrome:
1. anterograde amnesia and
2. retrograde amnesia, severe memory loss
3. confabulation, that is, invented memories which are then taken as true due to gaps in memory sometimes associated with blackouts
4. meager content in conversation
5. lack of insight
6. apathy - the patients lose interest in things quickly and generally appear indifferent to change.
-Don
I'm working with the OLPC project to develop the open source version of Micropolis (SimCity) for the OLPC, in C++ and Python, and we're looking for students who want to work on it for the Summer of Code.
The source is portable C++ and Python code, and compiles and runs on Linux, Mac and Windows. It uses GTK, Cairo and Pango to draw graphics and text. Here is the Micropolis project home on Google Code, and some development ideas on my web site.
I've been working on the MicropolisCore code in my spare time, and just checked in some changes to support map editing and multiple views. More details are in the news and development plan.
-Don
This would be the perfect input device for PSI Menus! Instead of Linear Thinking Menus (where you always think downward, but for a different distance to select for each menu item), PSI Menus let you think in different directions to select different items.
-Don
Sorry to break it to you, kiddo, but cross platform development IS hard, and has always been hard long before Microsoft ever existed.
You obviously have absolutely no idea what you're talking about, if you think that's all there is to cross platform programming.
And for your information: Sun ruined Java, not Microsoft.
-Don
Supporting WINE is a great idea, which I agree with! EA is paying Transgaming to port Spore to the Mac with Cider, which is based on WINE.
There are some silly people who argue that WINE and similar technologies are evil because it is an easy way out that prevents companies from doing native Linux ports of games. But harsh reality is that those ports would have never happened in the first place without WINE, because companies don't have years of spare have time to waste and wads of money to flush down the toilet -- not even a Linux-friendly company like Loki, who couldn't be bothered to pay their employees for all the time they put in because of their unswerving faith in the goodness of Linux. Most companies already weren't doing native Linux ports of games, before WINE was ever an issue. The few companies that were foolhardy enough to try publishing games on Unix (like DUX, who I worked for in the early 90's), or Linux (like Loki, who entered the market years later), didn't make nearly enough money to pay for all the work and expenses and licensing fees.
Those shrill arguments against WINE only make sense in a universe that we do not live in, where Windows is not important, and big public companies take huge risks and spend large amounts of money even though there will be no return on investments just because they love Linux, and everyone has a free flying pink pony who can sing, and whose farts smell like raspberry cream sherbet.
The existence of WINE is very very low on the long list of reasons companies don't natively port games to Linux. High on the list is the fact that there is a MUCH bigger and viable market for Mac applications that Linux desktop applications, so development effort goes towards that instead. Technologies like Cider solve the porting problem quite well (although they require development and bug fixing, since Windows is a moving target, and games can be very quirky and system dependent). It costs money to develop products like Cedega and Cider, and it makes sense for a company like EA to license it instead of putting their own effort into adapting open source software like WINE, since EA requires Transgaming's support and development effort, and they're using it to publish a proprietary game that presumably they're going to make money off of.
It's much better to have Windows games and other applications that run on Linux with WINE or Cedega, and Mac with Cider, than not having those Windows games and applications running on Linux and Mac at all.
-Don
Complaining about how bad Windows is DOES NOT MAKE LINUX ANY EASIER TO USE. When I criticize Linux, that does not mean I'm endorsing Windows or the Mac. Get over it.
There are so many mediocre choices of Linux desktop environments and user interfaces, and they are all so different and incompatible, that there is absolutely no consistency, and you end up with a bunch of antagonistic applications opened on the same screen that all disagree about cut and paste, drag and drop, mouse tracking, menus, keyboard shortcuts, internationalization, accessibility, interprocess communication, defaults, configuration, color management, etc. How you could possibly claim that the Linux desktop has any kind of consistency is beyond me. Maybe you just read about Linux on slashdot but don't actually use it yourself?
From The X-Windows Disaster, which I wrote 16 years ago, but shamefully STILL applies to Linux desktops: