There are better wordsmiths than Bujold, and she isn't terribly good at naming her characters, but nobody beats her when it comes to illuminating the human soul. In a century full of arrogant writers, she has been the one humble enough to let her characters live their own lives, however painful it might be to those of us looking on. When I read Bujold, I understand myself better.
Well then, Fatal.pm handles the other 50% of your quibble. But the "or die" idiom of Perl is nice in that it encourages the programmer to come up with a meaningful error message that is associated directly with the failing statement. An exception handler can guess about which statement threw the exception, but unless you're going to put an exception handler around every statement, it might guess wrong, and add a bogus message that would be negatively helpful.
At the same time, the "or die" idiom pushes the exceptional code off to the right where it doesn't obscure the intent of the flow very much.
Especially given the dozen or so little shell scripts and perl programs that have
since popped up, all of them ramshackle "baby's first program"-caliber triumphs.
Oh, not all of them are entirely ramshackle. Here's a Perl version suitable for framing:
Could we hold VA shareholder meetings on Slashdot?:-)
Seriously, most of the shareholders who care about open source have rather small amounts of stock individually, but collectively they could be a sizable voting bloc, perhaps large enough to keep the more, um, predatory stockholders at bay. I doubt that ordinary proxy voting will work to keep the bloc together, since many of the small investors will never turn in their proxy ballots. At the risk of using an overused word, is there any way to innovate in this area, or are we locked in to tradition?
curious... I understand why it is a great example of a successful free software project, but why is it a successful demonstration of open source?
Perhaps because its source is open? What does open source mean to you? Perl is certainly OSD compliant...
It seems that larry wall and people (of his choice) have done all of the development. The only thing I can think of is that it has been ported to so many platforms.
Gee, a lot of people think Larry has been terribly unselective in who he lets hack on Perl. Go figure.
Seems to me that you don't think open source is open source unless the code in question has been haggled over by people with differing ideas as to its future. If that's the criterion, then Perl is definitely open source. But it doesn't have to prove it by forking. What would be the use of that? Most forks are done to stoke egos, and the Perl community would like to think it is beyond that level of egotism.
I think that makes it a better example of open source than most.
Dynamic scoping. I'm aware of the existence of 'my', but having two different scoping mechanisms (one of which just shouldn't be used but is nonetheless the default) is an undeniable crock.
But it's a very small crock. It's trivial to make lexical scoping the default when you want it to be.
Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language.
It's just another form of interpolation, which is a very powerful feature. And doing lists of lists in any language requires a fairly sophisticated understanding of that language, and of computer science in general. Computer scientists love their trees, but lose sight of the fact that most ordinary folks prefer flat data structures most of the time.
To add insult to injury, there's no simple way of naming the parameters of a function.
You mean there's no required way. It's certainly possible to name your parameters in Perl, and not particularly complicated. In fact, parameter passing in Perl is very easy to explain precisely because you don't have to name your parameters if you don't want to. The fact is, compared to other languages, Perl's parameter passing scheme is rather orthogonal, relying as it does on the existing notion of arrays, rather than introducing extra syntax.
Even Scheme has this -- and it's the sort of language that gives you sand and a fire if you want a wineglass!
So you're complaining that Perl is more orthogonal here than Scheme. Cool!
The syntax. One of the persistent-but-wrong claims about Perl is that having lots of syntax is an indication of how the Perl culture values having more than one way to do things. In fact, much of Perl's syntax is just pointless complexity.
Pointless to some people who don't optimize for the same things other people do...
Syntax is helpful when it distinguishes different semantic domains; it is a bad thing when dissimilar ideas are conflated or when there are similar ideas with wildly different spellings.
Can't disagree with the platitude. However, people have the durndest ideas about which ideas are similar and which ones are different. Perl conflates the things it thinks most people want conflated, and doesn't stress about the others.
For example, why is 'eval' used to denote exception handling?
Why not? Doesn't the English word "evaluate" indicate some degree of suspicion as to the results?
Why are references to aggregates prefixed with a '$'?
Because what is really being referred to isn't the aggregate.
How come packages and classes are defined with the same syntax?
Seems like another place where Perl is being orthogonal and economical.
There are answers to all of these, but those answers are historical rather than meaningful.
Really? You think that history is not meaningful? You think that if someone thought something out ten years ago, the logic is no longer valid? What exactly do you mean by that?
Cars used to have reins in the early 20th century, but no one would argue that they belong on a car for the 21st.
And indeed nobody is arguing for reins. Perl left out a lot of reins to begin with, but kept the wheels. We're currently arguing about whether the clutch pedal should be mandatory or optional.:-)
In order to properly support having an sophisticated syntax, the right thing to do is to have a facility for syntactic extension like Lisp macros.
Ok: I think Perl is a badly designed language that makes programming in it harder than it should be. Here's why.
You have a strange definition of "harder". Most people who like Perl seem to find it easier than it should be.:-)
First, the type system, or more precisely, the lack of one. Values are not type-safe, in the sense that they can change meaning based on the context they show up in (eg, strings and numbers).
Perl is typesafe where it's important, and not typesafe where it's not important. Perl is actually quite picky about structural type issues, but purposefully mushes together the types that most people want to mush together. This is a feature. Most people don't want to think about whether a number happens to be represented as a byte or a short or a long or a float or a string. Most people just want to get their work done.
Please note that I'm not talking about dynamic versus strong typing: I'm talking about the types of values. Common Lisp and Smalltalk are both dynamically typed, but a value in either language always has a well-defined type. When you want to change the type of a value you do it explicitly.
Sometimes this is a feature, and sometimes it's not. Perl is about balancing computer science with a bit of common sense.
An example of how this problem complicated the design of Perl is the need for two sets of operators to distinguish whether you are treating a scalar as a string or a number. In a language with well-defined types, it's trivial to overload operators so they do the right thing polymorphically -- look at Cecil's generic function mechanism for an example of how this works.
So? By and large that's an undesirable feature. Any language that forces the programmer to overload the commonly used operators forces the reader of the program to disambiguate those overloaded operators. This is an area where Perl is more readable than the typical language. Things that are different should look different, and Perl just applies this to operators as well as to data structures.
You seem to assume that Perl is the way it is out of ignorance of the typical tenets of computer science. That's not generally true in the ways you seem to think it's true.
Note that the figures are botched at the beginning. The first figure is supposed to be about combining Linguistics, Computer Science, Common Sense, and Art.
I think the thing that makes Perl a great hack is that it's not just a computer hack or a language hack, but also a subversive cultural hack. It turned Unix philosophy inside out and made it portable to other platforms. There was an article about the subversive history in Perl in a recent ish of Linux Magazine, but it doesn't seem to be online yet.
I also found that peculiar. While there are certainly religious and rational people, the great majority of religious people I encounter are actually NOT rational about it.
I don't think it's all that peculiar, and I doubt the Professor finds it all that peculiar either. The great majority of NON-religious people are also not rational about it. Most folks find it profoundly disturbing to think about the syllogism that, if there is a God, he might have an opinion about how we should live.
Most agnostics are not really agnostics, they're antignostics. It's not that they don't know, it's that they don't want to know.
By and large, I find that the percentage of irrational geeks matches up with the percentage of irrational people. The irrationality just shows up in different ways in different groups. What's really, really irrational in my book is to judge the goodness of something by whether smart people or stupid people are associated with it. You can't judge anything by whether bozos are associated with it, because bozos are associated with everything.
Slashdot Mirror
Oddly enough, that's precisely what's happening. It's amazing how spontaneous programmers can be.
Please tell me these machines don't have a PCMCIA slot...
Larry
There are better wordsmiths than Bujold, and she isn't terribly good at naming her characters, but nobody beats her when it comes to illuminating the human soul. In a century full of arrogant writers, she has been the one humble enough to let her characters live their own lives, however painful it might be to those of us looking on. When I read Bujold, I understand myself better.
Well then, Fatal.pm handles the other 50% of your quibble. But the "or die" idiom of Perl is nice in that it encourages the programmer to come up with a meaningful error message that is associated directly with the failing statement. An exception handler can guess about which statement threw the exception, but unless you're going to put an exception handler around every statement, it might guess wrong, and add a bogus message that would be negatively helpful.
At the same time, the "or die" idiom pushes the exceptional code off to the right where it doesn't obscure the intent of the flow very much.
Because it is not there.
Please allow for the fact that the interviewer probably speaks English much better than you speak Japanese. :-)
Oh, not all of them are entirely ramshackle. Here's a Perl version suitable for framing:
#!/usr/bin/perl -n
printf "Serial: %sType: %sCode: %s\n", /\.([^.]+)/g;
map {
tr/a-zA-Z0-9+-/ -_/;
$_ = unpack 'u', chr(32 + length()*3/4) . $_;
s/\0+$//;
$_ ^= "C" x length;
}
See http://www.wall.org/~larry/natural.html .
Seriously, most of the shareholders who care about open source have rather small amounts of stock individually, but collectively they could be a sizable voting bloc, perhaps large enough to keep the more, um, predatory stockholders at bay. I doubt that ordinary proxy voting will work to keep the bloc together, since many of the small investors will never turn in their proxy ballots. At the risk of using an overused word, is there any way to innovate in this area, or are we locked in to tradition?
Perhaps because its source is open? What does open source mean to you? Perl is certainly OSD compliant...
It seems that larry wall and people (of his choice) have done all of the development. The only thing I can think of is that it has been ported to so many platforms.
Gee, a lot of people think Larry has been terribly unselective in who he lets hack on Perl. Go figure.
Seems to me that you don't think open source is open source unless the code in question has been haggled over by people with differing ideas as to its future. If that's the criterion, then Perl is definitely open source. But it doesn't have to prove it by forking. What would be the use of that? Most forks are done to stoke egos, and the Perl community would like to think it is beyond that level of egotism.
I think that makes it a better example of open source than most.
Dynamic scoping. I'm aware of the existence of 'my', but having two different scoping mechanisms (one of which just shouldn't be used but is nonetheless the default) is an undeniable crock.
But it's a very small crock. It's trivial to make lexical scoping the default when you want it to be.
Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language.
It's just another form of interpolation, which is a very powerful feature. And doing lists of lists in any language requires a fairly sophisticated understanding of that language, and of computer science in general. Computer scientists love their trees, but lose sight of the fact that most ordinary folks prefer flat data structures most of the time.
To add insult to injury, there's no simple way of naming the parameters of a function.
You mean there's no required way. It's certainly possible to name your parameters in Perl, and not particularly complicated. In fact, parameter passing in Perl is very easy to explain precisely because you don't have to name your parameters if you don't want to. The fact is, compared to other languages, Perl's parameter passing scheme is rather orthogonal, relying as it does on the existing notion of arrays, rather than introducing extra syntax.
Even Scheme has this -- and it's the sort of language that gives you sand and a fire if you want a wineglass!
So you're complaining that Perl is more orthogonal here than Scheme. Cool!
The syntax. One of the persistent-but-wrong claims about Perl is that having lots of syntax is an indication of how the Perl culture values having more than one way to do things. In fact, much of Perl's syntax is just pointless complexity.
Pointless to some people who don't optimize for the same things other people do...
Syntax is helpful when it distinguishes different semantic domains; it is a bad thing when dissimilar ideas are conflated or when there are similar ideas with wildly different spellings.
Can't disagree with the platitude. However, people have the durndest ideas about which ideas are similar and which ones are different. Perl conflates the things it thinks most people want conflated, and doesn't stress about the others.
For example, why is 'eval' used to denote exception handling?
Why not? Doesn't the English word "evaluate" indicate some degree of suspicion as to the results?
Why are references to aggregates prefixed with a '$'?
Because what is really being referred to isn't the aggregate.
How come packages and classes are defined with the same syntax?
Seems like another place where Perl is being orthogonal and economical.
There are answers to all of these, but those answers are historical rather than meaningful.
Really? You think that history is not meaningful? You think that if someone thought something out ten years ago, the logic is no longer valid? What exactly do you mean by that?
Cars used to have reins in the early 20th century, but no one would argue that they belong on a car for the 21st.
And indeed nobody is arguing for reins. Perl left out a lot of reins to begin with, but kept the wheels. We're currently arguing about whether the clutch pedal should be mandatory or optional. :-)
In order to properly support having an sophisticated syntax, the right thing to do is to have a facility for syntactic extension like Lisp macros.
That's probably the right way for you. TMTOWTDI.
You have a strange definition of "harder". Most people who like Perl seem to find it easier than it should be. :-)
First, the type system, or more precisely, the lack of one. Values are not type-safe, in the sense that they can change meaning based on the context they show up in (eg, strings and numbers).
Perl is typesafe where it's important, and not typesafe where it's not important. Perl is actually quite picky about structural type issues, but purposefully mushes together the types that most people want to mush together. This is a feature. Most people don't want to think about whether a number happens to be represented as a byte or a short or a long or a float or a string. Most people just want to get their work done.
Please note that I'm not talking about dynamic versus strong typing: I'm talking about the types of values. Common Lisp and Smalltalk are both dynamically typed, but a value in either language always has a well-defined type. When you want to change the type of a value you do it explicitly.
Sometimes this is a feature, and sometimes it's not. Perl is about balancing computer science with a bit of common sense.
An example of how this problem complicated the design of Perl is the need for two sets of operators to distinguish whether you are treating a scalar as a string or a number. In a language with well-defined types, it's trivial to overload operators so they do the right thing polymorphically -- look at Cecil's generic function mechanism for an example of how this works.
So? By and large that's an undesirable feature. Any language that forces the programmer to overload the commonly used operators forces the reader of the program to disambiguate those overloaded operators. This is an area where Perl is more readable than the typical language. Things that are different should look different, and Perl just applies this to operators as well as to data structures.
You seem to assume that Perl is the way it is out of ignorance of the typical tenets of computer science. That's not generally true in the ways you seem to think it's true.
Note that the figures are botched at the beginning. The first figure is supposed to be about combining Linguistics, Computer Science, Common Sense, and Art.
I think the thing that makes Perl a great hack is that it's not just a computer hack or a language hack, but also a subversive cultural hack. It turned Unix philosophy inside out and made it portable to other platforms. There was an article about the subversive history in Perl in a recent ish of Linux Magazine, but it doesn't seem to be online yet.
I don't think it's all that peculiar, and I doubt the Professor finds it all that peculiar either. The great majority of NON-religious people are also not rational about it. Most folks find it profoundly disturbing to think about the syllogism that, if there is a God, he might have an opinion about how we should live.
Most agnostics are not really agnostics, they're antignostics. It's not that they don't know, it's that they don't want to know.
By and large, I find that the percentage of irrational geeks matches up with the percentage of irrational people. The irrationality just shows up in different ways in different groups. What's really, really irrational in my book is to judge the goodness of something by whether smart people or stupid people are associated with it. You can't judge anything by whether bozos are associated with it, because bozos are associated with everything.
Larry Wall