Slashdot Mirror
Perl 5.8.0 Released
twoshortplanks writes "The latest version of Perl has been released, with new features such as better Unicode support, a new threads implementation, new IO layer support, and a whole plethora of bundled modules - plus a wonderful collection of regression tests and new documentation. The release notes and links to mirrors for download are on dev.perl.org." This is not a release candidate, it's the real thing, representing over two years of work by patch pumpkin holder Jarkko Hietaniemi and his merry band. Hugo van der Sanden is the new pumpking for perl 5.10.
good coders can write readable code in any language. bad coders cannot. So just what are you saying?
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
I assume that the source only is released so far. Time to start porting it to HPUX! I wonder if this will fix problems with Oraperl on HPUX 10.20... probably not.
Moderation: Put your hand inside the puppet head!
Many of you have noticed that CmdrTaco has changed a few things in Slashcode this week. The three changes I've observed so far are:
Karma displayed as an adjective
Karma score determines posting limit
Client IP addresses placed in readonly mode more easily
None of these are earth-shattering, so I'm going to cover them as a group.
Karma score determines posting limit:
Taco reminds everyone in this (non-archived) post that:
"KARMA DOES NOT MATTER". He goes on to prove this by making karma determine how many times you can post a day. Remember, you shouldn't use all caps, because caps is like being wrong. Here's a summary of how important karma actually is now, and while some of these details may be off, this reflects my best knowledge from reading Slashcode:
Karma: (PPD is posts per day)
26_50 : Post at 2, 25 PPD, Karma = Excellent
12_25 : Post at 1, 10 PPD, Karma = Good
1_12 : Post at 1, 10 PPD, Karma = Positive
Zero : Post at 1, 10 PPD, Karma = Neutral
-9_-1 : Post at 0, 2 PPD, Karma = Bad
-24_-10: Post at -1, 2 PPD, Karma = Terrible
Note that (as Taco points out) these are the default values in Slashcode atm; Slashdot itself may at any time be running with different values. Each IPID/SubnetId is allowed 10 AC posts per day, unless an IP is being 'abused', at which point things get more complicated. So the land of -1 trolling should be moving to threshold Zero, AC. Taco stated on IRC that the rate limiting change was made to prevent scripted crapflooding from -1 Accounts. I'd love to see a link to this crapflooding (I've never seen it) so if any of you have seen it, email me at operation_mongoose 'at' ziplip.com.
Karma adjectives:
Here's CmdrTaco's journal on the subject, and here's the non-archived discussion on the topic. Read it while you can, it will be deleted in two weeks. Taco states that he didn't just enable comments in his journal because he "didn't want people trolling his journal". Additionally, all the comments he made WRT to changes in the Karma system will be deleted. Make of this what you will.
Client IP addresses placed in readonly mode more easily
My details on this aren't very good, but as many have pointed out, the "readonly" error message seems to be popping up more often. The message is "You can't post to this page." and it appears when your IP address has been marked readonly. Basically, readonly mode means you're banned from posting anything, but you can still read the site. I think the only modification was one to the criteria for being placed in readonly mode, but I don't know exactly what the change is, only that pudge mentioned in IRC that he turned it up too high, and that now everything should be "Ok". If you've been placed in readonly mode, feel free to leave a comment and tell us what you did to get there. AFAIK, you can be placed in readonly mode for posting Offtopic comments as AC, or for posting a lot of comments that receive negative moderation as AC (ex: Windows is a pretty good O/S). That's just my experience; fill me in on yours.
That's all for now,
-s.
patch pumpkin n. [Perl hackers] A notional token passed around among the members of a project. Possession of the patch pumpkin means one has the exclusive authority to make changes on the project's master source tree. The implicit assumption is that `pumpkin holder' status is temporary and rotates periodically among senior project members.
This term comes from the Perl development community, but has been sighted elsewhere. It derives from a stuffed-toy pumpkin that was passed around at a development shop years ago as the access control for a shared backup-tape drive.
I used to bulls-eye womp-rats in my pants
or at least make it easier to write readable code...
The fundamental point of perl is its a quick way to write one-off scripts to do quick repetitive jobs - therefore maintainable code is not necessary. I accept there are other times when it needs to be readable tho...
Nonsense.
Would you say
" quick way to write one-off scripts to do quick repetitive jobs"
Accurately describes the slashdot application?
I suppose it's only a 'real' language if you have to compile it? I'll never understand that mentality.
Like most programmers, I use perl on a daily, if not hourly, basis. It is great for prototyping, proofs of concept, and the inevitable "glue" code. So I have been anticipating 5.8 for some time.
It's great to hear that they finally fixed the problems with threading, and Unicode support was a long time coming, but I'm sure well worth the wait. It is a shame the Perl team wasn't able to add true OO support and exception handling to this release, but I guess it is just another reality of open source software that projects are steered according to the whims of the programmers and not to what the users actually want. I'll be switching to Python, and I urge others to do the same.
Karma: Good (despite my invention of the Karma: sig)
I suppose it's only a 'real' language if you have to compile it
.... and yet too weird or short-lived to code in c'.
I didn't say this.
Would you say
" quick way to write one-off scripts to do quick repetitive jobs"
Accurately describes the slashdot application?
No. I did say it was suited for other things. But the fundamental entire basis for the whole point of perl is (and I quote from my O'Reilly Perl book) 'Perl is desinged to assist the programmer with common tasks that are probably too heavy
Feh.
I think it's easy enough to write readable code in perl, the great thing is that you have the option of writing horribly unreadable code to do in 3 lines what it would otherwise take 10 to do.
Perl gets more and more features it is not designed for, making it potentially more and more ugly if you use all of them.
;-)
Maybe it is time to dump Perl and start designing Berl = the Beautyfull Extraction and Reporting Language
"A programmer without a job had a problem. "I know, I will learn perl," he said. The programmer now had two problems."
How can that be off-topic (maybe moderators need to read the actual stories eh?) ? I thought it was funny, given that it's on the page that this story links to. The no warranty warning always makes me giggle (specially it's there when I log into Debian).
Im still having problems installing 5.8 on macosx. JFYI. dynlib issues.
Phwwttt..
M Felzien
"- New Threads Implementation: A new multithreading implementation called interpreter threads, or "ithreads" for short, is available, their use instead of the old "5.005 threads" is strongly encouraged. The major difference is that in ithreads any data sharing must be done explicitly."
Does this mean when you use fork() you must define a variable as global? I didn't think it was possible to declare a variable as global other than a "$var = 0". Also, does any one know if after forking how would a child return a variable to the parent?
I learned perl using 5.0.0.5, or somesuch. I learned using version 2 of the Perl Book.
:) It seems it would be a useful community project if someone were to take these changes and compile them into a sorted by type document-- I.E., all grammar changes, then all regexp changes, then library functions, etc., with sample code where germane.
:)
:)
It seems to be the case that the perl language has actually evolved a bit since 5. I am continually finding out about "new" features in Perl that i were not aware were there (invariably, the only ones that make a difference to me are the extentions to the Regexp system: there seems to be a whole class of (?X) operators that are not in my copy of the perl book).
Is there anywhere that summarizes the various changes to perl since version 5? there are the perldoc perldelta documents (here is the perldelta document for 5.8.0). However, these are complete, technical changelogs, and cover everything from language changes to small inconsistency smoothings to changes to obscure library functions to bugfixes in internal perl functions. Moreover, they do an even poorer job of explaining the consequences to the coder of things like (?>) than the perldocs
Really, now that i think about it, i guess what i would like is a summary of what they've done to the regexps since version 5.0
If no such document exists, maybe someone can write one and post it on PerlMonks
- super ugly ultraman
Perl is real programming language, and as for the readability aspect: Perl doesn't hold your hand. It's perfectly possible to write clear code in Perl. If I was to show you one of my scripts I'm sure anyone with basic programming knowledge would be able to understand it.
I never liked autovivified hash elements in the first place. It's such a pain in the butt to put a if (exists $hash{index}) before trying to access everything if I don't want autovivification. Don't take this as a slam against Perl, I love the language and the concepts, but there are a couple little nooks and crannies that ought to somehow be fixed. I say "somehow" because to do it with backwards compatiblity may be impossible.
"and not one with loads of irritating whitespace"
Lots of people make a big deal about whitespace in python, but frankly it really is a non-issue. Any decent python editor will manage the tabs for you properly, and you will marvel at the clean readable appearance of bracketless code. Get it a real try before you write this excellent language off will you?
Good coders use "ugly" pointers that scares C++ coders away. Good coders use complex structures that might give Visual BASIC aestetic freaks goose bumps. Heck it's even better to know some assembly with it's ugly jmp and branches. So I agree with the PERL philosophy, it ain't pretty to look at but then again it works. If you want cute readable code where you spend 60% of the time writing comments because you never when you gonna get fired from the project and some other company/guy will take over who might not know advanced stuff or read code, then somehow that might explain why code is getting even more sloppy these days.
/* */ Don't forget, you write for the computer in the end.
I met a PIC chip coder last day... 16 instructions, things that work in less then 20k and that can be timed at the m.second, now that is beauty in code! It's when it works that the beauty is, not when you cut and paste cute lines of
Now if only Apple would get the Cocoa bindings for Perl cooked up, so I could back-end in Perl and GUI in Cocoa...
I am concerned about any program, any piece of hardware, any treaty, any law that treats me as a consumer, not a citizen
Oraperl? Or do you mean DBI + DBD::Oracle. oraperl, sybperl and all those other monstrosities have been unsupported for ages.
I'm no coward, but don't want to spend time creatying an account (and remembering it) right now.
perl-5.8.0 is now completely 11.00 and 10.20 HP C-ANSI-C and GNU gcc safe. There are more 'README' pieces about Oracle in README.hpux and DBD-Oracle's README's have been extended, and probably will be even more in the near future.
I've already made a pa-risc-2.0 gcc version prepared for Oracle available on https://www.beepz.com/personal/merijn for HP ITRC forum members, and I cannot promise, but a 10.20-pa-risc-1.1 version is planned for the near future.
BTW, I seldom read this forum.
No. It was released today. You're thinking of the last Release Candidate which was released on Monday.
not true, here is a sample brainfuck program :
;)
hello world
I would include it in this body but it fails the lameness filter for having too many 'junk' characters, but its a program....
as you are not allowed comments and none of the operations are particularly obvious because of the lack of verbosity, its very hard to understand what it does even if you know brainfuck.
it prints out 'Hello World' by the way.
things are even worse when programming in machine code, because the commands' binary syntax is not very human readable, although at least you can put comments in machine code.
In short, some languages are better than others for promoting code readability, but I think the exact opposite of your statement is true : you can write unreadable code in any language.
I for one think Perl suffers from write-only tendancies, mainly due to the horrible mess that is called array access. Good clear types really help maintainability, and the last time I saw Perl's collection type(s) it was neither good nor clear.
I was happy to move over to Python mainly based on the quality of its type system, not that this was the only strength. But I must confess to being fully able to produce unreadable bits of Python that could make some Perl fragments look like angels.
Good coders use "ugly" pointers that scares C++ coders away.
Yes, you'd never see
Object *pointer=new Object("foo");
pointer->Method1();
pointer->Method2(1);
delete(pointer);
Oh, wait. Yes you do.
Say Goatse 5 times and you're illness would go away. Please do not post on /. for 3 days, if at the end of the 3rd day symptoms of paranoia and post 9/11 leandings appear, please destroy your workstation and try to buy a windows ME Pee Cee from K-Mark (use your offical Hick card).
The monstrosities, of course. I've battled with them many times. We actually have a procedure now for both 11.0 and 10.20, butit took literally days upon days of fact-finding and experimentation to get it to work at all.
Moderation: Put your hand inside the puppet head!
I use pointers in C++. What is scary about pointers?
Why use a complex structure when a simple one will do?
It's better to not branch at all, than to branch in assembly.
What actual evidence do you have that code is getting more sloppy? Or are you just waving your hands around making general statements, with the subtext that no-one can code as well as you?
Mmmm, chocolate perls....
:)
Thanks for the link!
I am concerned about any program, any piece of hardware, any treaty, any law that treats me as a consumer, not a citizen
to describe "bad coders," i think the phrase you're looking for is "Code Monkey," sense #1 from the Jargon file: A person only capable of grinding out code, but unable to perform the higher-primate tasks of software architecture, analysis, and design. Mildly insulting. Often applied to the most junior people on a programming team.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Oraperl (capital O) is a reverse compatibility wrapper around DBI.. lots of people are brain-locked on it and don't even know about DBI.
Yes, I know.
My favorite quote on Perl:
/., but can't attribute it. Sorry.
"A Perl script looks like an explosion in an ASCII factory"
I know I saw it on
You don't need the () with delete...
Can I suggest writing something that duplicates the oraperl interface using DBI and DBD::Oracle, and using that to run your scripts?
It'd probably make your life easier. In the long run.
I could not disagree more. I keep a copy of all interesting scripts I write. I often give them to friends or peers. In addition, I may not look at a saved script for some time in the future. Well written, documented code is key to being able to remember just what it was that you were doing and communictating these ideas effectively with others.
UNIX/Linux Consulting
How about: a good coder can write readable code in any readable language?
But I hardly think that trotting out languages that are difficult to read invalidates the statement you replied to. I could just as well say that it's impossible to write readable Russian, since I can't read Russian.
Good idea... if only real languages are compiled then we can effectively declare English, Spanish, etc as non-languages :P
Luke-Jr
- Safe Signals:
in previous versions of Perl signals could corrupt Perl's internal state
I was always a bit bummed that Carp was so unstable under mod_perl (I'd get seg faults every once in a while)... is this issue related to problems within Perl such as the above?
Nope - sybperl is still supported (although "sybperl" is just the collective name for the Sybase:: modules for perl 5)
"This is not a release candidate, it's the real thing, representing over two years of work by patch pumpkin holder Jarkko Hietaniemi and his merry band. Hugo van der Sanden is the new pumpking [sic] for perl 5.10."
Isn't it cute?
how about "piece of shit" then?
Do you even lift?
These aren't the 'roids you're looking for.
I always find my eye searching for the ending delimiter at the end of each block of code; this basically means I'm forever having to stop myself from thinking the code is somehow incomplete when I read Python.
:)
:)
I also found Python conciderably more opaque than Ruby, although I strongly suspect that had more to do with the documentation I found on it than anything else.
That most of the examples of Python apps I looked at were pretty messy didn't really help either
Unfortunately for Python, Ruby's filled my requirement for a clean dynamic language; I expect my next language to be more along the lines of SmallTalk or Lisp. Python just doesn't look that interesting anymore
<eagarly awaits a flood of examples and docs that'll make me change my mind and fall in love with it>
Hahaha, get back under your bridge, troll!
VB lower level than C... LOL
I'm only a little Burrahobbit and I wouldn't make above a mouthful... So don't even bother!
Any language is hard to read if you do not know it. "Readable" assumes a level of competence on the part of the programmer reading the code... e.g. if you do not know assembly, asm code looks pretty unreadable... So saying perl is "unreadable" to me says more about the programmer...
Wasn't there something about Perl 6 being released not too long ago? Anyway this release will give all the scriptkiddies something to do for a day.
Most of what I do is basic anyhow...so from what I've read, I'm not sure its worth an upgrade at this point. I don't think my projects would benefit that terribly much from it.
DBD::Oracle is an utter whore to get compiled & running on a HPUX box.
Which is better? Horses or cantelope melons?
HTML and Perl are two completely different things. HTML is a way of representing (textual) data, while Perl is a way of processing and/or creating data.
Stop the brainwash
patch pumpkin n. [Perl hackers] A notional token passed around among the members of a project. Possession of the patch pumpkin means one has the exclusive authority to make changes on the project's master source tree. The implicit assumption is that `pumpkin holder' status is temporary and rotates periodically among senior project members. This term comes from the Perl development community, but has been sighted elsewhere. It derives from a stuffed-toy pumpkin that was passed around at a development shop years ago as the access control for a shared backup-tape drive.
For those with Perl already, the following is an easy way to download and upgrade:
perl -MCPAN -e 'install J/JH/JHI/perl-5.8.0.tar.gz'
I agree with you, My formal training is a COBOL programmer, and I've written Perl programs that I consider readable even by COBOL standards. These are not one-timer scripts, but real world applications.
Sure Perl can be unreadable, and I'll admit if you want to write the most unreadable code humanly possible that actualy does something, Perl is probabaly the language for you. Try writing poetry in VB!
Apocalypse Cancelled, Sorry, No Ticket Refunds
I bet you're a Debian & Gnome user too, arn't you?
¦ ©® ±
when the writer is not that good at it. Perl si great as it is.
I agree. I'm a graduate student overseas at CERN. For my thesis, I'm working on prime number factoring sieve algorithms. I initially used "Fortran", but there were performance issues, so I switched to perl. It's much faster at matrix operations than the cobol libraries I was previously using, and since it's interpretted, I don't have to worry about long recompiles or syntax errors.
TMTOWTDI!
Bah, bad coders can't even write readable English (or their native language).
You are correct that it can be used for real, big, major, mission-critical applications, but that's not what it's original intent was. Quote from the O'Reilly book:
Everyone here understands that Perl can and is used for large applications, but that still wasn't its original intent. New features have made it appropriate for that but perl has always kept its vision of "keeping the easy things easy".
Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance.
In other words, it's a small concurrent functional programming language developed by Ericsson after their experiments with Lisp and Prolog.
Although, you will not love it if have already poisoned by OO "snake oil"
If it's a case then try Dylan
Less is more !
I see people bashing Perl for it's supposed unreadability. I see people bashing Perl so they can advocate Python or Ruby. I see people making general, blanket statements about code readability, as if these opinions are always ready to burst forth, making the speaker a hit at parties.
Arguments about programming languages on this level are pointless beyond belief. It's like arguing which pop band is better than another. Who cares? It's all opinion and hearsay.
Which is in this thread also.
( perl -MCPAN -e 'install perl-5.8.0.tar.gz' )
ActiveState Perl is still 5.6. Any ideas when it'll be updated?
I run the scripts on Linux, but I do my coding on a WinAMD machine.
No boom today. Boom tomorrow. There's always a boom tomorrow. - Cmdr. Susan Ivanova
There's a comment about pseudohashes being depreciated, but the tense of the comment is pretty strange. What's up? Are pseudohashes actually depreciated in perl 5.8.0? --j
If it just got released, what the heck is in RedHat Limbo that's marked perl-5.8.0-29?
The fact that Perl has a multitude of different syntaxes and structures available to do the same job - that hack on hack stuff you disparage - is a feature. It's one of the language's strongest suits. And it closely approximates a typical spoken language, like English.
Where you see piled-on hacks, I see evolution at work. Perl is richly expressive, and allows you to code in whatever style works best for the task at hand, rather than trying to force the solution-space of the problem into the modeling-space of the language.
That's why Java and other B&D languages suck so badly - they trade flexability for orthadoxy.
But spoken languages have proven to be stubbornly resistant to the imposition of bondage and discipline in the name of "simplicity", and attempts at creating new, simpler spoken languages from scratch - like Esperanto - have failed miserably. The parallel with programming language should hold true as well. What is a programming language but a way of communicating with your computer, your users, and other programmers?
It should be at least as expressive as your spoken tongue, not less.
"A foolish consistancy is the hobgoblin of little minds" and nothing illustrates that point better than a discussion of Perl by those who don't actually use it.
DG
Want to learn about race cars? Read my Book
Of Perl: "It also powers Sweden's entire pension system [oreilly.com]"
:-)
Your fanaticism seems to be clouding your vision
For the Swedish pension system, it is completely wrong to say that Perl powers the entire thing. If you had to choose only one thing, that would have to be Oracle. Slap bang, right in the middle, Oracle keeps the data. Most of the surrounding application is Perl - but not all of it - they also use JScript, VB and PL/SQL.
All this information is from the interesting link you posted. It's worth a read.
Tales from behind the Lagom Curtain
... it prints:
'Helo World!'
With '!' and line break.
"The Compiler Suite: bytecompiling and compiling still do not work"
Heck even Visual Basic compiles!
Silly Pudge. 5.10 5.8. Didn't you take math classes?
Prevent email address forgery. Publish SPF records for y
Silly Pudge. 5.10 is less than 5.8. Didn't you take math classes?
Prevent email address forgery. Publish SPF records for y
First off, let me state that choice of programming language isn't a reflection of the abilities of a developer.
I've seen dedicated, talented developers produce great apps with Perl, Python and even (gasp!) pre-.NET Visual Basic. On the other hand, I've seen careless, uninterested developers produce mounds of pure, unadulterated crap with C++.
The language used has little to do with the quality of thefinal result, and has a lot more to do with the person coding with it.
The language used for a product often isn't even up to the developer. Employers and clients mandate a language as often as not, sometimes for valid reasons, sometimes for moronic reasons ("The CEO plays golf with this dude who told him that using Java is gonna save big bucks").
Let's look at three factors we can use when comparing languages: Performance, Development Effort Required, and Maintainability.
C++ is a great language in experienced and knowing hands. When well-done its performance is good but it tends to be very effort-intensive.
Perl and other very high-level languages are less effort-intensive, but they have a corresponding performance trade-off.
Java and .NET languages are somewhere between the two, though they both seem closer to C++ on the scale than they are to VHL languages.
The maintainability of a language seems weakly related to individual languages. Most of the maintainabilty qualities of a product will spring from the all-too-often overlooked Planning, Design, and Discipline of the developers that worked on it!
I'll allow that Perl can really let you shoot yourself in the foot as far as maintainablity goes, but what languages aren't like this? Especially beloved C++?
The only thing that we learn from history is that nobody learns anything from history.
The article makes it clear that they wanted the whole thing written in Perl - they only used the other languages because they couldn't find enough Perl programmers in Sweden.
I guess I can upgrade from Linux 2.4.18 to 2.4.9 then.
Listen, little cowboy...
You've got no authority or position of judge to penetrate me with such evil words. But you sincerely deserve to work for Dell Computers. I know who you are now... You are that Stephen guy... That want to make every dude a Dell owner. And guess what, Dells do come with your tiny little piece of shit you call "Pee-Cee" - American bastard.
I will shit in your starred flag, I will burn it till it verts blood from all the people you have killed in this world just for the sake of filling your bellies with cash and macarroni.
Yes, you are on the top of the world but one thing you can't deny - that what makes you and your country so high is the amount of corpses that you guys piled up to reach the top.
Next time you direct your word to me, I will reveal some necromancy prophecies about the destiny of yours.
Thank you very much.
It sort of sounds like you just want version 3 of programming Perl he has the lists sorted by type and does mention where things have changes. At leasts that covers you up to 5.6. I'm waiting till 5.8.1 to switch over to 5.8. In any case with that you could then look at the 5.8 regex which should be pretty close.
I believe the correct quote is "Perl looks like an expolosion at a typewriter factory"
I really don't see how you get that interpretation from that quote simply because the quote and what we're talking about have absolutly nothing to do with each other!
Seriously... the quote doesn't say "Perl is designed to make small jobs easy, without making the large jobs impossible." It says 'easy' and 'hard'. I contend that you can have large programs that are fairly easy to write and vice versa small programs that are very complex.
That quote says nothing about not writing large mission-critical apps in Perl.
The Anti-Blog
Why make a scripting language even more inefficient and bloated? Why waste time on something like that when there are many other interesting PERL-related projects on the todo list?z
Perl can pump out HTML, can HTML pump out Perl? if so, HTML wins.
Yeah, and Linus once said that Linux was so dependent on i386 that it couldn't be ported to anything else.
Things can change.
Being concise usually leads to unreadable code? I disbelieve your assertion, for it is well known that, as the length of description increases, the probability of overflowing the attention span and the number of ideas readers can keep in mind simultaneously increases. Consequently, one should strive to make things as simple as possible to ease understanding and uptake. I shall repeat the main ideas of this paragraph, restating them as briefly as possible, to underscore my point, to provide a memorable phrase, and to serve as an object lesson:
how to invest, a novice's guide
Binary incompatibility is beginning to be Perl's bane. Didn't FreeBSD remove perl from their base system because of this?
It be ready.
I think code readability is a product of being concise and keeping things simple. At a certain point, increasing the concision of code increases complexity (by removing obvious meaning about what the code is trying to accomplish).
For example, the following includes explicit information that tells the reader that a choice is being made:
While this implies some matrix or arithmatic operation instead:
I think an extreme example is the concise perl code examples for DeCSS decoding.
-1 Irrelevant Thought parent funny.
You seem to be afflicted with a certain sort of political correctness where everything has to be "equally" readable. It's simply not true. For example, a good assembly programmer might be able to read code in a hex editor, but they can't do so as quickly and easily as a python programmer can read a python program that does the same thing. There are a number of factors that can make a language intrinsically more or less readable.
Ahh great ... so you never write good tools,
do you? You know, when you write GOOD software,
other people want to use it, too. Soon they
start to ask for new features, a bugfix here,
an extension there. "maintainable code is not
necessary" is a very POOR excuse for: I am too
lazy or I dont have the selfdiscipline to write
maintainable perl code.
Well that's his point, isn't it ? That a language can be intrinsically more or less readable than another language. Once you accept the possibility of an "unreadable" language, there's a legitimate question of the degree of readability.
One important tradeoff is that between writability and readability. The two conflicting philosophies are:
You simply can't have it both ways, because to allow concise expressive syntax is to allow ambiguity. Perl consistently chooses writability over readability. A language that prefers readability over writability will require more effort to code in, but be more readable (Python is a good example of such a language).
Perls design tradeoffs are writable over readable, rapid development versus safety. Wherever there's a choice to make the language easier to write or easier to read, Perl chooses easier to write. Wherever there's a choice between flexibility and reliability, perl chooses flexibility. All the tradeoffs Perl makes are an advantage for writing quick and dirty applications, and a drawback for writing large scale, robust applications.
That doesn't mean that it's not possible to write large maintainable programs in that language, it just means that it was not designed to the criteria that favor developing such applications.
A while back sockets under perl 5.6.0 stopped working on all of our Sun Solaris 8 systems. I tried recompiling it, 5.6.1, and 5.8.0rc2 (I plan on trying perl 5.8.0 final soon), but all of them fail on the socket tests, which include:
- lib/io_multihomed..Protocol not supported at lib/io_multihomed.t line 83.
- lib/io_sock........Protocol not supported at lib/io_sock.t line 37.
- lib/io_udp.........Protocol not supported at (maybe your system does not have a localhost at all, 0.0.1) at lib/io_udp.t line 60.
(Note: We do have localhost defined in our host table).It was a while before we noticed the error so I do not know what could have changed on our system to cause this problem. The only thing I can think of it being is that we patch all our systems between the time it last worked and when it did not. I did note that one of our installed Solaris patches is 111327 which does replace the socket libraries. We recently got a new SunBlade 2000 Workstation and I tried it again on it, and it too has the problem. It came prepatched and includes 111327 amongst many others. I have yet to try taking that patch off (mostly because of the logistics involved in removing one of our active Sun off the network for the test, and I am not willing to take a security patch off our system with it on the network).
This is not the same as noted in PerlFAQ 8, though I guess somebody at Sun could have deceided to change the Protocol numbers again, but I think it unlikely. I even went as far as modifying the test routines to add "use Sockets;", but no help.
Also, where can one submit and view bugs reports for Perl?
Your response borders on surreal.
Things to do today:
1. Start computer language flame war.
2. Wrestle Plato.
print "been there. done that.\n";
I see heavy use of Perl damage your logic ability. The response was clear, simple, and right on the point.
I see. And I guess you spend 3 hours for writing those 3 lines ? Because, of course, if you spent 1 minute, it won't be worthwhile to shorten it ; unless you spent the major part of your time writing throw-away scripts (say 300 three-liners per day).
I seem to remember that it was the principal development language for Interwoven TeamSite... which is many things, but not a quick one-off script.
Average 1st time install price for Interwoven customers? About US$250,000 for licenses. Development time and hardware are on top.
The only thing you can accurately describe as "Scotch" is a sticky tape made by 3M. And it's
Well that's his point, isn't it ? That a language can be intrinsically more or less readable than another language. Once you accept the possibility of an "unreadable" language, there's a legitimate question of the degree of readability.
And as I said... I could just as easily say that Russian is unreadable, simply because I can't read Russian.
Any language is unreadable if you don't know how to read it, regardless of how readable the code is. If you do know how to read it, then it is no longer an "unreadable" language, and any lack of readability is due to the writer, not the language.
This is all true, but it doesn't alter the fact that one language can be more readable than another.
If you do know how to read it, then it is no longer an "unreadable" language, and any lack of readability is due to the writer, not the language.
Not necessarily. There's a common political correctness that says that all languages must be equally readable. This is a fallacy. There are factors in a language that can make it less readable. It's not a difficult exercise to contemplate language features that would hurt readability (requiring all caps is one example that would make the language less readable, for example. So would alternating every second letter with characters from a pseudo-random sequence.)
This is all true, but it doesn't alter the fact that one language can be more readable than another.
So, which human language is inherantly the most readable, oh guru?
As to your examples... some people find all caps to be inherantly *more* readable. And throwing in pseudo-random sequences doesn't change anything.. that would increase the difficulty of learning how to read the language, not any inherant "readability" of the language (if there is truly a coherant, understandable structure, something that is pretty much required for the human concept of "language").
As I've pointed out twice already, Russian is entirely unreadable by my standards. The alphabet is gibberish to me, the words mean nothing (except for "goodbye", which I picked up from somewhere), and I don't even know enough to start thinking about the grammar of the language. Does my inability to grasp this language mean anything at all to the native Russian speaker who has grown up with it, and thinks that English is equally incomprehensible?
I don't know enough about human languages to make informed judgements. However, I can make such judgements about programming languages.
some people find all caps to be inherantly *more* readable.
The problem with all-caps is that all the letters are the same height. People can and do use the differing heights of lower case letters as visual cues. This makes it harder for the eye to follow text written in all-caps.
And throwing in pseudo-random sequences doesn't change anything.
Sure it does. Add enough noise to the signal and finding the signal becomes a difficult task in itself. For example, if we added 3000 such random letters, then the language would be less readable, because the very act of finding the letters would be time consuming. Learning the language wouldn't be that hard (any one who could count to 3000 could do it), but it would be harder to learn to read the language, and reading would demand more of the reader.
As I've pointed out twice already, Russian is entirely unreadable by my standards. The alphabet is gibberish to me, the words mean nothing (except for "goodbye", which I picked up from somewhere), and I don't even know enough to start thinking about the grammar of the language. Does my inability to grasp this language mean anything at all to the native Russian speaker who has grown up with it, and thinks that English is equally incomprehensible?
You can keep repeating it, but it does not in any way contradict what I am saying. Of course you won't be able to read a language you are not familiar with, and of course the fact that I am ignorant about the Russian language doesn't mean that Russian is unreadable, but it does not follow that all languages are equally readable.
On the contrary, if the choice was the developer's and he/she made a poor choice, that is very much a reflection of their (lack of) ability.
The language used has little to do with the quality of the final result, and has a lot more to do with the person coding with it.
Generally speaking, given the choice, a good programmer won't make a poor choice of language for a project. (We don't always have that choice, of course, but a good programmer knows the difference and will readily admit to suboptimal management constraints.)
The maintainability of a language seems weakly related to individual languages.
Most of the garbage code I see these days, both proportionally and in absolute terms, is written in Perl. I believe that this is due to design problems with the language itself, and due to the fact that the language is so popular, therefore drawing to it many unskilled programmers, and due to the compounding interaction of these two factors.
Perl was there first, and Larry Wall deserves accolades for it, IMO. These days, though, is there anyone that doesn't cringe at the thought of having another bale of newbie Perl code dumped on them to maintain?
--Mike
"Not an actor, but he plays one on TV."
Are we really supposed to believe that all languages are equally good/bad and that we might just as well choose any of them for any project? This is nonsense.
Languages do differ in clarity, maintainability, readability, and many other features, and, in the end, this will lead to fundamental differences on average in the engineering quality of the code. Little science (AFAIK) has been performed to study the relative quality of different languages, but there is no reason to believe that it could not be studied in principle. Nor is there much reason to believe that there wouldn't be substantial differences between languages.
--Mike
"Not an actor, but he plays one on TV."
to oppose some claims that the only reason brainfuck and machine code are unreadable is because the reader doesn't know HOW to read it I will go into why they are inherently less readable than some other languages DESPITE being able to read them.
;)
thankyou elflord for already getting the point
at one level brainfuck is extremely easy to read, it only has 8 characters, each of which corresponds to one of 8 simple to understand operations. Anyone could learn to read off the code operations given 10 minutes because there isn't very much to learn. brainfuck is still inherently unreadable because it is very hard to work out what a peice of code's functionality is when only given a list of low level operations. In brainfuck there are no function names to give a big clue as to what the function does, there are no variable names, and there are no comments.
Just imagine trying to write readable code in perl if you were forced to call all your functions f1, f2, f3.... and all your variables $v1 $v2 $v3.... and you are not allowed to create any comments, and you have to build your own strings at run time too, none of these abstract types thank you. Just to finish off remove all the whitespace from your perl script and tell me if it is readable. brainfuck forces all of those points, so although the operations are very readable, the functionality isn't.
machine code is also quite readable, it is perfectly possible to learn how to read machine code, but it is much harder to read machine code than it is assembly. Again this has nothing to do with the posibility of learning to read either, it is infact purely based on how quickly you can read them. There is a one to one translation between machine code and assembly (apart from label names)
but whereas I can read an assembly op in well under a second, I would have to spend a fair amount of time deciphering which op code is being used, with which options and registers and data. Even if I knew everything I needed to know to work out what the instruction is, I am still having to calculate it each time I read a code. In variable length instruction sets I have an even worse time as although I can see one assembly instruction followed by another, and I can simply skip looking at a few I am not interested in, in the machine code I have to work out every instruction before I know where the next intruction begins.
Now, for a stupid example that knowing how to read two languages does not imply equality in ease of reading them, as appropriate for a comparison of assembly to machine code: I pick english for one language and english with each letter offset by one for the second, so that 'a' is translated to 'b'.
The languages are almost identical, and you have been given everything you need to know how to read both, but how long does it take you to READ AND UNDERSTAND e"readable" compared to e1"vosfbebcmf"?
machine code is harder (but possible) to read because you have to work more things out than you do with assembly.
brainfuck is harder to read than C like languages because you don't have any names or comments to give you clues as to the functionality. If you wrote C with random function names, random variable names, no comments and agreed to never use any number except 0, and never use any strings then your code would be on par with brainfuck : but brainfuck manadates this style, which is why it inherently difficult to understand.
What I find funny about this, is that "gurus" (read arseholes on an ego trip that tend to live in c.l.p.m) always bitch and whine about people being confused about PERL/Perl, _still_ haven't changed the man page in the download available from perl.org. (It still says: "Practical Extraction...")
As far as I am concerned, they lost the valid right to bitch about the incorrect usage of PERL/Perl a long time ago.
If you were adept enough to read that, surely you were clever enough to notice it's never PERL within the text of the man page. You might even have noticed a link to perlfaq1, which explains the joke.
I've personally noticed people who write PERL have a strong tendency to write awful code.
how to invest, a novice's guide