In Perl 6, it would depend on what type $foo was. If it was an integer, then your initial assignment would set it to zero, and then the second statement would make it one.
If you never assign it a type, then it defaults to a fully-functional scalar and behaves much as a Perl 5 scalar would.
You can define syntax on the fly. What *will* happen for backward-compatibility is that certain Perl 5 features will be searched for, and those features will initiate a Perl 5 mode. For libraries this is easy ("package foo" is the first thing in every Perl 5 module), but in general-purpose code you have to get a little more context-sensitive.
However, there will of coruse be a command-line flag for "just do Perl 6", so you might write
#!/usr/bin/perl -6 use syntax::bash; if [ -e/etc/passwd ]; then
echo "passwd looks good." else
echo "erorr: no passwd" 2>&1
exit 1 fi
No, I pointed out a few already, and there are others. You simply happen to disagree. That's fine too. Perl is about accomodating disagreement in a single language, and that's hard to do with a limited keyword set.
You're carrying type-information around everywhere you go, because you think it allows you to add keywords
I've pointed out elsewhere that type information and variable glyphs are different. They do have an association to type, but it's a loose one.
Here you have three variables. One is a simple scalar. One is a reference to an array. One is an object that represents a socket, connected to the HTTP port of a remote server. The $ doesn't tell you a whole lot about type, it just indicates a scalar access-mode.
Do you know why C doesn't add new keywords
*I do*, but I wonder if you do....
C does not add new keywords because it is a syntactically simple language, and that's part of its attraction. Any attempt to change that (e.g. the way C++ did) would destroy that, and would need to justify such a change against the benefit.
I think that Perl does justify this increase in complexity, though to most outsiders that's not obvious. You really need to be able to think in Perl before you understand just how valuable all of that syntax is.
At one point, I knew C so well that I thought in it. That was long ago, but I still remember how powerful that was.
When I learned Perl well enough to think in it, I was introduced to a new kind of programming. I was suddenly able to write in a few lines of code, what would have taken pages and pages of C, even with a good set of libraries. Just the ability to say:
That's not to say C is useless. I still use it from Perl all the time, via XS. If I had to write a device driver or any other low-level code, I would still use C. But for your run-of-the-mill software, Perl is leaves low-level languages, and even most high-level languages far behind... at least from my, admittedly limited, point of view.
Speak in favor of Fortran, please do. It was a language that was hobbled by some of the physical limitations of the day, but still it was a wonderful language.
COBOL was a product of its environment, and could never have been a good language. If it had been, that would have defeated the point:-(
But, no. C has become SO widely used in the world that it has eclipsed even COBOL at this point. Just your avergage Open Source distribution has more C code than what was produced at 90% of the banks out there (of course, those 10% cranked out some amazingly vast code). The various C-based software for embedded systems, etc keep the pace going, and then you have other free operating systems, proprietary OSes, content management systems, telementry data managers for satellites, elevator control systems, mathematical simulation systems, payroll management software, etc, etc.
About the only think I could imagine coming close at this point is JavaScript, and that's only because there are so many page generators out there that spit out HTML with JavaScript embedded....
That does not seem very nighmarish to me. What's more, manipulating complex data on the fly is trivial in Perl:
$struct = [1, 2, 3, { a => [5, 6, 7], b => [8, 9, 10]}]
which would be an array of 4 elements, of which the fifth element is a hash of two elements, the values of which are themselves arrays. Not that hard is it?
There is the container-access syntax that I find rather messy, but even that's not so bad, and it goes away in Perl 6 entirely, again without impacting that very clean way of identifying variables that lets you do things like
$foo = "dogs"; $bar = "cats and $foo"; $baz = qr{($bar)+}; while(<>) {
if (/$baz/i) {
print;
} }
I would agree with the text that you cited, right up until he talks about the opposite.
The two are equally important, and both are critical to a good technical book. You cannot have a good tecnical book that is poorly written. You simply cannot.
I remember the original X reference set from O'Reilly, and the whole reason that they were a success was that they were essentially duplicates of the online X documentation, which was some of the best written toolkit documentation, ever.
Had those been just as technically accurate, but even just a little harder to navigate and use, they would have been nearly useless, given the complexity of the topic.
You have a good point at the end about expressions. I was being a bit too restrictive. I disagree with you elsewhere. Perhaps some compilers do what you suggest, but GCC allows for FILE* to iostream conversion in ways that ANSI C++ does not, and I don't call that C++ either.
You seem to only focus on where we disagree, so I'm going to let this one go for now. I do agree with you that Lisp is a flexible and powerful language. I think it was a shame that Perl only started to adopt some Lispisms as of version 5, and will have to wait until version 6 to "go all the way" as it were.
As of Perl 6, I don't think Perl and Lisp will have any major differences that don't result from the choice of syntax. The flexibility and functionality is all there.
As I said in the other reply, I thought macros were being held off until the grammer building system in Perl 6 was better fleshed-out. I haven't read A6 yet, only the stuff that Larry wrote leading up to it and a little bit of the chatter after, so I wasn't aware that had snuck in.
lisp is actually more of a truly compiled language than perl
Yes, and no. First off, don't assume that I don't know Lisp. I try to hide it at work because I have so many co-workers working in Lisp, and a basic working knowledge is actually more of a handicap in this crowd than ignorance....
Lisp is never truely compiled. It can be compiled down to machine code, but you always have to keep the S-expressions around, just as you keep a non-static inline function around in C or C++, except in C and C++ that copy that you keep is compiled. In Lisp it must not be!
Hence, my comment about Perl 6 (not Perl, BTW, which I use generically to refer to any version of Perl that has actually been released, and I say Perl 5 when I mean Perl 5) getting as close as any truly compiled language reasonably can. Perl 6 will not retain its syntax tree post compilation, and *that* is why I call it a truely compiled language. There *may* be byte-code, but that's a function of the back-end depending on if you're using a VM like parrot or compiling to machine code.
If you re-read my comment, you'll find that it was not a slam against Lisp. I like and respect Lisp. If you can only see languages as polar extremes, then I don't think you'll enjoy Perl 6.
Secondly, this Exegesis covered Perl6's macro capabilities. It works very much like lisps, actually.
No, not really. It looks similar, and in as far as most people will use them, they will be similar.
I had not actually realized that A6 had snuck macros in. I thought that Larry said he was defering them for later. Then again, I've been off the list for a while, concentrating on work, so it's good to see so much happened.
Still, macros in Perl 6 are a feature of Perl 6's built-in parser generator features (the replacement for regular expressions, and a first in general purpose programming languages, as far as I know, but there may be an expert system shell that provided something like this level of integration with the core language).
In Lisp, macros are expression constructors that return a lambda. Very, very different, though similar in application.
All in all, if this can be implemented as they have described, in an efficient manner, I will be impressed. It seems very lispy to me
Not really, like I say, it's more like SNOBOL or Prolog than Lisp.
Anyway, you are totally wrong, every object in C# is derived from 'object'. Same as VB.NET. Same as Managed C++
I think you're talking about the object model of the.Net runtime, and that's fine, but.Net runtime is not a language, and its objects are not language primatives.
To give an example of C++, and then discuss what is effectively an RPC-based library's object model is way, way beyond the scope of the original conversation.
Like I said before, this is not a unique feature to one, or even a dozen toolkits, languages, etc in the last 10 years. You're not citing something that originated with the example that you are citing. I was responding to an assertion of yours that you seem not to really be talking about any more, so I'm going to drop this thread.
Much of Lisp's flexibility comes from having programs represented in the same form as data (S-expressions)
That's the part that Perl does not have, and never will (though Perl 6 comes as close as a truely compiled language reasonably can). However, most Lisp code really doesn't benefit from this fact as much as it does from its side effects.
Let me give you an example. One side effect of what you describe is lambda functions, and a cool feature distinguishes lambda functions from simple function pointers in C is closures.
Perl provides the equivalent of Lambda functions in the form of anonymous subroutines, and they are also closures.
So, while you are correct that much of the flexibility of lisp falls out of S-expressions, it's not true that you cannot have that flexibility WITHOUT S-expressions.
What Lisp *does* have that Perl 5 does not is an excellent macro mechanism (which also falls out of S-expressions).
That is probably the one major thing that Perl 6 will need in order to truely surpass Lisp's flexibility for general purpose tasks, and while it has been much discussed on the mailing lists, it won't be realistic to decide on it, and nail it down fully for a few itterations of the apocolypses. But it's certainly clear that Perl needs some form of macro system that is at least very nearly as flexible as Lisp's.
Perl's eval is a red-herring. It's really a totally different (pair of) functions from Lisp's eval, acting as either parser or exception-handler. Lisp's eval is much more comparable to Perl 5's ->() operator which dereferences and executes a code reference which can be a reference to an anonymous or named closure, a subroutine or a regular method.
You can also build CVs, which are just data-structures, in C and present them to Perl as a code reference. That does give you all of the power of Lisp, but you have to drop down to C to do it, so it isn't at all trivial or useful for routine use.
Sorry, I meant "empty" in the sense of "undefined".
As you can see, I've sent too much time in high-level languages like Perl, where the two states can be distinguished, but are interchangable without error.
if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!
Ok, first off... Perl 6 will use Unicode by default, of course, and yes there is some talk of using things like the dot-product symbol to mean roughly what you would expect it to mean. However, that is limited by the practicality of entering and viewing Unicode characters with modern equipment. Perhaps in another 10 years....
Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).
You already had the $,@,%,& to prefix variables with.
But in Perl 6, they are rationalized a great deal, and made simpler to use (e.g. Perl used to use the glyph to indicate the type of operation being performed on a variable, no the type of the variable. In Perl 6, that has been changed to reflect what most programmers expect, so @foo[0] is the correct notation for accessing the zeroth element of an array, not Perl 5's $foo[0]).
Perl 6 is going ot be hard for outsiders to jump into at this stage because it doesn't exist yet. If you're not steeped in the culture of Perl 6's design, you won't be able to see where it's going, so everything looks kind of scary.
However, in about 10 years, I expect Perl 6 to be seen as the starting point of a new kind of programming and a level of symbolic abstraction that allows us to start looking at code in a much more constructive way.
Anyway, it looks like *somebody* is getting defensive about being a script programmer
Not at all. I'm simply not.
When I spend most of my day working on libraries that are used by a suite of tools, each of which is as modular and re-usable as possible, I find it hard to refer to that as "script programming".
The gulf between those two jobs is about as wide as the gulf between Web Master and C# programmer.
I meant any language that.NET supports... VB.NET, C#, J#, etc.
Then you are incorrect, since.Net also supports many languages which do not share this typing system. The.Net libraries may use that typing system internally, but that's because they are written in, or at least primarily written for C#.
Again, you are making a broad an inaccurate comparison between vastly different scopes.
There is absolutely no chance that either time or vtime would be keywords in any version of C
You make this assertion (which I can't understand the origin of), but then say:
C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny
Um... so, it's not "absolutely no chance", but "tiny".
You're sort of thinking about this backwards. The question is not "when a new keyword is added, will my variable name be one of them", but "in my giant project and all of the myriad libraries on which it depends, will any of that code break, when a new version of C introudces a keyword." From my prior experience in fixing code with exactly this problem, I can say "yes" with a high degree of certainty.
Perl's solution is, in my opinion, like taking a baseball bat to a cockroach
Bad metaphore, and again, you're looking at it upside down. How dangerous is it to add a keyword in C? Pretty huge, right? So the result is that you don't add keywords very often.
In Perl however, it's much less painful because of this "baseball bat", so Perl adds keywords where they are needed, rather than where they are unavoidable.
Keep in mind, I'm a fan of C (not C++) and Perl both, so this is not a language war, I'm just pointint out a relative merit of Perl's way of doing things. C has its own merits in sufficient quantity to make it the single most widely use language in history.
Having a weakly typed language is not an advantage
You're confusing variable glyphs with typing. While variable glyphs in Perl do indicate something about the typing, they are not type identifiers.
I was pointing out the advantages of glyphs, not types.
Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever
Script is a misused word here, since the term litterally means a collection of commands as a user would have typed them, and while you can write Perl code that looks kind of like that, it's certainly not the way Perl is used). Shell programs aren't even always scripts (just look at your average configure program). Don't contribute to watering down the word, especially if you're just doing so to make the "what makes us real programmers special" weak assertion.
Ok, that said, Perl does offer typing, but only when you really need it. Since strong typing isn't needed in perl by default (Perl 5 and under have no real compilation mechanism, so the performance gains would be minimal), all you really need is to type *data* not *variables*.
You can type data using any number of tools in Perl including pack, unpack, sprintf and vec.
In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler. This introduces the need to access system types in a more rigorous way, and Perl 6 has typing features such as you would find in any other language. Of course, $x = $y will still work regardless of types (though it could cause a compile or run-time error if they are excplicitly incompatible, but that's not going to happen unless you really mean for it to)..NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?
That's the approach of about 5-10 DOZEN languages (literally) over the last 10-20 years. Let's not credit C# with the "innovation" of objects as the only first-class data types (I assume you mean C#, since.Net isn't actually a language, but a Microsoft product that encompasses the.Net runtime, which in turn encompases C#... kind of like calling Java JSP).
Perl 6 is going down the same route as did Python (long before C#).
Perl 5 has fairly primative roots, and given those roots its typing system made sense at the time. Perl 5 does also have a universal base-class for all objects, but not all types are objects in Perl 5. They will be in Perl 6.
Normally, I would not reply to a troll, but this one allows me to bring up an interesting point for those polarists that think Perl and Python are somehow diametrically opposed.
While they certainly have different approaches to language design, Parrot (the Perl 6 back-end) will have front-ends for many languages. One of them will, in fact, be Python.
So, will everyone "then use Python", well perhaps, but if they do, they'll be using Perl 6;-)
Yes, as you note there's a bug in the example. Rushed slashdot posts, go figure.
Still, I disagree with this notion that you present (and every Strostrup appologist I've ever heard tackle this one has presented). Think back, and imagine that these are the days when no one had heard of C++ yet, and C was it.
Back then, there was no ambiguity. Every book ever written was of the form: int i, *j, k[200]; and everyone got exactly what that meant and why. It was good, common and expected programming practice to declare a set of variables of similar basic type that way as long as declaring them together wasn't semantically misleading to someone who would read the code.
Only in the face of Dr. Bjorn's evil char* s did people start to think that declaring multiple variables on a line was somehow evil (circa 1990 is when I first heard that claim).
So, it was in fact horrible form for an author to write code like that. There was nothing wrong with the way C worked, nor the way C++ would have worked, had he not conventionalized that broken usage.
When I program in C++, I keep the asterisk with the variable name, because that's how the compiler sees it, and any other usage would be misleading.
Heehee, kind of cool, as someone pointed out, that gcc just cleaned up my mess for me, there.
Dumb me, I forgot to malloc.
Still and all, you get the idea, and there's no flaw in the part of the code that I was attempting to test, so much as the use of the pointer (always my weak point in C, which is why I use high level languages now).
Perl has keywords picked up from C (for, if, while, int, printf, etc.); BASIC (substr); Modula (module); CPP (defined); and many other sources. It's very much a post-modern language in the sense that it seeks to deconstruct all other languages and re-build itself in their images without actually being just a collage of their parts.
HOWEVER, that being said Perl has a huge advantage over the keyword restrictions of most languages. I'll show you a sample of some code, and you tell me if you can see what the advantage is:
The same goes (to a slightly lesser extent, since you don't *have* to use the prefix-sigle &) for subroutines and all of the other miscelaneous Perl data types that can be named (obviously those that cannot be named like stashes never conflict with a keyword).
Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
You are exactly correct, and I have no idea what the original poster's problem with it was.
[ajs@put/tmp]$ cat >/tmp/c.c #include <stdio.h> void main(int argc, char *argv[]) {
int i, *j;
i = 1;
*j = 2;
printf("i=%d, j=%d\n", i, *j);
exit(0); } [ajs@put/tmp]$ gcc -o/tmp/c-test/tmp/c.c /tmp/c.c: In function `main': /tmp/c.c:3: warning: return type of `main' is not `int' [ajs@put/tmp]$/tmp/c-test i=1, j=2
Perhaps he was thinking of "int *i, j" which isn't all that bad in terms of confusion until you started seeing stroustrup's style, which I *hated* from day one of, "int* i" which of course lead to people using, "int* i, j".
You can write badly obfuscated code by abusing visual association in just about every language, but this particular gotcha should have tipped off Stroustrup VERY early on that his style was agegeously misleading, and a good technical editor should never have let him publish a book with such incomprehensible gibberish.
That very thing is one of the primary reasons I didn't use C++ for years (not to mention that I regretted it when I did). My thinking was that if the creator of the language didn't see how damaging it was to introduce confusion in his published writing, then he wasn't likely to avoid such in a programming language. I think ANSI C++ stands as a monument to the correctness of my thinking on that point!
Slashdot Mirror
In Perl 6, it would depend on what type $foo was. If it was an integer, then your initial assignment would set it to zero, and then the second statement would make it one.
If you never assign it a type, then it defaults to a fully-functional scalar and behaves much as a Perl 5 scalar would.
You're comparing apples and oranges.
This has been an advantage of Perl since it's very first release.
What you're talking about (compatiblity betwen 5 and 6) is neither mitigated by, nor a result of that feature.
You can define syntax on the fly. What *will* happen for backward-compatibility is that certain Perl 5 features will be searched for, and those features will initiate a Perl 5 mode. For libraries this is easy ("package foo" is the first thing in every Perl 5 module), but in general-purpose code you have to get a little more context-sensitive.
However, there will of coruse be a command-line flag for "just do Perl 6", so you might write
No, I pointed out a few already, and there are others. You simply happen to disagree. That's fine too. Perl is about accomodating disagreement in a single language, and that's hard to do with a limited keyword set.
You're carrying type-information around everywhere you go, because you think it allows you to add keywords
I've pointed out elsewhere that type information and variable glyphs are different. They do have an association to type, but it's a loose one.
For example:Here you have three variables. One is a simple scalar. One is a reference to an array. One is an object that represents a socket, connected to the HTTP port of a remote server. The $ doesn't tell you a whole lot about type, it just indicates a scalar access-mode.
Do you know why C doesn't add new keywords
*I do*, but I wonder if you do....
C does not add new keywords because it is a syntactically simple language, and that's part of its attraction. Any attempt to change that (e.g. the way C++ did) would destroy that, and would need to justify such a change against the benefit.
I think that Perl does justify this increase in complexity, though to most outsiders that's not obvious. You really need to be able to think in Perl before you understand just how valuable all of that syntax is.
At one point, I knew C so well that I thought in it. That was long ago, but I still remember how powerful that was.
When I learned Perl well enough to think in it, I was introduced to a new kind of programming. I was suddenly able to write in a few lines of code, what would have taken pages and pages of C, even with a good set of libraries. Just the ability to say:dwarfs the abilities of C.
That's not to say C is useless. I still use it from Perl all the time, via XS. If I had to write a device driver or any other low-level code, I would still use C. But for your run-of-the-mill software, Perl is leaves low-level languages, and even most high-level languages far behind... at least from my, admittedly limited, point of view.
Speak in favor of Fortran, please do. It was a language that was hobbled by some of the physical limitations of the day, but still it was a wonderful language.
:-(
COBOL was a product of its environment, and could never have been a good language. If it had been, that would have defeated the point
But, no. C has become SO widely used in the world that it has eclipsed even COBOL at this point. Just your avergage Open Source distribution has more C code than what was produced at 90% of the banks out there (of course, those 10% cranked out some amazingly vast code). The various C-based software for embedded systems, etc keep the pace going, and then you have other free operating systems, proprietary OSes, content management systems, telementry data managers for satellites, elevator control systems, mathematical simulation systems, payroll management software, etc, etc.
About the only think I could imagine coming close at this point is JavaScript, and that's only because there are so many page generators out there that spit out HTML with JavaScript embedded....
Oh so?That does not seem very nighmarish to me. What's more, manipulating complex data on the fly is trivial in Perl:which would be an array of 4 elements, of which the fifth element is a hash of two elements, the values of which are themselves arrays. Not that hard is it?
There is the container-access syntax that I find rather messy, but even that's not so bad, and it goes away in Perl 6 entirely, again without impacting that very clean way of identifying variables that lets you do things likewith one, uniform syntax.
I would agree with the text that you cited, right up until he talks about the opposite.
The two are equally important, and both are critical to a good technical book. You cannot have a good tecnical book that is poorly written. You simply cannot.
I remember the original X reference set from O'Reilly, and the whole reason that they were a success was that they were essentially duplicates of the online X documentation, which was some of the best written toolkit documentation, ever.
Had those been just as technically accurate, but even just a little harder to navigate and use, they would have been nearly useless, given the complexity of the topic.
You have a good point at the end about expressions. I was being a bit too restrictive. I disagree with you elsewhere. Perhaps some compilers do what you suggest, but GCC allows for FILE* to iostream conversion in ways that ANSI C++ does not, and I don't call that C++ either.
You seem to only focus on where we disagree, so I'm going to let this one go for now. I do agree with you that Lisp is a flexible and powerful language. I think it was a shame that Perl only started to adopt some Lispisms as of version 5, and will have to wait until version 6 to "go all the way" as it were.
As of Perl 6, I don't think Perl and Lisp will have any major differences that don't result from the choice of syntax. The flexibility and functionality is all there.
As I said in the other reply, I thought macros were being held off until the grammer building system in Perl 6 was better fleshed-out. I haven't read A6 yet, only the stuff that Larry wrote leading up to it and a little bit of the chatter after, so I wasn't aware that had snuck in.
Yes, and no. First off, don't assume that I don't know Lisp. I try to hide it at work because I have so many co-workers working in Lisp, and a basic working knowledge is actually more of a handicap in this crowd than ignorance....
Lisp is never truely compiled. It can be compiled down to machine code, but you always have to keep the S-expressions around, just as you keep a non-static inline function around in C or C++, except in C and C++ that copy that you keep is compiled. In Lisp it must not be!
Hence, my comment about Perl 6 (not Perl, BTW, which I use generically to refer to any version of Perl that has actually been released, and I say Perl 5 when I mean Perl 5) getting as close as any truly compiled language reasonably can. Perl 6 will not retain its syntax tree post compilation, and *that* is why I call it a truely compiled language. There *may* be byte-code, but that's a function of the back-end depending on if you're using a VM like parrot or compiling to machine code.
If you re-read my comment, you'll find that it was not a slam against Lisp. I like and respect Lisp. If you can only see languages as polar extremes, then I don't think you'll enjoy Perl 6.
Secondly, this Exegesis covered Perl6's macro capabilities. It works very much like lisps, actually.
No, not really. It looks similar, and in as far as most people will use them, they will be similar.
I had not actually realized that A6 had snuck macros in. I thought that Larry said he was defering them for later. Then again, I've been off the list for a while, concentrating on work, so it's good to see so much happened.
Still, macros in Perl 6 are a feature of Perl 6's built-in parser generator features (the replacement for regular expressions, and a first in general purpose programming languages, as far as I know, but there may be an expert system shell that provided something like this level of integration with the core language).
In Lisp, macros are expression constructors that return a lambda. Very, very different, though similar in application.
All in all, if this can be implemented as they have described, in an efficient manner, I will be impressed. It seems very lispy to me
Not really, like I say, it's more like SNOBOL or Prolog than Lisp.
The ability to sayWill be quite interesting....
Anyway, you are totally wrong, every object in C# is derived from 'object'. Same as VB.NET. Same as Managed C++
.Net runtime, and that's fine, but .Net runtime is not a language, and its objects are not language primatives.
I think you're talking about the object model of the
To give an example of C++, and then discuss what is effectively an RPC-based library's object model is way, way beyond the scope of the original conversation.
Like I said before, this is not a unique feature to one, or even a dozen toolkits, languages, etc in the last 10 years. You're not citing something that originated with the example that you are citing. I was responding to an assertion of yours that you seem not to really be talking about any more, so I'm going to drop this thread.
Much of Lisp's flexibility comes from having programs represented in the same form as data (S-expressions)
That's the part that Perl does not have, and never will (though Perl 6 comes as close as a truely compiled language reasonably can). However, most Lisp code really doesn't benefit from this fact as much as it does from its side effects.
Let me give you an example. One side effect of what you describe is lambda functions, and a cool feature distinguishes lambda functions from simple function pointers in C is closures.
Perl provides the equivalent of Lambda functions in the form of anonymous subroutines, and they are also closures.
So, while you are correct that much of the flexibility of lisp falls out of S-expressions, it's not true that you cannot have that flexibility WITHOUT S-expressions.
What Lisp *does* have that Perl 5 does not is an excellent macro mechanism (which also falls out of S-expressions).
That is probably the one major thing that Perl 6 will need in order to truely surpass Lisp's flexibility for general purpose tasks, and while it has been much discussed on the mailing lists, it won't be realistic to decide on it, and nail it down fully for a few itterations of the apocolypses. But it's certainly clear that Perl needs some form of macro system that is at least very nearly as flexible as Lisp's.
Perl's eval is a red-herring. It's really a totally different (pair of) functions from Lisp's eval, acting as either parser or exception-handler. Lisp's eval is much more comparable to Perl 5's ->() operator which dereferences and executes a code reference which can be a reference to an anonymous or named closure, a subroutine or a regular method.
You can also build CVs, which are just data-structures, in C and present them to Perl as a code reference. That does give you all of the power of Lisp, but you have to drop down to C to do it, so it isn't at all trivial or useful for routine use.
Sorry, I meant "empty" in the sense of "undefined".
As you can see, I've sent too much time in high-level languages like Perl, where the two states can be distinguished, but are interchangable without error.
if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!
Ok, first off... Perl 6 will use Unicode by default, of course, and yes there is some talk of using things like the dot-product symbol to mean roughly what you would expect it to mean. However, that is limited by the practicality of entering and viewing Unicode characters with modern equipment. Perhaps in another 10 years....
Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).
You already had the $,@,%,& to prefix variables with.
But in Perl 6, they are rationalized a great deal, and made simpler to use (e.g. Perl used to use the glyph to indicate the type of operation being performed on a variable, no the type of the variable. In Perl 6, that has been changed to reflect what most programmers expect, so @foo[0] is the correct notation for accessing the zeroth element of an array, not Perl 5's $foo[0]).
Perl 6 is going ot be hard for outsiders to jump into at this stage because it doesn't exist yet. If you're not steeped in the culture of Perl 6's design, you won't be able to see where it's going, so everything looks kind of scary.
However, in about 10 years, I expect Perl 6 to be seen as the starting point of a new kind of programming and a level of symbolic abstraction that allows us to start looking at code in a much more constructive way.
Anyway, it looks like *somebody* is getting defensive about being a script programmer
.NET supports... VB.NET, C#, J#, etc.
.Net also supports many languages which do not share this typing system. The .Net libraries may use that typing system internally, but that's because they are written in, or at least primarily written for C#.
Not at all. I'm simply not.
When I spend most of my day working on libraries that are used by a suite of tools, each of which is as modular and re-usable as possible, I find it hard to refer to that as "script programming".
The gulf between those two jobs is about as wide as the gulf between Web Master and C# programmer.
I meant any language that
Then you are incorrect, since
Again, you are making a broad an inaccurate comparison between vastly different scopes.
There is absolutely no chance that either time or vtime would be keywords in any version of C
You make this assertion (which I can't understand the origin of), but then say:
C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny
Um... so, it's not "absolutely no chance", but "tiny".
You're sort of thinking about this backwards. The question is not "when a new keyword is added, will my variable name be one of them", but "in my giant project and all of the myriad libraries on which it depends, will any of that code break, when a new version of C introudces a keyword." From my prior experience in fixing code with exactly this problem, I can say "yes" with a high degree of certainty.
Perl's solution is, in my opinion, like taking a baseball bat to a cockroach
Bad metaphore, and again, you're looking at it upside down. How dangerous is it to add a keyword in C? Pretty huge, right? So the result is that you don't add keywords very often.
In Perl however, it's much less painful because of this "baseball bat", so Perl adds keywords where they are needed, rather than where they are unavoidable.
Keep in mind, I'm a fan of C (not C++) and Perl both, so this is not a language war, I'm just pointint out a relative merit of Perl's way of doing things. C has its own merits in sufficient quantity to make it the single most widely use language in history.
Having a weakly typed language is not an advantage
.NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?
.Net isn't actually a language, but a Microsoft product that encompasses the .Net runtime, which in turn encompases C#... kind of like calling Java JSP).
You're confusing variable glyphs with typing. While variable glyphs in Perl do indicate something about the typing, they are not type identifiers.
I was pointing out the advantages of glyphs, not types.
Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever
Script is a misused word here, since the term litterally means a collection of commands as a user would have typed them, and while you can write Perl code that looks kind of like that, it's certainly not the way Perl is used). Shell programs aren't even always scripts (just look at your average configure program). Don't contribute to watering down the word, especially if you're just doing so to make the "what makes us real programmers special" weak assertion.
Ok, that said, Perl does offer typing, but only when you really need it. Since strong typing isn't needed in perl by default (Perl 5 and under have no real compilation mechanism, so the performance gains would be minimal), all you really need is to type *data* not *variables*.
You can type data using any number of tools in Perl including pack, unpack, sprintf and vec.
In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler. This introduces the need to access system types in a more rigorous way, and Perl 6 has typing features such as you would find in any other language. Of course, $x = $y will still work regardless of types (though it could cause a compile or run-time error if they are excplicitly incompatible, but that's not going to happen unless you really mean for it to).
That's the approach of about 5-10 DOZEN languages (literally) over the last 10-20 years. Let's not credit C# with the "innovation" of objects as the only first-class data types (I assume you mean C#, since
Perl 6 is going down the same route as did Python (long before C#).
Perl 5 has fairly primative roots, and given those roots its typing system made sense at the time. Perl 5 does also have a universal base-class for all objects, but not all types are objects in Perl 5. They will be in Perl 6.
In Perl, you are guaranteed that your variables will never conflict with keywords. Not ever. Not even if you try.
And everyone will then use Python
;-)
Normally, I would not reply to a troll, but this one allows me to bring up an interesting point for those polarists that think Perl and Python are somehow diametrically opposed.
While they certainly have different approaches to language design, Parrot (the Perl 6 back-end) will have front-ends for many languages. One of them will, in fact, be Python.
So, will everyone "then use Python", well perhaps, but if they do, they'll be using Perl 6
Yes, as you note there's a bug in the example. Rushed slashdot posts, go figure.
Still, I disagree with this notion that you present (and every Strostrup appologist I've ever heard tackle this one has presented). Think back, and imagine that these are the days when no one had heard of C++ yet, and C was it.
Back then, there was no ambiguity. Every book ever written was of the form: int i, *j, k[200]; and everyone got exactly what that meant and why. It was good, common and expected programming practice to declare a set of variables of similar basic type that way as long as declaring them together wasn't semantically misleading to someone who would read the code.
Only in the face of Dr. Bjorn's evil char* s did people start to think that declaring multiple variables on a line was somehow evil (circa 1990 is when I first heard that claim).
So, it was in fact horrible form for an author to write code like that. There was nothing wrong with the way C worked, nor the way C++ would have worked, had he not conventionalized that broken usage.
When I program in C++, I keep the asterisk with the variable name, because that's how the compiler sees it, and any other usage would be misleading.
He was pointing out (rightly so) my lack of malloc. I was assigning to empty space.
Heehee, kind of cool, as someone pointed out, that gcc just cleaned up my mess for me, there.
Dumb me, I forgot to malloc.
Still and all, you get the idea, and there's no flaw in the part of the code that I was attempting to test, so much as the use of the pointer (always my weak point in C, which is why I use high level languages now).
HOWEVER, that being said Perl has a huge advantage over the keyword restrictions of most languages. I'll show you a sample of some code, and you tell me if you can see what the advantage is:The same goes (to a slightly lesser extent, since you don't *have* to use the prefix-sigle &) for subroutines and all of the other miscelaneous Perl data types that can be named (obviously those that cannot be named like stashes never conflict with a keyword).
- Everyone in the world had a chance to submit RFCs
- Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
- After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
- Eventually, this will lead to the Design Documents
Hope that helps clear this up for those who aren't sure what's going on when they see a new Apocolypse or Exegesis come forth.You can write badly obfuscated code by abusing visual association in just about every language, but this particular gotcha should have tipped off Stroustrup VERY early on that his style was agegeously misleading, and a good technical editor should never have let him publish a book with such incomprehensible gibberish.
That very thing is one of the primary reasons I didn't use C++ for years (not to mention that I regretted it when I did). My thinking was that if the creator of the language didn't see how damaging it was to introduce confusion in his published writing, then he wasn't likely to avoid such in a programming language. I think ANSI C++ stands as a monument to the correctness of my thinking on that point!