Slashdot Mirror
Elements of Programming with Perl
The teaching flow is logical and consistent, with chapters dividing the material into logical divisions. By the end of chapter flow, students should be capable of writing moderately complex programs. Subsequent chapters build on that foundation, and most provide a specific example program to tie things together. These programs all have a practical concentration.
On the Perl-specific side, Johnson does not shy away from recommending the copious Perl documentation, CPAN, other books like the Camel, and many other excellent resources. Much of the value of an education is learning where to go for further information.
What's not Great? Some of Johnson's focus is on mathematical applications, which may distract some readers. Also, this book may not serve as a future reference after you've become more comfortable with the language. Look to the Camel or Perl in a Nutshell for that -- Johnson concentrates on teaching the basics rather than documenting the iotas and tittles of internal Perl functions.Finally, the example program in Chapter 19 may be hairy for novice programmers. Sit down in a very quiet room with a pad of note-paper and your beverage of choice. Consider it a final exam after you're familiar with everything preceding it.
Summary This is a good introduction to Perl, and a very good introduction to programming in general. Johnson promotes good habits and discipline. Elements may not sit on your shelf as a reference, but it will help you to become an effective programmer. It's a rare book that teaches as well as it informs, so take the plunge and teach yourself Perl and programming.Pick this book up at ThinkGeek.
Table of Contents
- preface
- acknowledgments
- Introductory elements
- Introduction
- Writing code
- Writing programs
- Essential elements
- Data: types and variables
- Control structures
- Simple I/O and text processing
- Functions
- References and aggregate datastructures
- Documentation
- Practical elements
- Regular expressions
- Working with text
- Working with lists
- More I/O
- Using modules
- Debugging
- Advanced elements
- Modular programming
- Algorithms and data structuring
- Object-oriented programming and abstract data structures
- More OOP examples
- What's left?
- appendix A Command line switches
- appendix B Special variables
- appendix C Additional resources
- appendix D Numeric formats
- glossary
- index
Putting aside the (flamebait) arguments that Perl is or is not a good first language, I've seen several people turn to other languages that were less appropriate for their needs (like sysadmins) because of the lack of a good beginner book for Perl
Until now, it's been relatively easy to find books on C, C++, Java, etc for the non-programmer, but Perl has historically been supported by tomes that double as reference manuals, which are not really the best for first-time language instruction
Even the excellent Llama book (Learning Perl) assumes some familiarity with the use of logic and simple programming concepts (like variables). This makes it doubly difficult for a newcomer who wants to harness the text-processing power of Perl but quickly becomes lost in its (admittedly unique) syntax.
I'm glad to see a better entry point to perl for the programming newbie. Maybe now the c.l.p.m. s/n ratio will improve
So E is relatively prime to (P-1)(Q-1)... Odd, that.
That's fine if you know programming already. I can just picture an English lit graduate trying to learn programming from slash 0.9.1... hahahah :)
And besides that - theres an awful lot of crud code in the open source world (as there is in the closed source world - but you can't download and learn from that) and I'd hate to see someone learn object oriented techniques from that rather than a good book on the subject.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
I've used perl a LOT, and i think it's extremely sweet. AND i appreciate the review of the book since i think i will be getting my little brother into something soon and i _may_ choose perl since he likes the web and such. It would get him plugged into CGI quickly.
( 115),10);'}
However, i've been hearing more and more about python, so i decided to grab Mark Lutz's book "Programming Python" published by O'Reilly. I'm not too far into it yet, but in a couple of weeks should have chunked through most of it. As a further test to see what's so great about this thing, i'm going to write an OOP app in it (not too sure what it will be yet). Cuz as of this moment i can't see the reason to switch from perl.
But the question is, would anyone care to have me post a review of this book eventually?
Cheers,
DQ
------
perl -e 'print {$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct
os.system("perl -e 'print \"My first Python Script.\"'")
I agree no book (O'Reilly or otherwise) is perfect. But uhh... i have to ask: Why on earth didn't you look in the book(s) to see if it had what you wanted first?
As geek books go i find that OR books tend to be pretty high up there. They are certainly the ones which are most consistently good. Other books have better information in them that beat one of OR's books from time to time, but there isn't anything out there i've found that can beat them all, or even come close to doing that.
os.system("perl -e 'print \"My first Python Script.\"'")
before I start, I would like to thank the reviewer for their time in posting their comments.
IMHO......
From a non system-admin point of view...Perl as a first language is scary.
Thats not to say Perl isn't useful or good, but I would not want to learn about programming by learning Perl as my first language. It has way to many oddities that, if you are interested in programming, don't make the conceptual leap, as it were, to other languages.
For example, in Perl (like most scripting languages) there is a single data type to represent everything from strings to characters to all sorts of numbers. Java/C++/C/Fortran/Basic etc...have different data types (short, long, char, String etc...) for very good reasons.
Having someone learn programming via Perl then have them get "more specific" is harder than going in the reverse direction. I can just imagine all these questions from students..."What do you mean there are specific types of variables? "What is strongly typed?" etc....
Perl also suffers from a syntax problem. Perl has chosen highly compact notation that can scare even the mosty hardy Perl programmer.
I say learn another language so you can see how Perl has generalized the problem space, not the reverse.
With these things in mind, I think the usefullness of this book is not as high as one might think.
I'm still working on a clever footer.
From a strictly academic viewpoint, Pascal enforces excellent programming practice. Unfortunately, it isn't used very much in the real world. As a general purpose starting language, I'd bite the bullet and learn C++. It has it's own set of ideosyncracies, and you have to be careful not to get too gung-ho on classes (It can be easy to get out of hand, for example, the Microsoft Foundation Classes are just plain scary). :)
Java has some design flaws (see the January and February 2000 issues of C/C++ user's journal) and you are at the mercy of Sun. Plus I don't care what anyone says...Java is slow.
With the advent of a standardized C++, it doesn't make much sense to learn straight C right off the bat, and besides, in my experience people who try that end up learning a weird C/C++ hybrid. (ie. the only C++ features they use is streams and the ability to declare variables throughout your code).
If you learn C++ though, it is important to learn when not to use it. Sometimes plain old procedural C is best. Hell, sometimes Perl is best. VB is very rarely best, and COBOL is never ever best.
--GnrcMan--
Hmmm...
Perl + convert = Pervert?
:)
Andover's self-referential integrity is still intact.
That argument doesn't merely apply to books; it applies to all facets of education. If the knowledge is out there, why don't we liberate ourselves to seek it rather than being directed by some obscure authority figure?
The fact is that this doesn't work. The act of seeking relevant information alone gradually takes more time than absorbing the information itself (as any graduate student can tell you). An instructor, whether at the podium of a lecture hall or at the typewriter, putting together a book, does the initial search for you.
If your time is worth nothing (and some people's time is worth nothing), then you can spend time working through library catalogues and search engine results. You can gain sufficient experience and knowledge to figure out a subject on your own, but it takes time. Most people, including myself, don't have that luxury; we could all reinvent the wheel, too, but why?
--
--
There is no premature anti-fascism. -Ernest Hemingway
Any good programmer knows that sometimes there's no substitute for treeware, particularly if you don't have the monster monitor from hell on your desk. It's bloody difficult to use a highlighter on a CRT, or scribble in its margins. This goes triple for the source code you're hacking on.
:( ) No, I don't have the bloody URL for it. Besides, I wouldn't want to be seen as advertising one bookseller over another, particularly given the current political climate concerning a certain 250-pound-and-growing-fast gorilla of an e-bookseller we have in this town... as if Boeing and Microsoft weren't gorillas enough... jeez.
Actually, a good solution (perhaps not the best) is that new CD O'Reilly is selling that has all six of their Perl books on it, that just happens to come tucked in the back of a treeware version of the Nutshell. (It also comes with a search engine, but apparently O'Reilly's R&D department is sadly WinDoze-centric...
But really, if you already have the proper filters in place and know good code on sight, then, no, books are often more frustrating than not. This is not this book's target audience. OpenSpace doesn't need the book... but my friend across town who's just getting the hang of the whole coding thang... might. My ten-year-old friend who is just being allowed to tinker with web publishing stuff for the first time... most certainly.
Something us olde farte geeks tend to forget is that there are, in fact, newbies out there, and that if we don't train them correctly the first time, they turn into script kiddies instead of budding hackers. Doubleplusungood. Thus the need for good treeware docs.
--
"Hey, rat!" yeah?
"Where's your rat hat?" (points atop flagpole) there.
"Get it."
I guess another thing to consider,too, is why you're learning to code in the first place.
If you're completly new to coding, Pascal is a bloody good language to teach you fundamentals: loops, iteration, variables, functions etc.
Heaps of "learn x in 24 hours" book forget these fundamentals, and I have debugged a shitload of code written by finance geeks that could have been a lot more concise and efficient if they had known the benefits of using functions rather than retyping a whole bunch of code every time they wanted to add a few columns of numbers.
I'd have to say C++ is a horrible language to learn as a first language. There are sooo many "advancd features" like operator overloading, all sorts of class issues (try explaing friends to someone who just learned the difference between x++ and ++x.
In fact, even if you're an experienced coder learning OO techniques, C++ can be confusing. I remember my second year at university going from simple little MacPascal programs to C++ on DOS and Unix machines. It put me off coding for a long time.
I'm not sure what the design flaws in Java are, but it has been pretty easy to pick up for a guy who previously maintained code written in xBase, VB, Delphi and plain ol' procedural C.
I've also heard Python is a good language to learn good OO techniques.
I'd say unless you really, really, really need to learn C++, stay away!
OT:Anyone using Java with MPW on a Mac? Mail me and tell me what you think.
my blog: good times, man, good times
Handspring Visor (TM) + iSilo (TM) + The Perl CD Bookshelf = Perl Hacker's Reference Nirvana
:)
I carry 6 books with me on Perl, along with the whole bundle of Perl docs that come with Perl itself, on my Handspring Visor with a memory expansion module. It's nice, fairly readable and usable, and searchable. I even read the XS tutorial while in the can. It took some ponderance and reflection, and what a better place to do it?
As for the search engine on the CD-- it's in Java, and I've gotten it working under Linux. IIRC, there are directions in the kit on how to get it working.
As for books in general, I'm working on getting more and more of them into my Visor, but I still tend to need a physical papery copy of it lying around. Electronic books (at least on the Visor) still haven't gotten the correct user interface details down to replace paper.
My current companion is DocBook: The Definitive Guide, so that I can be a DocBook XML expert while composing the massive body of documentation for my Open Source project. Try learning a new set of XML tags without flipping rapidly back and forth to see what's valid within what, what attributes are legal where, and what the hell is this?
There are many reasons why Perl may or may not be a good first language, but this can't be one of them, since it just isn't true. TCL used to be the textbook example of a language that used the string as its representation for everything, but TCL isn't string only anymore, either.
Really, I don't know where people get this idea about Perl, which certainly isn't the most typeful language on the block, but is hardly short of interesting types. I suppose it comes from the fact that Perl does provide a lot of automagical operators and conversions (although the fact that conversions are involved should make it clear that Perl has more than one underlying type).
But one thing I'd like to point out in particular:
Says somebody who clearly hasn't ever had to justify the difference between a short and long to a beginning (or non-)programmer. I would actually argue that the short/long difference is exactly the kind of "people working for the computer" stuff that doesn't belong anywhere near somebody's first exposure to programming.
If you want to teach the importance of types at the same time you teach programming, you would do better to use a language that has a more interesting and flexible type system; one obvious candidate would be Haskell, or it's interpreted cousin Hugs.
Babar
Scheme.
Imperative languages in general present syntax obstacles that you shouldn't have to deal with. Because of its genesis, perl is the most challenging, but C++'s provenence is nearly as mongrelish. It so happens that the greatest computer text ever, Structure and Interpretation of Computer Programs, by Abelson & Sussman, uses Scheme, but if you don't have a teacher, this book is not for beginners. You might want to check out The Little Lisper or The Little Schemer by Friedman
Perl is, without a doubt, the absolute last programming language you'll ever need.
Give up on pointers -- they're an archaic holdover from assembler. If I have to think about memory addresses, I might as well toggle the program into the front panel in hex.
Memory management? Don't make me laugh. The only thing that causes more bugs in software than forgetting to free resources is walking into memory you're not supposed to use (see "pointers" above).
OO is a failure. Sorry, I know this akin to telling some people that God is dead (or that God never existed). It's true and whining won't change it. OO promised code reuse and it never happened. Programmers trying to make reusable classes all went over deadline and were fired. They were replaced by quick-and-dirty hackers who understood that management just wanted to get the darn thing shipped. The only code reuse going on is open source coders who snag each other's routines for their own projects. That's a good thing.
I'm tired of hearing the "Perl is a scripting language" whiners. At this point, a "scripting" language will do 99% of what needs to be done with a computer. The operating systems are written. The applications are written. All we do now is glue them together to get the data we want. If it's harder than that, you're probably reinventing a wheel.
"Enterprise systems?" Yeah, right. Most of those enterprise systems are aging COBOL and C driven junkers that should be replaced with multiple x86 boxen running Linux or BSD. They're cheap, reliable, and you can find people to work on them who don't cost an arm and a leg. If you think it takes more than that, you're just wrong.
-- In the future, everyone will code Perl for 15 minutes. --
Well, Perl has some advantages and disadvantages as a learning programing language. I definitely agree that its lack of strong typing and quirky handling of nested data structures are things that I wouldn't want to force a beginning programer to learn. OTOH, I think that some of its other features, like being interpreted, having localizable variable, and having easy file handling, are things that are desirable for a learner.
What might be interesting is a list of features that should be in a language for beginners. Everyone seems to complain about the things that various languages do wrong or don't include, but it might be nice to have a list of things that should be included. My modest attempt at this:
Any other ideas for what a language should have?
There's no point in questioning authority if you aren't going to listen to the answers.
The best thing about C is that almost anybody with any sense teaching or learning C uses K&R. Beginners consciously or unconsciously absorb a standard style and approach to common programming problems that are within the purview of the language.
What's the worst thing about Perl? The biggest complaint I hear is that Perl is cryptic; however I think this is bit of a bum rap. It isn't hard to make C programs that rival the worst Perl examples. Also, I've found some largish Perl systems that were a breeze to maintain, very clear and well organized.
I think a lot of this complaint really can be traced to the Camel book, which while generally admirable and clear in its explanations is a bit too hung up on the Perl motto: "There's more than one way to do it". It is an interesting, and perhaps essential element of the Perl philosophy (I haven't decided which), but unfortunately every new Perl programmer who uses the Camel book to learn makes up his own idioms, and they don't always choose well.
I'd be interested in the consistency and quality of the Perl style in the book. It may be time for an "elements of Perl style" handbook.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Point taken, maybe C++ is a bit complex (I didn't take that route, I went Pascal->C->C++.) What do I know, anyway? :)
Casey
--GnrcMan--
Perl zealots sound exactly like VB zealots, and for the same reasons: It's a blunt instrument. It looks "powerful" to them,
but that's because they just don't get it.
That is a very insightful statement(ignoring the surrounding flamebait). Gung-ho Perl programmers do have the same mentality and viewpoint as VB programmers.
But the reason Perl is so quick is the same reason that VB is so quick. They both let you get away with almost anything. While this is fine for small scripting solutions, it breaks down as your application becomes more complex.
Perl is useful, but only for small scripting problems. As your problem grows, Perl becomes less and less useful and no amount of burying your head in the sand will change that.
One of the most important and valuable skills a developer can have is knowing what tools to use for what job. I use Perl to bang out a simple script in a day or two. For anything more complicated I use C or C++.
--GnrcMan--
As I said above, point taken. I was looking at it from the mindset that you might as well learn everything at once. But looking again, I can see how a learning programmer could get bogged down and frustrated by C++. After all, I learned C first myself* , so what do I know anyway?
:) But once you realize what C can do for you, the payoff is enormous.
In response to your flamebait: You certainly can use C for just about anything you can use C++ for. However there are many extremely useful constructs in C++ for large scale development. Besides, C++ isn't just about OOP. While that is probably the centerpiece of C++, there are lots and lots of extensions which have nothing to do with OOP.
* Actually, I learned Pascal first. Moving from the protective womb-like Pascal environment to the cold and uncaring world of C was scary.
--GnrcMan--
Does Perl support OOP?
Yes and no. How's that for a lame answer. Let me expand.
Perl cheats. Take this exerpt, straight from Programming Perl:
* An object is simply a referenced thingy that happens to know which class it belongs to.
* A class is simply a package that happens to provide methods to deal with objects.
* A method is simply a subroutine that expects an object reference as it's first arguement.
What they appear to have done is tack on some features which, when added to your regular old subs in your regular old packages, auto-magically turn the package into a class. Inheritance is barely supported. (There's an array called @ISA which has a list of packages to look in for "methods").
To be honest it seems very kludgy to me. It almost appears as a way for procedural programmers to get that warm and fuzzy object oriented feeling without actually doing it properly.
By way of truthfullness in advertising, I'm not terribly familiar with the OO features of Perl, but to my untrained eye, it's somewhat akin to a C programer adding functions to their structs so they've got packaged functions but can still access the data members freely. Sure, you've got an object, but you're missing the point.
--GnrcMan--
First, It amazes me the maturity level one finds on public discussion boards. I am very grateful for the moderation system, so that, in general, I ;-) ). The x86 is still alive and kicking, /^A/; END {print $x }' " and other such one line programs that I can test the concept of in less than 10 seconds.
do not have to be subjected to this. But on topics such as this, I feel compelled to actually read everything. How people's opinion of Tom
Christianson relates to this escapes me. He has contributed considerable intelligent information that can only help the Open Source community.
I'd like to present the idea of evolution, if I may. A man evolves by growing more nimble fingers, a larger brain with greater capacity for
memory, problem solving, etc. He evolves by being able to withstand harsh cold ( or hot ) environments. Often times, man finds himself with
strange and seemingly useless biology: An appendix, toes, back hair, various skin tones and shapes, etc. Life, on the other hand, evolves
through natural selection of species. When one species can no longer adapt ( analogously finding a local minima that they can not surmount ), it
is replaced by others.
The same holds true for our silicone world. A technology is created. The environment changes, and the technology must adapt or die. Death
involves reinventing the wheel with our new life form; starting from scratch on the technical design, AND convincing a target audience to
support the new technology. Thus, just like in nature, the predisposition of a technology to adapt is greater than it is to die off and be replaced by
something new.
As a case example, take Intel's x86 ISA. A venerable and intelligently adapted system. Sure, the original draft of x86 didn't take into account
32 bit memory, pipelining, n-way parallel instruction execution, etc. Yet that same language has been adapted to systems today that are among
the fastest and cheapest in the world. This of course, was not to the merit of the appauling instruction set, but to the adaptiveness / inventiveness
of their designers who knew how to maintain their market. Before shreding the idea of the x86 ISA, try, yourself, to invent a hardware language
today that can cleanly adapt to technologies 10 years from now. ( neural message passing systems possibly? ) It's really hard to do. The only
real way is to have enough of an influence to periodically reinvent yourself in an incompatible way ( as Apple or SUN was able to do. Though
their lack of a perfectly competative market reduces their value to the computing society as a whole. )
Perl, likewise could not have have forseen all the uses that it has today ( and therefore produced a language suitable for everything ). Written
first as a scripting language, then later as a full general purpose language. Never being fully without bugs, constantly reinventing itself, yet
keeping backward compatibility as best possible. Still later, we add certain modern programming techniques ( again without breaking
compatibility ) such as OOP, and threading. Threading isn't fully stable, and many important packages ( such as DBI ) warn against using it,
while OOP is something of a perversion of classical approach. It is difficult and inconvinient to consistently define class objects. When dealing
with OO, I much prefer java ( and to some small degree, Python ) since these were created after the OO revolution ( or skirmish, if you prefer ).
Still, perl seemed better apt to handle these two revolutions than C ( which isn't pleasent for writing threading code, and had to be mangled in
order to handle OOP ). Without breaking backward [symantic] compatibility, perl has managed to encorporate many exciting modern features.
It's nature has even allowed it to adapt to web server-side embedded scripting ( in the form of ePerl, embPerl, mason, etc ).
My focus is not that perl has conqured the world, but that it has survived the changing world. It has its scars and strange looking unused
appendages, but for it's intended purpose, it provided zero down time through the evolving years ( referring to porting time ). People that buy a
new linux distribution could still use their old perl scripts as is. But additionally taking advantage of the newer features in the new release. Much
like one can do with the x86 architecture.
If we take a look at java for a moment, we'll see yet another example of the uglyness of evolution. Originally concieved of as a fresh new
concept taking advantage of the state of the art in computer science ( If you'll forgive the proposition ) we're already in our 3'rd revision, which
has made heavy use of the term deprecation. First we do it one way, then decide that there really is a better way of doing it. But now we've
discovered a more elegant approach to event handling and change so we change things yet again. Each time, it was essential to maintain
backward compatibility ( this is still a fledgling system, and supporters would not accept such unreliable lack of support with legacy applications
as they might with the conversion from SunOS to Solaris, or mc6800 -> powerPC ). Java is in the same boat as perl and x86 in that as long as
the language evolves, it will be plauged with legacy features. Thankfully I can think of little that is hurt by the existing evolutionary steps in Java,
but it is still much younger than perl or x86. Give it a decade and we'll see how well it fairs against new and shining languages. And some will
support Java even though it is considered archaic and too difficult to keep up with the new boys. Or stead-fast C coders will mock Java, saying
C was the true language all along ( as some humorously still do about assembly today ).
The key is really whether a life form ( or a technology ) has outlived it's usefullness. Java obviously hasn't. It's a good programming model (
with far fewer points for error than C++, with what I'd call, similar support for the technology ). ( Notice I said model, since, obviously the
execution time is subject to debate ). C is going to be around for as long as UNIX. Assembly as long as the discrete instruction model exists (
I'm all for neural messaging systems personally. Interpret your code directly without compilation!!
simply because the technology is such that the underlying negative effects for a non-optimal instruction set are offset by pipelining and caching (
as in the case of AMD's micro-op cache ). To boot, this performance increase in changing the ISA is miniscule compared to the inconvinience
of developers supporting a new platform. The added cost of compatibility translation hardware is offset by the massive economies of scale. As
far as I'm concerned, we were taught a long time ago to not program in assembly when you can program in C, ( and consequently, not program
in C if you can use something more aptly suited to the task ). Thus the processor is a black box, and I could care less what instruction set it
uses. Give me performance / cost ( and if I'm in a laptop, additionally devide that by power consuption ).
So what of perl? Originally designed as a reporting language ( before the days of the Dynamic web ) it now finds itself primarily as the glue
between c libraries. To my knowledge, perl was not designed as the creator or the repository of information, but for the "extraction", and
"reporting" of that information. Thus the DBI hook to mysql and the CGI front end allows it to format the data found in so many of our web
sites. But this specific functionality has been built anew by php. Doesn't the [cached] CGI method of c-like logic control structures seem
outdated in the modern world of table generation and data reporting. There have been no new op codes in perl to conviniently generate an
HTML table in perl ( though embPerl and the like do so nicely but at a much higher level ( and thus less efficiently ) ). Thus has perl been
replaced by php or the like in the realm of simple DHTML DB reporting? And since HTML is a far more common report medium than
vterminals, has the underlying theme of perl been superceeded? I'll leave this as an open item.
Whatever perl's role in the web, it still has roles in System programming. I find perl much more powerful and pleasant to program in than sed,
awk, or even bash. If you need to write a filter or data converter from one database to another, I doubt that you're going to use php, and possibly
not even C ( unless you really don't know any others ). If you want to provide a summary of slack space used on your hard drive ( sorting by
directories, then by files, etc ), I'd find a hard time doing this in any other language than perl. ( Not impossible mind you.. ) Also I find perl very
useful as a configuration script or simple socket daemon. Additionally, I can take advantage of many libraries that have perl hooks into them.
OpenGL, XML parsers, TK, QT, Gnome, OLE, NT registry, socketing, etc. I can take advantage of these without having to learn all the
intracacies of each language. I can play with new technologies found on CPAN, and decide early on if they're worth persuiing. The late binding
and non-strict type checking really aid in such a transparent interface.
Peronsonally, I find these times exciting. Who will win out in the language wars? Of course there will be more than one winner, because there
is more than one target audience. As each new computing need arises, existing languages will adapt, and new tailored languages will appear. It
is this trade off that the devoloper has to make. Personally, I like the advantage of perl's wealth of c-library compatibility, so I write many
things in perl ( and even write emulators of HTML templating, or even the FastCGI / java-serverlet model to suite my own needs, just so that I
can make use of certain libraries that are not readily availble in php or Java ) It also means I can have a common library package for both
configuration / database manipulation and CGI scripting.
I like the open nature of perl ( hard to compile away into hidden libraries ), I like the "more than one way to do it" methodology. I like that I
_can_ write strongly typed modules ( through perl 5.005's "my Foo $var = new Foo;" and the "-w" and "use strict" directives ), but can also
write "perl -pe '$x++ if
( though the obove seems clearer with 'egrep "^A" | wc ' ). When solving such specific pre-defined dillemas, perl excels.
I should hope that I have to say very little about the most important contribution of perl; it's regular expression library. Highly optimized C (
depending on which version of perl you're using ), has managed to take an NFA construct and extend both it's efficiency and feature set. I have
never seen such an extensive reg-ex package in all my years of programming. ( I would definitely be interested to learn of more powerful ones
if any of you is able to provide me with such info ). php has seen fit to include perl reg-ex's, but I'm not sure how up to date, or how completely
compatible it is. To be able to mathematically speak to your computer in such a way as to have it almost understand what you are thinking ( in
terms of syntactic identification and manipulation ) never cieses to bring a smile to my face. Having the ability to intelligently merge a group of
HTML files and into a single one with 3 lines of reg-ex code expresses such a mathematic bueaty I can not properly describe it. It isn't about
doing it in fewer lines of code, it's about commanding power over symantics. Of course it seems cryptic to the uninitiated. So does calculus. Is
that any excuse for shunning the language? Neuton invented Calculus because it was too tedius ( and in fact impossible ) to correctly describe
bodies in motion without it. Yes I can write an optimized and easy to understand filter or parser in simplistic C constructs, but reg-ex allows you
to attack the problem from a completely different and extensible approach. I've regularly written entire parsers in perl ( memory management
alone eases the pain of writing a parser ) as a simple OO module that gets loaded into a larger program. Meta language is therefore much more
obtainable in a smaller development group. Even today, perl's reg-ex is being extended with parenthesis matching, and the refinement of a
procedural approach. So long as perl contains the most powerful and unmatched reg-ex library, I will not lose use for it. But meanwhile,
nay-sayers will scoff at perl code littered with such "unreadible" expressions, happily ignorant of the calculus of the programming world.
Lastly, on the topic of a first time language ( which seems closest to the original topic ). Perl is great in that it allows the most straightforward
possible program. perl -e 'print "Hello World"'( as with BASIC ). You can even enter the debugger and type this in manually ( again, a la
BASIC ). You can create an initialized variable the first time you use it.
$x = 2 + 3; print $x;
Essentially, I'm claiming that perl is every bit as good as BASIC as a first time language. Moreover, it's better than the old GWBasic, Apple
Basic or TI Basic that I first learned on, in that we're not dealing with antiquted line numbers, or goto's. Intead we have very nice flow control
structures ( last, next, redo ). Aside from that, you could completely take a BASIC lesson plan and "port" it over to perl, with the advantage that
the student now contains some real world experience ( as opposed to BASIC ). I doubt system programming is a good second step. Perhaps
CGI's, though you really do need to have _some_ programming experience before you're allowed to crash your school's local web server.
Just for reference. I learned the
Basic -> Pascal -> Scheme \
C -> C++ -> System programming ( insert thousands of languages here including Java and Perl )
I kind of like this approach, but am basically questioning if Perl could replace Basic as I've said above. Real work should _not_ be performed
until a C like language is well understood. But there is no reason you couldn't return to perl at the system level.
Well, this is long, and time is short, so I shall end you here.
-Michael
-Michael
There were several people complaining about this. I was one of them, but it's not me doing the attacking. For the record, I'm thrilled that the code's out, and have no further problem with slashdot or it's management.
You're right though that /. appears to be suffering what amounts to a DOS attack, in the comments. Maybe we could rename it a "Denial of Signal" attack.
My only suggestion for this is that basically, totally anonymous posting should go. Here's how I would do that:
- To post a comment, you must have a user account and be logged in.
- You MAY choose to post your comment anonymously. The system will know who you are, but your name will not be associated publicly with your post.
- User accounts must be confirmed via email before being activated. That is, you sign up,
/. sends you a "confirm" mail, and you return it to activate the account. - Accounts may be disabled by admins because of abuse of the comment system, which constitutes a DOS atack, as I mentioned above.
The overall effect of this is that it would be much more difficult to automate the slashdot-bombing procedure, as you'd have to create a new email account and user account every time you got booted. I think this would kill about 90% of the worst crap posted here.Note that I'm talking about the long pasted-in text posts, and the really just useless crap. Some of the trolls are amusing, and I don't think they'd get all get booted.
As for the user account hijacking problem, I assume there are some security issues with the slash code. Bummer.
Wish you could moderate the submission queue?
There is no K5 cabal.
I am not the real rusty.
Not sure what this discussion has to do with the subject of the story (and, in that sense, it's as much a DoS as the "attack" the posters are complaining about), but the above is hardly a hindrance. It wouldn't take a halfway decent coder more than an hour to write a Perl or Python program that creates a new email account on one of the many free email services out there, and a new account on slashdot. Let the account generator run overnight, and you have quite a few accounts you can (mis)use.
I would say, let's keep the "Anonymous Coward", but add an "AC" filter, regardless of your comment level. A filter like "show me only comments of people having positive karma, have made at least 10 comments, and have been around for at least 4 weeks" would be useful.
-- Abigail
That depends on what your view is. If you mean that C and C++ have the types of variables more visible in program text than Perl, certainly. I disagree that they are strongly typed. Or whether C's typing mechanism is actually useful. Take for instance a look at this program:
#include<stdio.h>
#include<stdlib.h>
intmain(void)
{
unsignedchar*c;
floatf=10;
for(c=(char*)&f;c<s izeof(float)+(char*)&f;c++){
printf("%u",*c);
}
putchar('\n');
return0;
}
Compiling that with gcc -Wall, you get:
float.c: In function `main':
float.c:9: warning: comparison of distinct pointer types lacks a cast
A warning that shouldn't be there, and many type violations that don't get flagged at all.
I wasn't sure what that meant. An array is a list of values addressable by a subscript, ie foo[1]. I simply don't understand what you mean by "monsters that try to look like arrays".
C lacks useful operators on arrays. You can't add from arrays. You can't take pieces of it. Copying arrays is fun too. Look at the following program:#include<stdlib.h>
#include<stdio.h>
intmain(){
int*a;
int*b;
a=(int*)malloc(sizeof(int));
b=(int*)malloc(sizeof(int));
a[0]=3;
b=a;
printf("%d\n",b[0]);
a[0]=5;
printf("%d\n",b[0]);
exit(0);
}
When run, it will print
3
5
This is of course because we copied pointers, not arrays. So, let's change the program slightly, to use arrays, not pointers.
#include<stdlib.h>
#include<stdio.h>
intmain(){
inta[1];
intb[1];
a[0]=3;
b=a;
printf("%d\n",b[0]);
a[0]=5;
printf("%d\n",b[0]);
exit(0);
}
Fun. This won't even compile - due to a (to make the circle round) a typing error:
try.c: In function `main':
try.c:9: incompatible types in assignment
So, that's what I mean with monsters. They call themselves arrays, but they really just pointers - and the language doesn't have anything to actual manipulate arrays - just pointers.
Arrays in Perl are used to hold data structures.
Rubbish. Arrays in Perl are used to hold data, just like in any other language. An array can be (an implementation of) a datastructure, or be part of a datastructure.
I don't think arrays have enough structure for a beginning programmer. While C structs allow you to defeat the structure, you at least have the option of defining a rigid structure and having the compiler enforce it.
Perl arrays certainly don't have less structure than C arrays or Python arrays. And just like in C or Python, or most other languages, Perl has more data structures than arrays. If you want structures, pseudo-hashes will approximate your needs. Compiler enforced checking, with the speed of arrays.
Personally, I don't think statements of opinion with earnest attempts to explain the reasoning behind the opinion constitute trolls.
"Don't get me started on Perl arrays" in a discussion about a beginners book of Perl doesn't contain any reasoning in my book. It was nothing more than a flamebait.
My initial response to you was hostile. Why? Because your initial post to me was hostile.
I think your first post was hostile.
-- Abigail
Given that this isn't something appropriate for either JavaScript or HTML, I'm somehow unsurprised that it wasn't covered.