Slashdot Mirror
Perl Medic
One of the goals of Perl Medic is to transform code from stylistically poor and unmaintainable into stylistically sound, maintainable and testable code. The format of Perl Medic is very similar to books like The Pragmatic Programmer or The Practice of Programming. Perl Medic shows the reader best practices by example. Some of the chapters are checklists of practices that will help improve your ability to manage and wrangle the code, while others are lists of patterns and practices you should avoid, and should replace with the examples provided. This format very readable, and provides an excellent forum for gleaning what ways to improve the code.
Perl Medic is designed with experienced coders in mind. Topics are presented as if the reader may be using these ideas already in their code, whether good or not. While the advice is good, the presentation may be confusing for beginner and intermediate programmers who aren't intimately familiar with the concepts. I found myself re-reading several topics to try and grasp what the author was trying to convey. After several readings of the section on test harnesses, I still needed help, and ran to the Perl documentation to better understand what the author was saying. Certain advice is also presented, only to have it countered in the next section. Most Perl programmers are familiar with the '-w' switch, which turns on warnings in a Perl program. The pragma 'use warnings' is introduced as a way to turn on warnings for just the code being worked on without displaying the warnings of the modules included in the program. In the next section, the author points out that it might be a good idea to put '-w' in there to see if there are any issues in the modules you may be including. While this advice may be intuitive for experienced Perl coders, the beginner may be confused. "Should I use '-w', or should I use 'use warnings'" she may ask herself.
The book also suffers from a case of being too brief in some sections. In section 2.3.1 (Gobbledygook) the reader is directed for help on how to turn a partially obfuscated program into more intelligible code; a very useful skill indeed. The author redirects the reader to section 4.5 where the utility perltidy is discussed with further detail, but before ending the section, the author also introduces the module 'B::Deobfuscate' along with a URL. No mention of how to use it is provided. In section 6.4 (Debugging Strategies) the author gives advice on how to debug a program. His advice: "Divide and Conquer". While there is debugging advice throughout the book, it's a little frustrating to see a section specifically designated "Debugging", with only one subheading under it. The organization of some of the topics feels artificial, and perhaps should be reorganized in future editions.
Underneath these faults, though, Perl Medic is a great book. Chapter 11 (A Case Study) should be required reading for coders inheriting Perl projects. This chapter is a blow-by-blow account of the author's work in transforming a simple LDAP application from Perl 4 into a robust Perl 5.8 application. The author is very candid about what decisions were made in the code transformation, and why certain elements were addressed in the way they were addressed. One particular element is an elderly module used for the LDAP lookups themselves. The author details the process used to determine a better module to replace this module, and guides the reader through each of the steps required to change the code to use this new module. The decisions the author uses to make this code work under the new environment are enlightening for anyone planning a migration of Perl code into a newer environment. Chapter 7 contains the versions of Perl from Perl 4 up until 5.8.3, and elaborates on what changed between the versions (very helpful for those who are planning an upgrade from 5.003 to a more recent version of Perl). Chapter 9 (Analysis) has very useful tips for not only debugging you program, but for using the Perl Debugger and getting the most out of your debugging session.
Perl Medic is recommended for anyone who is tasked with maintaining or writing Perl Code. While the examples are written with experienced coders in mind, beginners will do well to use this book for areas to focus on while they learn the language. Inheriting code can be a daunting task, but with a book like Perl Medic, you'll have the tools at hand to help ease the work ahead into a more manageable task. And you'll make it easier for "the next guy".
You can purchase Perl Medic: Transforming Legacy Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
and people say that /. has no standards...
Hmmm witty sig or funny sig? Maybe elitest techy sig!
or not, musta been somewhere else. I could swear it was /.
Search first next time...
All true wisdom can be found in sigs.
Preventative and maintainance coding is difficult enough when a language has a particular idiom you can follow. Perl gives you an unparallelled freedom of expression and with it several confusingly different ways to achieve the same task.
I used to be a believer, but now it seems Python is ready to take the yoke, at least with those of us who wonder how can you build a complex yet maintainable script without static typing.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Yeah. Because PHP is great at non-web applications.
s/shitty perl code/shitty code in any language/;
You can inherit shit in any language.
This is the best book I've ever read about how to write clear and maintainable Perl code. The advice is solid and up-to-date with discussions of perltidy, modern web techniques, etc. I would recommend this book to anyone who writes Perl, just as a style guide.
In most cases, refreshing an existing program will take less time than rewriting it in a diffferent language, as in both cases you need to have a firm understanding of what the program does before proceeding.
In many corporate cases, you don't have the luxury of writing in any language you please and, even if you do, in most cases you'll have an uphill challenge convincing a PHB that rewriting from scratch in a new language is the better proposition.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Perl, does in fact, run 4x slower than C. If your program requires speed and maintainability, then stick with a real compiled language. Anything else is a scripting language and should be used appropriately.
When this happens, just write a Perl script to sort out the parts you need to know and print out a nice little summary.
Ruby is replacing perl in my case, and I think that will develop into a trend. Ruby is a lot more like coding in perl.
Maybe you should learn how to write maintainable Perl scripts/apps then. I too have used for nearly 2 years now and have never had a problem with maintainabillity of one of my scripts. Not even of those from the very beginning.
Proud owner of BOT2K3 [ bot2k3.net ]
What has /. come to? Preemtive "dupe flames"? :D
Generally, bash is superior to python in those environments where python is not installed.
PHP?! PHP?!?!
;)
Okay. Sure. PHP does give some advantages over Perl.. To lazy programmers that is. Really, PHP has over 3125 core functions, while Perl has "only" some 150. Include a module and whoop, some more functionallity, including only those things you need.
Really, how often do you have to look up a PHP function's working (or even name, hence PHP isn't very consistant, something2something, something_to_something, somethingtosomething... the list goes on)? When I haven't worked with PHP for a while that starts to faint. Perl never does.
Oh and, rewriting a map{} and grep{} is left as an exercise to the reader
Proud owner of BOT2K3 [ bot2k3.net ]
Cue the flood of 'Perl is hard to maintain/read' and counterflood of 'You can write hard to maintain/read code in any language' posts.
I think it can be generally agreed that due to the TMTOWTDI philosophy behind Perl, there can be complications involved when inheriting code from others who use a different style and different approach. (Obviously due to the many ways any given task can be approached).
One (common?) approach to dealing with this seems to be to use different languages such as Python or Ruby. Arguably, however, if more coders stuck to code style guidelines and used best practices instead of quick hacks, the problem would be minimal, or at least no worse than other scripting languages.
Business Voyeur
Actually, there are some things that I have written commandline PHP scripts to do. It's not often, but sometimes PHP is just the best tool for the job. Other times it's Perl. Other times it's a shell script, or C, or Java, or whatever. It all depends on what you're used to, what you're skilled at, and what problem you're trying to solve.
"You're older than you've ever been, and now you're even older."
Baloney. The advantage of Perl is that you have the option to write maintainably if you want to!
If I just need a quick solution to a problem, I can very quickly write gibberish that does the job and then forget about it.
If I'm writing a big app which someone will inherit from me, I can avoid confusing constructs for something easier to follow. I can pass variables in Perl style, C-style, I can use objects if I want. Whatever I think will be most maintainable for somebody else.
Just because you can write gibberish in Perl doesn't mean you can't write good stuff too.
if self.sanity_questionable?
:perl }.each do |script| :ruby)
:ruby }
raise "I'm waiting for Perl 6 you insensitive clod!"
end
scripts.select { |s| s.written_in?
rewriter = Rewriter.new(:perl,
rewriter.transform script
end
assert scripts.all? { |s| s.language.clean_object_model? }
assert scripts.all? { |s| s.language.easy_on_the_eyes? }
assert scripts.all? { |s| s.concise? && s.readable? }
assert scripts.all? { |s| s.maintainable? }
self.productivity *= 2
fellow_programmers.each { |w| self.evangelize_language w =>
Rrrrrrgh. People who suggest Python as Perl replacement are bonkers. People who suggest PHP instead of Perl or Python are clearly insane.
My honest opinion is Ruby beats either as a Perl replacement - Ruby retains a lot of Perl ideas while succeeding in providing a very clean syntax.
And people these days can't even do language trolls properly. Let me try. Ahem. hm. hm. hm. (climbs to mountaintop and shouts:) "We should rewrite the Perl programs in Common Lisp!" (dramatic echo) (gasping heard all over the world) (climbs down) There, much better. Now let's rewrite the apps in both common lisp and ruby! Before Perl 6 ships and we need to rewrite everything again, of course! Go on, hurry!
I have been a "Perl Medic", and re-wrote old perl with new perl - much better.
Perl gives you enough rope to hang yourself. If you are disciplined, it is powerful enough to do anything cleanly, quickly, and efficiently.
I think I'll just crank up my written in perl browser, and use my written in perl email client on my written in perl operating system and use my written in perl command line to run "wc" written in perl.
Scripting languages are obviously the solution for all problems, including fast word counting !!!!
PHP? Are you kidding me? There is nothing worse than PHP. PHP looks strewn together without thought. Just consider the system by which PHP's built-in functions are named. Except that there is no such system; the names follow all sorts of different casing rules.
PHP was made by taking a cute language for embedding a broken imitation of Perl-esque syntax in-between HTML and extending it with bajillions of functions that badly needed to be namespaced. It never provided anything useful that Perl couldn't, except that it made newbies comfortable by making them feel like they're in "HTML land" instead of "Programming language land."
Yeah, but perl makes it easier to write shit. I happen to love perl and use it all the time, but I also have to be very disciplined about the aspects and particularly syntax conventions of the language that I use, in order to write readable perl. Just because you can write:
do { thirty(); things(); in(); a(); list(); unformatted(); } if($foo);
Doesn't mean that you should.
One of the brilliant aspects of perl is that it allows you to write code like you think about code. Well doesn't that presuppose that other people are going to think about code the same way you do? Ooops.
Books and books have been written on the need for code formatting, syntax, and variable naming conventions in languages that are twice as rigorous and disciplined as perl. In perl, the need is double.
So I guess what I'm saying is that although shitty code is shitty code in any language, perl provides the possibility for a certain depth and richness of shit that just isn't accomodated in other languages. Kudos to the authors for addressing what is a real problem with a powerful and widely used programming language.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
s/shitty perl code/shitty code in any language/;
You can inherit shit in any language.
That is true, but perl does provide easy ways to write sloppy or unmaintainable code. That's not necessarily a bad thing, because it is exactly that looseness that makes perl a very fast language to develop quick scripts in - there aren't anywhere near as many hoops to jump through and TIMTOWTDI makes it very easy to just write whatever you're thinking. For the niche of a language that lets you knock together something to do the job quickly perl is fine.
If you want anything maintainable you need to forget all of that and make use strict and use warnings mandatory, and enforce some coding style standards. That can be done, and if you do that it is easy enough to write maintainable perl - it's just that you can't expect the language to help you with it much: you have to enforce and police the standards yourself.
Jedidiah.
Craft Beer Programming T-shirts
#!perl -w
use strict
Those are the two guidelines required by our methodology.
https://www.accountkiller.com/removal-requested
For other languages there is -Wall -Werror. On a better OS use ${BDECFLAGS} instead of -Wall :-)
In Soviet Washington the swamp drains you.
Longest pregnancy every, since 2001.
Actually I had a project that did exactly this at a major financial company. I had to convert their old Perl scripts into Unix scripts because the manager was sick of them breaking when new Perl versions came out.
Typical thing for a PHP user to say. You show that PHP is the language for bashers and those who can't grok other languages.
ANY language is only as maintainable as the author of the program/script makes it. You can either do things in an elegant way, or write complete crap.
On the PHP front.. I have yet to find a project where it is a better choice than Perl. Then again, usually a Swiss Army Knife is more useful than an empty canteen.
"I'll get marked as a Troll for saying this..."
Be careful what you wish for
Ruby is a lot more like coding in perl.
Than coding in what? Perl?!?
but the fact that some alter their argument in-place, others return a value...and no rhyme or reason to this. php is the ultimate toy that survives only by virtue of the fact that it is easy to install
What the hell are you talking about and why should we care?
The lack of namespaces and the inconsistent naming conventions can certainly be a problem, albeit not insurmountable. The price is a slightly increased learning curve but the PHP manual at php.net is a very quick way to answer questions one may have while coding. For example, you can do php.net/explode or php.net/strings and it'll take you to the proper pages. It's an example of documentation done right and while it does not address the issues you brought up, it does make them more bearable. Towards more modularized code, PEAR aims to provide something like CPAN does for Perl. It's nowhere near as large and mature yet, but it's growing up.
If you're going to attack PHP, I'd suggest its more unsavory aspects like register_globals (thankfully defaulting to off in official PHP but many hosting providers turn it back on for compatibility with scripts that assume it) or magic_quotes_gpc (protects newbies from themselves but means good PHP coders must do special checks with get_magic_quotes_gpc() and stripslashes() if they want to portably obtain the raw data the user entered).
Though I don't know very much Perl at all, it looks like map{} can be done with array_map. For grep{} with regular expressions, there's preg_grep and for the general case, array_filter.
The IT industry is stuck in a loop. Every few years it tries to re-invent lisp, smalltalk and unix each time coming up with something that ends up being a mutated ugly hack.
The latest attempt at that is ruby. Ruby is great fun and a neat language but honestly it's just an attempt to rewrite smalltalk in a perl idiom.
evil is as evil does
Out of curiosity, how come this posting lists the body byte count on the /. home page and the other postings don't?
I agree, perl medic is a great book, influential in encouraging and developing good habits.
Peter will be speaking, though not on the same topic, at YAPC:2005, June 27, 28, 29 in Toronto. There's a whole day's worth of workshops on perl6, including PUGS, most of a day on testing, as well as threads on DBI, CGI, and lots of other workshops. Register now! At $85US for registration, it's the best bargain you'll find this year.
If you are planning to attend, Book your hotel room soon. The host hotel is only guaranteeing room availability till next weekend. There's a huge conference coming to Toronto a few days after YAPC, so the hotel wants to start making rooms available for early arrivals. Not that all the rooms will disappear the first day, but you wouldn't want to be disappointed, would you?
Though I don't know very much Perl at all, it looks like map{} can be done with array_map. For grep{} with regular expressions, there's preg_grep and for the general case, array_filter.i
:)
array_map is great, but requires an extra function. map{} can handle pretty much any perl code instantly, without any extra subs or other weird constructs. While it's not a "real" problem, I am annoyed at PHP for the fact that I have to write a whole function for every simple map I want to perform, whereas perl can do them in a line. For larger projects, you might even want to create a whole file filled with just those functions.
preg_grep is great, too.. But lacks code support. For example, one could use functions, or any other expression that returns something (or nothing, undef) in Perl, whereas preg_grep only does regular expressions. array_filter is great too, but again requires additional functions.
This also immediatly shows the problem with PHP: Why does it require a gazillion functions for a couple of tasks that only one function could quite well accomodate? IMHO, this is mainly the reason for the "core bloatness" of PHP; the PHP developers have created a function for pretty much every simple task (and a whole lot of functions so obscure you will probably never will be able to use).
For example, you can do php.net/explode or php.net/strings and it'll take you to the proper pages. It's an example of documentation done right and while it does not address the issues you brought up, it does make them more bearable
As for the documentation, yes, I love the way PHP has set it up. Perl's manpages are nice, but still harder to read and slower to access. The php.net/function redirect is a very nice idea, indeed
On a sidenote, I still use PHP frequently when creating simple websites that don't need the power of Perl or need to quickly done. PHP is great for starters, but eventually you will want to try something else.
Proud owner of BOT2K3 [ bot2k3.net ]
PHP was made by taking a cute language for embedding a broken imitation of Perl-esque syntax in-between HTML and extending it with bajillions of functions that badly needed to be namespaced. It never provided anything useful that Perl couldn't, except that it made newbies comfortable by making them feel like they're in "HTML land" instead of "Programming language land."
I'll requote as I share the same opinion. In fact, I'd offer the argument that contrary to the "right tool for the job" advice that gets bandied about so frequently, if you write a lot of code in Perl, it's often more efficient to keep writing code in Perl, as there's very few areas where Perl doesn't shine.
My personal opinions aside, I wonder how you would explain the widespread and seemingly increasing usage (and popularity) of PHP?
Some of the code I've been forced to maintain needed Dr Kevorkian.
self.profit!
As explained above, many perl programs are no longer maintainable because of the extensibility of the language. As some perl modules rise in popularity, some fall - an example is the old LDAP library mentioned above that is no longer usable on new perl versions.
For quick hacks, if it can be done with awk, I will do so. If it requires date processing, I will use gawk. I am not above shelling out to ldapsearch from awk because I will have to maintain fewer complex package installations.
I will only fall back to perl when I need access to system calls or other facilities that the more primitive UNIX tools do not provide (and I am not willing to write the utility in C).
I do this because I like easy portability. Perl's extensibility precludes this approach.
no comment.
While Perl has gotten a bit of a bad rap because it's a disaster of a language, what kind of future do you envision for efforts to improve it, like Python?
Oh crap! A recursive discussion!
I hate the language for its utter lack of consistency. People talk about how great the php.net documentation is but I think they have the causality reversed: those docs have to be excellent or the language would be unnavigable. I have no desire to remember 3500 core language functions with similar (but inconsistent) naming systems and a randomized argument list. Seriously, what were they thinking?
I don't think PHP is inherently bad, but the current implementation certainly is.
Dewey, what part of this looks like authorities should be involved?
I've used both and love both. Perl was first then php. PHP is very well suited for what it is, and perl just speaks for itself. But I would have to say that newbs that use php don't really know what php is... They mix it up with Javascript all the time.
Fastduke
You do realize that PHP started out as a Perl module don't you? Ever hear of Personal Home Page?
Solution to shitty Perl Code:
Python.
I've used both commercially - give me Python anyday.
You infidels.
I too have used for nearly 2 years now and have never had a problem with maintainabillity of one of my scripts.
Yes yes, but how easy would it be for someone else to maintain/update your code?
Ask any VB developer about the 'Option explicit declaration' (I think thats the name? Its been years since I touched it)?
:-)
It forces the compiler to treat code without explicit declarations of types to be treated as errors. It also prevents undeclared variables from being used due to spelling errors.
For example in C++ you have to do
int test1 =0 or
int test1
before you can use it in code. Earlier versions of C did not do this and created alot of hassles.
Also many gnu C++ programs were not that well written before the even of gcc 3.x which treated some warnings as errors. It was a pain but it improved alot of programs as a result.
Many developers are jr level guys and sometimes system administrators writing scripts. Not everyone can write good code and no one can do it wihtout practice. Strictly typed languages help because it forces everyone to follow a standard.
As you can tell I am not a big fan of perl and prefer python or tcsh for scripting.
http://saveie6.com/
Oh crap! A recursive discussion!
Yahoo happens to disagree.
http://saveie6.com/
Oh crap! See parent!
I am no longer wasting my time with slashdot
How about the fact that the PHP parser just exits if there's a syntax error in an eval. Yes, pass malformed code to eval and it will unconditionally abort the parent script. Nice parser.
Perhaps PHP5 is more sane. PHP5 looks reasonable, though I suspect it still inherits all the silly 3000+ global functions of its parent, and still requires you to bracket even commandline scripts with <?php ?>
I am no longer wasting my time with slashdot
Actually it started out as an apache module.
.h header files in which the compiler loads the headers files known as step1 or prelinking and loading in a compiler. Then the rest of the code is loaded and linked to the precompilied files and executed.
It stands for "Pre Hypertext Pages". It was supposed to be similiar to C/C++
Basically the creater wanted to make specific tags and code in his homepage that apache would read first and run before teh html is processed and sent, in order to see how many employers accessed his resume.
http://saveie6.com/
My personal opinions aside, I wonder how you would explain the widespread and seemingly increasing usage (and popularity) of PHP?
It's supremely easy to install, and you can be up and running in a couple minutes from scratch. mod_perl requires a lot more work.
Ironically, PHP1 (aka PHP/FI) was written in perl.
"Actually it started out as an apache module."
Actually, you're totally wrong.
"It stands for 'Pre Hypertext Pages'."
No, no, and no again. It never stood for that, not once, not ever. I'm not even going to dive into the rest of what you wrote, I'll just back myself up with real facts, unlike yours.
I quote:
"PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume. He named this set of scripts 'Personal Home Page Tools'."
Thanks. Now please stop trying to prove people wrong unless you know your OWN facts first.
Only joking.
Seriously, I second your position; Perl breaks all the rules but works anyway, given some discipline. It is both powerful and fun.
If I get a choice, I use it for everything.
Karma: Excellent (My Karma? I wish...:-( )
isn't the whole idea of utf-8 that it can be used by code that wasn't explicitly designed for unicode?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
note that perl programs NEVER mention the memory footprint or startup overhead in perl programs.
Ruby supports UTF-8.
Java is the blue pill
Choose the red pill
Having written code in Perl and other languages (COBOL, C++, Java, VB, TCL), I have come to the conclusion that Perl as a language is more concerned with being clever than getting the job done. The language has some of the most untechnical keywords (e.g. bless, chomp and others) and it makes it completely laughable (like a toy almost). Also, just look at any of the books and or documention written about perl. They all read like Tom Baker scripts from the 1970s Dr. Who episodes.
While the TIMTOWTDI philosophy of perl is cute in theory, it seems to have backlashed and its now total anarchy. I look at some perl and it's total alphabet soup. And the lame excuse of "just because you can do it this way doesn't mean you should" is like putting warnings on cigarette boxes (just because you can smoke these doesn't mean you should).
This book is not going to save perl. It's way too late for that. Perl will continue to be written poorly by people who think they're smarter than everyone else and will try to write their code to read like Tolstoy rather than for what it is.
GOBACK.
Fairly easy. I work on some with a friend (which, even though a bit unrelated, is at the other end of the planet). I work on it for a bit, then swap code and he works on it. We have always been able to read each others code perfectly fine even though we have different ways of writing Perl. We don't usually do weird stuff, either ("Keep it simple, Stupid!") so I think the code would be fairly simple for someone else to read. If it were open source, that is.
Proud owner of BOT2K3 [ bot2k3.net ]
The International Obfuscated Perl Code Competition
:-)
Very similar to the IOCCC. You are given a selection of pieces of Perl code, some of which have been written normally, and some of which have been deliberately obfuscated. All you have to do is tell which is which
For many problems in the busines world, a 12% speed increase isn't worth having if it doubles development time.
For example, I recently put together a reporting system. It's all scripting and Java. Could it run faster if it was all in C? Undoubtedly. However, it's only going to run once a month, so whether it takes 20 minutes or 22 minutes to crunch the data is utterly unimportant. Writing it in C would simply be premature optimization.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Even though I'm still inexperienced at writing Ruby code, I already find it faster to write good code in than Perl.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I agree!
Perl is hard to read and is hard to maintain. When we write English papers there are expected standards concerning sentences, paragraphs, chapters etc. Perl is way too loose on what it allows.
I'm not an expert on it but it sounds like you're talking about mod_php.
The guy is demuxing some data and flipping bytes;
so development time went from 5 minutes to 10 minutes. Imagine the poor clown that has to run
10 of these jobs sequentially on Friday at 4PM. With the C implementation he can go home a half hour earlier.
Uh. What's your point?
cat *.file | perl -ane "$c += scalar @F;END {print qq(Counted $c words.\n)}"
1) I get a syntax error with this.
2) So, you jammed two lines into one.
3) "| wc" is a lot easier to type and remember.
when it's calling libraries written in C. :)
...is to write compilers and interpreters for other languages.
for toy languages like Perl. :)
My personal opinions aside, I wonder how you would explain the widespread and seemingly increasing usage (and popularity) of PHP?
Sturgeon's Law.
From link "..The whole new language was released under a new name, that removed the implication of limited personal use that the PHP/FI 2.0 name held. It was named plain 'PHP', with the meaning being a recursive acronym - PHP: Hypertext Preprocessor."
Php/FI is not PHP in its current form. But I did assume it was. The scripts were read in on apache but I do nto know if it were originally a set of cgi scripts or were they actual apache mods like modern incarnations are.
http://saveie6.com/
I am not an expert either. But php by default is run as a mode but it also can be run as a cgi. Perl and python now run as mods as well but I believe php started putting everything the apache engine just like Microsoft did with ASP and IIS.
http://saveie6.com/
While that point of view does have some merit, it also points out the worst failure of Perl. Far to many people do almost no thinking about their code and then get to live with just what they bargained for. Sadly, any later maintainers didn't bargain at all but still have to survive the mess created in the mean time. In se, this "why would I need to think" attitude is not a problem of Perl, but Perl does implicitly encourage it.
Linux user since early January 1992.
yeah, you better stick to perl.
It gets worse... mSQL is "em-sequel" whereas mySQL is "my ess-cue-ell".
Why? cuz the Gnu people can't have a monopoly on weird names, damnit.
"Faith: Belief without evidence in what is told by one who speaks without knowledge, of things without parallel." - A.B.
Do Not Resuscitate. Sorry, I'm not a great fan of Perl, useful though it is on occasion.
-- "It's not stalking if you're married!" My Wife.
How does Ruby compare to Python? And is it portable to the Mac or (ugh) Windows?
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Why isn't everyone totally unforgiving of the idea that new version releases break existing products? If it's suppposed to be the same language, it's supposed to WORK. Yes, you can "deprecate" things, and suggest that they not be used any more, and even let them be less efficient, but legacy code is not supposed to be broken by the compiler, any more than running the same old code on a newer computer should break. I've been in programming since the IBM mainframe days, and this would have been considered a hanging offense - certainly lawsuit material. Imagine if the phone company decided to change its interfaces overnight and your phone stopped working - that's how ticked everyone should be.
Ruby is pretty comparable to Python in most ways. Pretty much, if you like Perl, and you like Python, you will like Ruby. It is portable to *nix (including Mac), and Windows, and downright neat.
If you're going to attack PHP, I'd suggest its more unsavory aspects like register_globals [etc, etc]
No, I think the haphazardly-named and insanely numerous core functions all stuffed into the primary namespace are far more damning because they are aspects of the language itself rather than of the interpreter. While I can easily control the interpreter's behavior regarding magic quotes and register_globals, I can't irradicate the language problems without recoding the interpreter itself.
As you already explained: that one can write shitty code doesn't mean one has too. Moreover, I haven't seen any language yet that guides one to write any algorithm in such a way that comments are not needed. There is no programming language that thinks for you. Perl's major problem is the huge number of people who learned it by just peeking at a CGI script and tweaking it to their needs. Same holds for PHP, and hey, isn't the quality of code quite similar? I recently had a long winding discussion with someone who complained how bad Perl was designed (http://groups-beta.google.com/group/comp.lang.pyt hon/messages/7e74fc5dd24047a1,4434b5a10d0e32f8,142 2dd275c9c6e3a,3547b6a0a71c1dfd,dce98f843551d487,dc 30957084149f8e,0fc2b0d1cc84a2c2,4eb114d062008987,d 0257059b4c0f09b,de6a3819b19098d3?hl=en&thread_id=6 d65bbac956ebbb0&mode=thread&noheader=1&q=bokma+per l+skills+python&_done=%2Fgroup%2Fcomp.lang.python% 2Fbrowse_frm%2Fthread%2F6d65bbac956ebbb0%2F4ff432e af904ac53%3Fq%3Dbokma+perl+skills+python%26rnum%3D 2%26#doc_dc30957084149f8e but after some time I got the feeling that just his Perl skills were severly limited.
Perl Programmer for hire
Yeah, ruby runs fine on any of the common platforms.
Yahoo, yeah, now there's a really weird place, which only happens to come into existence when people really want to use what seemed like the right tools at the time... They have stuff in both Common Lisp and PHP. I can kind of understand CL but PHP is still kind of weird.
(And they have quite a bit of stuff in other languages as well, to be fair - Java and Perl at least. I think I saw a .py or two in an Yahoo URL somewhere a few times. I always kind of liked the fact that they don't make their language choices very apparent unless you point them specifically out.)
You talk about a PHP3 lib and think this is current implementation? Of course an API does not change. But in PHP5 you've mysqli:As you see it's the way you want it. And every new lib since PHP4 follows the same guideliness.
BTW no one should use the database libs directly anyway. Use an abstraction like adodb or PDO in PHP 5.1. If you'd have a well structured code you'd never see the mysql quirks.
b4n
In the book, he advocates reducing lines of code by getting rid of temporary variables where possible. I've never agreed with that philosophy, and I think it's a terrible way to make code maintainable.
magic quotes ... I don't think there are appropriate words to describe how stupid that is. Everybody needs to suffer so newbies won't have to escape data before inserting it into a db?!?!?! Arrghgh!!!!
Do you even lift?
These aren't the 'roids you're looking for.
Not unlike Michael Jackson's dick the morning after a Macaulay Culkin sleep over.
Do you even lift?
These aren't the 'roids you're looking for.
Solution: Add more functions.
I like the PHP language, but the functions are a mess. Functions that shouldn't even be included (ie converting jewish dates to non jewish dates). Naming schemes more erratic than Courtney Love. Functions which work differently depending on the version. It's a mess.
There are not too many functions. --without-mysql and all mysql_* functions are gone. That's how modules work in PHP. It still has no namespace (maybe PHP6 via Parrot) and thus the prefix.
;)
They made a new module for different reasons. First everyone know the inconsistency sucks. But you can't just change alls mysql_* functions and break older code. Second mySQL matured. Mysqli is meant for mySQL 4 and adds some new functions like prepare or transactions.
Again if you don't want them don't compile them.
For the jewish stuff. I guess someone could need them. Like some people need to know when is Easter. But again if you don't need them don't enable the calendar module. It's not enabled by default anyway. Thus you're responsible for having them, or maybe you're using windows - I won't comment on that
b4n
PS: Try to register. It's always nice to know to whom I'm speaking, AC