Seriously, this would be a great idea. I'm partially red/green colourblind, and to me the amber and the green lights look the same. And I'm not alone - 10% of the male population have the same complaint.
Ah now that, that, is up to a judge, and who knows what a judge might decide (well, lawyers, and I'm not one, but I digress.) I agree that all involved would probably rather not get to that point.
Anyway, a Rose by any other name still renders pages as quick...
Of course you can. You can't have a blanket trademark on a word in all areas, but you can certainly trademark a word or association in an area of buisness. Computing for example.
For example, I recently wanted to use a Camel on a Perl website (not completed yet) and I had to consult O'Reilly, since they have a trademark on associating a camel with Perl. Other people can use camels for whaterver they want, it's just that they have a trademark when using it in conjunction with Perl. See the FAQ for more info.
I'm impressed a lot by your argument here, and I'm willing to say that you're right...maybe filenames should be case insensative. However, sadly in this world we're all not going to agree on things, and how much I might like to agree with you about the merits of HFS+, some people are still going to want case insensative systems.
I still argue it's a cultral thing. Many unix users would never sacrifice the ability to have case sensitive file systems as they'd die before taking functionality away from their system. You say "That you like to think of words on the computer as different than words anywhere else doesn't change the fact that this is a lousy interface decision for humans, because words are words even in a filename". However consider that to a Unix person having case insensitve files breaks their interface considerably. It's just inconsistant with every else that treats all things as strings. The -h option is not the same as the -H option. And yes, maybe this is wrong, but it's their culture that has set them up to do it.
What I'm trying to say here is that no matter what you might think of the idea being wrong, the people that use it arn't wrong themselves. They're just following a different set of guidelines. (Note, I don't mean to imply that you think they are or that you made this point...it's just a point that's worth making)
This reminds me of a debate I had about spaces in a file name. Now, I personally have no very stong feelings on the matter, but I can remember a Mac user complaining a lot about bad handling of spaces in a filename in Unix. Now, to be fair they're completely right in their opinion - unix does break horribly. What they're wrong in doing is considering that this is due to stupidity...it's not, it's a cultral thing. To the command line people a space isn't part of a file name unless it's properly escaped....it's a meta charecter that delimits the edge of commands and file names. It's a hang over from using the CLI too much...
And yes, you could consider this bad and wrong (especially in the day of the GUI,) but it's a convention that's sprung up over time...like double clicking, or anything else that you can't really draw a comparision to the real world.
Oh, and on a personal note, thanks for the debate...it's not often you get sensible replies on slashdot;-)
Actually, you're the fool to think this has anything to do with power
Hey, I never denied I was a fool;-)
What is it with the ability to have the files Grok, grOk, GRok, and grOK in the same directory that gives you a sense of power?
Nothing. But I wasn't talking about having lots of files named/Grok/i, I was talking about a more general situation.
My point was (and still is) that in a Linux sense having case sensitivity is thought of as more powerful system as there isn't a arbitary restriction placed on you by the operating system. (you can always do the case munging in user space if you really want.) The counter argument from HFS+ fans is that the filesystem is better as it's more powerful - look, it has these power features like ignoring cases on reads.
Until Linux users can recognise the design decisions were made for valid reasons for the Mac (and vice versa) we'll never get anywhere. Yes, you might not agree with them...but that's okay. You just have to accept that they have their reasons.
The same filename with different casing is still the same filename.
This is all dependant on your point of view. You're looking at the issue as someone who's used primarly to dealing with letters as words. Other people who are used to thinking of letters as codes for numbers may not agree with you. Neither of you is right - or maybe both of you are - it's just a different model of looking at it. It's a cultral thing.
Filenames ultimately are a small piece of metadata attached to a file for the sake of humans. If filenames were meant for computers the files would have names like 1, 2, 3, 4,..., 54654654,...
That's like saying domain names are just for humans to use and computers should just use IP addresses. This is clearly not true as if a computer needs to change IP and if there was no lookup system via the DNS then none of the other computers would be able to find it and it's resources again. Likewise if a computer needs to find a file resource then it looks it up by it's filename, not by an inode, as who knows what that inode might be on any particular system. Filenames, like domain names, are both human readable but are important for computers to find things too.
HEAD - send a http head request to a website and print the result
I have heard my Mac friends complain about the inability to use both commands on the same system, and the problems this has caused.
This is a thing about power. Traditionally Linux users think the power to do whatever they want is the most important thing. The Mac thinks that it's the power to get things done in the easiest way possible (even if you have to make a few edge cases harder - or impossible to do.) You'd be a fool to say either way was better than the other, as it really just reflects on your personal opinion which power is more important.
Can you explain to me what the difference between file IDs and a path name is please? They're both unique ids that point to a resource.
Remember that under unix you can have a symlink (like a shortcut but supported by the very OS rather than just by the file manager.) This can be used to point from your "file ID" (your unique path) to whereever you actually want the file.
This seems to me to be a much more user friendly way of doing things. Of course, you're more than welcome to disagree over that - it's one of those cultral things (you tend to like what you're used to) so of course people are going to say one system is better than the other and vice versa.
Yes, I've seen people do this. We're using ParseExcel and WriteExcel as our servers arn't running a Microsoft OS (and arn't near ones that are) and both these modules work file under FreeBSD.
Oh, you can do that...but I've come across numerous problems while doing this. For a start, you lose the metadata about cells (i.e. if it's a formula or a string or a number with $foo number of decimal places.) You have problems associated with using multiple workbook speadsheets (annoying if you've ever had to use them.) CSV is okay (and I've used it quite a bit) but it simply doesn't hold as much info as the original file.
Ignoring it is really too strong a word here. I was using the joke as a platform to make a lame joke about damian normally explaining everything that Larry says, and I thought I might as well dump some quick links in there for anyone who actually wants to know more.
Heaven forbid I try and be useful and share information on Slashdot. If that's karma whoring, then dammit I'm a karma whore.
To be honest, embedding html in your PHP is pretty much the same problem. It's about seperating out the content from the buisness logic. Essentially what you want is template files (containing just the html and a few 'stick this here' type statements) and code files (containing the stuff that does the heavy lifting and creates the data that will be stuck there.)
Of course, you can force yourself to do that with PHP, by limiting what you do in the actual HTML. Most people don't, but that's not the fault of the language.
Normally Damian Conway does a set of code examples based on what Larry's been saying. Maybe we could get him to do one for slashdot...
Seriously, if you want some explanation of what's been said then I can recommend:
Programming Perl
Larry and friends explaining about Perl 5. Big book, but nice and easy with lots of explanation about why things are done the way they are
The Perl 6 list
People asking questions about how Perl 6 will work, what's the changes are going to be, what's been written so far. There's a good summary on perl.com that's written once a week
The Apocalypses and Exegsis
How Perl 6 is changing from Perl 5 written by Larry and Damian. Also on perl.com.
Personally? Because I find that PHP is too powerful for an embedded language. You end up with this large chunks of code in the middle of your HTML making it really hard to maintain.
Give me a simple language like the Template Toolkit that can connect to a more powerful language (er, Perl) to do the difficult stuff any day.
Of course, you may disagree, and you're not stupid or evil for doing it. You just have a different point of view...I'm certainly not going to start bashing PHP.
Of course, wat I'm really waiting for is Parrot to be completed, both with the ability to run Perl 6 and PHP generated bytecode, so we can both use whatever we want, call each other's code all over the place, and play nice together...
Domain specific languages are really good. They allow you to think more about the task at hand than the task of getting the language you are using to do the task.
Of course, one such example of a domain language is the Template Toolkit which is a language that's inside out and designed to be used in places like webpages and config scripts. It's used in Slashdot, and written in Perl (and can call perl routines really easily called.) There's a good justification why not to use pure Perl in the template in the manual
Of course, come Perl 6 we'll be able to redefine our own grammers. By using a module (technically a grammer) we'll be able to dynamically switch in anohter rule (er, perl 6 regex able to match grammers) in the current scope to parse the current section - essentially our own little mini langauge.
Re:Concurrent/Distributed tasks
on
Ask Larry Wall
·
· Score: 2
It seems form your comments that you haven't
done any large scale enterprise programming.
If you want to discuss Perl then I can do that. I can't be arsed to reply to comments attacking me. The world is too short for flamewars.
Re:Concurrent/Distributed tasks
on
Ask Larry Wall
·
· Score: 2
How about the fact that CPAN won't work with it,
What do you mean by this? That the CPAN shell won't work with it? Yes, it does. That modules from CPAN won't work? In the majority they do. I'm not sure what you mean by "won't work." Give me something I can answer to.
and I wouldnt put money on mod_perl working with it either.
More importantly, camel three says "The Lord of the Rings by J.R.R. Tolkien
(most recent printing: Houghton Mifflin, 1999)."
Does it really have to be the most recent printing?
(The Perl CD Bookshelf and grep are cool toys to have)
Examples of doing inheritance and polymorphism
on
Ask Larry Wall
·
· Score: 3, Informative
INHERITENCE ===========
package Foo; use strict; use warnings;
sub new { my $class = shift; my $this = bless {}, $class; }
sub foo { "foo from foo\n" } sub bar { "bar from foo\n" }
package Foo::Bar; use base qw(Foo); use strict; use warnings;
sub bar { "bar from bar\n" }
-- later in a script
#!/usr/bin/perl
use strict; use warnings;
use Foo::Bar;
# call inherited methods from Foo my $foobar = Foo::Bar->new(); print $foobar->foo;
# call overloaded method from Foo::Bar print $foobar->bar
-- prints
foo from foo bar from bar
POLYMORPHISM ============
This is hard to describe...everything is polymorphic
my $foo = IO::File->new("bob",">") or die "Problem with file: $!"
# treat $foo as a IO::Handle, and print to it print $foo "hello";
Sorry, this is needed to defeat slash.
Please try to keep posts on topic.
Try to reply to other people comments instead of starting new threads.
Read other people's messages before posting your own to avoid simply duplicating what has already been said.
Use a clear subject that describes what your message is about.
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Slashdot Mirror
Seriously, this would be a great idea. I'm partially red/green colourblind, and to me the amber and the green lights look the same. And I'm not alone - 10% of the male population have the same complaint.
Anyway, a Rose by any other name still renders pages as quick...
It's been one week since you looked at trademarking
Threw your arms in the air and said 'It's crazy'
For example, I recently wanted to use a Camel on a Perl website (not completed yet) and I had to consult O'Reilly, since they have a trademark on associating a camel with Perl. Other people can use camels for whaterver they want, it's just that they have a trademark when using it in conjunction with Perl. See the FAQ for more info.
I still argue it's a cultral thing. Many unix users would never sacrifice the ability to have case sensitive file systems as they'd die before taking functionality away from their system. You say "That you like to think of words on the computer as different than words anywhere else doesn't change the fact that this is a lousy interface decision for humans, because words are words even in a filename". However consider that to a Unix person having case insensitve files breaks their interface considerably. It's just inconsistant with every else that treats all things as strings. The -h option is not the same as the -H option. And yes, maybe this is wrong, but it's their culture that has set them up to do it.
What I'm trying to say here is that no matter what you might think of the idea being wrong, the people that use it arn't wrong themselves. They're just following a different set of guidelines. (Note, I don't mean to imply that you think they are or that you made this point...it's just a point that's worth making)
This reminds me of a debate I had about spaces in a file name. Now, I personally have no very stong feelings on the matter, but I can remember a Mac user complaining a lot about bad handling of spaces in a filename in Unix. Now, to be fair they're completely right in their opinion - unix does break horribly. What they're wrong in doing is considering that this is due to stupidity...it's not, it's a cultral thing. To the command line people a space isn't part of a file name unless it's properly escaped....it's a meta charecter that delimits the edge of commands and file names. It's a hang over from using the CLI too much...
And yes, you could consider this bad and wrong (especially in the day of the GUI,) but it's a convention that's sprung up over time...like double clicking, or anything else that you can't really draw a comparision to the real world.
Oh, and on a personal note, thanks for the debate...it's not often you get sensible replies on slashdot ;-)
My point was (and still is) that in a Linux sense having case sensitivity is thought of as more powerful system as there isn't a arbitary restriction placed on you by the operating system. (you can always do the case munging in user space if you really want.) The counter argument from HFS+ fans is that the filesystem is better as it's more powerful - look, it has these power features like ignoring cases on reads.
Until Linux users can recognise the design decisions were made for valid reasons for the Mac (and vice versa) we'll never get anywhere. Yes, you might not agree with them...but that's okay. You just have to accept that they have their reasons.
This is all dependant on your point of view. You're looking at the issue as someone who's used primarly to dealing with letters as words. Other people who are used to thinking of letters as codes for numbers may not agree with you. Neither of you is right - or maybe both of you are - it's just a different model of looking at it. It's a cultral thing.
That's like saying domain names are just for humans to use and computers should just use IP addresses. This is clearly not true as if a computer needs to change IP and if there was no lookup system via the DNS then none of the other computers would be able to find it and it's resources again. Likewise if a computer needs to find a file resource then it looks it up by it's filename, not by an inode, as who knows what that inode might be on any particular system. Filenames, like domain names, are both human readable but are important for computers to find things too.
- head - get the first 'n' lines of a file
- HEAD - send a http head request to a website and print the result
I have heard my Mac friends complain about the inability to use both commands on the same system, and the problems this has caused.This is a thing about power. Traditionally Linux users think the power to do whatever they want is the most important thing. The Mac thinks that it's the power to get things done in the easiest way possible (even if you have to make a few edge cases harder - or impossible to do.) You'd be a fool to say either way was better than the other, as it really just reflects on your personal opinion which power is more important.
Can you explain to me what the difference between file IDs and a path name is please? They're both unique ids that point to a resource.
Remember that under unix you can have a symlink (like a shortcut but supported by the very OS rather than just by the file manager.) This can be used to point from your "file ID" (your unique path) to whereever you actually want the file.
This seems to me to be a much more user friendly way of doing things. Of course, you're more than welcome to disagree over that - it's one of those cultral things (you tend to like what you're used to) so of course people are going to say one system is better than the other and vice versa.
Yes, I've seen people do this. We're using ParseExcel and WriteExcel as our servers arn't running a Microsoft OS (and arn't near ones that are) and both these modules work file under FreeBSD.
- Spreadsheet::WriteExcel
- Spreadsheet::ParseExcel
(there are also simpler interfaces if you want them too.)Or you could go the whole hog and use a SAX writer like XML::SAXDriver::Excel to create the documents from XML yourself.
(This is not to say I don't think XML native formats arn't cool and will have many uses, I'm just pointing out what you can do now.)
I'd also recommend looking at YAML
Heaven forbid I try and be useful and share information on Slashdot. If that's karma whoring, then dammit I'm a karma whore.
Of course, you can force yourself to do that with PHP, by limiting what you do in the actual HTML. Most people don't, but that's not the fault of the language.
Thanks for the link...I'll have a look at it.
Seriously, if you want some explanation of what's been said then I can recommend:
- Programming Perl
- The Perl 6 list
- The Apocalypses and Exegsis
- The Perl Beginners list
(side note: Why doesn't slashcode let me do definition lists in HTML?)Larry and friends explaining about Perl 5. Big book, but nice and easy with lots of explanation about why things are done the way they are
People asking questions about how Perl 6 will work, what's the changes are going to be, what's been written so far. There's a good summary on perl.com that's written once a week
How Perl 6 is changing from Perl 5 written by Larry and Damian. Also on perl.com.
High traffic, but good. From the lists page: http://lists.perl.org/
Give me a simple language like the Template Toolkit that can connect to a more powerful language (er, Perl) to do the difficult stuff any day.
Of course, you may disagree, and you're not stupid or evil for doing it. You just have a different point of view...I'm certainly not going to start bashing PHP.
Of course, wat I'm really waiting for is Parrot to be completed, both with the ability to run Perl 6 and PHP generated bytecode, so we can both use whatever we want, call each other's code all over the place, and play nice together...
Of course, one such example of a domain language is the Template Toolkit which is a language that's inside out and designed to be used in places like webpages and config scripts. It's used in Slashdot, and written in Perl (and can call perl routines really easily called.) There's a good justification why not to use pure Perl in the template in the manual
Of course, come Perl 6 we'll be able to redefine our own grammers. By using a module (technically a grammer) we'll be able to dynamically switch in anohter rule (er, perl 6 regex able to match grammers) in the current scope to parse the current section - essentially our own little mini langauge.
(This joke refers to: this movie.)
Or, if you're in London tomorrow, you can pop along to Conway hall and see Damian speak, and give him a donation then and there.
(The Perl CD Bookshelf and grep are cool toys to have)