Lots of Perl people do tell me that they have trouble reading other people's Perl code. The
examples you give are four extremely readable Perl snippets. They are not typical.
I've already said, that I personally don't know
any Perl coder (excluding beginners) who doesn't
know the Perl syntax and semantics,
and who therefore doesn't understand Perl code
of other people, written in different styles.
Even so,
they are enough to confuse a new Perl programmer which I would say is reason enough to
choose one way and stick with it.
Remember that you're a beginner only at the
beginning, and after you learn it, you're
an expert for the rest of your life.
That is why I don't prefer to save
few hours (or even few months) at the start
and stick with something simple and easy
to the end of my days.
I prefer to chose
what's better for me in the long run.
And when you find that there is a bug in that code? Or need to add a feature that
cannot be added by subclassing (i.e. MOST features!)
Then I fix the bug.
Isn't that quite obvious?
I've already told you that I don't have problems
in understanding Perl syntax.
Perl is designed somehow similar to natural languages.
I know that that it the mantra of the Perl community but that doesn't make it either
true or relevant.
What is your point?
Do you say that Perl is not"designed somehow similar to natural languages"?
When I'm working together on a project artistry is secondary to engineering. Natural
languages are not typically used for engineering. In fact, we tend to use languages that
are more formal: like algebraic symbols or pseudo-code languages.
That is exactly why I'm saying that
"Perl is designed somehow similar to natural languages".
It's a quite unique design goal.
If every programming language had this
property, then it would be quite pointless
talking about it to explain
what I like about Perl, wouldn't it?
The descriptive power of a natural language is not proportional to either its vocabulary
or its grammatical complexity.
But you have to agree, that
"A language that is artificially simple induces artificial complexity in all solutions written in that language."
As I'm sure you've been told, the problem solving
power of a programming language is exactly equivalent to that of any other
programming language. Really smart people can say really smart things in
ASSEMBLY LANGUAGE. So if you want to compare languages you have to look at
other factors such as cost of development, cost of maintenance, amount of fun (Perl
probably wins in that category for some people), etc.
If I didn't consider anything other than the bare
ability to solve problems,
I wouldn't see the difference
between any two Turing-complete languages,
and I'd be probably using Unlambda instead
of Perl, because the syntax is much simpler
to learn,
while it's still Turing-complete.
If what you really mean to say is that Perl is more fun, for you, and you've actually tried
the other languages to compare, then I will support that wholeheartedly.
And what did you think I could mean otherwise?
I was telling different stories and
showing many code examples,
to illustrate what I like in Perl,
not why Perl is better than your favorite
language,
while strongly stating that these are my
subjective opinions,
from
the beginning,
through the whole thread.
Please read the disclaimer at the end
of this post.
But there is a
price to be paid: and whoever has maintain your code is probaby paying it. And there is
no payoff in descriptive power or cost of development.
Here you assumed that: I use Perl,
therefore my code is less maintainable.
Which is irrational,
I hope you realize that.
I'll just add that I've cleaned up hideous code in C, C++, ASM, Perl, Basic, VB,
ObjectPAL, and probably other languages. Usually because somebody didn't know a
simpler way to accomplish the task and ended up reinventing the wheel, or used a bubble
sort where a quicksort would do, etc. Or, in nasty cases, coded their own quicksort as an
optimization, because they didn't realize the libraries contained a quicksort routine...
You're right.
The most important mistakes which I've seen,
was caused by the lack of knowledge
about CPAN or STL.
The syntax is on the second place.
Such programs run much slower, have more bugs,
and are harder to maintain,
but what's even more important,
it took much more time
(and money) to write them.
That is why it's not smart to hire
a poor programmer for $10/hour
to produce some crap after a week of full-time work,
when someone for $100/hour can do it better
in few hours.
Hackers with high rates
are often much cheaper in the long run,
that's something which is often being not
fully understood by the management.
(The side effect of this though is programmers who do terribly complex list operations
without an understanding of what would be involved in coding them manually, and
thus no idea of what is involved in processing them. But that's my example of why
formal education (forcing you to do stuff that doesn't immediately make sense, like
ASM) is really a good thing.)
That's a very good point.
Only when I know Assembler,
I can fully understand what is really going on,
when I run my C program.
The same is true with e.g. Perl,
when I know C and perl internals.
I didn't write any assembly code in the last
five years, but still I use that knowledge
even while hacking Perl.
You have to know how much and what exactly is
being done,
very low in the machine,
when you write
print "$_ $hash{$_}\n" for sort keys %hash;
to fully understand your own abstract code.
That's true that you have to master hacking
on every level of abstraction, to truly
master any one of them.
But speaking about formal education,
I actually haven't got much, to be honest.
Unless you count dozens of books read,
as a formal education.
But don't get me wrong,
it's not that I think that I don't need a
more formal education,
it's actually quite complicated,
mostly from the economical standpoint.
Perl can make an unreadable program,
but it'd be an unreadable C program,
just ten times longer.
And I'm sure many of the people
I've worked with
(myself included I'm sure, at times)
could mangle it even with Python,
if we were rushed.
Good point.
Before I knew Perl, I used to write
text-processing programs in C.
Sometimes many screens of C code,
for what I write in Perl one-liners today.
And however obfuscated would it be,
it's still just one line.
Besides, I do like to have a choice.
I write unreadable, quick and dirty
Perl one-liners every day,
and it's a Good Thing that I can write
them in few seconds directly from the
shell command line,
which would be impossible witch such verbose
languages like Java.
It's not that I have to write
larger programs that way, it's however
important that I can if I want to.
You know, you sometimes just want to know hexadecimal values of ip addresses in Net-HOWTO.txt.gz, and you just want to write:
hit enter, get answers, and forget about this
crap. Not to design a nice and elegant
program.
This code is ugly, it's probably not efficient,
elegant, fast or readable,
but I have my answers after few second from
thinking my questions,
which is quite important
to me.
(BTW, I wonder how the same would look in
Python or Java - not that I want to
start any flame wars whose language is
better -
I just wonder how exactly the same filter
would be written by Java and Python wizards.
Would it be smaller? Larger? Simpler?
More complicated? More elegant?
I'm curious.)
And the ability itself to write ugly code,
like that above, didn't prevent
Tim Bunce from writing DBI,
or Lincoln Stein from writing CGI.pm,
which are both great examples of beautiful
Perl code.
Disclaimer:
(this is for some people, who get this thread
very personally, even when I
stated at the very beginning:
"Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that
it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally
prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally
powerful languages today.")
I do not think that Perl is better than
[insert your language here].
I'm just telling about things which I like
in Perl, with many examples of code,
real-life situations, etc.
I hope that maybe people find it somehow interesting.
I'd also love to hear other interesting
stories, about other languages.
When people tell me about
advantages of Python I'm not mad that
it means that Python is better than Perl,
or that my IQ is lower than theirs,
or anything like that
- I listen to what they have to say
and I'm glad that I can learn something
new.
It's about time for many people to understand
the same.
If you can't figure out the majority of what the programmer is getting at... There's
more than one way to RE-do it.
I don't know what painful memories do you have
with redoing something
(do you know about CPAN?),
but
if you can't figure out the majority of what the programmer is getting at...
There's a sign, that you need more
education. Sad but true.
This includes much more than only programming.
The problem is that programmers that care will differ radically in which the consider
the most readable one and many programmers just don't care at all. So in either case
we have trouble reading each other's code because even when we are trying our hardest
we can easily make code that is mutually incomprehensible.
When you know the syntax and semantics,
you won't have problems reading different
styles. At least I don't have any problems,
and I don't consider myself a Perl guru.
Read The Camel Book and you'll learn
everything you need to understand any Perl code.
I don't know personaly any Perl coder who
would not understand the Perl syntax.
It doesn't meter if someone has written
print "ITEM: $_\n" for @items;
or
for(@items){ print "ITEM: $_\n" }
or
foreach $item (@items) { print "ITEM: $item\n" }
or
print map {"ITEM: $_\n"} @items;
when you know the basics of Perl,
you understand it.
Also you have to remember a very important
thing,
true for Perl, Python, Smalltalk, C++,
Ruby, Java or any other higher-level language.
When you have a good code, you don't have to
fully understand or often even read the
implementation details to maintain it
(not to say about simply using it).
All you need is to understand the interfaces.
When you have a working class and you need to
add a new functionality, you shouldn't edit
the implementation. You should subclass it
instead.
These are the most basic concepts of
code design for future reuse.
But you have to actually design the code
in the first place, not just write some crap.
Python cannot prevent
this but it can encourage a
consistent and readable
style. The language encourages
good taste. No more, no less.
Perl is designed somehow similar to
natural languages.
You don't have anything in English, Latin,
Polish, Russian or any other natural language,
which
would "encourage a
consistent and readable
style",
still there's a lot of great art.
Remember that there's not only one good style
of English, almost every poet, every novelist,
every writer has his or her own, unique style.
And that freedom of choice also means that
you can hear lots of crap.
But we can't restrict English to only a subset
of lexical and semantic rules,
because any restrictions which would prevent
stupid people from saying stupid things,
would also
prevent
really smart people from saying really smart things.
Seeing as how parrot is being developed pretty much entirely by Perl developers (heck,
the development is being done on the perl6-internals mailing list), I think it's unlikely
that it'll ever be adopted by the Python community.
Given that a Google search
for "Parrot" on the Python.org
shows 570 matches, I don't think so.
Does Parrot even support real type
systems, or does it only support Perl's broken "scalars are scalars" type system?
If you had ever clicked
oneofthelinks
in my post,
you'd have known that.
There are these basic data types:
IV (integer)
NV (floating-point)
STRING (encoding-independent string)
PMC (Parrot Magic Cookie)
Parrot Magic Cookie type is the whole magic here.
Let me quote Simon Cozens' article
Parrot: Some Assembly Required,
emphasis is mine:
Vtable Datatypes
The next major thing that Parrot needs to implement is PMCs;
these are almost like Perl 5's SVs, only more so. A PMC is an
object of some type, which can be instructed to perform various
operations. So when we say
inc P1
to increment the value in PMC register 1, the increment method is
called on the PMC - and it's up to the PMC how it handles that
method.
PMCs are how we plan to make Parrot language-independent - a
Perl PMC would have different behavior from a Python PMC or a
Tcl PMC. The individual methods are function pointers held in a
structure called a vtable, and each PMC has a pointer to the vtable
which implements the methods of its "class." Hence a Perl
interpreter would link in a library full of Perl-like classes and its
PMCs would have Perl-like behavior.
And about
``Perl's broken "scalars are scalars" type system''.
I won't argue with you, as you obviously
have no idea what are you talking about,
but other people may be interested in this subject
as well, so I'll point out where to find
informations on how these things
are going to change in
Perl 6:
I haven't finished reading
the article yet,
because one thing caught my entire attention:
Andrew Morton: Well, I've always been that-way inclined. Back in '86 I
developed a build-it-yourself 68000-based computer. Both the
hardware and its unix-like operating system. We sold about 400 of
them. We licensed Minix from Macmillan and my great friend Colin
McCormack ported it - I think this may have been the only non-PC
port of Minix. The Applix 1616 project was fun, and a lot of people
learned a lot of things.
So I found The Applix 1616 project website.
Very interesting read.
I'd love to see something like this today.
If anyone knows anything about something
similar to 1616 which is available today,
please share with us.
The original poster's point still stands though - most Perl code is utter crap and
completely unreadable. This is not to say that Perl is inherently worse than Python, and
good Perl code is probably comparable to good Python code (maybe better?). But Perl is
much more lenient in allowing really really horrible code, which for some reason a lot of
people take advantage of.
Most of everything is uter crap.
This includes every aspect of human creation.
a one-liner to be typed directly
at a shell prompt,
which does exactly the same. Much simpler,
isn't it?
It's just that, like Larry Wall has well said,
Give people enough rope to hang themselves, and they'll usually figure out how
not to, after several successes.
I'll give you another good example.
Some time ago I tuned Perl code of one
Senior Design Technologist
(I won't tell you the name of his company,
for obvious reasons).
This was one of my records, so I have
the exact stats.
His program had 190 lines of code in
6530 characters and he asked me if
the same can be done in more elegant way.
I wrote my version from scratch, which had
only 13 lines of code
in 227 characters, i.e. it was
30 times smaller - it's 3% of original size.
It was also over 900% faster than the original
(doing exactly the same of course),
as a side effect of my elegance-tuning.
And no, it wasn't obfuscated and I wasn't
writing it just to use as small space
as possible.
Later I wrote a minimal version of that program and it had 2 lines in 112 characters (including a new-line), so the real 13-lines version was
quite readable, with descriptive function and
variable names, indentation, etc.
So, my point is:
Most of everything is uter crap.
This includes Perl code.
But it says more about programmers than about
the language itself.
Like the fact that most of text available on
the Internet is crap, doesn't mean that
the English or any other
natural language is crap.
The problem with newbie Perl programmers is that
they usually write in C, not in Perl.
The Perl motto is
There's More Than One Way To Do It.
That means that you can also program
using a C-style if you want.
This is sometimes very useful,
but it's often abused by beginners.
So it's very common to see a code like this:
You see my point.
I'll quote Larry once again:
Perl is designed to give you several
ways to do anything, so consider picking
the most readable one.
That said,
I may surprise you,
that I am going to learn Python.
For few reasons:
It's a nice and powerful language,
with many unique features
(like e.g. the idea of using the indentation
to define blocks scope) so it's
definitely worth learning,
even if it won't be my main language,
and the WorldForge
AI scripts are written in Python.
OK, I said a lot, much more than I originally
wanted to...
Now you should tell me something interesting
about Python,
as a revenge.:)
No what I actually did was install Red Hat. That's something I thought I'd never do, but
I don't regret it. When debian adopts a sensible release cycle I will come back to it.
If you just don't like Debian and prefer Red Hat,
then good for you, but don't spread
misinformation.
What I'm trying to say here, is that
there is not one Debian. There's:
"Both the Debian and OpenBSD projects exhibit many of the aforementioned
characteristics which help explain why they are the Open Source UNIX
operating systems with the best security record."
That means that you won't see the latest
untested toys in Debian stable, like you won't
see them in OpenBSD.
There is no point in arguing that Debian stable
doesn't have the newest software, because if
you want to run the newest (which also means
untested) software, that means you don't want
Debian stable. You should use one of the other
available versions, unstable or testing.
I usually find the testing version the best
for my own use, but I still use stable Potato
on few mission critical machines, which
have never disappointed me so far.
The whole issue is that woody defaults to 2.2.x. You could probably use a 2.5.x kernel as
well. The whole point is that in about two years or whenever woody's successor is
announced, people will still be installing woody distros with 2.2 kernels.
No.
You can always use whatever you want,
you can build your own kernels, from
many different trees etc.,
but the point is that
2.4.x kernels have been already
available as
binary packages in
base section of Woody for quite some time now.
Woody is going to be obsolete the day it is released. The day after people will already be
pointing endusers to testing because it's a public secret that stable really stands for
seriously out of date.
It's one thing to program in good style, but it's another to have the language
force you to. Yes, I'm still resentful over that.
It's a well known fact, even among Perl advocates, that the
vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean
code in Perl, but the language certainly doesn't encourage it.
Please, don't argue Perl vs. Python,
it will only start pointless flame wars.
Let's agree that it's just a matter of taste.
Remember,
There's More Than One Way To Do It.
I personally prefer Perl,
but it's a totally subjective opinion.
Perl and Python are more or less equally
powerful languages today.
But what I'm really looking forward to is
Parrot,
i.e. the virtual machine for
Perl 6
and, I hope, also for
Python,
Ruby,
Tcl
and maybe few other good languages.
It's a VM and a low-level assembly language for
that VM - the language, to which Perl 6
(and hopefully other high-level languages) will
be compiled to
(as a layer between Perl and the VM bytecode)
like C is compiled to
machine-specific Assembbler
(between C and the machine code).
See the examples of Parrot use and read
Parrot: Some Assembly Required
to see what it is.
Also the perl6-internals at perl.org mailing list archives is a good place to start.
I'd love to see Perl and Python playing nice together, thanks to Parrot.
It'd be really cool if I could write
a program in Perl with someone who writes his
part in Python, and another one writing in Ruby.
I would just use their classes and objects,
they would just use mine as well, without
worrying about the language of our
implementation.
Parrot can be the answer here.
Would it be the end of language flame wars?
I do hope so.
All I can say is this: I'm deeply disappointed they aren't using a 2.4 kernel. I'm a debian
potato devotee. Going to woody, and staying with the 2.2 kernel is a letdown.
I'm hoping they're serious about changing to a much shorter development cycle. 2.2
was out of date enough when I installed it over a year ago.
You should've installed Woody then.
Most of the time you have three versions to
choose from: stable, testing/frozen and unstable.
When you need a system which will not ever crash
after years of heavy load, use stable.
If you want more decent software, use testing.
If you want the newest versions of software
from yesterday, use unstable.
It's Good Thing because you have a choice,
so don't complain that you're not forced to use
the latest untested software,
it's up to you.
And remember that unstable Debian is
usually more stable than any other distro.
you very much can have an smtp server that does not listen on a tcp port, but it can only be
used for outgoing mail. Many people use this configuration with sendmail so they can send
mail directly from there workstation, but recive mail on another system. Sendmail is just
invoked from the command line, so it doesnt need to listen on a tcp port.
Yes, I know (I've configured quite a few
workstations that way),
but I consider such configuration an smtp
client, rather than smtp server.
Sendmail/Exim/etc. are clients in smtp
transactions here, and can't act like
a server (from the network standpoint).
What I was saying about is that, while
you of course can eliminate open relays by
denying access from every host with open
smtp port, you will also eliminate that way,
every host which can get mail,
not only those who can get mail from everyone
and send it to anyone, i.e. you deny access
from every public smtp server.
It's like eliminating misconfigured web servers
by denying access from every host with port 80
open.
Yes, after those ten hours I wasn't sure if I understand what "localhost" means, so I wrote 127.0.0.1 which seemed to be the only safe
notation at that time.
And those ten hours, was a constant fight.
Of course I didn't know I have an open relay
until the spammers attacked.
I was manually killing smtp servers and
removing messages from the queue with
something like
killall -KILL exim; for m in `exim -bp | perl -ne 'print "$1\n" if/\b(\w{6}-\w{6}-\w{2})\b/'`; do exim -Mrm $m; done
whenever I noticed, that they were back,
in my xterm with
unplugging the network
cables etc., while reading the exim docs,
smtp specification, faqs, howtos, rfcs, everything,
and wondering "what the hell can be wrong?".
Believe me, something like this can quickly
drive you insane.
When I found out what was wrong, I shouted
quite loudly
"Ale ja jestem glupi!" (which in Polish means
"How stupid am I!" or something like that)
and after a while of
silence wondering if anyone heard it
(I usually don't shout alone so it's
pretty embarrassing feeling, you know),
I just changed the config to every
host written as literal ip address.
Eventually, after few days of comparing
slash notation definitions
from many independant sources,
I wrote it as 192.168.1.0/30.
But I still keep those comments in my/etc/exim.conf:
# dobra maska:
#host_accept_relay = localhost:192.168.1.0/30
(zla maska means bad mask in Polish,
and dobra maska means good mask)
This is a frightening story of a
hard and deadly fight
of human versus his eternal enemy,
his own stupidity.
100% of adrenaline.
This is exactly what kids are talking about
when they say:
"Mommy, I wanna be a sysadmin when I grow up."
Wouldn't it just be a lot simple if the mail servers, when they receive a connection
from an smtp server to deliver mail, make another connection back to the smtp server
on port 25. If the connection can be made, then it means that it's an open port, and
therefore the mail is rejected?
It means that the port is open
(you can't have smtp server with smtp port closed),
but it doesn't
mean that it's an open relay.
You'd have to make an smtp transaction.
When you set up a mail server,
never EVER write:
host_accept_relay = localhost:192.168.1.0/2
when what you want is
host_accept_relay = localhost:192.168.1.0/30
It took me ten long hours to figure out that
I allowed 1/4 of the whole Earth to use my relay,
when I wanted 4 computers on a private network.
And it was probably the worst 1/4 of the Earth,
every C-class network...
It was a long day which I will never forget.
In this ten hours I read more about smtp
than ever before...
So remember kids, don't do this at home!
Until they change their business model to allow them to generate revenue for
producing secure, stable code, they will never succeed in generating secure, stable,
well-architected products.
I think it's the other way around.
Unless people will stop buying insecure products,
nothing will ever change.
Voting with our wallets, we can change the
corporations any way we want.
If all people decide to buy only cars with
built in CB radio,
we would see every car producent making only
cars with CB radios built in.
It's really that simple.
Slashdot Mirror
print "$_ $hash{$_}\n" for sort keys %hash;
to fully understand your own abstract code. That's true that you have to master hacking on every level of abstraction, to truly master any one of them.
But speaking about formal education, I actually haven't got much, to be honest. Unless you count dozens of books read, as a formal education. But don't get me wrong, it's not that I think that I don't need a more formal education, it's actually quite complicated, mostly from the economical standpoint.
Good point. Before I knew Perl, I used to write text-processing programs in C. Sometimes many screens of C code, for what I write in Perl one-liners today. And however obfuscated would it be, it's still just one line.Besides, I do like to have a choice. I write unreadable, quick and dirty Perl one-liners every day, and it's a Good Thing that I can write them in few seconds directly from the shell command line, which would be impossible witch such verbose languages like Java. It's not that I have to write larger programs that way, it's however important that I can if I want to.
You know, you sometimes just want to know hexadecimal values of ip addresses in Net-HOWTO.txt.gz, and you just want to write:
shell$ zcat Net-HOWTO.txt.gz | perl -ne 'print"$1\n"for/((\d+\.){3}\d+)/g' | sort | uniq | perl -pe 's/(\d+)/sprintf"%.2X",$1/eg;y/.//d'
hit enter, get answers, and forget about this crap. Not to design a nice and elegant program. This code is ugly, it's probably not efficient, elegant, fast or readable, but I have my answers after few second from thinking my questions, which is quite important to me. (BTW, I wonder how the same would look in Python or Java - not that I want to start any flame wars whose language is better - I just wonder how exactly the same filter would be written by Java and Python wizards. Would it be smaller? Larger? Simpler? More complicated? More elegant? I'm curious.) And the ability itself to write ugly code, like that above, didn't prevent Tim Bunce from writing DBI, or Lincoln Stein from writing CGI.pm, which are both great examples of beautiful Perl code.
Disclaimer: (this is for some people, who get this thread very personally, even when I stated at the very beginning: "Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today.") I do not think that Perl is better than [insert your language here]. I'm just telling about things which I like in Perl, with many examples of code, real-life situations, etc. I hope that maybe people find it somehow interesting. I'd also love to hear other interesting stories, about other languages. When people tell me about advantages of Python I'm not mad that it means that Python is better than Perl, or that my IQ is lower than theirs, or anything like that - I listen to what they have to say and I'm glad that I can learn something new. It's about time for many people to understand the same.
It doesn't meter if someone has written
print "ITEM: $_\n" for @items;
or
for(@items){ print "ITEM: $_\n" }
or
foreach $item (@items) { print "ITEM: $item\n" }
or
print map {"ITEM: $_\n"} @items;
when you know the basics of Perl, you understand it.
Also you have to remember a very important thing, true for Perl, Python, Smalltalk, C++, Ruby, Java or any other higher-level language. When you have a good code, you don't have to fully understand or often even read the implementation details to maintain it (not to say about simply using it). All you need is to understand the interfaces. When you have a working class and you need to add a new functionality, you shouldn't edit the implementation. You should subclass it instead. These are the most basic concepts of code design for future reuse. But you have to actually design the code in the first place, not just write some crap.
Perl is designed somehow similar to natural languages. You don't have anything in English, Latin, Polish, Russian or any other natural language, which would "encourage a consistent and readable style", still there's a lot of great art. Remember that there's not only one good style of English, almost every poet, every novelist, every writer has his or her own, unique style. And that freedom of choice also means that you can hear lots of crap. But we can't restrict English to only a subset of lexical and semantic rules, because any restrictions which would prevent stupid people from saying stupid things, would also prevent really smart people from saying really smart things.- IV (integer)
- NV (floating-point)
- STRING (encoding-independent string)
- PMC (Parrot Magic Cookie)
Parrot Magic Cookie type is the whole magic here. Let me quote Simon Cozens' article Parrot: Some Assembly Required , emphasis is mine: And about ``Perl's broken "scalars are scalars" type system''. I won't argue with you, as you obviously have no idea what are you talking about, but other people may be interested in this subject as well, so I'll point out where to find informations on how these things are going to change in Perl 6:- Apocalypse 2
- Built-in Data Types
- Variables
- Properties
- Exegesis 2
For a good introduction to Perl 6 in current shape read Larry Wall's Apocalypses and Damian Conway's Exegeses:- Apocalype 1
- Apocalypse 2
- Exegesis 2
- Apocalypse 3
- Exegesis 3
- Apocalypse 4
For more detailed info, join the mailing lists and read the archives:- perl6-language at perl.org
- perl6-internals at perl.org
There's more info about in on dev.perl.org - the Perl 6 homepage.Few days ago, someone posted this Perl code:
to which I posted this: a one-liner to be typed directly at a shell prompt, which does exactly the same. Much simpler, isn't it? It's just that, like Larry Wall has well said, Give people enough rope to hang themselves, and they'll usually figure out how not to, after several successes.I'll give you another good example. Some time ago I tuned Perl code of one Senior Design Technologist (I won't tell you the name of his company, for obvious reasons). This was one of my records, so I have the exact stats. His program had 190 lines of code in 6530 characters and he asked me if the same can be done in more elegant way. I wrote my version from scratch, which had only 13 lines of code in 227 characters, i.e. it was 30 times smaller - it's 3% of original size. It was also over 900% faster than the original (doing exactly the same of course), as a side effect of my elegance-tuning. And no, it wasn't obfuscated and I wasn't writing it just to use as small space as possible. Later I wrote a minimal version of that program and it had 2 lines in 112 characters (including a new-line), so the real 13-lines version was quite readable, with descriptive function and variable names, indentation, etc.
So, my point is: Most of everything is uter crap. This includes Perl code. But it says more about programmers than about the language itself. Like the fact that most of text available on the Internet is crap, doesn't mean that the English or any other natural language is crap.
The problem with newbie Perl programmers is that they usually write in C, not in Perl. The Perl motto is There's More Than One Way To Do It. That means that you can also program using a C-style if you want. This is sometimes very useful, but it's often abused by beginners. So it's very common to see a code like this:
where you could just write: You see my point. I'll quote Larry once again: Perl is designed to give you several ways to do anything, so consider picking the most readable one.That said, I may surprise you, that I am going to learn Python. For few reasons: It's a nice and powerful language, with many unique features (like e.g. the idea of using the indentation to define blocks scope) so it's definitely worth learning, even if it won't be my main language, and the WorldForge AI scripts are written in Python.
OK, I said a lot, much more than I originally wanted to... Now you should tell me something interesting about Python, as a revenge. :)
- Debian stable version (today it's Potato),
- Debian testing version (Woody) and
- Debian unstable version (Sid).
Have you read The Myth of Open Source Security Revisited ? That means that you won't see the latest untested toys in Debian stable, like you won't see them in OpenBSD. There is no point in arguing that Debian stable doesn't have the newest software, because if you want to run the newest (which also means untested) software, that means you don't want Debian stable. You should use one of the other available versions, unstable or testing. I usually find the testing version the best for my own use, but I still use stable Potato on few mission critical machines, which have never disappointed me so far.Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today. But what I'm really looking forward to is Parrot, i.e. the virtual machine for Perl 6 and, I hope, also for Python, Ruby, Tcl and maybe few other good languages. It's a VM and a low-level assembly language for that VM - the language, to which Perl 6 (and hopefully other high-level languages) will be compiled to (as a layer between Perl and the VM bytecode) like C is compiled to machine-specific Assembbler (between C and the machine code). See the examples of Parrot use and read Parrot: Some Assembly Required to see what it is. Also the perl6-internals at perl.org mailing list archives is a good place to start. I'd love to see Perl and Python playing nice together, thanks to Parrot. It'd be really cool if I could write a program in Perl with someone who writes his part in Python, and another one writing in Ruby. I would just use their classes and objects, they would just use mine as well, without worrying about the language of our implementation. Parrot can be the answer here. Would it be the end of language flame wars? I do hope so.
"You want it in one line? Does it have to fit in 80 columns?" - Larry Wall
That's insightful and informative indeed, but wrong. Why won't you just check it? You can use "2.4.16 or .17",
they're in binary base packages and have been for some time now.
Sorry, you can use 2.2.20 or 2.4.13 2.4.14, 2.4.16 and 2.4.17.
See the list of base packages.
(and always you can build your own kernel of course)
So why won't you use Sid with 2.4.17 then?
You should've installed Woody then. Most of the time you have three versions to choose from: stable, testing/frozen and unstable. When you need a system which will not ever crash after years of heavy load, use stable. If you want more decent software, use testing. If you want the newest versions of software from yesterday, use unstable. It's Good Thing because you have a choice, so don't complain that you're not forced to use the latest untested software, it's up to you. And remember that unstable Debian is usually more stable than any other distro.
use apt-get...
2.2.20 AFAIK. It's a rock solid kernel.
http://staging.infoworld.com/articles/hn/xml/02/02 /14/020214hnwifispec.xml?Template=/storypages/prin tfriendly.html
What I was saying about is that, while you of course can eliminate open relays by denying access from every host with open smtp port, you will also eliminate that way, every host which can get mail, not only those who can get mail from everyone and send it to anyone, i.e. you deny access from every public smtp server. It's like eliminating misconfigured web servers by denying access from every host with port 80 open.
host_accept_relay = 127.0.0.1:192.168.1.1:192.168.1.2:192.168.1.3
Yes, after those ten hours I wasn't sure if I understand what "localhost" means, so I wrote 127.0.0.1 which seemed to be the only safe notation at that time. And those ten hours, was a constant fight. Of course I didn't know I have an open relay until the spammers attacked. I was manually killing smtp servers and removing messages from the queue with something like
killall -KILL exim; for m in `exim -bp | perl -ne 'print "$1\n" if /\b(\w{6}-\w{6}-\w{2})\b/'`; do exim -Mrm $m; done
whenever I noticed, that they were back, in my xterm with
tail -f /var/log/exim/mainlog | perl -ne 'print"\a$_"'
unplugging the network cables etc., while reading the exim docs, smtp specification, faqs, howtos, rfcs, everything, and wondering "what the hell can be wrong?". Believe me, something like this can quickly drive you insane. When I found out what was wrong, I shouted quite loudly "Ale ja jestem glupi!" (which in Polish means "How stupid am I!" or something like that) and after a while of silence wondering if anyone heard it (I usually don't shout alone so it's pretty embarrassing feeling, you know), I just changed the config to every host written as literal ip address.
Eventually, after few days of comparing slash notation definitions from many independant sources, I wrote it as 192.168.1.0/30. But I still keep those comments in my /etc/exim.conf:
# ZLA MASKA:
#host_accept_relay = localhost:192.168.1.0/2 # ZLE!
# dobra maska:
#host_accept_relay = localhost:192.168.1.0/30
(zla maska means bad mask in Polish, and dobra maska means good mask)
This is a frightening story of a hard and deadly fight of human versus his eternal enemy, his own stupidity. 100% of adrenaline. This is exactly what kids are talking about when they say: "Mommy, I wanna be a sysadmin when I grow up."
When you set up a mail server, never EVER write:
host_accept_relay = localhost:192.168.1.0/2
when what you want is
host_accept_relay = localhost:192.168.1.0/30
It took me ten long hours to figure out that I allowed 1/4 of the whole Earth to use my relay, when I wanted 4 computers on a private network. And it was probably the worst 1/4 of the Earth, every C-class network... It was a long day which I will never forget. In this ten hours I read more about smtp than ever before... So remember kids, don't do this at home!
That one who modded this post down as flamebait, obviously doesn't know the history.