> if you read all the claims for ABS from makers and such, they don't ever > claim "better braking." They claim "better stability" or something like > that. They do it for two reasons. First, the don't want the liability. > Second, they know that the system can't guarentee shorter distances, and > will take longer in many circumstances. Yes, ABS is getting better, but > that doesn't mean that it is better than a well trained foot yet.
Yeah, but a well-trained foot fails badly in a crisis situation if e.g. the driver panics. ABS gives the same mediocre performance almost no matter what (provided you actually get the pedal pushed), so it fails better.
On the whole, it is preferable to rely on a system that underperforms in the best case but fails well, as opposed to a system that performs well in the best case but fails poorly. (Granted, what can be even better is to set things up so that the mediocre system that fails well is a fallback that kicks in when the good system fails. I'm not sure how that could be done reliably in this case, though, and if it's done unreliably, i.e., if the fallback mechanism fails poorly, you can get the worst of both worlds, which is bad.)
> if you want to lock your wheels on a snow/ice road, you are suicidal
No, no, no, not on the *road*. You do that in a corporate (or factory) parking lot, on Saturday mornings when the place is closed and there are no cars parked there. Mmmmm.... doughnuts!
> But for the most part, 99% of my driving takes place on dry pavement > However, they... don't realize they're driving on the shoulder, or > even worse off the road and headed toward a cliff or something.
So, let me get this straight... Driving on snow is very unusual, but driving right next to cliffs is something you do on a regular basis? Where is it exactly that you are you driving, southern Jordan near Petra?
I don't use it on my primary workstation either at home or at work, but I do keep a Windows system around at home (for assorted reasons, the easiest of which to explain is the need to test web pages for IE compatibility), and of course at work I have to administer a number of Windows systems that are mostly used by other people.
> No that means they are talking about TCP on top of IP.
We usually just say TCP if it's primarily TCP we're talking about. It's understood that it's probably layered over IP, simply because it's unusual to layer TCP over some other network layer (as the whole suite of protocols is normally kept together), but if you're talking about things at the transport layer, the underlying network layer is mostly incidental to what you're talking about. Saying "TCP/IP" to mean "TCP layered over IP" makes only marginally more sense than saying "IP/ethernet" to mean IP layered over ethernet or "IP/PPP" to mean IP layered over a point-to-point dialup connection. When people say "TCP/IP", they're normally talking about the entire protocol suite that makes the internet work, and that includes ICMP and UDP.
> How about this? > http://sourceforge.net/softwaremap/trove_list.php? form_cat=160 > IMO, this sample is actually skewed toward Perl, because Perl is very > popular in the open source community.
Sourceforge is not especially popular in the Perl community, however. I'm pretty sure there are rather more than eleven thousand modules on the CPAN. Heck, there are some 4500 *authors* who have published work via the CPAN.
> Of course, there may also be legions of Perl and Java programmers that have > blacklisted SourceForge from the community because they disagreed with it.
Huh? Blacklisted? Disagreed? More like Perl programmers look at sourceforge and say, "Oh, it's sort of like the CPAN, but without the nifty Perl-specific features." Perl programmers don't use sourceforge very much because the CPAN fills that role in the Perl community and provides significant additional benefits, such as better search facilities (search.cpan.org, which incidentally automatically extracts the embedded documentation from the POD and makes it available in HTML format on the web), dependency resolution (pretty decent dependency resolution, too, significantly better than urpmi or apt-get can manage, for instance), and a larger and less congested set of mirrors, among other things. Plus the CPAN was already the de-facto clearing house for Perl before sourceforge ever existed, so migrating over to sourceforge at that point wouldn't make sense even if it *had* the features CPAN has. The overall reaction to sourceforge in the Perl community varies from nonplussed to "Cool, I'll use that when I do projects in other languages than Perl."
> Anyways, none of this will apply to me. I don't plan on dying.
Good luck with that.
> If science can make clones of people, how far off are we from taking the > neural patterns of people and transplanting then into a mechanized human?
Nobody has any idea. Could be a long, *long* time, potentially never. Cloning cells is one thing, but we know, to a first aproximation, nothing whatsoever about how the mind works. We understand some of the low-level chemistry of brain function, in terms of passing a signal from one neuron to another, but in terms of the overall function of the thing, we're pretty much completely lost. A lot of models have been proposed over the years, but thus far none of them have turned out to be very usefully accurate. A real breakthrough would be needed, the kind of breakthrough that creates an entire new major field of study, overnight, ex nihilo.
In other words, don't hold your breath, and don't have your body frozen until you have nothing to lose because you're dead anyway.
> I think the day is comming when artificial hearts will be better than > real hearts.
Yeah, but the heart is pretty simple. Basically, it's just a pump, albeit with some timing mechanisms. The brain is rather more complex.
> I see a new world in 100 years where people can live to 200 years of age
Now that is more plausible. It is, after all, an incremental improvement, albeit a pretty significant one -- should be MUCH more achievable than the immortality you were talking about a moment above.
> if this gets popular, how long till someone is offering ads for it?
Wow. The audacity. That, like, wouldn't offend anyone, or anything... sheesh. What kind of sick, twisted, warped mind could conceive of something like that?
They'll do it, of course. I give it two years, from general availability of the things, until the advertisements start appearing.
Any change or action that anyone might take, however minor, that it is even *vaguely* related to cemetaries is positively guaranteed to deeply offend at *least* 10% of the population of North America. People, for reasons I don't fully understand, get *extremely* emotional about anything having to do with cemetaries. Walking a dog in a cemetary offends a lot of people. Stepping on or over one of those flush-with-the-ground grave markers offends a lot of people. Wearing a hat of any kind in a cemetary, even the keep-you-warm kind in winter, offends a statistically significant portion of the population. Some kinds of lawn care that are considered mandatory for yuppie suburbian residential lawns will offend people if done in a cemetary. I can positively guarantee that video feeds embedded in the actual tombstones will offend some people.
UDP and ICMP, in addition to IP and TCP, are generally considered to be part of the TCP/IP protocol suite, but for some odd reason nobody wants to call it the TCP/UDP/ICMP/IP Protocol Suite (TCPUDPICMPIPPS) every time it is discussed, so we usually just call it TCP/IP. As a rule, if someone says just "TCP" or just "IP", they're talking about that specific protocol, but if they say TCP/IP, they're talking about the entire suite. HTH.HAND.
IMO, the number one force in changing the world of comics in the last twenty years has been the influence of Bill Waterson. Other comic strip artists (well, the ones who were paying attention) have picked up two things as a result of his strip.
The first is that the strip needs to engage the reader every single day; I think other comic strip artists had known that in the past, but they had forgotten it, and the comic strips of the 1980s were a bland world wherein out of an entire page of comics, with eight or ten strips, the reader hoped to get a chuckle out of one of them. That trend has reversed now, thanks in large part to Waterson.
The second thing, however, is in the long term probably the more important influence of Waterson's work -- not because it's not important to engage the reader every day, but because the other strips would have figured that out anyway. But Waterson was the one who rebelled against the constrained panel layout that the newspapers and syndicates had been enforcing on everyone and experimented with more interesting layouts. This has inspired other strips, and will presumably continue to do so. Most strips still fit in the standard panel layouts, but the door has been opened for other possibilities.
And that's where we come back to topic, because publishing on the web gives comic strip artists the opportunity to do, layout-wise, whatever they want. Some of them are taking advantage of that. This is the beginning of a whole new *kind*, IMO, of comic strip.
> a bot is going to be able to monitor the situation and execute the > 'ideal' strategy far better than any human
If you write a bot that can execute strategy better than any human, you can name your salary and your title at practically any company in the world. The best minds in AI research don't even know where to *start* writing a computer program smart enough to think in strategic terms.
Computer programs can be very good at *tactics*, but they can't think strategically at all. It's AI-complete.
> Even (or especially!) in games with complex PvP like Guild Wars
I don't know that specific game, but if the best humans can't beat a bot, I'm not even vaguely interested in playing it.
> I think "mainstream" is less about who's RUNNING a given language, > and more about who's WRITING it.
Ah, so what you're saying, then, is that more people *write* stuff in PHP than write stuff in Perl. Well, that's harder to measure, but it still sounds like unmitigated malarke to me. I know, for instance, that when the Open Clip Art Library needs changes made to the PHP portions of its website, beyond merely changing stuff in the HTML that is printed out, it's quite a lot easier to find someone willing to rewrite the page from scratch in Perl than it is to find someone to make the needed changes to the PHP. The site started out 100% PHP, adapted from some other website with minor modifications, and at this point about half of it is Perl. There are only a few people involved in the project, so the sample is probably not statistically significant, but nevertheless, there are a *lot* of Perl programmers out there actively writing code.
> These sorts of niche technologies still do the job, and selecting one of > them instead of a more "mainstream" language like PHP or C++ identifies > you as a particular kind of person.
You really think PHP is more mainstream than Perl?
Wow. That's a new one.
Perl is a core part of practically every non-Microsoft OS and distribution; half the applications on a typical X11-based desktop depend directly or indirectly on it. On Mandrake, for instance, all of the *drak apps (printerdrake, fontdrake, harddrake,...) depend on it. On Gentoo, the package system depends on it, so you can't even install PHP without already having Perl. It's part of the core on OS X as well. On my Debian workstation, things that depend on Perl, either directly or indirectly, include the font manager, Gnome, KDE, autoconf, xscreensaver, and Mozilla Firefox, among plent of others.
Whereas, if you uninstall PHP, the only likely casualty is WordPress.
Yeah, PHP is so much more mainstream, so much more widely deployed and relied on than Perl. That's why LAMP was "Linux, Apache, MySQL, and Perl", but then as an afterthought, to be politically correct and inclusive, they changed it to "Linux, Apache, MySQL, and Perl or Python" and then to "Linux, Apache, MySQL, and Perl, Python, or PHP". You can almost here the unspoken word "even" before the PHP in that last form.
> Python gives you the power and expressiveness of perl, but with actual > design principles behind
Yeah, and the primary design principle is, "There's One Best Way To Do It", and woebetide anyone who wants to use a different approach. Heaven forfend I should want to solve a particular problem with the paradigm it best lends itself to, if that paradigm doesn't happen to be the one Guido thinks is best for all problems.
This philosophy is so pervasive in the Python community that it leaks over into software that's written in Python, infecting it in some cases with a distinct lack of flexibility and an unwillingness to let the user do things the user's way. Mailman, for instance, will not let a user subscribe to both individual messages and also digests, because the guy who wrote it decided that was not the most elegant way to do things. The Perl community dislikes this sort of arrogance. (We have, instead, our own form of hubris... the belief that our ways of doing things are good enough to show to the world, even if they're not the most popular. Hence the CPAN.)
In short, there are major *cultural* differences between Perl and Python. The differences in the languages themselves either result from the cultural differences (in the language designers) or result in the "right" sort of people gravitating toward each language and thus each language's community -- probably both.
I tried Python, but I determined that it's not for me. Perl is for me. Lisp is for me. At some point I want to try Ruby and see if maybe that's for me too. But Python is not.
> By performing tasks within a game repetitively or very quickly, bots > can easily outplay human-controlled characters, giving unscrupulous > players an unfair advantage."
Sounds like incredibly poor game design to me. Why would anyone want to play a game where how fast you can punch the button is an important skill? *YAWN*. Whatever happened to games with _strategy_?
> For instance, the 0.16 release of the Open Clip Art Library, in.tar.bz2 > format, is 51M with only the SVG images or 72M with the SVG images plus > an 80-pixel-wide PNG thumbnail of each
Conveniently, it contains some logos, which we could use as examples. If you look in the logos folder, you will see 30 images. For 30 out of 30 of them, the.svg file is larger than the 80-pixel.png thumbnail. In some cases quite a bit larger (as in, orders of magnitude).
> The logo at the top of your screen is here: > http://images.slashdot.org/title.gif.
That's not a logo. That's a banner. It doesn't even *contain* a logo, just the name of the site. Here are some examples of logos:
The Nike swoosh: http://upload.wikimedia.org/wikipedia/en/c/cf/Nike logotype.png The Golden Arches: http://www.mckansas.com/images/operators/100000263 7/ArchLogo_small.gif
> SVG is a lot smaller than you think....
In theory, maybe. In practice, SVG images can take up quite a bit of space. For instance, the 0.16 release of the Open Clip Art Library, in.tar.bz2 format, is 51M with only the SVG images or 72M with the SVG images plus an 80-pixel-wide PNG thumbnail of each (and also a small.txt file for each, containing a summary of the file's metadata). (Some of the thumbnails may now be 128 pixels wide, instead of 80, as the library is in the process of transitioning toward freedesktop.org thumbnail specification compliance. But I think most are still 80px at this point.)
> Next you'll be telling me that you can fly by throwing yourself at the > ground and missing.
No. Well, in theory, yes, but in practice you can't miss, because your aim is too good. The entire human race has, on the whole, pretty good aim, and so we can't fly. It's funny to fantacize about what we could do if our aim were really bad, but ultimately that's just fantasy.
Part of what makes your aim so good, as a human, is your density. You're quite heavy, for your size and surface area, really, almost as dense as water. Consequently, you tend to move along a smooth curve, rather than floating about aimlessly like dandelion fluff or a mosquito. This is a large part of the reason why you can't fly and those things can.
> Network bandwidth is reduced for many types of graphical data such as > logos, emblems, seals, and other types of data that can be described > in relatively few drawing commands
Actually, for now[1], most logos, on the web, are probably better off delivered in GIF format, bandwidth-wise, because they're not very large and don't have very many colors. However, SVG is better for things like charts, graphs, clip-art that you might want to use at different sizes, and so on. In fact, SVG would be a great format to use when creating and/or editing a logo, and then you could render it at whatever sizes you like -- one size for your site's bookmark icon, another size for the banner at the top of the front page, another size for on the corporate letterhead, and so on. But at small sizes such as you'd probably use on the web, the GIF will likely be smaller. It's pretty amazing, actually, how small a GIF image can be if it's only got a couple of colors in it, which is what you want anyway for a logo, usually, because you want to be able to produce versions of it for fax transmission forms, the shape of the hedges on the front lawn, screening onto tshirts, and so on and so forth.
But you don't want that 32x32 pixel GIF version of the image for the glossy-print brochures. It's a great delivery format for the website, but it's not such a great source format. SVG, OTOH, is a great source format.
[1] I say "for now", because for the forseeable future screen resolutions seem stuck at a few hundred pixels each way. It's easy to imagine that changing in the future, but in the last roughly fifteen years we've gone from 640x480 to, for most users, less than double those dimensions (or less than four times the total number of pixels on the screen), which is hardly impressive.
> Right, and the next thing you'll tell me is that the Earth isn't flat!
Let me guess: you're from Iowa? No, the Earth isn't flat. You should visit Pennsylvania or Kentucky sometime, and you'll see.
> And that the sun doesn't revolve around the earth.
Well, sort of. The Earth and the Sun exert the same force on one another, which causes the revolving to happen, so from one perspective it's possible to say that the Sun and the Earth both revolve around one another. But that ignores the pull of every other object that pulls on both of them... the Moon, by virtue of being quite a lot closer than the Sun, has quite a bit of influence on the Earth, even though it's smaller.
(You can verify that the Moon is smaller than the Sun, because in a solar ecclipse edges of the Sun still shine, around the edges of the Moon. Just don't stare at it directly; you have to use a mirror, or you'll turn into a Gorgon. HTH.HAND.)
> I bet Slavery is freedom
No, no, that's completely wrong. You've got it totally backwards. Freedom is slavery, no the other way around.
> and War is piece
Piece of what, Hell?
> if you read all the claims for ABS from makers and such, they don't ever
> claim "better braking." They claim "better stability" or something like
> that. They do it for two reasons. First, the don't want the liability.
> Second, they know that the system can't guarentee shorter distances, and
> will take longer in many circumstances. Yes, ABS is getting better, but
> that doesn't mean that it is better than a well trained foot yet.
Yeah, but a well-trained foot fails badly in a crisis situation if e.g. the driver panics. ABS gives the same mediocre performance almost no matter what (provided you actually get the pedal pushed), so it fails better.
On the whole, it is preferable to rely on a system that underperforms in the best case but fails well, as opposed to a system that performs well in the best case but fails poorly. (Granted, what can be even better is to set things up so that the mediocre system that fails well is a fallback that kicks in when the good system fails. I'm not sure how that could be done reliably in this case, though, and if it's done unreliably, i.e., if the fallback mechanism fails poorly, you can get the worst of both worlds, which is bad.)
> if you want to lock your wheels on a snow/ice road, you are suicidal
No, no, no, not on the *road*. You do that in a corporate (or factory) parking lot, on Saturday mornings when the place is closed and there are no cars parked there. Mmmmm.... doughnuts!
> But for the most part, 99% of my driving takes place on dry pavement ... don't realize they're driving on the shoulder, or
> However, they
> even worse off the road and headed toward a cliff or something.
So, let me get this straight... Driving on snow is very unusual, but driving right next to cliffs is something you do on a regular basis? Where is it exactly that you are you driving, southern Jordan near Petra?
Sheesh.
> I don't use microsoft at home or at work.
I don't use it on my primary workstation either at home or at work, but I do keep a Windows system around at home (for assorted reasons, the easiest of which to explain is the need to test web pages for IE compatibility), and of course at work I have to administer a number of Windows systems that are mostly used by other people.
> No that means they are talking about TCP on top of IP.
We usually just say TCP if it's primarily TCP we're talking about. It's understood that it's probably layered over IP, simply because it's unusual to layer TCP over some other network layer (as the whole suite of protocols is normally kept together), but if you're talking about things at the transport layer, the underlying network layer is mostly incidental to what you're talking about. Saying "TCP/IP" to mean "TCP layered over IP" makes only marginally more sense than saying "IP/ethernet" to mean IP layered over ethernet or "IP/PPP" to mean IP layered over a point-to-point dialup connection. When people say "TCP/IP", they're normally talking about the entire protocol suite that makes the internet work, and that includes ICMP and UDP.
> How about this?? form_cat=160
> http://sourceforge.net/softwaremap/trove_list.php
> IMO, this sample is actually skewed toward Perl, because Perl is very
> popular in the open source community.
Sourceforge is not especially popular in the Perl community, however. I'm pretty sure there are rather more than eleven thousand modules on the CPAN. Heck, there are some 4500 *authors* who have published work via the CPAN.
> Of course, there may also be legions of Perl and Java programmers that have
> blacklisted SourceForge from the community because they disagreed with it.
Huh? Blacklisted? Disagreed? More like Perl programmers look at sourceforge and say, "Oh, it's sort of like the CPAN, but without the nifty Perl-specific features." Perl programmers don't use sourceforge very much because the CPAN fills that role in the Perl community and provides significant additional benefits, such as better search facilities (search.cpan.org, which incidentally automatically extracts the embedded documentation from the POD and makes it available in HTML format on the web), dependency resolution (pretty decent dependency resolution, too, significantly better than urpmi or apt-get can manage, for instance), and a larger and less congested set of mirrors, among other things. Plus the CPAN was already the de-facto clearing house for Perl before sourceforge ever existed, so migrating over to sourceforge at that point wouldn't make sense even if it *had* the features CPAN has. The overall reaction to sourceforge in the Perl community varies from nonplussed to "Cool, I'll use that when I do projects in other languages than Perl."
> Anyways, none of this will apply to me. I don't plan on dying.
Good luck with that.
> If science can make clones of people, how far off are we from taking the
> neural patterns of people and transplanting then into a mechanized human?
Nobody has any idea. Could be a long, *long* time, potentially never. Cloning cells is one thing, but we know, to a first aproximation, nothing whatsoever about how the mind works. We understand some of the low-level chemistry of brain function, in terms of passing a signal from one neuron to another, but in terms of the overall function of the thing, we're pretty much completely lost. A lot of models have been proposed over the years, but thus far none of them have turned out to be very usefully accurate. A real breakthrough would be needed, the kind of breakthrough that creates an entire new major field of study, overnight, ex nihilo.
In other words, don't hold your breath, and don't have your body frozen until you have nothing to lose because you're dead anyway.
> I think the day is comming when artificial hearts will be better than
> real hearts.
Yeah, but the heart is pretty simple. Basically, it's just a pump, albeit with some timing mechanisms. The brain is rather more complex.
> I see a new world in 100 years where people can live to 200 years of age
Now that is more plausible. It is, after all, an incremental improvement, albeit a pretty significant one -- should be MUCH more achievable than the immortality you were talking about a moment above.
> if this gets popular, how long till someone is offering ads for it?
Wow. The audacity. That, like, wouldn't offend anyone, or anything... sheesh. What kind of sick, twisted, warped mind could conceive of something like that?
They'll do it, of course. I give it two years, from general availability of the things, until the advertisements start appearing.
> who is going to be offended by this?
Any change or action that anyone might take, however minor, that it is even *vaguely* related to cemetaries is positively guaranteed to deeply offend at *least* 10% of the population of North America. People, for reasons I don't fully understand, get *extremely* emotional about anything having to do with cemetaries. Walking a dog in a cemetary offends a lot of people. Stepping on or over one of those flush-with-the-ground grave markers offends a lot of people. Wearing a hat of any kind in a cemetary, even the keep-you-warm kind in winter, offends a statistically significant portion of the population. Some kinds of lawn care that are considered mandatory for yuppie suburbian residential lawns will offend people if done in a cemetary. I can positively guarantee that video feeds embedded in the actual tombstones will offend some people.
It'll also be a maintenance nightmare.
But it might sell pretty well anyway.
UDP and ICMP, in addition to IP and TCP, are generally considered to be part of the TCP/IP protocol suite, but for some odd reason nobody wants to call it the TCP/UDP/ICMP/IP Protocol Suite (TCPUDPICMPIPPS) every time it is discussed, so we usually just call it TCP/IP. As a rule, if someone says just "TCP" or just "IP", they're talking about that specific protocol, but if they say TCP/IP, they're talking about the entire suite. HTH.HAND.
IMO, the number one force in changing the world of comics in the last twenty years has been the influence of Bill Waterson. Other comic strip artists (well, the ones who were paying attention) have picked up two things as a result of his strip.
The first is that the strip needs to engage the reader every single day; I think other comic strip artists had known that in the past, but they had forgotten it, and the comic strips of the 1980s were a bland world wherein out of an entire page of comics, with eight or ten strips, the reader hoped to get a chuckle out of one of them. That trend has reversed now, thanks in large part to Waterson.
The second thing, however, is in the long term probably the more important influence of Waterson's work -- not because it's not important to engage the reader every day, but because the other strips would have figured that out anyway. But Waterson was the one who rebelled against the constrained panel layout that the newspapers and syndicates had been enforcing on everyone and experimented with more interesting layouts. This has inspired other strips, and will presumably continue to do so. Most strips still fit in the standard panel layouts, but the door has been opened for other possibilities.
And that's where we come back to topic, because publishing on the web gives comic strip artists the opportunity to do, layout-wise, whatever they want. Some of them are taking advantage of that. This is the beginning of a whole new *kind*, IMO, of comic strip.
> a bot is going to be able to monitor the situation and execute the
> 'ideal' strategy far better than any human
If you write a bot that can execute strategy better than any human, you can name your salary and your title at practically any company in the world. The best minds in AI research don't even know where to *start* writing a computer program smart enough to think in strategic terms.
Computer programs can be very good at *tactics*, but they can't think strategically at all. It's AI-complete.
> Even (or especially!) in games with complex PvP like Guild Wars
I don't know that specific game, but if the best humans can't beat a bot, I'm not even vaguely interested in playing it.
> I think "mainstream" is less about who's RUNNING a given language,
> and more about who's WRITING it.
Ah, so what you're saying, then, is that more people *write* stuff in PHP than write stuff in Perl. Well, that's harder to measure, but it still sounds like unmitigated malarke to me. I know, for instance, that when the Open Clip Art Library needs changes made to the PHP portions of its website, beyond merely changing stuff in the HTML that is printed out, it's quite a lot easier to find someone willing to rewrite the page from scratch in Perl than it is to find someone to make the needed changes to the PHP. The site started out 100% PHP, adapted from some other website with minor modifications, and at this point about half of it is Perl. There are only a few people involved in the project, so the sample is probably not statistically significant, but nevertheless, there are a *lot* of Perl programmers out there actively writing code.
> These sorts of niche technologies still do the job, and selecting one of
...) depend on it. On Gentoo, the package system depends on it, so you can't even install PHP without already having Perl. It's part of the core on OS X as well. On my Debian workstation, things that depend on Perl, either directly or indirectly, include the font manager, Gnome, KDE, autoconf, xscreensaver, and Mozilla Firefox, among plent of others.
> them instead of a more "mainstream" language like PHP or C++ identifies
> you as a particular kind of person.
You really think PHP is more mainstream than Perl?
Wow. That's a new one.
Perl is a core part of practically every non-Microsoft OS and distribution; half the applications on a typical X11-based desktop depend directly or indirectly on it. On Mandrake, for instance, all of the *drak apps (printerdrake, fontdrake, harddrake,
Whereas, if you uninstall PHP, the only likely casualty is WordPress.
Yeah, PHP is so much more mainstream, so much more widely deployed and relied on than Perl. That's why LAMP was "Linux, Apache, MySQL, and Perl", but then as an afterthought, to be politically correct and inclusive, they changed it to "Linux, Apache, MySQL, and Perl or Python" and then to "Linux, Apache, MySQL, and Perl, Python, or PHP". You can almost here the unspoken word "even" before the PHP in that last form.
> Python gives you the power and expressiveness of perl, but with actual
> design principles behind
Yeah, and the primary design principle is, "There's One Best Way To Do It", and woebetide anyone who wants to use a different approach. Heaven forfend I should want to solve a particular problem with the paradigm it best lends itself to, if that paradigm doesn't happen to be the one Guido thinks is best for all problems.
This philosophy is so pervasive in the Python community that it leaks over into software that's written in Python, infecting it in some cases with a distinct lack of flexibility and an unwillingness to let the user do things the user's way. Mailman, for instance, will not let a user subscribe to both individual messages and also digests, because the guy who wrote it decided that was not the most elegant way to do things. The Perl community dislikes this sort of arrogance. (We have, instead, our own form of hubris... the belief that our ways of doing things are good enough to show to the world, even if they're not the most popular. Hence the CPAN.)
In short, there are major *cultural* differences between Perl and Python. The differences in the languages themselves either result from the cultural differences (in the language designers) or result in the "right" sort of people gravitating toward each language and thus each language's community -- probably both.
I tried Python, but I determined that it's not for me. Perl is for me. Lisp is for me. At some point I want to try Ruby and see if maybe that's for me too. But Python is not.
> On one hand, its just a game. On the other hand, so is blackjack, but its
> a crime to cheat someone out of money.
Depends on jurisdiction. In some places, blackjack is entirely legal.
> By performing tasks within a game repetitively or very quickly, bots
> can easily outplay human-controlled characters, giving unscrupulous
> players an unfair advantage."
Sounds like incredibly poor game design to me. Why would anyone want to play a game where how fast you can punch the button is an important skill? *YAWN*. Whatever happened to games with _strategy_?
> For instance, the 0.16 release of the Open Clip Art Library, in .tar.bz2
.svg file is larger than the 80-pixel .png thumbnail. In some cases quite a bit larger (as in, orders of magnitude).
> format, is 51M with only the SVG images or 72M with the SVG images plus
> an 80-pixel-wide PNG thumbnail of each
Conveniently, it contains some logos, which we could use as examples. If you look in the logos folder, you will see 30 images. For 30 out of 30 of them, the
> The logo at the top of your screen is here:
e logotype.png3 7/ArchLogo_small.gif
.tar.bz2 format, is 51M with only the SVG images or 72M with the SVG images plus an 80-pixel-wide PNG thumbnail of each (and also a small .txt file for each, containing a summary of the file's metadata). (Some of the thumbnails may now be 128 pixels wide, instead of 80, as the library is in the process of transitioning toward freedesktop.org thumbnail specification compliance. But I think most are still 80px at this point.)
> http://images.slashdot.org/title.gif.
That's not a logo. That's a banner. It doesn't even *contain* a logo, just the name of the site. Here are some examples of logos:
The Nike swoosh:
http://upload.wikimedia.org/wikipedia/en/c/cf/Nik
The Golden Arches:
http://www.mckansas.com/images/operators/10000026
> SVG is a lot smaller than you think....
In theory, maybe. In practice, SVG images can take up quite a bit of space. For instance, the 0.16 release of the Open Clip Art Library, in
> Next you'll be telling me that you can fly by throwing yourself at the
> ground and missing.
No. Well, in theory, yes, but in practice you can't miss, because your aim is too good. The entire human race has, on the whole, pretty good aim, and so we can't fly. It's funny to fantacize about what we could do if our aim were really bad, but ultimately that's just fantasy.
Part of what makes your aim so good, as a human, is your density. You're quite heavy, for your size and surface area, really, almost as dense as water. Consequently, you tend to move along a smooth curve, rather than floating about aimlessly like dandelion fluff or a mosquito. This is a large part of the reason why you can't fly and those things can.
> I'd say all it would need to get widespread adoption would be reasonably
> close parity taste-wise
Right, but artificial sweeteners don't have anything like reasonably close parity, taste-wise, to sugar.
Perl? PHP? Who needs 'em? Firefox supports SVG now so why not just do everything in that?
Sheesh.
> Network bandwidth is reduced for many types of graphical data such as
> logos, emblems, seals, and other types of data that can be described
> in relatively few drawing commands
Actually, for now[1], most logos, on the web, are probably better off delivered in GIF format, bandwidth-wise, because they're not very large and don't have very many colors. However, SVG is better for things like charts, graphs, clip-art that you might want to use at different sizes, and so on. In fact, SVG would be a great format to use when creating and/or editing a logo, and then you could render it at whatever sizes you like -- one size for your site's bookmark icon, another size for the banner at the top of the front page, another size for on the corporate letterhead, and so on. But at small sizes such as you'd probably use on the web, the GIF will likely be smaller. It's pretty amazing, actually, how small a GIF image can be if it's only got a couple of colors in it, which is what you want anyway for a logo, usually, because you want to be able to produce versions of it for fax transmission forms, the shape of the hedges on the front lawn, screening onto tshirts, and so on and so forth.
But you don't want that 32x32 pixel GIF version of the image for the glossy-print brochures. It's a great delivery format for the website, but it's not such a great source format. SVG, OTOH, is a great source format.
[1] I say "for now", because for the forseeable future screen resolutions seem stuck at a few hundred pixels each way. It's easy to imagine that changing in the future, but in the last roughly fifteen years we've gone from 640x480 to, for most users, less than double those dimensions (or less than four times the total number of pixels on the screen), which is hardly impressive.
> Right, and the next thing you'll tell me is that the Earth isn't flat!
Let me guess: you're from Iowa? No, the Earth isn't flat. You should visit Pennsylvania or Kentucky sometime, and you'll see.
> And that the sun doesn't revolve around the earth.
Well, sort of. The Earth and the Sun exert the same force on one another, which causes the revolving to happen, so from one perspective it's possible to say that the Sun and the Earth both revolve around one another. But that ignores the pull of every other object that pulls on both of them... the Moon, by virtue of being quite a lot closer than the Sun, has quite a bit of influence on the Earth, even though it's smaller.
(You can verify that the Moon is smaller than the Sun, because in a solar ecclipse edges of the Sun still shine, around the edges of the Moon. Just don't stare at it directly; you have to use a mirror, or you'll turn into a Gorgon. HTH.HAND.)