I have to say it: This guy makes some valid points. There, I feel better now. Seriously, while I don't agree entirely with his article (not by a long shot), I also don't agree with any of the posts so far either (which could all be summed up as "he disagrees with us, don't listen to him!").
He makes very valid points about PHP's current weak points, which no one actually responded to in their comments, especially his mention of Unicode support. Proper date support is another biggie. A unified DB abstraction layer should have been added a long time ago. These are basics I had years ago when I used to write in Perl. Not only are they still outstanding issues in PHP, the core of PHP is too busy adding nifty little OOP features, ignorant of the real needs of the community. This is a VALID complaint! (The fact that these could all be solved by looking more closely at Java is a point I find slightly ironic, given the pro-Java/anti-Java polarity around here)
PHP finally getting a real OO system is dandy and all, but PHP's API has started to stink like an old dog. Function naming and parameter ordering inconsistencies could have been fixed for PHP5, with the backwards-compatible functions being marked "deprecated" so that by PHP6 they could be retired for good. PDO or something similar (just give us the basics -- add the gravy later!) should have been a much bigger priority. PHP's Unicode support is shameful. SimpleXML is a good start, but it still only puts PHP at runner-up (maybe we'd be a leader if it came 2-3 years ago).
I hate to say it, but there's a jealousy that rises in me when I look to languages like Ruby and projects like Rails, and I'm unable to join due to my coding activities being tied to 100,000's of lines of PHP code. I'm even more jealous of them after seeing the reaction of the community at a legitimate complaint.
Now to defend Zend for a moment: Of course a business has their profitability to consider when steering the software they rely on. That's not unethical, and as a user you should be aware that that's the case. However, it's not Zend's responsibility to single-handedly create PHP -- we all do it together. And doing it together means that we, the community, dropped the ball.
PHP has not been innovative for a number of years now. Projects like Ruby on Rails and Perl's Maypole, they are.
At the risk of sounding like a Mac fan-boy, I'm going to lay this one on the table. As I see it, ThinkSecret.com is clearly not acting with journalistic integrity in that they gain their content by coercing informants who are not at liberty to reveal the information they have. While this does not absolve the informant of responsibility (they should be found out and included in the lawsuit), it does change the issue at hand. The issue is then not the first amendment rights of ThinkSecret.com, which would be the only purpose of the EFF getting involved, but whether they were acting in accordance with the law, which they clearly were not. As such, I can see this only as a PR move on the part of the EFF, and a questionable one at that.
Perhaps they are more intimately aware of the issues of this case (I would hope so, and they are lawyers, which I am not), but it makes me question whether they are knowingly wasting their resources (resources myself amongst others have donated towards) for the sake of increasing their exposure via a high-profile case. If this is so, I can understand that it may be a calculated risk that they feel will pay off in the end, but I have to wonder, at what cost?
Woah, where did that come from? The parent post may not have been totally correct (science has its share of validation issues, but it is not totally invalid because of that -- not that that is what he claimed anyway, although it seems to be your interpretation of it), but I don't see where the logical leap from "I think I see a logical fallacy" to "I'm a religious bigot" can be made.
The point in his second paragraph is quite valid too. I've lost count how many times it was determined that butter was worse than margarine, then the reverse, then back again. Empirical observation is flawed too. For example, prove by use of the empirical method that the empirical method is correct. Heck, use logic too. You'll still end up in a circular proof, with two logical bits pointing at each other, shrugging their shoulders, and saying "but it _must_ be true!"
"Myriads of people have shown this, so it must be true" is fairly close to "Myriads of lab tests have shown this, so it must be true" since we can't know all causes nor all effects to a cause.
Agreed. Skin and all, a carrot should be had au natural.
Also, cooking them in water until the water evaporates is the equivalent of steeping tea leaves then throwing out the water and eating the leaves once the water has absorbed all the flavour, and more importantly, the nutrients. That recipe is simply a how-to on butchering a good vegetable.
True, true. But I'm sure if anyone can speed it up, Microsoft can.;)
Cheap MS jokes aside, they should be able to achieve some significant speed improvements, being the developers of the original and not some external reverse-engineering company. I suppose this is slightly limited/dependent on the emulation type though as well (ie. processor emulation, API emulation, etc.).
I wonder how much Apple was able to speed up whatever emulation engine they bought (assuming it was bought...).
I am stoked that Microsoft is developing VPC however, because now they can hook it into those sekret API's (sssshhhh).:D
Seems to make some sense, but not so much from a $$$ angle. Mac OS X, for example, uses an emulator to run Mac OS 9 apps on OS X, which was necessary since the new system is not backwards compatible with the old one at all.
Microsoft seems to be looking to use Longhorn as an opportunity to break free from the backwards compatibility that affords them little room for flexibility in how they can implement changes, and now they can do so via the same emulation idea Apple succeeded with in their transition to OS X.
I don't see how this will double their licensing fees, and I think it would be a big mistake for them to break compatibility with XP, 2000, NT, 98, etc. without providing a built-in (ie. included in the OS) bridge to help people onto the new platform. And whether they make Longhorn compatible with non-x86 processors, I don't see how that really changes any of the above.
I've always found that fonts on Windows look like ass. Especially web page rendering.
On Linux, I find the anti-aliasing a bit aggressive, which seems to be the way with most OSS. As soon as they get a new feature, they ramp it up to full for the first two releases thereafter, until they realize that a moderate amount of said feature would be better.
On Mac OS X, under System Preferences > Appearance, there's an option "Turn off text smoothing for font sizes [n] and smaller." It's set to 8 and under by default, but you can set it up to 12 if you want. This pretty much solves the problem of smaller fonts being less legible with anti-aliasing turned on.
IMO, Apple generally has the best font rendering (although some of it is application-dependent, for example, BBEdit turns anti-aliasing off entirely, and I find Preview.app a little blurry compared to Acrobat).
I switched from Windows to Linux not long after the release of Windows ME (what a joke), and a couple years later, when I needed a laptop, I bought the only well-polished Unix-based laptop around: a Mac (powerbook). I've had it for 3 1/2 years now, and I just recently bought a 20" iMac (the new nothing-but-screen model) which is fantastic as well, and I'm waiting for my Mac Mini now too. I'm a total convert. I even feel the zeal rise in me from time to time.
I run a web-based software business, which necessitates testing in MSIE on Windows, so I put together a shitty Windows XP box out of the old one I had before, but I can't stand using it. I only connect to it from the OSX boxes via rdesktop anymore. It's amazingly unintuitive (now that I've had better) and not smooth at all. I haven't had any security issues with it lately (knock on wood), but it requires way more maintenance than the two Mac's do (they require none).
I talked with my dad the other day and I asked him about what he thought of the new Mac Mini. He said he read a bunch of PC magazine reviews that could be summarized with "don't bother". I wasn't able to find those reviews myself (although I found a few naysayers complaining about the price). He also said he would never use a Mac because it's a proprietary system. Apparently, Windows is no longer proprietary, due to sheer prevalence...
I tried explaining the misconceptions of the Mac, since he is quite fed up with Windows, and has seriously contemplated switching to Linux recently, but he didn't seem to want to hear it. Oh well, not much you can do.
The business models employed in the software industry are no different than in other industries, yet software makers continually try to convince themselves that they are the only area of business where the only way to make it is with entirely new ideas. Perhaps those who make it do so because of things like good timing, and more knowledge about how business actually works (ie. what plans work in what circumstances, how to see the patterns into which said plans would fit, as they're emerging). The second biggest problem in software is people who continually try to publicly pat themselves on the back and call themselves "original thinkers". The biggest problem in software are the people who believe them.
It's funny how everything in this (pseudo-)decentralized environment keeps naturally migrating towards a single central point that everything else revolves around. Not that I think this is a good or bad thing, it seems that its just a natural part of everything human to form itself into some structure resembling the state (city=net,government=google,citizens=sites), which may be also true of much of the natural world as well (galaxies, for example, are drawn together around a common object, which is similar, although the cause of it is different).
It's almost as if, given the chance at a total level of equality, we unconsciously back away from it. Maybe equality isn't what we need or want (subconsciously speaking, of course;)), or maybe it's too difficult (maybe it's impossible)...
Perhaps P2P is the answer to this little late-night rant -- the example of a lasting and true decentralized system -- but seeing as how the only real mainstream applications of it have so far been illegal activities, I don't see it replacing the WWW any time soon (ie. freenet).
Does any of this make sense, or am I just really tired?;)
It is a newer offering, which also means it's likely actively gaining new features (they may be open to suggestion), and the price is more than fair IMO.
Disclaimer: I'm not affiliated with Basecamp in any way, it just came to mind. For my affiliations, see.sig:)
This is a good point. Depending on the type of work you do (most peoples' needs are quite minimal), even older Macs are just fine. Based on my experience with a 3-1/2 year old PB 667 (which I have no intention of selling any time soon), even compared to my new 20" iMac G5, I'd say that older Mac users feel the age of their machines a lot less than users of other OSes. This is true especially of Windows, but slightly less so with Linux -- I do have a Windows and a Linux desktop at the office here.
With that in mind, plus the usability difference (I never have to administer my Macs, the others are a PITA at times), it's a no-brainer for me.
I'm actually demoting our Windows desktop to a remote-connections-only test machine (and ONLY for IE) and replacing it with a new Mac Mini whenever that arrives (I'm in with the "3-4 weeks" orders, since I didn't make the purchase in time to have it sooner).
Returning a JavaScript data structure is sufficiently compliant (ie. it's part of the language itself), and has the benefit of skipping the deserialization step entirely.
Plus, on the server-side, you should be able to write a JavaScript serializer in 30 lines or less. For example, the one used in our project (sitellite.org) is exactly 30 lines of PHP code, and properly handles strings, numbers, booleans, arrays, and objects.
Wouldn't it make more sense to include the B for Binary, which is the essential purpose of the new "standard"? Plus, XBop sounds more natural when spoken than XOP does, and it's way more fun too!:)
I didn't see much on their site about the API, just the serialization, but I'm wondering how this compares with JPSPAN (http://jpspan.sourceforge.net/wiki/doku.php) which actually mimicks the server-side objects in JavaScript, which is a really cool idea that take a lot of the pain out of client-side RPC programming.
"Are you saying that CSS is to XSL as Ruby is to Perl?"
In terms of elegance yes. In terms of features, no. However, as the CSS specs advance, the feature gap could become a little smaller. They wouldn't ever be even, or even close to it, since XSL is a complete language and CSS is not, but they both approach a similar problem space (from different angles).
"What I don't like about CSS is that the results are dependant on the browser, and browsers don't implement CSS consistently."
This is true in that the rendering of the markup is always going to differ from one engine to the next. But isn't the same also true of the results of the XML documents that are output from the XSL? XSL transforms one document into a new format, but if that format is ever going to be displayed, then it will still have the same problems as CSS or any rendering technology.
Even PDF rendering isn't exact between, for example, Apple's Preview.app and Adobe Acrobat. Although perhaps compared to PDF or PostScript, CSS + XML has a long way to go (engine-wise, spec-wise, both...).
Still, CSS for XML is at the stage where it has a lot of potential, and a lot of growing yet to do. But for output formats like PDF, and doing away with HTML altogether (which browsers still have to contend with for the foreseeable future) it can probably achieve a pretty high degree of accuracy across print-rendering engines too.
Sorry, to clarify I meant when XSL was first introduced, and for the first while thereafter, but looking at my comment that wasn't clear at all. I am aware of the current state of support for XSL in many tools, including the major browsers. It's not the tool support that keeps me from XSL, but XSL itself.
It's the same reason that, while Perl is an interesting language (Perl 6's regexps for example are really cool), Ruby provides 99% of what Perl can do with 100x the elegance (mind you, elegant programming solutions are one of the big strengths of Perl, but the language itself doesn't exhibit that elegance itself).
And to extinguish any sign of language-war flaming on my part, Perl is the first real language I cut my teeth on. I had a passionate love affair with it, and we've parted on good terms.:) My 9-5 language these days is actually PHP, a far cry from Ruby's elegance itself (but very simple and focused for its intended goals). I also happen to think Javascript (out of the browser context) is another amazingly elegant language with a lot of potential. I just bought an O'Reilly Objective-C book on a whim today, so I'll find out how well that stacks up soon I suppose.
Why am I seeing so many bad reactions on here? Responses like "show me the browser support"? You don't need browser support for print! You need another program capable of it. So what that the first one to do it is commercial -- commercial businesses quite often outpace open source, truth be told.
Show me the browser support for XSL? The article is displaying an example of why CSS3 will solve most of the same problems 1000x more elegantly. XSL is Perl's (I like Perl, I don't like XSL) ugly kid brother -- got beat twice as hard with the ugly stick.
When XSL came out, where was the tool support for it? Nonexistant. Because it was just a standard first. The tool support even now, years later, is only partial.
So yes, CSS3 will take time to implement in the real world, but it's a clearly superior solution. Shortcomings? Probably more than a few. But if we WORK on them, we can overcome them, probably also 1000x more elegantly than the atrocity that is XSL.
So instead of bitching about someone getting it right for a change (now that we've wasted how many years trying to work with XSL), why not start up an open source project to build support for the new spec? This sounds like a good side-project for Mozilla.org or the KHTML folks (since they already have a rendering engine).
They do this regularly in theatres around here. I'd be interested in the source of this claim, to verify that it's true. If it is, that's despicable. I can understand some of it going to the cost of the pins and perhaps a very low administration cost, but $2 out of $3 is fraudulent activity, IMO.
Nvu (http://www.nvu.com/) bills itself as "the complete web authoring system for linux". Not sure the status of it, or whether it offers templating, but it ought to if it's called "complete".
On another note, a CMS (content management system) can be an option, but it can be an expensive one (ie. time-wise or cost-wise or both). Open Source CMS's (including my own -- see.sig below) usually require some degree of setup/customization and you'll have to be able to work with their template system too (or pay someone to do it for you, usually the CMS vendor or a consultancy based on that CMS). CMS's don't often offer WYSIWYG design/layout tools, which is a lot more complicated than WYSIWYG content editing (hard enough to do well in the browser). So if you're lucky you find a system that allows you to make most of the template stuff in Dreamweaver, and you'll usually have to do a degree of tweaking in the template language itself. This requires learning a template language, and already being proficient in XHTML + CSS. DW users are less likely to be proficient in even XHTML + CSS, since it's such a visual tool, which makes the leap to a CMS a bigger one for those folks.
However, as evidenced by Macromedia's introduction of several content management-related products over the past few years, Dreamweaver doesn't offer near the flexibility a CMS can for web sites that need it.
So basically, if you have the time or money to dedicate to it, a CMS can be rewarding, provided you find one that matches your site's needs. For many sites, a CMS is overkill. On the other hand, for many sites, Dreamweaver is spreading itself way too thin, and a CMS could be just the remedy needed.
Slashdot Mirror
I have to say it: This guy makes some valid points. There, I feel better now. Seriously, while I don't agree entirely with his article (not by a long shot), I also don't agree with any of the posts so far either (which could all be summed up as "he disagrees with us, don't listen to him!").
He makes very valid points about PHP's current weak points, which no one actually responded to in their comments, especially his mention of Unicode support. Proper date support is another biggie. A unified DB abstraction layer should have been added a long time ago. These are basics I had years ago when I used to write in Perl. Not only are they still outstanding issues in PHP, the core of PHP is too busy adding nifty little OOP features, ignorant of the real needs of the community. This is a VALID complaint! (The fact that these could all be solved by looking more closely at Java is a point I find slightly ironic, given the pro-Java/anti-Java polarity around here)
PHP finally getting a real OO system is dandy and all, but PHP's API has started to stink like an old dog. Function naming and parameter ordering inconsistencies could have been fixed for PHP5, with the backwards-compatible functions being marked "deprecated" so that by PHP6 they could be retired for good. PDO or something similar (just give us the basics -- add the gravy later!) should have been a much bigger priority. PHP's Unicode support is shameful. SimpleXML is a good start, but it still only puts PHP at runner-up (maybe we'd be a leader if it came 2-3 years ago).
I hate to say it, but there's a jealousy that rises in me when I look to languages like Ruby and projects like Rails, and I'm unable to join due to my coding activities being tied to 100,000's of lines of PHP code. I'm even more jealous of them after seeing the reaction of the community at a legitimate complaint.
Now to defend Zend for a moment: Of course a business has their profitability to consider when steering the software they rely on. That's not unethical, and as a user you should be aware that that's the case. However, it's not Zend's responsibility to single-handedly create PHP -- we all do it together. And doing it together means that we, the community, dropped the ball.
PHP has not been innovative for a number of years now. Projects like Ruby on Rails and Perl's Maypole, they are.
At the risk of sounding like a Mac fan-boy, I'm going to lay this one on the table. As I see it, ThinkSecret.com is clearly not acting with journalistic integrity in that they gain their content by coercing informants who are not at liberty to reveal the information they have. While this does not absolve the informant of responsibility (they should be found out and included in the lawsuit), it does change the issue at hand. The issue is then not the first amendment rights of ThinkSecret.com, which would be the only purpose of the EFF getting involved, but whether they were acting in accordance with the law, which they clearly were not. As such, I can see this only as a PR move on the part of the EFF, and a questionable one at that.
Perhaps they are more intimately aware of the issues of this case (I would hope so, and they are lawyers, which I am not), but it makes me question whether they are knowingly wasting their resources (resources myself amongst others have donated towards) for the sake of increasing their exposure via a high-profile case. If this is so, I can understand that it may be a calculated risk that they feel will pay off in the end, but I have to wonder, at what cost?
I see, I see. My apology. ;)
Woah, where did that come from? The parent post may not have been totally correct (science has its share of validation issues, but it is not totally invalid because of that -- not that that is what he claimed anyway, although it seems to be your interpretation of it), but I don't see where the logical leap from "I think I see a logical fallacy" to "I'm a religious bigot" can be made.
The point in his second paragraph is quite valid too. I've lost count how many times it was determined that butter was worse than margarine, then the reverse, then back again. Empirical observation is flawed too. For example, prove by use of the empirical method that the empirical method is correct. Heck, use logic too. You'll still end up in a circular proof, with two logical bits pointing at each other, shrugging their shoulders, and saying "but it _must_ be true!"
"Myriads of people have shown this, so it must be true" is fairly close to "Myriads of lab tests have shown this, so it must be true" since we can't know all causes nor all effects to a cause.
Agreed. Skin and all, a carrot should be had au natural.
Also, cooking them in water until the water evaporates is the equivalent of steeping tea leaves then throwing out the water and eating the leaves once the water has absorbed all the flavour, and more importantly, the nutrients. That recipe is simply a how-to on butchering a good vegetable.
True, true. But I'm sure if anyone can speed it up, Microsoft can. ;)
Cheap MS jokes aside, they should be able to achieve some significant speed improvements, being the developers of the original and not some external reverse-engineering company. I suppose this is slightly limited/dependent on the emulation type though as well (ie. processor emulation, API emulation, etc.).
I wonder how much Apple was able to speed up whatever emulation engine they bought (assuming it was bought...).
No doubt. :)
Seems to make some sense, but not so much from a $$$ angle. Mac OS X, for example, uses an emulator to run Mac OS 9 apps on OS X, which was necessary since the new system is not backwards compatible with the old one at all.
Microsoft seems to be looking to use Longhorn as an opportunity to break free from the backwards compatibility that affords them little room for flexibility in how they can implement changes, and now they can do so via the same emulation idea Apple succeeded with in their transition to OS X.
I don't see how this will double their licensing fees, and I think it would be a big mistake for them to break compatibility with XP, 2000, NT, 98, etc. without providing a built-in (ie. included in the OS) bridge to help people onto the new platform. And whether they make Longhorn compatible with non-x86 processors, I don't see how that really changes any of the above.
I've always found that fonts on Windows look like ass. Especially web page rendering.
On Linux, I find the anti-aliasing a bit aggressive, which seems to be the way with most OSS. As soon as they get a new feature, they ramp it up to full for the first two releases thereafter, until they realize that a moderate amount of said feature would be better.
On Mac OS X, under System Preferences > Appearance, there's an option "Turn off text smoothing for font sizes [n] and smaller." It's set to 8 and under by default, but you can set it up to 12 if you want. This pretty much solves the problem of smaller fonts being less legible with anti-aliasing turned on.
IMO, Apple generally has the best font rendering (although some of it is application-dependent, for example, BBEdit turns anti-aliasing off entirely, and I find Preview.app a little blurry compared to Acrobat).
I switched from Windows to Linux not long after the release of Windows ME (what a joke), and a couple years later, when I needed a laptop, I bought the only well-polished Unix-based laptop around: a Mac (powerbook). I've had it for 3 1/2 years now, and I just recently bought a 20" iMac (the new nothing-but-screen model) which is fantastic as well, and I'm waiting for my Mac Mini now too. I'm a total convert. I even feel the zeal rise in me from time to time.
I run a web-based software business, which necessitates testing in MSIE on Windows, so I put together a shitty Windows XP box out of the old one I had before, but I can't stand using it. I only connect to it from the OSX boxes via rdesktop anymore. It's amazingly unintuitive (now that I've had better) and not smooth at all. I haven't had any security issues with it lately (knock on wood), but it requires way more maintenance than the two Mac's do (they require none).
I talked with my dad the other day and I asked him about what he thought of the new Mac Mini. He said he read a bunch of PC magazine reviews that could be summarized with "don't bother". I wasn't able to find those reviews myself (although I found a few naysayers complaining about the price). He also said he would never use a Mac because it's a proprietary system. Apparently, Windows is no longer proprietary, due to sheer prevalence...
I tried explaining the misconceptions of the Mac, since he is quite fed up with Windows, and has seriously contemplated switching to Linux recently, but he didn't seem to want to hear it. Oh well, not much you can do.
The business models employed in the software industry are no different than in other industries, yet software makers continually try to convince themselves that they are the only area of business where the only way to make it is with entirely new ideas. Perhaps those who make it do so because of things like good timing, and more knowledge about how business actually works (ie. what plans work in what circumstances, how to see the patterns into which said plans would fit, as they're emerging). The second biggest problem in software is people who continually try to publicly pat themselves on the back and call themselves "original thinkers". The biggest problem in software are the people who believe them.
It's funny how everything in this (pseudo-)decentralized environment keeps naturally migrating towards a single central point that everything else revolves around. Not that I think this is a good or bad thing, it seems that its just a natural part of everything human to form itself into some structure resembling the state (city=net,government=google,citizens=sites), which may be also true of much of the natural world as well (galaxies, for example, are drawn together around a common object, which is similar, although the cause of it is different).
;)), or maybe it's too difficult (maybe it's impossible)...
;)
It's almost as if, given the chance at a total level of equality, we unconsciously back away from it. Maybe equality isn't what we need or want (subconsciously speaking, of course
Perhaps P2P is the answer to this little late-night rant -- the example of a lasting and true decentralized system -- but seeing as how the only real mainstream applications of it have so far been illegal activities, I don't see it replacing the WWW any time soon (ie. freenet).
Does any of this make sense, or am I just really tired?
http://gotvision.org/ROCK/images/contortionist.jpg
:)
Didn't see invoicing mentioned on their site, but I keep hearing a lot of good things about Basecamp:
http://basecamphq.com/
It is a newer offering, which also means it's likely actively gaining new features (they may be open to suggestion), and the price is more than fair IMO.
Disclaimer: I'm not affiliated with Basecamp in any way, it just came to mind. For my affiliations, see .sig :)
This is a good point. Depending on the type of work you do (most peoples' needs are quite minimal), even older Macs are just fine. Based on my experience with a 3-1/2 year old PB 667 (which I have no intention of selling any time soon), even compared to my new 20" iMac G5, I'd say that older Mac users feel the age of their machines a lot less than users of other OSes. This is true especially of Windows, but slightly less so with Linux -- I do have a Windows and a Linux desktop at the office here.
With that in mind, plus the usability difference (I never have to administer my Macs, the others are a PITA at times), it's a no-brainer for me.
I'm actually demoting our Windows desktop to a remote-connections-only test machine (and ONLY for IE) and replacing it with a new Mac Mini whenever that arrives (I'm in with the "3-4 weeks" orders, since I didn't make the purchase in time to have it sooner).
Returning a JavaScript data structure is sufficiently compliant (ie. it's part of the language itself), and has the benefit of skipping the deserialization step entirely.
Plus, on the server-side, you should be able to write a JavaScript serializer in 30 lines or less. For example, the one used in our project (sitellite.org) is exactly 30 lines of PHP code, and properly handles strings, numbers, booleans, arrays, and objects.
Wouldn't it make more sense to include the B for Binary, which is the essential purpose of the new "standard"? Plus, XBop sounds more natural when spoken than XOP does, and it's way more fun too! :)
I didn't see much on their site about the API, just the serialization, but I'm wondering how this compares with JPSPAN (http://jpspan.sourceforge.net/wiki/doku.php) which actually mimicks the server-side objects in JavaScript, which is a really cool idea that take a lot of the pain out of client-side RPC programming.
"Are you saying that CSS is to XSL as Ruby is to Perl?"
In terms of elegance yes. In terms of features, no. However, as the CSS specs advance, the feature gap could become a little smaller. They wouldn't ever be even, or even close to it, since XSL is a complete language and CSS is not, but they both approach a similar problem space (from different angles).
"What I don't like about CSS is that the results are dependant on the browser, and browsers don't implement CSS consistently."
This is true in that the rendering of the markup is always going to differ from one engine to the next. But isn't the same also true of the results of the XML documents that are output from the XSL? XSL transforms one document into a new format, but if that format is ever going to be displayed, then it will still have the same problems as CSS or any rendering technology.
Even PDF rendering isn't exact between, for example, Apple's Preview.app and Adobe Acrobat. Although perhaps compared to PDF or PostScript, CSS + XML has a long way to go (engine-wise, spec-wise, both...).
Still, CSS for XML is at the stage where it has a lot of potential, and a lot of growing yet to do. But for output formats like PDF, and doing away with HTML altogether (which browsers still have to contend with for the foreseeable future) it can probably achieve a pretty high degree of accuracy across print-rendering engines too.
Sorry, to clarify I meant when XSL was first introduced, and for the first while thereafter, but looking at my comment that wasn't clear at all. I am aware of the current state of support for XSL in many tools, including the major browsers. It's not the tool support that keeps me from XSL, but XSL itself.
:) My 9-5 language these days is actually PHP, a far cry from Ruby's elegance itself (but very simple and focused for its intended goals). I also happen to think Javascript (out of the browser context) is another amazingly elegant language with a lot of potential. I just bought an O'Reilly Objective-C book on a whim today, so I'll find out how well that stacks up soon I suppose.
It's the same reason that, while Perl is an interesting language (Perl 6's regexps for example are really cool), Ruby provides 99% of what Perl can do with 100x the elegance (mind you, elegant programming solutions are one of the big strengths of Perl, but the language itself doesn't exhibit that elegance itself).
And to extinguish any sign of language-war flaming on my part, Perl is the first real language I cut my teeth on. I had a passionate love affair with it, and we've parted on good terms.
Why am I seeing so many bad reactions on here? Responses like "show me the browser support"? You don't need browser support for print! You need another program capable of it. So what that the first one to do it is commercial -- commercial businesses quite often outpace open source, truth be told.
Show me the browser support for XSL? The article is displaying an example of why CSS3 will solve most of the same problems 1000x more elegantly. XSL is Perl's (I like Perl, I don't like XSL) ugly kid brother -- got beat twice as hard with the ugly stick.
When XSL came out, where was the tool support for it? Nonexistant. Because it was just a standard first. The tool support even now, years later, is only partial.
So yes, CSS3 will take time to implement in the real world, but it's a clearly superior solution. Shortcomings? Probably more than a few. But if we WORK on them, we can overcome them, probably also 1000x more elegantly than the atrocity that is XSL.
So instead of bitching about someone getting it right for a change (now that we've wasted how many years trying to work with XSL), why not start up an open source project to build support for the new spec? This sounds like a good side-project for Mozilla.org or the KHTML folks (since they already have a rendering engine).
Here are some good arguments why this may not be true:
http://daringfireball.net/2005/01/the_rumor_game
http://adzoox.com/otherendoftheroom.html
WOOOHOOO!!!!!
They do this regularly in theatres around here. I'd be interested in the source of this claim, to verify that it's true. If it is, that's despicable. I can understand some of it going to the cost of the pins and perhaps a very low administration cost, but $2 out of $3 is fraudulent activity, IMO.
Nvu (http://www.nvu.com/) bills itself as "the complete web authoring system for linux". Not sure the status of it, or whether it offers templating, but it ought to if it's called "complete".
.sig below) usually require some degree of setup/customization and you'll have to be able to work with their template system too (or pay someone to do it for you, usually the CMS vendor or a consultancy based on that CMS). CMS's don't often offer WYSIWYG design/layout tools, which is a lot more complicated than WYSIWYG content editing (hard enough to do well in the browser). So if you're lucky you find a system that allows you to make most of the template stuff in Dreamweaver, and you'll usually have to do a degree of tweaking in the template language itself. This requires learning a template language, and already being proficient in XHTML + CSS. DW users are less likely to be proficient in even XHTML + CSS, since it's such a visual tool, which makes the leap to a CMS a bigger one for those folks.
On another note, a CMS (content management system) can be an option, but it can be an expensive one (ie. time-wise or cost-wise or both). Open Source CMS's (including my own -- see
However, as evidenced by Macromedia's introduction of several content management-related products over the past few years, Dreamweaver doesn't offer near the flexibility a CMS can for web sites that need it.
So basically, if you have the time or money to dedicate to it, a CMS can be rewarding, provided you find one that matches your site's needs. For many sites, a CMS is overkill. On the other hand, for many sites, Dreamweaver is spreading itself way too thin, and a CMS could be just the remedy needed.
Don't lots of people already use ear pieces for talking on their cell phones? This actually seems like quite a natural progression.