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
The ultimate tool is a good set of definitions. All I can say is
print "Good bye book world";
print "Hello wired world";
Unlike windows, linux distributions come with it.
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.
Also, Tom Christensen is a fucking asshole.
Open dk() at all?
Thank You
Perl certainly is good for many things, and it really can't be beat for many uses, but like linux, it's not an answer to every question. There are things that perl (or even linux) aren't the best solution or even an appropriate tool.
For example, the company I work for spent over a year going down the dead-end road of trying to implement a petrified Natalie Portman in perl. After all that was canceled, we were able to have a working prototype written in YAIL (Young Actress Implementation Language, an industry specific language) within 1 month.
Yes, there are rough edges and bugs - the finger interface can cause a spurious signal 69 to be produced and/or a core dump), but after 70-100 man years of work with Perl, all we had was a mess of gobbledy-gook code that no one understood, and didn't even run.
Anyway, thanks for your time
I post anonymously because I'm more interested in the discussion than the karma
...
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.\"'")
What I've found with O'Reilly is that they really want to sell you more books. For example, I bought their "HTML Definitive Guide" a few weeks ago trying to figure out how to protect subsequent pages after a user enters their password. Of course, this topic is not covered in that book (some Definitive Guide, huh?). It sort of pointed to their "JavaScript Definitive Guide", so I bought that one yesterday. They only mentioned that topic long enough to say they were not going to cover it.
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.
This is an excellent book - I hjust picked it up last month. The section on modular programming is particularly thorough. But how is this News for Nerds or Stuff That Matters?
I can see why it looks difficult to learn, having just taught myself the basics. However, it's worth learning! Having scalars that aren't strongly typed is a little weird for me, since I came to Perl by the BASIC->Pascal->C route, but after I got used to that and the enormously greater flexibility I have in Perl, I haven't looked back. Two days after I cracked the book, I was doing more with Perl than I've ever done with C.
IMHO, any entry point that makes it easier to get started in this language is fine by me. The camel book was a bit over my head too when I got started -- it's only started to be really useful to me. (Thanks Randal for Learning Perl, BTW!)
73 de N5VB (ex-KD5BIV) AR SK
Perl sucks my rather considerable dick.
Don Knots guy endorses this post.
Thank you.
I bought the llama book recently, but admittedly don't know how to program at all. What language would be best to start with?
You should know what the language, tool, or technologoy is for before you try to use it. Don't blame Ora on the HTML book not having information about "password protecting". HTML has nothing to do with security.
I'm looking for a Perl book that already has a bunch of good scripts for log analysis and shopping carts etc... and basically shows you how to implement them. Why re-invent the wheel everytime.
Nathaniel P. Wilkerson
NPS Internet Solutions, LLC
www.npsis.com
Nathaniel P. Wilkerson
www.haidacarver.com
Although paper books have a better UI, you can take them anywhere easily and read them in your bed or upside down...
This AC thinks we need more books (perhaps in PostScript form) written by volunteers and distributed freely via the net. There are tons of skilled people out there, so maybe they should write a book! Us poor students could save a load of money to put into pizza and alcohol and the like.
UnrealScript b17ch3z!!!!
This guy is a raving lunatic! I don't know what book he read, but the Elements of Programming with Perl that I read was something entirely different.
This was the bittersweet story of Natalie Portman's coming of age. The beginning of the book, which gave a brief history of Natalie's childhood, evoked long-lost memories of my own growing-up. The chapters describing her 18th birthday made me giggle with joy. The part where she befriended the lubricating midget who was suffering with tourette's syndrome made me cry. Not to mention the sexually charged passages describing Natalie exploring herself while reading posts about herself on slashdot.
This book has it all. I highly recommend it for anyone wanting to spend time becoming better acquainted with their favorite hot young actress. You won't regret it!
On the Open Source Hot Young Actress book scale, this one gets 10 gnu-sausages.
thank you.
"...trying to figure out how to protect subsequent pages after a user enters their password."
Would you please e-mail mail as you figure it out?
Thanks.
Perl also suffers from a syntax problem. Perl has chosen highly compact notation that can scare even the mosty hardy Perl programmer.
I'm assumint that you're referring here mostly to the special variables. You can use the more abbreviated syntax if you like, you can also do things more explicitly and plainly and define everything carefully. It is nice to have a quick'n'dirty when you get used to it though.
Again, though, I agree with your main point that data-type issue would be possibly bad for a beginner.
A harsh comment. Anyone unfamiliar with Mr. Christiansen might think it unjustifiably harsh. It isn't, though. sr
Of course, if the day ever came that Windows did ship with Perl, we'd hear the usual Slashdot bitching and moaning about those unfair Microsoft bundling tactics.
You know it's true.
Cheers,
ZicoKnows@hotmail.com
Despite being a Perl fanatic (it was, in fact, my first language -- BASIC, shell scripting, and TeX don't count), I have to say I agree that Perl is bad for learning straight-up programming.
That's why I tend not to think of Perl as an actual language. I think of it as a utility. This sounds counter-intuitive, but let me try and explain:
Perl was designed by Larry Wall to be as much like natural language as possible, in order to make it easy to learn, useful, and comfortable for _programmers_. Most languages, IMHO, no matter how high-level, are designed to make some aspect of the _computer's_ "mindset" accessible to the programmer, even at the expense of having to jump through mental hoops to do it. A good example is C: C was written to be portable, yes, but it was also written to "get under the hood" of a machine and allow it's users to do low-level things like (heh), write UNIX. Most languages, I've found, are like this: they use things like (as mentioned) datatypes, that force the programmer to think like a computer. It's hard to get used to, but is ultimately a Good Thing.
Perl, on the other hand, allows a programmer to think like a human, and this is a Good Thing as well, but it IMHO really bars it from being de facto a programming language. It can be used as one, _if you already have the knowledgbe to think like a computer_ -- ie, you understand data types, how memory works, etc, etc, etc, all the things that you pick up in more standard programming languages. Perl makes more sense of you think of it as a meta-utility that can _be_ a language.
(this probably will sound like complete bollocks an hour from now, but that's what 72 hours with no sleep will do to you...)
Hmmm...
Perl + convert = Pervert?
:)
Let's face it folks, the real reason Perl's so popular because Larry Wall is sooo coool. I mean, he's got so many one liners- the mans a walking clint eastwood of the computer world.
As for the language itself, I find it useful, but I'd rather do most general purpose stuff in Java. Perl's text mangling stuff is very convenient though.
Blender And Linux Fan
I have to agree that making whitespace significant, even if only in the form of indentation, is a horrible horrible design decision.
Andover's self-referential integrity is still intact.
Why is it a mistake? Why aren't the other programs that can't handle it considered mistakes instead? Seems to me that if I post something it ought to look like I pasted it, and any tools that violate this are broken. And, plenty of perl programs will break when posted anyway. A large subset will work, but by no means all... think about print Seems to me that the answer is: both. I think a language that requires indentation is a good thing, but have the syntax be redundant so that the indentation can be regenerated if it is lost; then build a "beautifier" into the language so it will recreate indented source. Yes, there are different indentation styles, but it's easy enough to get used to any one. My preference is for just following one simple rule: once you open something, everything on succeeding lines of it are indented till it is done. Most people do not indent this way, i.e. function header blocks usually have the curly brace out at the left margin (why?) and closing curlies are usually brought back out to line up with the opening line (why, esp. since that's not where the opening curly is?)
Hmm..
All this weekend, I have been unfortunate enough to see many pictures of Don Knotts and ulcerated anal cavities (seperated at birth?), that I have been trying to figure out a way to avoid accidentally (read:not paying attention to the URLin the status bar) viewing these 2 atrocities.
Well, here's my suggestion. Don't allow AC to post HTML. Surely that couldn't be THAT hard to implement...and we wouldn't be subjected to the kind of filth we have seen this past weekend (some would say *months* ).
I like to view at -1. I frequently like the comments that get blurbled over at a higher setting, but, man oh man.
That guy with the seriously ill posterior makes we wanna puke. I'm literally afraid to click an URL on SlashDot anymore...
"Don't try to confuse the issue with half truths and gorilla dust."
Bill McNeal (Phil Hartman)
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
Yes, I agree TC is an asshole (sometimes!) After being the target of one of his diatribes, I can attest to that from personal experience.
However, TC never gets personal and does't have the reputation of a computer-thug like OpenBSD's Theo the Rat.
I can forgive TC because he's given me and lots of others a lot more in the form of his knowledge and experience than he's taken away by being a hot-headed SOB.
Just Another Anonymous Coward
JAAC
BTW What would you use instead of Perl? Are you falling into the: "I have a hammer, so all the world's problems are NAILS!" mentality?
/. plugin.
BTW, what is "filthy" about Don Knots?
Please, do not be afraid, we will not hurt you.
Thank you.
Did anybody ask your fucking opinion?
Tom C.? Is that you?
I do not often respond to obvious flame bait, but try adding some reasoning (and examples) to your broad-brush sweeping criticism.
As a long time C programmer I jumped with joy when I encountered Perl. I found that my personal collection of high-level library functions that I had maintained for years, such as:
- String manipulation functions.
- Implicit loop functions such as grep, map.
- Hashes.
- Linked lists (dynamic arrays).
had already been done (and much better) by Larry and put into a package called Perl. Performance was excellent and even exceeded custom C libraries. Not to mention all the software available for reuse such as Socket, POP3, CGI, FTP, TELNET, Date Manip, Image modules.
I just finished writing a module to communication to industrial data acquisition units (Opto22 Brain Modules) using IEEE 1394 Firewire protocol. The company provided poorly programmed C++ drivers, which I replaced with a Perl Module, building on the excellent IO:Socket module. I completed the driver within 5 working days and achieved a 4 to 1 code reduction. I never needed to drop down to C for any reason, Perl gave me the ability to twiddle bits and even do a big-endian to little-endian byte swap in two lines of code !
I have found Perl to be an excellent tool in my toolbox and have found many occasions where it was an excellent choice for the problem at hand. Coming from a UNIX background I find it wonderfully designed and intuitive. My hat off to Larry and others for making Perl freely available. To those who have been pissed off by Tom, grow some thicker skin.
However, unlike most Perl-detractors, Tom has the coding skills to back up his attitude.
Back under your bridge, VB-boy!
Of course if this is a slash exploit (not hemos), it's even better !
Perl is to English as [Python|Java|Scheme] is to Esperanto.
Esperanto may be a whole lot prettier language, and even more regular (in the mathematical sense) than English - but a whole lot more useful work gets done in English than Esperanto.
LOGO its not just for kids any more ;-) Really I'm not kiding. LOGO then LISP (very easy transation, just add parens and stir ) Then C or/and asembly then some OO language Eiffel or Java. SB
All it's good for is writing toy scripts and webmonkey crap. That's fine for Slashdot, but I'm a programmer and it's of no interest to me.
The natural language analogy is idiotic because these aren't natural languages. You're not talking to people, you're talking to a computer.
You can spend a month learning C and then spend years learning programming, or you can spend years memorizing arbitrary trivia about Perl and never learn programming at all. It's your perfect right as a free citizen to choose the latter. Since I'm more interested in programming than I am in trivia, and since people pay me to write efficient and maintainable code all day, I've chosen the former.
Next?
...before buying a book
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?
You, sir, are a booby.
And you belong in the booby-hatch.
--
I noticed
--
I noticed
It's getting about time to leave everywhere
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
Generate a report based on form input from my website to figure out how many of my visitors have tried my virtual "hot grits down the pants" program???
"Bad moderator, no karma"
Strangely enough, people pay me a great deal of money to write highly efficient and vastly maintainable code - in perl.
But yet, because it is perl and not C or (shudder) Java, it doesn't take ME all day to do it.
More money for less work... sounds like a pretty good trade to me.
Say, what are you doing reading Slashdot anyway? Shouldn't you be out tracing down mis-cast pointers, or working out yet another replacement for malloc() or something?
I think it is, there is one from Roblimo above.
I wonder how they did that, and if they have access to everyone's account like that.
(posting anonymously, so they won't hijack my account, too...)
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. --
It's an interpreted language.
Do you write OS kernels with it? Text editors? Language interpreters? Compilers? Do you write anything that can't be cobbled together by gluing together modules that a competent programmer wrote in C or C++? Can you do proper OOP with it, or does it just have a fake toy "class" thing like Visual Basic has?
Please, don't be ridiculous. 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.
And you're simply inventing the maintainability thing.
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.
I'm earning $85/hr corp to corp for writing Perl scripts, Sybase stored procedures, and Sybase triggers in the New York financial industry. The Sybase is the reason my rate is this high, not the Perl.
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.
OpenDK
Thank you.
It's an interpreted language.
True, but a very efficient interperted language. Somewere I have link to a study done by Kernahan (spelling ?) comparing perl performance to C, C++, Java and others. For some operations Perl even bested C++ and C and almost always bested Java. Yes, I know Java performance has increased significantly lately.
Do you write OS kernels with it? Text editors? Language interpreters? Compilers?
No, and nobody has suggested such, that is why Perl itself is written in C.
Do you write anything that can't be cobbled together by gluing together modules that a competent programmer wrote in C or C++?
Yes, all the time. In fact, one could consider Perl as a gluing of C modules for use at a higher level.
Can you do proper OOP with it, or does it just have a fake toy "class" thing like Visual Basic has?
I suppose that depends on your definition on "Proper" OOP. Check out CPAN which is probably the largest collection of freely reusable source code in existance. Remember one the primary objectives if OOP is software reuse. On that account Perl delivers.
And rememeber few "Perl Zealots" recommend Perl for everything. They are Zealots because that for a sizeable portion of the problems they encounter in their programming careers, they find Perl to be an appropiate tool.
Try educating yourself before making an Ass out of yourself.
You are certainly correct about C++, which is the perfect language for meeting its goals. Of course, those goals, C compatibility and shielding programs from effects of features they don't use (see Soustrup, I believe the title is Design and Evolution of C++, have little to do with life cycle effectiveness.
Java is cleaner, but basically combines the elegant simplicity of C++ with the blinding speed of Smalltalk. (I am a Sun Certified Java Programmer.)
For a really clean first language and nice first book, check out Switzer's Introduction to Eiffel. The GNU Eiffel compiler runs from the command line and generates good code. A spiffy commercial object oriented interactive development environment is also downloadable. Eiffel makes life complicated for the compiler, not the programmer.
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--
Maybe you don't hear the complaints, but I've heard people bitching about losing time and getting extremely frustrated debugging makefile's that contained blanks instead of tabs. Who would expect to be nailed by cut and paste when the copy looks identical to the source?
Seriously, OpenDK made EZ runs circles around this.
I agree with you mostly, but that's a lame argument: every programming language that supports functions supports abstraction. The idea is not something that any particular languages can "support"; it's above that, and nothing to do with OO programming.
You must be deaf, then. I hear people complaining about make's goofy tab syntax all the time. Most people get over it, but just about everyone I know was bit by it at least once when they were starting out, and no doubt muttered under their breath (like I did) "what a dumb syntax".
Code Complete or Writing Solid Code?
Or rather, which would you recommend?
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--
(completely off-topic, btw)
Just an anonymous note to state the obvious that Slashdot is under 'attack' by a techno-dweeb with a chip on his/her/it's shoulder. It's clearly the same person who kept railing on about Slashdot's not releasing the Slash code and whatnot. The person has managed to generate postings in Hemos' and Roblimo's names, which is interesting and a good bit of bug-finding if not a bit alarming and annoying. Other attacks consist of posting spurious topical links that lead to porn/whatever links and the repeated posting of a morbidly descriptive bunny mutilation. Posts are fed in in amounts intended (successfully) to make moderating them all down practically impossible.
This was bound to happen eventually, as a site this prominent, like a movie star, is bound to provoke the ire of a demented soul somewhere who then proceeds to stalk and harass the object of their obsession. It's sad and all that one single numb-nut can cast such a shadow upon something otherwise benigh, but such is life.
Slashdot will respond creatively, I am sure. Till then, take EVERYTHING you read here with a big grain of salt. Expect fairly dreadful porn links and provokative racist bits as par for the course.
Cheers.
MODERATORS - in cases where a story is 'flooded' with bogus posts (gritz and other nonsense), try posting the good articles UP rather than the bad ones down. If an article is already up to '3' or something, leave it alone and bring up some others to help the good/normal posts to rise above the bs. Just an idea.
I imagine a story will appear soon addressing this issue
Perls of DK
Thank you.
- Minimizing small blobs of global data, but instead putting things into record/struct/hash structures.
- Bunching procedures together, whether or not the syntax allows it, to make it clear that they operate on a particular object.
- Inheriting, whether through IS-A or HAS-A relationships. Making every procedure generic enough to be useful outside the original designed domain. This is what I mean by code re-use.
- Applying a reasonable amount of discipline regardless of what the language allows.
That's what makes my programs Object Oriented.: Fruitbat :
I have discovered a truly remarkable
elle est bonne :-))))
This one is very, very funny Mr dillon rinker or LOL as you use to say sometimes.
I was laughing when i read your comment, previous where so serious...
But anyway, for my first visit (browsing the net) here, i think that this 'forum' is nice !
and it's seems that there are smart guys around there ...humm . I'll try to learn perl indeed !
GeeBee From France
old thread at deja
the math comes to this gentleman, assuming 8 hrs a day, biling at a rate of $250/hr. so oops, i underestimated! of course, he is not your run of the mill programmer.
my fiance had an offer two months ago for a position in SF for a 280k annual salary at a startup. and yes, it was for Perl. that comes to ~140/hour, but self employment (incorporating, etc) and salaried bases can have very differenct meanings to net income.
Should I have said "data abstraction"? Should I have mentioned type safety? Is there any way in C you can do anything analagous to overrideing a virtual function, without throwing function pointers around by hand? Say for example I have a base class, foo, and from foo I derive bar and baz, each of which has very different guts, but the same interface . . . This is often extremely handy. You can do something like that in C, but you've got to implement a lot of things by hand that C++ does automagically, and it's bound to be less efficient because you don't get static type-checking on concepts that the designers of the language didn't anticipate. You'd be stuck with type fields or other ugliness. Yeah, you can do it. The Win32 API does it. Windows [as a general noun, I mean] in Windows (C)(TM) are conceptually rather similar to "classes" in C++, and it's all done in C. But it's ugly. I really love C; it's a cleaner and more elegant language than C++. But C++ has all these goodies . . .
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
IIRC, the deal for writing a "class" in VB involves naming the source file what you want the class to be called, and telling the IDE that it's a class now or something weird like that.
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.
Sounds like MFC. Ugh.
:)
The foo/bar/baz example had a point to it, which I implied by mentioning type safety, but never really addressed:
You can declare a pointer (or a reference) to foo (the base class), and then that pointer can point (or the reference can refer) to an instance of any descendant of foo. And when you call a foo:: virtual function on that object, if it's been overridden in the subclass you'll get the subclass implementation. This is damned fantastic. If whatever Perl does isn't doing that, it's not OOP.
Minimizing small blobs of global data, but instead putting things into record/struct/hash structures.
It's not entirely clear what you mean here, but I get the impression that you're talking about structured programming, a much older paradigm.
Bunching procedures together, whether or not the syntax allows it, to make it clear that they operate on a particular object.
I'm sorry, but this makes no sense to me at all. Do you mean declaring them near each other in the source?
Inheriting, whether through IS-A or HAS-A relationships.
This is a start, except that "has-a" is when you add a member instead of inheriting.
Making every procedure generic enough to be useful outside the original designed domain. This is what I mean by code re-use.
That's what Weurth meant by "re-use" back in the 1960's when he was pushing structured programming. It's something you should really grasp before approaching OOP, however, so at least you're on the right track. Object-oriented reuse is a lot more powerful and interesting.
Applying a reasonable amount of discipline regardless of what the language allows.
That idea predates even the structured programming paradigm.
That's what makes my programs Object Oriented.
You seem to be saying that you pick words which appeal to you on the basis of their sound or something, and then you inent new definitions off the top of your head. That's very nice. I'm glad you have a hobby. As for me, I bathe and shave every morning and feed my cat -- and that's what makes my programs object-oriented!
If I'm not being clear enough here, I'll try harder: From your post, it looks very much like you have no idea what OOP means or signifies. Learn a proper OOP language, write a lot of code in it, and get a solid grasp of what it's about. You will recognize that "solid grasp" because when it arrives, you will suddenly understand why these things you describe are irrelevant and/or old news. You are missing the point.
Okay, okay, excellent! Excellent. Now it's time for you to get defensive and flame me, and claim that you do too know what OOP is. Right? Right. Well, tough shit. I really don't give a damn. It's your life. Do as you please with it.
This said, there are a bunch of OO features that I wish perl would add when they reach 6(or earlier!). These are:
Its a wish list, anyways.
- Get more than one book. Buy/borrow about a half dozen. I've yet to find a combination of only one or two that was gentle enough to a newbie, yet still had comprehensive technical detail. In addition it is not uncommon for me to find five or more mistakes within the first three chapters. Nothing is worse than debugging when you're not yet confident in your own abilities, and it turns out to be an editing error in the book! I now cross reference everything I read.
- Remember that these large volume texts are not actually going to teach how to program nearly as well as playing with code. Perl is one mother bear to learn(my opinion). It is a considerable maze, albeit an organized one. You don't learn a maze by reading a map. Start walking.
- Find a LUG and pester the piss out of anyone claiming to have written a Perl script longer than 10 lines. After reading every iota of documentation first, of course. Bring them lots of beer. Maybe some sandwiches, too.
- Learn shell, sed, awk, C, C++, Pascal, and Python first
:)
Don'tThere's a spider on your shoulder.
Can't someone post a story about Perl and not have it devolve into a language war? Discuss the book and book review at hand, or shut up and go somewhere else.
Damian Conway's Object Oriented Perl by Manning (the same publisher of the book whence springs this entire thread) is one of the best language-specific books I've ever read. The explanations are clear, the examples are meaningful, and it's funny as hell, to boot.
it is wrong (of the editors) to give link
to oreilly and NOT link manning in the article
(yeah yeah, its there somewhere, not in the
first few lines which show up on the homepage).
Infact, it is wierd that oreilly is linked
at all, given that they neither publish the
book nor own perl.
syam
To give you an idea how open the perl world is, some joker posted the entire CD in tar.gz form (learning perl; camel book; cookbook, yada yada) to comp.lang.perl.misc a few weeks ago. 100 consecutive 64k posts. I HAD to download it 'cause I 'suck' my groups into INN. It WAS complete! The only folks who said a word about it, that I detected, were a couple of lurkers and those whining (justifiably) about bandwidth.
Christiansen and Schwartz, whose work had just been offered up to the globe, and lurk and post to the group, never objected! (to my knowledge)
Classy guys, those perloid fellas!
Brak: What's THAT?
Thundercleese: A light switch.. of TOTAL DEVASTATION!
For those of you that learned it I was wondering what is a good Perl book to go out and buy to learn it, this one? or another?
Very few programmers do all levels of programming - there are much more effiecient ways to make some programs using assembly - and you use C (or C++). The important thing is the applicationg and when you are trying to integrate a web site with interactive content PERL is a VERY effective way. I am not trying to compete with you - go preach your I am better than you because crap to some other forum - obviously those people here are interested in using PERL to solver their problems and not interested in the mundane reasons of using C vs PERL. I could preach about PERL over JavaScript - but JS is by far the best way to do some things - go back to your cube and talk to your computer and create your objects.
This code is ripped from somewhere (I can't remember where), and it takes care of about anything.
And yet another good reason to use OO perl: It is way easier to get your perl modules to work under Apache mod_perl if you always use the OO model.
One last comment about "Some sort of abstract/interface setup."
You can do something very similiar to that already. Have a look at the Tie::Hash -package. It defines all the methods needed for an implementation of a Tie::Hash object, but does not really implement them.
I apologise for the lecturing. :-)
btw, university of Helsinki (in Finland, yes) nowadays has a course on (OO) perl. Which is nice.
Trivial. See Damian's excellent book.
Most people don't do that, because as it turns out, unless the class is very well designed to begin with, anyone extending the class will need access to something that was left out. So most people follow the path of least resistance initially.
But it is indeed possible and simple for me to hand back an opaque reference to you from my constructor that you cannot do anything with except hand back to me in a method call, and you can't even fake one up on your own -- I'll know.
That your self-touted programming "skills" are not yet at the level where you can appreciate the beauty and elegance that is well-written perl code.
One day, when you've grown and learned enough, perhaps you will. One can only hope. I do so hate to see young "programmers" stuck on a point in their personal growth curve.
Types are not everything. Some of the best OO programmers in existence first learned the concepts on Smalltalk, then later applied them to C++ and Java, adapting to the idosyncracies of a strongly-typed system.
Perl is questionable as a first language because it is by its very nature a language that you can blow your leg off with - there is a lot of power, but knowing how to properly use that power is something a newbie won't grasp immediately.
With Smalltalk, you get to learn the wonders of inheritance & polymorphism WITHOUT dealing with derived-types, casting, etc. You also get to learn the wonders of block-closures and the reasoning behind seperating interface from implementation. You also become (out of necessity) a _relentless_ unit tester, since you don't have compile time checking for semantic errors.
So, some over-generalizations about "intermediate-level" programmers based on my experiences in the industry and in university:
- Most programmers don't properly apply OO concepts in Perl, Java or C++.
- Most programmers don't grasp the idiosyncracies each language brings to the OO programming model.
- Most programmers don't test their stuff.
- Most programmers don't seperate interface from implementation, nor do they see why they would want to.
- Most programmers think cleverness is cooler than clean, readable, modular code.
All of these can be attributed to LINEAGE of education. In C, it was tedious to test stuff, and you HAD to be clever to survive.
So, I think Smalltalk would be a great first language. [s/Smalltalk/Python or Obj-C]
-Stu
See my post in the thread above.
[Or Scheme / LISP, actually. All three languages are actually quite alike, with the edge in flexibility going to Lisp.]
And to people who still think OO or LISP is retarded: get out of the dark ages please.
-Stu
You talked about "strongly typed languages". Not language that are stronger typed than Perl. If you are referring to something different than I am,
what do you mean by strongly typed languages then?
The context of the discussion was Perl, I was referring to languages that are strongly typed relative to Perl. I thought I had clarified that in my first response to you. Sorry.
What it comes down to is this: Do you agree that C and C++ are both more strongly typed than Perl? If so, there's nothing to argue about. If not, we differ on a fundamental point and there's no point in going any further.
My second question was "What about arrays?" after your remark "don't get me started on Perl arrays". Your broad statement about your experienced
lack of structure in Perl doesn't address arrays at all. Hence, it doesn't answer the question, it's just a flamebait.
Your initial comment was:
What about them? At least Perl has arrays, unlike popular languages like C, which just has monsters that try to look like arrays.
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". You seemed offended by my apparent dislike of Perl arrays, so I backed off and made a more broad statement which I felt explained my perceived problem with Perl, arrays included. I was trying to quickly and succinctly summarize my viewpoint. Let me try again:
Arrays in Perl are used to hold data structures. While this makes things quick and easy, 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.
If there's any trolling going on, it's you doing it.
Personally, I don't think statements of opinion with earnest attempts to explain the reasoning behind the opinion constitute trolls. I do perceive a statement like:
At least Perl has arrays, unlike popular languages like C, which just has monsters that try to look like arrays.
to be a troll.
I don't see how my posts can be seen as trolls. They may be wrong (it wouldn't be the first time) but they don't have some key characteristics of flamebait:
A. Make value judgements. I didn't say that Perl's lack of structure was bad. I simply stated that Perl lacks structure, which makes it unsuitable, in my opinion, for a learning language.
B. Purposefully represent statements of opinion as fact. Again, I may be wrong, but that doesn't constitute flamebait.
My initial response to you was hostile. Why? Because your initial post to me was hostile. Your initial comments to me gave me the impression that you think I'm wrong without explaining your position. Furthermore, their tone conveys arrogance and superiority ("I know something you don't"). If that is true, enlighten me. But don't turn open dialog into one sided interrogation. It's not very nice.
--GnrcMan--
You can browse parts of the book online at http://www.manning.com/Johnson/index.html
You can browse parts of the book online at http://www.manning.com/Johnson/index.html
Thank you. That's the sort of comment I enjoy responding to. If you want to continue this discussion, e-mail me. I'd be glad to discuss your points with you.
Casey
--GnrcMan--