|
Re: perl not omnipotent? let's see!
by xdg (Monsignor) on Oct 12, 2005 at 16:06 UTC |
It's a fine challenge. Of course, given the original claim, it's important to recognize that these are not equivalent (replacing "Perl" with "A" to make the point):
A is the only language that can do everything any other language can d
+o.
Everything that can be done in another language can be done in A.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply]
[d/l] |
Re: perl not omnipotent? let's see!
by Perl Mouse (Chaplain) on Oct 12, 2005 at 16:09 UTC |
This thing could go either way (but I disagree with your claim both ways).
Either you mean Perl is the only language that has all constructs/techniques that any other language has. That isn't true - for instance, Perl doesn't have continuations or co-routines. Or even POSIX regular expressions (always prefer to find the longest match instead of the first match).
Or you mean that Perl is the only language that can simulate or mimic constructs/techniques that any other language has. That isn't true either, because if it can be simulated in Perl, in can in C, as C is driving perl.
| [reply] |
Re: perl not omnipotent? let's see!
by Dominus (Parson) on Oct 12, 2005 at 16:10 UTC |
Said Moron:
those who agree with the statement could produce a piece of functionality in another language they think cannot be done in perl.
But that's not enough. You said that "(Perl) really is the only language that can do everything any other language can do.". To prove that, you need to prove that no other language can do everything any other language can do. So for each other language l, other than Perl, you need to find something that l cannot do.
That's the part of your statement that I thought was most mistaken, anyway.
| [reply] |
|
I have updated it to include the idea of feasibility.
| [reply] |
Re: perl not omnipotent? let's see!
by itub (Priest) on Oct 12, 2005 at 16:11 UTC |
Sorry, I'm too lazy to provide code samples.
The question is ambiguous. Of course, everything you can do in Perl, you can do in C, because perl is implemented in C. And everything you can do in C, you can do in assembler.
The real question, IMO, is whether you can express things in a "natural" and efficient way in a language. I think any declarative language such as Prolog or SQL is full of examples of things that are trivial to do in those languages, but awkward and inefficient in Perl. Of course, you can use SQL and Prolog from Perl if you want...
Another case is when you need speed and memory efficiency. Can you multiply large matrices in Perl efficiently? Not really, unless you use PDL or some other numeric extension, which happens to be implemented in C (there might be some in Fortran as well).
| [reply] |
Re: perl not omnipotent? let's see!
by rnahi (Curate) on Oct 12, 2005 at 16:16 UTC |
Your claim is pointless. If you are smart and knowledgeable,
you may do almost everything in every language.
Somebody even solved The N-queens problem using pure regexes. So Perl could do
mostly everything, provided that you know how to. But the
real question is "it is really worth doing everything in Perl?
See What is Perl *NOT* good at? for a more reasonable take of this
issue.
| [reply] |
|
It would hardly be either to attempt to write a compiler in say visual basic. I think the N-Queens case is just done for fun - it certainly amused me!
| [reply] |
Re: perl not omnipotent? let's see!
by Skeeve (Vicar) on Oct 12, 2005 at 16:40 UTC |
If we limit ourselves to algorithms, Perl Mouse is right with her/his statement.
If I recall my computatenol lectures correct, it's a prooven fact that a turing machine can compute any algorithm. So it's a fact that for any algorithm you can express in any computer language, there is a turing machine that is an implemantation for this algorithm.
If that statement is correct, and please correct me everyone who knows better, it's a fact that a perl program can compute any algorithm. It's simply a matter of implementing a turing machine in perl.
Agreed: It's very theoreticaly ;-)
s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%.+=%;.#_}\&"^"-+%*)
+.}%:##%}={~=~:.")&e&&s""`$''`"e
| [reply]
[d/l] |
Re: perl not omnipotent? let's see!
by steelrose (Scribe) on Oct 12, 2005 at 16:58 UTC |
| [reply] |
Re: perl not omnipotent? let's see!
by TedPride (Priest) on Oct 12, 2005 at 17:01 UTC |
Data structures tend to take up a lot more space in Perl than they do in C++. Therefore, given a large structure and limited memory, a program could work in C++ but not in Perl. | [reply] |
|
Actually it is possible to reduce the perl datastructure to a tiny overhead using a single hash and use of the pack() function to control how it is stored in memory. The real overhead is the interpreter itself, although the C++ libraries are going to offset that in a comparison. But the more common language than either for such situations is embedded C which is specially designed for small units such as mobile telephones. Despite that, downsizing advances suggest that this will be a temporary circumstance - as bigger systems get delivered on smaller handheld units, the near future is looking far from written.
| [reply] |
|
| [reply] |
Re: perl not omnipotent? let's see!
by tirwhan (Abbot) on Oct 12, 2005 at 17:08 UTC |
OK, please try to do this in perl. | [reply] |
|
| [reply] |
|
| [reply] |
|
Aw come on it's a simple one liner, surely... ;)
perl -e 'system $_ while(<>);'
| [reply]
[d/l] |
Re: perl not omnipotent? let's see!
by tilly (Archbishop) on Oct 12, 2005 at 17:48 UTC |
For a number of years the International Conference on Functional Programming has held an annual competition. In this competition teams are asked in a very short period of time to build a the best piece of software that they can under tight time deadlines. An example was this years task to build a program that would play a variant of cops and robbers.
Any team may use any language.
Most (all?) years, some teams attempt to use Perl for this. As far as I know, Perl has never managed to place in the top 3.
That strongly suggests to me that there are some kinds of tasks which Perl is not ideal for. | [reply] |
|
| [reply] |
|
Game software is indeed highly specialised - usually needs special hardware as well. But the fact remains it would probably still be easier or mor likely to be possible for perl to call up functionality in a specialised gaming language than the other way round.
| [reply] |
|
You have this almost exactly backwards. You're thinking of the wrong kind of game.
Don't think of this as a game like Doom. Think of it more as a game like chess. It isn't about being able to draw lots of frames really quickly. It is about coming up with the best choice you can find in a definite time. The best piece of hardware to use for this on a normal PC is the main CPU.
In general the contest is set up to favour languages that are good for rapidly developing complex software which has decent performance. Compared to the languages that regularly place well in that competition, Perl loses on all of these criteria. Development in Perl is slower, it is harder to manage complexity in Perl, and the final program tends to perform more slowly. Furthermore (contrary to what you claim), Perl's basic extension mechanism is a mess, I would not be surprised if it is easier to extend those other languages to call up functionality in a specialized language than it is in Perl.
Take, for instance, the language that won first and third prizes in the ICFP contest this year. It is the language that Atrijus Tang chose to implement his version of Perl 6. Everyone who has even a passing familiarity with this project has been astounded at how quickly that project was developed. And its extension mechanism is a lot easier than Perl's XS.
So why don't those languages take the world by storm and wipe out Perl? (If you're familiar with Worse Is Better, then you know the punchline that is coming.)
Well because Perl is better at being popular.
First of all, if you're serious about finding the absolute best language for development, you form strong opinions. And your opinions probably don't match the opinions of someone else who wants a perfect language. So you both write your own languages. This leads to a lot of very good languages with very small user bases. And no matter how good the language may be, without users you're not going to build up good libraries. Without libraries you'd better be good at rapid development, because you're going to have a lot of development in front of you!
Compare to Perl and CPAN. If your style of rapid development is building software from scratch (as the problems in that contest force it to be), Perl loses. If your style of rapid development is finding big working pieces that you can plug together, Perl wins big for many practical problems. For instance if you want to call out to some weird library or language, it may be easier to write that binding for Dylan, but you're more likely to find it already written for Perl.
A large enough user base brings all sorts of other advantages as well. You can find programmers when you want to grow your team. You can find people who can help you with problems. You can find people who have tried to do what you're trying to do. Publishers are willing to write books about your language. And so on. Accumulate more reaasons to use Perl.
So you want to be popular? One of the first things that you'll want to do is make it easy to get started. For instance make it easy to program in "baby talk". That is, let people who know very little Perl easily write useful programs. You might also deliberately make your language look a lot like a lot of languages that your target audience is familiar with. In Perl's case some languages to resemble are C, awk, sed, and shell. That lets people leverage existing knowledge.
By contrast "ideal programming languages" often have a big learning curve as they push you to work in a specific way that is alien to both novices and many experienced programmers. For instance any imperative programmer who wants to learn Haskell has to re-think everything they think they know about how to organize programs. (What do you mean that a print statement there would be a compile error?) Any programmer in an ALGOL-descended language (eg Pascal, C, Java, Perl...) who wants to learn LISP has some syntactic sticker-shock to get over. (Perhaps I should say "non-syntactic sticker-shock"...) Those techniques often are big improvements in how to program (at least for some kinds of problems), but a lot of people are going to fail to get there.
That is not to say that better techniques don't make their way into mainstream languages from time to time. For instance it was once claimed to be easier for non-programmers to learn Smalltalk than programmers because they had less to unlearn. That isn't true today (if it ever was) because people learn object-oriented techniques in many other languages. But, for instance, Perl doesn't push you to use OO like Smalltalk does, nor can Perl express a pure OO design as cleanly as Smalltalk. OO in Smalltalk was a Big Idea. Telling people that they should organize their programs that way was a Big Change.
Perl's improvements are far less intrusive. A big one was a series of improvements in regular expression support. But you can learn Perl without learning regular expressions. Real programs aren't typically organized about the idea of regular expressions. It was never all that hard to do text matching and substituting in any case. In short, having some improvements in regular expressions isn't a big change in how we program.
But improved regular expression support is an easy improvement to evaluate. After a short learning curve, a lot of somewhat annoying tasks become easier. Contrast how hard it is to benefit from OO. Or functional techniques. Or monads. So Perl's improvement might not have been very important. But it was popular.
In short, on a lot of criteria that you might think should be important, Perl is worse. But Perl is worse in a Worse Is Better kind of way that leads to success.
As I've commented many times, I think that Larry Wall is better at hacking communities than he is languages. (That's not to say that he is bad at languages...) And the community that he has created is Perl's single biggest strength.
| [reply] |
|
|
|
Re: perl not omnipotent? let's see!
by Anonymous Monk on Oct 12, 2005 at 18:23 UTC |
I have to admit it. Excellent choice of nick.
As for the rest, try doing your advocacy at comp.lang.c.
Perhaps you would get more challenging answers.
| [reply] |
|
I suggest you or someone else register and publish on that URL before you advocate it ;)
| [reply] |
Re: perl not omnipotent? let's see!
by Anonymous Monk on Oct 12, 2005 at 21:53 UTC |
hey moron, its Perl not perl! | [reply] |
|
I suggest you take it up with the trademark owners if you disagree - it has nothing to do with me that it was registered in lower case.
| [reply] |
|
what trademark? what was registered in lower case?
| [reply] |
|
|
|
|
| [reply] |
|
|
What's the difference between "perl" and "Perl"?
Also note that I'm not aware of any trademark on Perl or perl. There is a trademark held by O'Reilly on the camel as a symbol of Perl. There are trademarks held by The Perl Foundation on a number of logos for Perl with an onion on them. (In those trademarks the name is capitalized.) But to the best of my knowledge, the actual name of the language is not trademarked.
| [reply] |
Re: perl not omnipotent? let's see!
by GrandFather (Cardinal) on Oct 13, 2005 at 03:54 UTC |
If it is computable then any Turing complete language can compute it. Ook! is Turing Complete (appart from issues of memory size) and I can write an Ook! interpreter in Perl thus Perl (by using the Ook! interpreter) can compute anything computable.
Perl is Huffman encoded by design.
| [reply] |
|
| [reply] |
|
...which is what the 'p' in Perl stands for.
| [reply] |
|
|
|
|
Re: perl not omnipotent? let's see!
by Moron (Curate) on Oct 13, 2005 at 12:27 UTC |
Well sorry monks, but most of who responded clearly failed to even try to meet this challenge. What I was hoping for, amongst other opportunities to show your abilities outside of being able jumping to conclusions, was more understanding of the fact that Perl does not exist as an island entire of itself but can be used to control foreign functionality to get results more effectively than other languages can which don't lend themselves to such easy communication between functional layers. A good example of this principle in action where you might expect instead to see assembler or C instead is how the CPAN module dvd::rip was written.
| [reply] |
|
So, what is it that DVD::rip is using that can't be done in C, Python, Java or Ruby?
| [reply] |
|
Not a question I am begging an answer to, but what I will say is that everything can be done in assembler, but that doesn't mean it should be.
| [reply] |
|
|
|
Well, as GrandFather pointed out, there isn't anything that one language can do, that another can't. The exercise reduces to proving Turing's Halting Problem, which Turing already proved. So yes, your original idea is OK - Perl can do whatever any other language can do. We've known this for something like seventy years (except, of course, Perl hasn't exited all that time).
UPDATE: As Tilly has pointed out, this has nothing to do with Turing's Halting Problem. It has to do with Church's Thesis (thank you, Tilly, for correcting me).
| [reply] |
|
Some of the replies have already cited examples which suffice to show that just because something is computable doesn't mean it's feasible, for a given Turing-complete language.
| [reply] |
|
|
Um, no.
Turing's Halting Problem is about the impossibility of writing a program that can figure out whether another program will or will not halt on given input.
The result that you're referring to is variously known as Church's thesis, the Church-Turing thesis, Turing's thesis and Church's conjecture. There are many minor variations, but they all boil down to, "Anything that can be computed, can be computed on a Turing machine." This statement is unproveable because "can be computed" is undefined. However it is generally accepted, and holds true for every reasonable definition of "computed" that anyone has been able to come up with.
| [reply] |
|
Re: perl not omnipotent? let's see!
by Anonymous Monk on Oct 16, 2005 at 17:21 UTC |
| [reply] |
|
I have read this reply but see no further comment as being necessary.
| [reply] |
