Slashdot Mirror
Unix in Perl
An anonymous reader writes "Or at least a pretty comprehensive suite of the classic utilities. Tom Christiansen (well-known in Perl circles) has decided that it is easier to write the utilities in Perl and make them available on all platforms than to constantly rewrite Perl scripts that use backticks. Full details are available right here. "
Did the anonymous reader really start his email with "Or"?
he he. Naughty thought. Lets re-write Netscape with perl. he he. Ahh. Too much studying..
ah, an even better idea. Convince Microsoft to rewrite win98 in perl. It'll be faster, more stable AND open source. But they'd find a way to make perl only run win98 (now perl). Only microsoft would be able to convince the american public of that.
/me shudders.
Couldn't they at least have used something decent, like gforth? Perl is just too big...
Wouldn't it make more sense to use something like Java? It's more widely supported, faster, and can be compiled to native code for even more speed. Not to mention the porting process would probably be easier, since you could cut and paste parts of the code.
I don't get something about lex and yacc being in their target list. Sure, you can reimplement the commands themselves in Perl. But what about the libraries they are supposed to come with?
Python
Eh? I've *never* had to reset my RS/6000 workstation because of a perl problem. In fact, I don't even recall ever having a coredump. And my project isn't some dinky 500 line perl script. Its maybe 20,000 lines of Perl/Tk code heavily used by over 40 users in an EDA setting.
I think you just had perl invoke a program which trashed your box. If not, post your source to the contrary.
My biggest concern with implementing the unix command set in perl is that each time you invoke a command, you'll recompile the script. Or does Tom plan to perlcc everything on install?
email that Tom posted and see this closing line...
"And it would make nice press for Perl, too, eh?"
Geez Tom go write a new book or something. This is not the spirit of Open Source, which would be to FIX the original utils in their native language.
Windows has Dll Hell,
we got Perl Purgatory!
jmr
But he never mentioned Java, and he never mentioned anything about Slashdot. He just looked at a web site put together by some loon who's re-implementing the GNU utilities in perl rather than C (the GNU utilities are a very popular set of unix utilities). He pointed out that all those GNU programs are just fine the way they are, and that there's really nothing to be gained by rewriting them in Perl. Does that help?
I'm looking at your post, and I'm trying to imagine what kind of mental illness (or maybe it's just traumatic brain damage) could have driven you to start yammering about Rob making a copy of GNU's website, and to be honest I'm stumped. It's a complete non-sequitur. There's just no point at which your post even begins to address any issues raised in his. You're a hopeless vegetable.
"but the perl religion is really overdone"
Jave my friend is overdone. People often complain about Perl being ugly. Actually, I think Perl has a very forgiving syntax and the Ugly parts are most regular expression, which are ugly but powerful.
I don't care how many Java books are sold, the amount of perl code that gets jobs done every day on real web sites is greater than java by at least a factor of two.
Oh come on!
They're doing it for FUN! It's a GOOD HACK!
----------------
This chair is squeaky. How do I patch it's kernel to include support for my weight?
It's not the spirit of OpenSource to code what other people want you to code either.
Can't you guys accept that programmers like to have fun writing things they want to write? Is that really so hard to understand?
Look at the tripe we get in the responses these days. This site is clearly catering to non-programmers more and more - look at the senseless crud we get in response to Tom's simple desire to get basic unix utilities working on foreign platforms.
Yes perl is slower than compiled code. Yes it uses more memory - these are the simplistic responses I always here from non-programmers. People who work with it will tell you that perl saves their hides numerous times per day. Most data posted on the web is done in the background folks - it really doesn't matter if it the tool generating it takes two seconds longer and uses twice the memory.
The most valuable resource is not processor time or memory - it is programer time.
Anyone who labors to write simple data filters in C may conserve memory useage, but they typically will take twice as long or more to write the program. Perl code is typically a tenth of the size of an equivalent C program. For all the memory they conserved, I could have written three programs to solve three different problems, and went to Fry's to plonk down for a gig of ram with the money saved to complete the projects.
Memory is cheap. If you need some more to run perl code, go buy a gigabyte of it.
Well, before we recreate the Unix tool collection, how about PSH (Perl Shell) and PMACS (Perlish EMACS). The idea behind the first is that it's unneccessary to have a shell language other than perl. And the idea behind the second is that if you're building a text-processing machine -- which is what EMACS is -- why not use the best text processing language around -- which is perl.
We are intentionally avoiding the anti-Unix feature bloat painfully demonstrated in some of the more egregious GNU utilities or in the icky System V perversions that have infected Unix releases like Solaris.
"perversions"?! Blah blah blah, drop the propaganda and make sense. If all he's got to offer is name-calling, I've got better things to do with my time than listen to another Larry Wall slagging off the rest of the world. I'll gladly enjoy the irony of a Perl partisan accusing GNU of "feature bloat", but it doesn't make up for the rest of the rant.
simplicity is paramount. It's better to get something that works in 90% of the cases than not getting anything at all, or to get something that's huge and complicated and hard to maintain.
What, like Perl itself? Seriously! Yet this guy obviously finds it very useful. Why didn't he stop and think? Just for a moment -- "Uh, duh, George . .
If programmer time were the most valuable thing in the world, then why does speed make such a big difference?
:) ).
Look at it this way. For any project, you must balance programmer time versus program time, complexity, and stability. If a program crashes because I spent 1 hour programming, thus saving money, my company will probably lose money because no-one wants to buy a buggy product (avoiding MS issue here
There is also the question of what use the program will recieve. If the program will run once a year on a Sunday at midnight, then it doesn't have to efficient. If it has to run every time someone connects to Slashdot, then it really must be efficient. That speedup may end up saving money, even if extra programmer time is wasted. To say that any one attribute is monolithic is sophomoric.
Yes perl is slower than compiled code. Yes it uses more memory - these are the simplistic responses I always here from non-programmers.
Really? I guess I always miss those posts.
Most data posted on the web is done in the background folks - it really doesn't matter if it the tool generating it takes two seconds longer and uses twice the memory.
Gee, that's a really fascinating point. Now for your next trick, can you explain what that has to do with writing yacc or tr in perl? Do you think he's planning on running a public access unix utility website, like you upload your entire filesystem and it runs ls on it, and sends back the output or something?
This guy writing the utilities is doing NOTHING that has anything to do with the web. Nothing at all.
You're not a programmer, you're a web monkey, so can the attitude.
The most valuable resource is not processor time or memory - it is programer time.
That's true if you're writing cgi scripts for a website, or if you're writing dumb database frontends in visual basic at a bank. So what?
Anyone who labors to write simple data filters in C may conserve memory useage, but they typically will take twice as long or more to write the program. Perl code is typically a tenth of the size of an equivalent C program. For all the memory they conserved, I could have written three programs to solve three different problems, and went to Fry's to plonk down for a gig of ram with the money saved to complete the projects.
What, and you're going to give the memory out to your users so they can run your giant program? Oh, I forgot. You don't have any users. You're not a programmer, you're a web monkey. (Here's a rule of thumb: If your code isn't running on any computer not owned by you or your employer, then you really have no conception of the world that most programmers live in. In that world, the code you write ought to run on the user's computer. If it doesn't, you've wasted the user's time and your own).
The things that you do with perl are best done in perl, I'm sure. Naturally, that's entirely irrelevant to my job, because I do things that are best done in C++, and I do those things in an entirely different environment.
Actually, my original post was aimed at the statement, ``i just can't see any advantage over the GNU utils.'' Since Slashdot is done in Perl, I thought, perish the logic, that that would be a fine test for GNU utils: use ls and ps and wc, et al. to build a website.
He didn't say it was a bad idea to write Slashdot in perl, he said it was pointless to write ls in perl, you twit. He said it was stupid to write ls in perl, because we already have a perfectly good version of ls which is written in C, okay? Should I repeat it again? I pointed out that you missed his point completely, and I even took the time to explain it very carefully because you're obviously not very bright. But you still don't get it.
You're mentally retarded. I can't believe this. You have the brains of a goddamn gerbil.
.
Unix tools rewritten in Perl is an excellent idea.
What we need to do next is rewrite Linux in Perl.
We could call it 'Penux' and say that it was written by a Finnish guy called 'Penus'.
Since when does everyone feel they can say what people can program or not. Just think of what would not have been written:
Linux
xbill
perl itself
tcl/tk
xbill (i really like that game)
xscreensaver
system32
that's about all. I guess there wasn't that much maybe everyone should dictate what can be written.
Lightman
"Backdoors are not secrets!"
I totally agree.
Funny how LW and (for example) myself share a common religious faith yet our taste in programming languages are polar opposites.
:)
Any Examples ?
i've been writing programs for a major web company since before you were a glint in our collective eye.
In plain english: You're not a programmer, you're a web monkey. You write programs to be run on a small number of computers, which are owned by your employer. If you write bloated, slow programs, you can buy more RAM. Well, that situation is completely irrelevant to me because I write software for end-users, who have to wade through enough bloated garbage on their computers already. If I went out and bought a gig of RAM for every user of the programs I work on, I would be deeply in debt for the next thousand years.
It doesn't take much brains or skill to work in a situation where you can buy more hardware to paper over your incompetence. (Though I'm sure that most web programmers have more common sense than you).
my web page views for one day most likely will blow away your lifetime total by a factor of ten.
Page views? What does that have to do with programming? I'm sure your perl code generates more page views in a given minute than GCC has generated in all the years since the day it was first compiled. You know why? I'll tell you why: GCC doesn't generate page views. It's a C compiler. So I guess by your standards, GCC is worthless and Stallman is a loser -- because GCC doesn't generate page views!
You're an idiot.
You use a text editor, right? Does it generate page views? No. Was it handed down by god? No. It was written by a programmer, and it wasn't written in perl. You use a lot of tools -- where do you think they come from? People write them. Those people are called programmers. You use an operating system, right? Does it consist of "page views"? No. It's got a kernel, a filesystem, drivers, utilities, etc. Did all of that crap magically spring up out of the earth after a nice rain? No. All of those things were written by programmers.
Did you actually read the post?
(It's like this with all new technology. At some point the economy will slow, the cs departments will churn out enough new grads, immigration and just plain old fashioned saturation will slow the web employment market down tremendously. But before then, those who are currently in demand cop quite an attitude. Saw this in Austin in 1987. Framing carpenters were hot hot hot until they were not not not. Then they had the take their attitudes to Florida or someplace, or learn some new skills, like those pussies that did remodeling.)
Amen!
:-)
While you guys are slaving away on that program in C trying to squeeze out 0.000012% performance increase, I'm gonna be drinking a beer after I'm done with the same one in perl.
While you wouldn't want to write a window manager in perl, many things just make sense to use perl. Sure, unix tools may be slower written in perl than in C, but on obscure platforms, having them is better than having none.
Lighten up. Perl is fun.
That kind of attitude makes it clear how GNOME and KDE both got the way they are now... *duck*
:)
. . . therefore reimplement ls with fingers only!
uh . . . okay, that was kinda lame
That would be kind of cool (ls directing output directory to the video card :), but that would kind of defeat the purpose... I mean, the goal is to make unix commands portable to crappy operating systems (uhm. 98 uhm...).
Yes, sure, but if you use Perl and speed in the same sentence I will fall over laughing. Because the latest Java is considerably faster for most tasks than Perl. yes, I love Perl, but pretty or fast she ain't. That's kinda the point. Java is a MUCH cleaner design, and the latest JITs manage to get decent (not great) performance out of it. But I still prefer writing Perl code, because its "more comfortable".
Randal Schwartz, yet another big Perl name, posted a response to Tom's announcement. Tom did not like this; his counter-response can be found here. Be warned; it's quite a rant. I know that since I'm posting as an AC, my words don't carry much weight, but Tom's proven once again he's not my kind of people.
A subject is just that. It's not the start of a message.
The subject under consideration is not whether or not to use perl in general. The subject is whether or not to use perl to duplicate the GNU utils.
Context matters. You're a retarded child.
I notice that perl itself is not on the list .....
That guy has some serious issues.
In one post, he's explaining that he doesn't want to bother doing some things in a really robust way, because perl won't do it for him -- he seems to be hoping that somebody will add something to perl in C, to save him the trouble of having to write real code in perl. It's weird. I guess I mostly use ANSI C, and there's just no way anybody's gonna come along at this point and change the language to save me the trouble of coding something hard -- so I just get on with it, and lo and behold, good heavens, it's not that tough . . . "Doing block reads backwards form the end and parsing into lines with carry is somewhat nontrivial." Oh, yeah? Well, that does sound like a little bit of a hassle in C, but even if it were a real bastard, so what? If you have to write it, you have to write it! Now I know what he hates about GNU: They take the time to write the damn code so it works.
"somewhat nontrivial"
And then in another post, he explains why he can't be bothered to make his great port of the unix utils actually USABLE on any platforms that won't do all the work for him (those being, of course, exactly the platforms that he needs to port these things to).
"not my problem"
What a loser. I really don't need some cocky, slapdash bonehead like this writing utilities for me. Of course, I don't have to use his utilities; GNU has been ported to every platform I use (more platforms than perl, probably
Hell, I myself have written scripts, and when I do that, I think the same way I'm accusing script-writers of thinking! It's nothing about them, I guess (when i put it that way, it seems pretty obvious!); it's just the nature of the language, and how we (all) relate to it. Or something.
No text
Perl already compiles down to a well-defined byte-code that is then executed by the interpreter. There is no reason that this byte-code cannot be natively understood.
However some of the constructs (think eval) hook back to the interpreter, this may complicate things considerably...
Ben
#!/usr/bin/perl
while (chomp($line = )){eval($line);};
In 3 years of playing with perl on Unix, I've never seen it even raise the load average except for some largish dbm rebuilds. and it's never crashed them machine or even affected the responsiveness. (but then again, that's on Linux and Solaris)
Resource pig from hell?
hehe, that's funny.
sounds like an nt problem to me...
Point of fact, Cochise, it's usually a waste of time to grok upon a language that can't be used to write its own compiler. (see also "toy language" -- shame about vitual memory and penny megahertz, now BASIC is a real language)
Perl DOES have a very forgiving syntax. Sweat pants, in turn, have a very forgiving waistline, but you're limited in the places you can wear them, aren't you? (Wait, these are CS types. Uh, SPOON != HAMMER, right?)
I know its out, I got it working under winNT and win95, but it doesn't seem to work under win98... Maybe its the registry.
chomp
There it is. Right there. I don't rent Winnie-the-Pooh movies, I'm a grown man, I don't need this cutesey-wootsey crapola.
But the purpose of reimplementing these utils in perl is to use them _in_ perl programs. Of course there's no reason to replace ls with a perl version. But by creating perl code that implements unix utils that are often called by perl programs, you avoid forking lots of processes in your perl scripts, thereby making them more efficient.
Because who ever writes the code chooses the platform.
If people want these utils in another form pick up the keyboard and start writing them.
One of the things I don't like about NT is it's lack of Unix tools which I have become familiar with over the years. I don't care if they are coded in FORTRAN - If they work how I expect I dig them.
Show me another floor waxer with built-in infinite undo so I can remove the wax I get on the carpet, and I'll switch.
I was taking input from the user or a file, converting it to an integer
If you converted it to an integer, presumably using int(), then there wouldn't be any non-numeric characters and $foo++ would have acted as you expected it to.
My biggest concern with implementing the unix command set in perl is that each time you invoke a command, you'll recompile the script. Or does Tom plan to perlcc everything on install?
The perl unix commands are not intended to be invoked the same way the "normal" unix command is. i.e. the goal is not to convert:
$foo = `du`;
to
$foo = `du.pl`;
Rather, the goal is to do something like:
require 'du.pl';
$foo =
Which will have du.pl parsed once, regardless of how many times &du is called.
At least read the article before you respond to it. The goal is to avoid backticks and dependancy on certain programs being installed on the machine the script is running on. Distributing a java program with your perl program creates a dependancy on java being installed and if you're gonna create a dependency you might as well rely on the original program which will be natively compiled and faster than java.
You might want to try Dylan. It is:
1. more powerful than Python
2. doesn't suffer from indentation changing the meaning of the program
3. doesn't force you to be object-oriented all the time though it is totally object-oriented
4. has a nice regexp library
The URL is
http://gwydiondylan.org
Don't use it. Use guile or whatever you want, but not PERL. It's not better than Qt.
Ever run anything *other* than an applet?
But ... I'd rather do it quickly in Perl (devel.) ...)
than in C or C++ and waste my time parsing things
the hard way (and yah, lex/yacc would work but not
in my "environment"
Gwydion Dylan (http://gwydiondylan.org) has a regular expression library. And your large program will be well organized and modular.
I code java applets since summer 97, and never made a single applet in my life. Those who do not know java are the ones usualy who don't know there is more to java than crappy applets.
Why would a Perl programmer be worse at implementing a utility then a GNU programmer? Perl programmers wrote perl, after all, and perl is helluva robust program.
As a C programmer, I spend way too much time wondering what type a
variable should be...
Computers are fast enough. Let's work on something else. At this point
I'll gladly trade in speed for decent functionality.
Check out Gwydion Dylan, the open source implementation of the Dylan programming language. In Dylan, you don't have to specify types unless you want to. Dylan is a very abstract and flexible language, but is still efficient. It even has a regular expression library. http://gwydiondylan.org
I don't know why, but perl just *clicked* for me. I picked up Randal Schwartz's Learning Perl a few years back. Did all the tutorials in total bewilderment (I'd spent the previous 12 years programming C). This was the craziest, twisted, most badly designed language I'd ever seen.
Then I tried to write a program. I had no idea about the syntax, or the semantics, but amazingly what I wrote worked. I wrote a bit more. I thought "this will never work, I'm doing a crazy assignment here". Perl seemed to read my mind! It did exactly what I wanted, when I wanted.
Now I understood why it was doing what I wanted, and I no longer write perl using the Zen "code it and it'll work" technique. But I truly find it to be the ultimate scripting langauge. Strong string handling, useful data types like associative arrays and lists, good formatting functions, and a huge library of useful stuff. You can write quick "hacks" to do just about anything, from writing a CGI to a parser to a utility to a menu system.
I've even written code using ioctl() in perl! It's incredible what you can do.
I was a total convert from awk/sh to perl. For the past 4 years I've used it almost exclusively for scripting needs, and I've never looked back. Once you get used to it, Perl code looks elegant, and it's *very* easy to read. I'm not kidding. It's as if your brain just turns into a pretzel to let it all make sense, but it's worth it.
But since other people are willing to put in the work, great. These kinds of tools will be useful if they get properly debugged, and a lot of the modules on CPAN do, in fact, work quite reliably.
In any case, I suspect no matter what the Perl community does, sooner or later, we are bound to see a POSIX-compliant shell environment in Java as well because there is actually a need for it.
my @ary;
while () { chomp($_); push(@ary, $_) }
What would u prefer???
truncate($_, 1)??
$_ = substr($_, 0, length($_)) ???
come up with a real reason, dipshit
I have a feeling Tom and Randall aren't going to be co-authors of the third edition of the Camel book. This silly public Tom/Randall bickering has been going on for a long time and, at least to this observer, it seems to be mostly Tom that's gone a little weird.
Too bad, really. They both know their stuff.
too bad, really. nice language. but even with an editor mode i can't tolerate the syntax. so i don't use it anymore. i stopped after a two-hour debug session of critical code turned up that someone had stuck an extra space in when they edited my script with vi, thus altering a loop. absolutely UNACCEPTABLE.
The problem is probably the lack of support for Python in your editor.
The bad indentation error happened to me years ago, but now it is completly fixed: I use [x]emacs, and when I'm reindenting python code I systematically use Ctrl-C . Poof. Problems are gone.
hint to the python evangelists: fix this and i'm back. i freely admit i'm no good with compiler design to do it myself.
It's not likely that a bunch of '{','}' get accepted in the language, no more that C/C++ switch to a Lisp-like notation... Indentation is a feature not a bug (look at books: when they are using pseudo-code without a C or Pascal syntax, they strangely revert to a Python-like syntax. Why? because '{' and '}', BEGIN and END are a readability hindrance).
In the meantime you may have a look at CorbaScript which is a bastardised version of Python, focusing on scripting Corba objects though.
too bad, really. nice language. but even with an editor mode i can't tolerate the syntax. so i don't use it anymore. i stopped after a two-hour debug session of critical code turned up that someone had stuck an extra space in when they edited my script with vi, thus altering a loop. absolutely UNACCEPTABLE.
The problem is probably the lack of support for Python in your editor.
The bad indentation error happened to me years ago, but now it is completly fixed: I use [x]emacs, and when I'm reindenting python code I systematically use Ctrl-C < or Ctrl-C >. Poof. Problems are gone.
hint to the python evangelists: fix this and i'm back. i freely admit i'm no good with compiler design to do it myself.
It's not likely that a bunch of '{','}' get accepted in the language, no more that C/C++ switch to a Lisp-like notation... Indentation is a feature not a bug (look at books: when they are using pseudo-code without a C or Pascal syntax, they strangely revert to a Python-like syntax. Why? because '{' and '}', BEGIN and END are a readability hindrance).
In the meantime you may have a look at CorbaScript which is a bastardised version of Python, focusing on scripting Corba objects though.
PS: Slashdot preview changes the > and < in > and < :-(
Well said. As someone who has written code knowing that it may have to run on platforms as diverse as Unix, Win32, and Netware, Perl has been a real lifesaver for me. It may not be the tightest or fastest language in existance, and some may question its syntax and readability (although I personally find that once you've used Perl for a few months, it's very easy to write and understand), but that's neither here nor there - one of the things that really makes Perl shine is its portability.
I for one am quite pleased at the prospect of having more Unix tools written in Perl for just this reason - fewer backticks means more elegant, portable code. And for those who complain about such tools introducing bloat into Perl, I don't see it happening - that's the beauty of optional modules.
Perl is free (GPL) open source software. The poster must be confused.
Agreed on most of your points. However Perl is NOT slow. I have written text parsing routines that use only 15% more cpu time then an equivalent C program. I have been amazed with Perl's near C speed. Of course I may not be an efficient C programmer, still Perl is fast enough most jobs that require parsing text.
The tools are already on Windows, but they may NOT already be on MacOS, Netware, VMS, or numerous other systems that Perl runs on that aren't Unix or Win32.
From the perl man page:
"If you have a problem that would ordinarily use sed or awk or sh, but it exceeds their capabilities or must run a little faster, and you don't want to write the silly thing in C, then Perl may be for you. There are also translators to turn your sed and awk scripts into Perl scripts."
While more flexible than awk, for the simpler jobs gawk blows away perl. I'm talking like 10 times faster. I won't be switching my scipts to a perl implementation of awk any time soon.
Perl is perfect for writing small text-processing routines, the sort of things I used to do in awk. Perl is excellent at building small command-line utilities, which helps to explain why it is so popular among the Unix-types who love their shell (or NT users who desperately need a good shell).
Java solves an entirely different set of problems nicely, that of building scalable/persistent server agents, where threading and synchronization primitives are essential. Dynamic class loading is a plus. I can upgrade my server code without interrupting the VM.
Java, in general, is poor at small utilities, due to the relatively high overhead of starting up/shutting down the VM.
Anyway, isn't it nice to have so many languages available to choose from?
It doesn't force you to be OO any of the time. Besides its whitespaces, it doesn't force you to do anything. Like the Perl monkeys are fond of saying "there's more than one way to do it". I could never ever ever get around Perl's $_ $@ $! @@%*_; for qw{/w3~!$FLsNN::->$/blick/gWi} syntax myself. Python's whitespaces can be a pain, but even good Perl can be worse than reading a cartoon-cuss-word filled book of Hagar the Horrible.
There is a semi-emacs like text editor being written called aced. It hasn't been released yet, but I have used it. It isn't xemacs, but it works and is fairly cool.
Someone is working on a PSH...
Port Perl to the Exo kernel.
http://www.pdos.lcs.mit.edu/exo/
Perl runs on my 68k mac. I havn't looked, but I don't think the GNU tools will.
Nope. Randal will not be on the 3rd ed. of the Camel, but will retain sole authorship of the Llama. ORA isn't the only publisher of Perl books either, though their finest offering at this point is the Ram, which is by Tom and Gnat.
Perl is reference-counted. I'm the first to agree that's among the most brain-damaged forms of reference counting, but it's better than nothing.
This is why our systems are going to hell. Wasting the resources of thousands (or millions) to save one guy some work is sometimes necessary, but it's always evil.
Makes me wish fork(2) were cheap again, so we could trivially combine tools in different languages as ghod intended. But I'm not a wizard kernel hacker, and I suspect you'd have to start from scratch anyway....
You obviously cannot read because Perl comes
*also* with GPL.
"It's not worth the trouble. So more care goes into it."
Nope, the two points are unrelated.
It is true that more work goes into it, but not more care.
Too complicated. Try: perl -0777 -neeval
-- Abigail
Cherub wrote:
....
i suppose this is amusing, but as quick-easy-and-portable as perl is, i just can
't see any advantage over the GNU utils.
Do the GNU utils run on Win3.1? Do they run on DOS? On the Mac? On VOS? On a Cray? On the Amiga?
On VMS? On QNX? OS/2?
It was said:
He didn't say it was a bad idea to write Slashdot in perl, he said it was pointl
ess to write ls in perl, you twit. He said it was
stupid to write ls in perl, because we already have a perfectly good version of
ls which is written in C, okay?
Does GNU ls run on the Mac? Does it run on VMS?
Does it run on OS/2?
-- Abigail
jmr said:
This is not the spirit of Open Source, which would be to FIX the original utils in their native language.
That would be hard to do, as many of the original
utilities have all kinds of license restrictions.
Some times, the original code of the utilities
isn't even available.
Now, before you start arguing about GNU stuff,
most of their file- and binutilities aren't
original. Just rewrites. And *I* don't consider
GPLed stuff "free". It's tainted.
-- Abigail
Tim Pierce wrote:
we cannot afford to spawn fifty Perl processes every second.
Did you try building libperl.so?
-- Abigail
Andy Tai wrote:
Yes, Tom is big on Perl. But he did not provide argument on why Perl is the right tool for the job. He did not show proof why Perl is better than Python, or Java, or Tcl, for the job.
Why should he? He. me, and others are *doing* it.
In Perl. If you, or anyone else, thinks it's
better done in Python, Java or Tcl, proof us
wrong. Implement the same utilities in Python,
Java and Tcl, and run it on the same platforms
Perl runs on.
-- Abigail
It was said:
Perl is shiped with "artistic" license, which only
distorts spirit of the free software. we must create new, GPLed perl
Perl has *two* licenses. GPL and Artistic, and you
can choose which license you used. The Artistic
license is certainly freeer than GPL, as it puts
lesser restrictions on the user.
As for the PPT tools, most contributed programs
seem to have copied by license notice:
This program is free and open software. You may use, copy, modify, distribute and sell this program (and any modified variants) in any way you wish, provided you do not restrict others to do the same.
-- Abigail
why stop at just basic tools? why not write a whole kernel in perl! with a builtin interpeter
Heh, that's all that we'd need to avoid the long startup times. Otherwise, seems like a cute idea.
Posted by Matt Perry:
Geez, how old is Tom? Twelve? He acts like an immature brat, especially to send such a heated and off topic response to what I would consider to be good questions that should be discussed.
Posted by Deus_X:
But, yes find a real reason or admit your your uninformed bias. (two posts up that is)
Can't you guys smell trolls yet? Hehehe... Laugh. It's funny.
Posted by silverharloe:
point 1:
if you don't like the idea of the tools, don't
download them, don't use them.
point 2:
if you think it's a big waste of time to write
the tools, don't contribute your time to them.
point 3:
this project is unrelated to the perl5 distribution, and so nothing is being "taken" from
anything.
point 4:
I think I like a lot of the features and options in many GNU binutils, and so I'll probably stick with those. but that's just me, that's just my time, and I don't see why that should affect Tom's fun.
If what you are saying is that your perl scripts are just as fast as your C programs, then I must ask you:
what the hell are you talking about?
Write this in Perl for me, or write it in shell, and tell me which is fastest. I bet it's C.
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char * argv[]) {
int l, h, s, i;
if (argc>=2) {
l = atoi(argv[1]);
h = atoi(argv[2]);
if (l>h) { s = l; l = h; h = s; }
s = 1;
if (argc>=3)
s = atoi(argv[3]);
for (i=l;i=h;i+=s) printf("%d ",i);
}
return 0;
}
pb Reply or e-mail; don't vaguely moderate.
As I often start every one of my posts:
:)
What the hell is wrong with you people?
Lighten the fuck up. Must everything have a clear
and explicit purpose to be allowed to exist?
I laughed out loud when I read that. Then I
checked out the page and realized they were
serious. It stopped being funny and I started
fingering the possibilities.
Sure, Perl is butt slow, but so what? So is Java.
Do we really have nothing better to do than
complain that an application takes 8 seconds to
load as opposed to 3 seconds? (Netscape vs. IE?)
I scoffed at Perl for awhile until I picked up
the O'Reilly "Camel" book a few weeks ago and
found that I loved it after I read the second
chapter. Perl is an attempt to change the
environment. To make things better. Something
the inventor of Java has said once.
As a C programmer, I spend way too much time
wondering what type a variable should be and how
to save memory and gain precious nanoseconds of
time. "Bah, don't use unsigned long, unsigned
short is enough". Do I really need to waste
precious seconds of my life to save two whole
bytes of memory? Which cost what? $0.000012?
That's an inefficient use of my life, since I
usually throw pennies away rather than let them
collect in my pocket. Not to mention that my
processor is 98% idle most of the time.
Computers are fast enough. Let's work on something
else. At this point I'll gladly trade in speed
for decent functionality. If I can write what I
do in C in Perl in 10% the time for a 1000% speed
hit. I don't care.
I only wish I was good enough at Perl (only a week
or two old here) to help this project out.
To reiterate, lighten the fuck up.
The point is not to have a set of Unix utils in /bin that are written in Perl. The point is to give someone some code to paste into his or her Perl program to avoid having to do things like `date` and `wc -l /foo/bar`. I for one support this effort, as my Perl programs suffer mainly from the overhead involved in using backticks.
--
--
I noticed
It's getting about time to leave everywhere
If you were running this under NT, it sounds like a problem with either your port of Perl or NT itself. I have dozens of Perl scripts (many running fill-time) running under Linux here without so much as a hiccup. Memory, load and CPU usage are negligible and when the scripts are actively doing something, the system isn't taxed any more than if traditional programs were being used instead.
Before you diss the language, try looking to see if maybe your system or implementation of the language might be at fault.
All of my perl scripts are just as responsive and any load-time delays are unnoticable as any other C utility.
Though I do agree that often times Perl is touted as a fix-all language suitable for most any task. I use Perl for just about every little scripting task I need, simply because it's so much easier to use than most any other language I've dealt with, and it's actually *fun* to write under.
Let them do what they like. I might actually be contributing to this myself.
The scripting language itself is just that -- A scripting language. It's some *developers* who choose to try and use it for tasks that it's not well-suited for.
There are legitimate reasons why you'd want to fetch data from the Web and process it by a Perl script. There are hundreds of Perl modules that let Perl scripts interface with and use data from tons of different data sources and formats. These things are useful.
I don't understand..
I run Perl under NT as well and I understand where the original poster was coming from...
I don't understand your post.
UNIX: Any of a collection of similar operating systems that you can run the programming language 'perl' on.
Yesterday, while looking at dejanews.com, I found out that someone is still using it as a .signature. Somehow, I find this project to be most amusing.
SPF support for most open source mail servers can be found at libspf2.
Heh. I dunno what he meant... but I'm gonna be charitable and assume that when he said "malloc by hand" he really meant "keep track of pointers and free() by hand".
Sure, experienced C programmers instinctively write well structured algorithms where pointers don't get lost, and everything malloc()d is free()d when it's done with, but to the mortal among us, that's hard work, and having our garbage collected for us is a blessing.
This is just...disturbing. I suppose they'll work but...Perl? (shudders)
)
Daniel
# Parse options here
import sys
import os
import re
if os.exists(sys.argv[-1]):
if not isdir(sys.argv[-1]):
throw "%s is not a directory!"%sys.argv[-1];
for i in sys.argv[:-1]:
infile=open(i)
outfile=open(sys.argv[-1]+os.path.split(i)[1],"w"
stuff=infile.read(16384)
while len(stuff)>0:
outfile.write(stuff)
stuff=infile.read(16384)
else:
if sys.len(argv)>2:
throw "Need two arguments!"
destname=argv[1]
if(os.isdir(destname)):
destname=destname+os.path.basename(filename)
infile=open(argv[0])
outfile=open(argv[1],"w")
stuff=infile.read(16384)
while len(stuff)>0:
outfile.write(stuff)
stuff=infile.read(16384)
Hurry up and jump on the individualist bandwagon!
Well, there's a simple solution for that. Rewrite the Perl interpreter in Perl. :-)
Daniel
Hurry up and jump on the individualist bandwagon!
Python is different. It doesn't try to be C. Or sed. Or awk. Or bash. (Perl, by comparison, looks like some unholy mutant offspring of the above) It has unusual things. But I stopped using Perl when I tried to add one to an integer and instead incremented a character in its string representation.
Daniel
Hurry up and jump on the individualist bandwagon!
I'm aware that it's a documented feature. If I remember correctly, I was taking input from the user or a file, converting it to an integer, and incrementing it. Using $foo++ caused character incrementation but $foo=$foo+1 caused numerical incrementation. Certainly it's a language 'feature', but so is Python's use of whitespace (which I personally found quite useful after using it for a day or two). Both can lead to unexpected results. At least Python is internally consistent. ;) (If Larry Wall likes 500 different ways to do everything, that's fine..I'm happy with ten to fifty, though.)
Daniel
Hurry up and jump on the individualist bandwagon!
I don't think so -- many compilers are written in themselves.
For interpreters, most Forths are written in themselves -- but then Forth isn't really interpreted (it's wordcoded). The Forthers call it metacompilation.
-Billy
True, but not all individual systems have the GNU tools installed. And for those that do, it's not likely that they are installed as the standard tools.
The intention is that, in a perl script, instead of calling the external program in backticks (which, if you don't know perl, has the same effect as doing it in the shell) you would load in the equivalent script. So instead of calling whatever ls is installed on the system--not really knowing for sure what the command-line syntax or output format is on this particular machine--you just make sure and call the perl version.
Yes, Tom is big on Perl. But he did not provide argument on why Perl is the right tool for the job. He did not show proof why Perl is better than Python, or Java, or Tcl, for the job.
Tom, please provide the proof.
Free Software: the software by the people, of the people and for the people. Develop! Share! Enhance! Enjoy!
It had no whitespace. If you think Python is ugly without whitespace, try Perl.
-russ
His point still remains: This has nothing to do with the web. Perl has very little to do with it in all reality. It's just a powerful tool used in CGI a lot.
And you did prove, just now, you are exactly what he (or she I guess... Doubtful though) said you are.
Now that guy really should have gone a little farther, and mentioned that if everything written in perl is more robust than anything written in c, why then perl itself -- having been written in c -- must suck, and so therefore anything using it (e.g., a perl script) must suck too! Around and around and around and around . .
Too bad you can't rewrite perl in perl.
The world's first recursive programming language.
Great, undoubtedly, but the perl religion is really overdone. Sure, it's the only way to get anything done on NT, but that's no excuse.
Just a little DogBarf tossed at the faithful...
Haven't you ever recompiled gcc with gcc? Granted, C isn't interpreted. However I've been forced to run Scheme interpreters that were written in Scheme. Scheme types adore the notion of recursion, thus they found this beautiful. Drop the word "performance" and they go through the roof, though...
BTW- I like PERL
--Lenny
As someone who worked with tom in the early perl days, let me say, and this is strictly MY opinion, I believe that Tom is persuing this, in no large part, because both his coffers and ego are feeling a drain from perl being in the shadows of Linux and OSS.
just my 2 cents.
Anyway, there's a simple reason why those of us who love Perl love Perl. It works. Having said that, reimplimenting UNIX utilities in Perl is really silly. Perl has a module system for a reason.
fish and pipes
Have you ever used Java? You know the way Netscape starts grinding the disk and doubling its RAM consumption when it runs into an applet? You want your system doing that every time you run "ls"?
So, okay, it's a pretty silly idea to have "ls" in Perl too. But last time I checked, Perl ran on more systems than Java, and though it's developing a bit of a gut these days, it's still the Laurel to Java's Hardy.
fish and pipes
# Wouldn't it make more sense to use something like
# Java? It's more widely supported, faster, and can
# be compiled to native code for even more speed.
# Not to mention the porting process would probably
# be easier, since you could cut and paste parts of
# the code.
ROTFL! Java more widely supported than Perl? You're kidding, right? And porting easier? You must not know Java well. Its similarity to C is about the same as Perl's. And speed? Hehehehe. You really crack me up.
While we're on the subject, an idea I've been playing with for quite some time is implementing perl as an OS kernel. Perhaps using the ext2fs and large portions of the Linux kernel as a base for hardware access and multitasking, but everything even remotely user-land using entirely Perl as the base.
Yes, its going a bit overboard on the Perl language. Still, such an OS would be enormously fun to play with. At least, I think so.
If you want to start a language war at least get your facts straight. Perl, in it's 10 years of life, has been ported to basically every platform, including Atari ST or mainframes. Java is still struggling to be on Linux. Second, Perl is several times faster than any Java app. native code compilation is in the works. BTW, the number of modules (classes) available for Perl today will be a target for Java for a long time.
... A good number of the (very few) times I've had to hit the reset button, perl was the cause.
...
then:
... it's the only way to get anything done on NT
Then your NT kernel is coded in perl, or what? If your machine drops, the kernel is guilty (or you did some nasty lowlevel stuff). If NT is uncapable of running perl without crashing then I'm very sorry for it.
If you talk about "resource hog/pig" in conjunction with "NT" and "perl", guess to which this is attributed (grammar?)...
Nils
Perl 5.005 is supposed to have some backends to other languages and binary. However, I don't know how good that works.
logan
A perfect example of how Python combines the power of MS-DOS batch file programming with the intuitiveness of INTERCAL.
spawn_of_yog_sothoth
It's not all that hypothetical.... If you're willing to brave an alpha version, have a look at Perlmacs. I expect to have a new version out RSN. It's getting stable enough to call beta.
i suppose this is amusing, but as quick-easy-and-portable as perl is, i just can't see any advantage over the GNU utils.
Tools written in perl will become available on brain-damaged systems that don't have those tools available, and you can take the SAME file to a different platform to get those tools ported. Think of it as a cast while the broken underlying OS sets. Or a crutch if it never does. Not perfect, but available.
The other aim of the project is to reduce the usage of backtick subs in perl scripts. These are what makes perl slow -- I have a driver and display architecture for some LED display boards written entirely in perl. It speed up by a factor of three when I removed the numerous calls to system utilities in favor of a "native" solution.
I've finally had it: until slashdot gets article moderation, I am not coming back.
The problem with using the GNU utils is that they don't help much if the bonehead sysadmins whose machine you are using either ... ) ( esp if you wrote the script in bash2 / ksh / zsh ... ) OTOH, perl makes this easy . Of course, for short scripts ( say 100 lines ) , shell scripts are nice. But I cringe at the thought of writing >500 line proggies in shell script ( I've tried, and it worked, but it was unportable, not to mention darned ugly ... )
(a) don't install them,
(b) don't install them completely and/or correctly.
The GNU utils work just fine on systems that have them. However, shell scripts tend to require some hacking at when their moved from one system to another ( even one *NIX system to another
--Elflord
--
Donovan Rebbechi
no freaking kidding!! this is the #1 reason why I haven't learned Python. #2 being that it forces you to be OO all the time. It may be a nice language in a lot of ways, but it's no match for perl in flexibility
well, I can see one: these things will be *much* easier to make than the GNU ones ever were, and far easier to debug. the counterpart is, of course, that they will be a little slower and use more memory. then again, no-one is suggesting to replace all of /bin and /usr/bin with perl scripts. *that* would be quite silly. OTOH, I wouldn't mind a system that used perl as its main userland language, with /bin and /usr/bin in perl with a global cache of bytecode-compiled scripts somewhere.
go read the site, dork. the point is not to run a Unix box with the GNU utilities replaced by the perl ones (unless you're doing it for the hack value, of course). it's to get instant-portable utilities on every single thing perl runs on. and it's *not* limited to Unix/Linux and win32.
the difference is that it takes about twice as long in C, even with the regexp library, thanks to having to malloc everything by hand. Python or maybe Java maybe could compare in development speed, certainly not C.
there's a perl interface to nvi. disclaimer: I haven't used it.
why put it on the *kernel*? hte kernel is supposed to be fast and low-level and every cache miss counts. everything on userland using perl as the base language, that's something I could agree to :-)
let's give perl a commandline switch so it will compile 2 file. then wehnever it is invoked it will test to see if the code has been modified more recently than the binary (it would then recompile). This would be really handy.
xm@GeekMafia.dynip.com [http://GeekMafia.dynip.com/]
No one-liners.
;-)
Sure, you can! Just use semicolons to separate statements and lambda. Then you end up with something as unreadable as the average Perl script
remove_one_or_more_newlines_at_end_of_the_char_str ing()
How about:
theString.removeNewlines()
or
theString removeNewlines.
There's more than one way to skin a fish in a barrel.
The gnu tools definitely need to be redesigned and rewritten, but in C not perl!!! less bloat not more! :)
And then back again! Write Awk in perl, then perl in that awk, then awk again in your new perl . . . Ultimately, you could waste literally DECADES of time that could -- in a less ideal world -- have actually been spent doing something useful, interesting, or productive.
Way to go, guys!
I like the idea of implementing all this stuff in a portable language, but why must it be such a horribly UGLY one?! Why, why . . . Yeah, sure, it does regular expressions -- but GNU has a perfectly good C library for that, right? What's the damn difference between writing in C with GNU's library, or writing in perl which probably uses the same damn GNU library anyway?!
Anyhow, as has been said above, all this guy's complaints (buffer length etc.) were addressed years ago -- in the GNU tools that they're using as examples. Uh, duh.
-j
"Christianity neither is, nor ever was a part of the common law." --
I seriously doubt that perl's regexp code is derived from GNU. After all, with perl you have your choice of licenses -- GNU or Artistic. If you choose Artistic, you can keep things as proprietary as you wish.
Really? Well, yeah, then I guess they're not using much GNU code there. Odd. Hey, what the hell, it's their own code. More power to 'em.
-j
"Christianity neither is, nor ever was a part of the common law." --
Your program didn't work for me.
I wonder why not?
Oh, it's because in Python, whitespace is
significant.
And now that it's gone, it's awfully hard to put it back because there's no other syntax indicating the block structure.
Too bad about that, huh?
Why draw the line at sed, awk, lex, yacc. What about an implementation of perl - written in perl?
On second thoughts, this all sounds completely pointless...
> Wouldn't it make more sense to use something
...
/any/ system and expect them to work: no porting involved.
> like Java?
No.
> It's more widely supported,
Wrong.
> faster,
By what metric?
> and can be compiled to native code for even more
> speed
So? That's not the point of these tools (at least, as I can see.) They basically are a set of perl utilities that make the life of a perl programmer working in a brain-dead environment easier.
Finally,
> Not to mention the porting process would
> probably be easier, since you could cut and
> paste parts of the code.
I'm unsure exactly what this means, but the point of all this is that Jane Perl can carry a CD with all of these scripts on it to
Java is Java and perl is perl and they solve different problems and represent different approaches. Personally, I prefer Smalltalk, but that's neither here nor there.
Regards,
JFB
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Perl Emacs? Wash your mouth out with soap!
I don't expect we'll ever see a federal judge hollering at a Microsoft witness to shut up already when testifying about how they messed with Perl (as happened indirectly when ActiveState started forking Perl a while back; saner heads including Larry prevailed, fortunately). That unique scene is reserved for Microsoft's testimony on Java, which closed the trial this past week.
As for Perl on Microsoft platforms, I've been using it daily since 1991 and it has made my professional life worth living, I can tell you. That and 4DOS/4NT, the command shell Microsoft should have done in 1983. (How they bought and butchered an already cut-down version of 4DOS from Norton/Symantec in the early 1990s is a story in itself.)
--------
Bill Gates Is My Evil Twin.
I'd have to say that Perl is every bit as overhyped as Java is. :-)
There it is. Right there. I don't rent Winnie-the-Pooh movies, I'm a grown man, I don't need this cutesey-wootsey crapola.
--
First off, if you can't have a sense of humor about what you do, it probably isn't worth doing. `chomp' is one of the most memorable commands in Perl 5, for that very reason. At least I seem to remember it well.
But you would rather have something like:
s/(.*)\n$/$1/;
That's much easier to remember. If only all Perl syntax was that clear.
Which brings me to one reason that I like Perl a great deal: "There's more than one way to do it."
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I love Perl. I love Java. They are different,
use them differently. Blanket statements like,
"I would venture to guess then a good perl
programmer could out produce a good jave [sic]
programmer by 2 to 1," are incredibly ignorant.
There are, believe it or not, things that can
be easily done in Java and not done AT ALL in Perl. Likewise, there are things that can be done
in Perl (regex/text stuff) that is much more
difficult to do in Java (but probably not impossible).
That's why we have >1 language available.
So let's not be bandying about such crazy notions.
Perl has how many years on Java? Apples and
oranges are no fun to compare. You would probably
be lying to yourself if you claimed that Java does
not have amazing distribution and maturity for
such a young language.
If you MUST compare languages (a trivial and useless exercise usually), let's at least compare Perl when it was 4 years old with Java now.
That'd be a fairer comparison, say, like apples and pears.
However, that doesn't mean that it's either smart or useful to reimplement the Unix command toolset in Perl. On a busy server, Perl's resource footprint will still trip you up. We have had to reimplement a number of small Perl tools in sh, awk or C by virtue of the fact that even with a half-gig of RAM, we cannot afford to spawn fifty Perl processes every second.
Perl is still a great tool for a lot of our applications. Just not all of them. It might be fun to rewrite zork in Perl, but we're still going to be using good old-fashioned egregious GNU tools for getting real work done.
I think perl and java are going to be something to think about, there is alot you can do with it. I run a web hosting provider, we charge $50.00 setup and then no monthly charges, People love it, And they get all the neato things like cgi-bin, etc.. click here for more info, But anyways, i think perl is a way to get things done on the web, Our FiP, "Free Internet Project" is going to use alot of perl and database kinda stuff. But i think alot of providers are not gonna like us, Just because we are doing something, no one has ever done.
Got shack?
ShackCentral Network
Worlds best gaming network!!!