Elements of Programming with Perl 194
| Elements of Programming with Perl | |
| author | Andrew L. Johnson |
| pages | 352 |
| publisher | Manning Publications, 09/1999 |
| rating | 8/10 |
| reviewer | chromatic |
| ISBN | 1884777805 |
| summary | New to programming, and think Perl may be up your alley? Andrew Johnson's excellent Elements of Programming with Perl will teach you both disciplines. |
What's the Purpose?
Hundreds of books teach programming. Dozens of good books teach Perl. Where's a book for someone who wants to learn Perl and programming, at the same time? Thankfully, that's just what Elements of Programming with Perl does.What's Good?
From the start, Johnson's explanations are clean and clear. It's obvious that he's polished his didactic style through years of real world teaching. Also from the start, good programming practices receive due emphasis. Though it's not specifically mentioned until chapter 9, Johnson advocates and demonstrates good program design through a mixture of Donald Knuth's Literate Programming and his own code tangling style (mingling documentation, design notes, and code in a single source file, similar to POD on steroids).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
Re:Linux? (Score:1)
This fills a void (Score:5)
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
usefullness of perl limited. (Score:1)
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
Re:Books can be over rated (Score:3)
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.
My two cents (Score:1)
Python? (Score:2)
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
Re:Python? (Score:3)
If you post a perl program on /., it works. If you post a python program on /., it fails.
Indentation is important for readability, I'd consider a program badly written if it didn't have correct indentatation, but to to make it syntaxly significant is a mistake.
Re:Problem with O'Reilly books (Score:2)
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.
Perl as A First Language Is Scary (Score:3)
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.
Confessions of a recent Perl convert (Score:1)
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!)
Because HTML has nothing to do with password auth (Score:1)
Fills void but not completely... (Score:1)
Nathaniel P. Wilkerson
NPS Internet Solutions, LLC
www.npsis.com [npsis.com]
Re:Python? (Score:2)
"Programming Python" is a strange beast of a book, not very well suited for a newbie, whether it be to programming as a whole or to Python itself. If you already program in some other language, then the tutorial and library reference (at python.org [python.org]) is really all you need. As to the absolute beginner... well there's "Learning Python" but I haven't read that one.
"Programming Python" is the kind of book you peruse over a pot of coffee and with plenty of free time on your hands. Don't expect to read/understand it all in one sitting either.
Re:Then what language? (Score:1)
Even though these languages may not be all that useful now, they're some of the best learning languages, IMO.
Re:Perl as A First Language Is Scary (Score:2)
numbers. Java/C++/C/Fortran/Basic etc...have different data types (short, long, char, String etc...) for very good reasons.
You make an excellent and very important point. Learning to program with a language as sloppy as perl is probably a BAD idea.
Perl is great for banging out a script in a couple days, but I always get this dirty feeling when I declare variables in Perl. If you are writing Perl scripts and don't feel kind of weird about variable declarations and use, you probably should pick up a book like "Code Complete" or maybe "Writing Solid Code". (Yes, they're both Microsoft Press, but that doesn't change the fact that they're excellent books.)
Keep in mind that one of the reasons Perl is so quick and easy is because it doesn't enforce much in the way of good programming practice. That makes it great for quick and dirty solutions, but it also makes it easy for a project to collapse under it's own complexity. And I firmly believe that it's very difficult to unlearn bad programming. Remember, the designers of strongly typed languages weren't just being masochistic. Strong typing can save you from yourself.
And don't get me started on Perl arrays.
(stepping down off soapbox)
--GnrcMan--
Offtopic, skip this... (Score:1)
"...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.
Re:Python? (Score:1)
I looked at "learning python" and it was rather jokey
"Programming Python" has its drawbacks, for sure. There are already some things i would like to see different. But it has also had some of those "tying in together" kind of things that i wanted. Is it worth the $60+ (CDN)? That remains to be seen. But so far it's not too bad.
And anyways, my job owes me about 200 hours of "geek improvement time". I know perl, c, c++, shell, blah blah blah... all the unix geek, administrator stuff. So Python is what i'm looking at now. And just as you advised, i've got my coffee, and i've got the time (they're paying me to do this
Cheers,
DQ
Don't disagree (Score:1)
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.
Re:Then what language? (Score:1)
Re:Then what language? (Score:2)
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--
Re:Linux? (Score:1)
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
Justification. (Score:1)
perl-as-language? (Score:1)
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...)
Offtopic - Re:Confessions of a recent Perl convert (Score:2)
Perl + convert = Pervert?
:)
It's because Larry's soooo cool! (Score:1)
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.
Re:Problem with O'Reilly books (Score:1)
Read about the format for the
Python books (Score:1)
I have to agree that making whitespace significant, even if only in the form of indentation, is a horrible horrible design decision.
Re:Fills void but not completely... (Score:1)
Why? Just start with Learning Perl. If you really want some scripts in dead-tree format, get the Perl Cookbook. For fully functional scripts like the one you mention, get them online, like at CGI Resources [cgi-resources.com].
Re:Perl as A First Language Is Scary (Score:5)
After reading it I built XML::XPath - an implementation of the XPath spec in perl. It uses lots of classes to do its work, and I feel it's coded very cleanly. And it remains pretty quick (Damian has a discussion of Perl's OO speed issues in the book). If you want to check it out see CPAN. If you don't or can't understand the code I feel I've done something really wrong.
Re:Problem with O'Reilly books (Score:1)
Thanks vectro.
cheaper than thinkgeek (Score:2)
Andover's self-referential integrity [slashdot.org] is still intact.
Re:Python? (Score:3)
Can't say I was exactly thrilled with Programming Python. I came into Python already knowing Perl, and just didn't really get anywhere with Programming Python. The continuity just seemed all wrong, out of order, etc. So, I didn't do anything with Python for a couple of years.
On a whim (meaning one of those times when you're walking around a bookstore with a wad of cash burning a hole in your pocket), I decided to pick up Learning Python. Man, am I glad I did. Yeah, there's a lot of really basic programming stuff in there (which makes it an excellent book for complete newbies), but I found it to be a much better introduction to the Python way of doing things, possibly because it was such a fast read. Once I got the basics down, exploring the more advanced stuff just from the online and included docs was a breeze.
Stick with giving Python a try, though. You say you know OOP, but if your knowledge comes from using Perl, I think you'll be happy just how easy OOP is with Python in comparison. I like it enough that it's replaced Perl for me as my favorite quick-n-dirty language -- it just "feels" more correct when I'm using it. And yes, I know the degree to which Perl is a "write-only" language depends on the particular programmer, but it's been my experience every single time that when I've had to work with other people's code, the Python stuff was always easier to jump right into than the Perl stuff.
Anyway, that's just my opinion -- what prompted me to write was that I just purchased "Python and Tkinter Programming" from Manning Publication's website, then came to Slashdot to see a book review featuring a book from the same company. I've never read any of their books before, so am kind of curious.
Cheers,
ZicoKnows@hotmail.com
indenting (Score:1)
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?)
Re:This fills a void but does it cover (Score:1)
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)
Fine way to waste your time (Score:3)
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?
--
Re:Books can be over rated (Score:2)
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."
Tom C.? Is that you? (Score:1)
Tom C.? Is that you?
Re:Justification. (Score:1)
Re:SLASH moving to Python (Score:1)
Of course if this is a slash exploit (not hemos), it's even better !
Re:Then what language? (Score:2)
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 [mailto] and tell me what you think.
Re:Perl as A First Language Is Scary (Score:2)
Getting positive feedback on a relatively structured language is a good thing.
Re:This fills a void (Score:1)
As for application development, I prefer python, partly because not enough people write legible Perl. If I'm working on a project with other people, I want a language that will force the others to write legible code. Perl is just too tempting--you get into stream-of-consciousness programming.
I applaud the introduction of the literate programming technique into Perl. I've been doing it with Python's documentation strings for a while now.
--
I noticed
Re:Python books (Score:1)
The former is a good tutorial for those-who-program, and the latter is a good reference (it's basically some of the python.org references with a ton of rewriting and embellishments and new example code).
--
I noticed
Re:Then what language? (Score:1)
Maybe you should look at the table of contents (Score:1)
Re:Python books (Score:1)
Handspring + ISilo + Perl CDROM Bookshelf (Score:2)
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 [oreilly.com], so that I can be a DocBook XML expert while composing the massive body of documentation [ninjacode.com] for my Open Source project [ninjacode.com]. 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?
Re:Tom Christensen is a fucking asshole. (Score:1)
And you belong in the booby-hatch.
--
I noticed
Perl does NOT have just one datatype (Score:4)
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 [haskell.org].
Re:Perl (Score:1)
perl is FAR from out grown. there is a reason good developers have no problems charging 150/hr.
as for perl, it's OO duct tape.
books teaching PERL programming are not very easy to write, much less programming skills alone. hopefully, more people will make an attempt to learn as opposed to reverting to a script kiddie.
Re:Fills void but not completely... (Score:1)
why not? at least that way you know it's YOUR wheel, and if there are any problems you know who to blame. Of course, I'm over ambitious and twice as arrogant
Re:Then what language? (Score:2)
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
Re:Python books (Score:1)
echo foo
is different from
echo
foo
Specifically, one prints "foo", and the other echoes nothing and then tries to execute the file named foo.
Whitespace characters are characters just like alphanumerics. Is
The last language (Score:2)
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.
Re:Then what language? (Score:1)
Huh? No, really. For education. I wouldn't suggest that you just learn assembly and then use that for everything, but if you're enthusiastic about programming, then it's best to start out with the simplest situation, as close to the wire as is reasonable, IMHO (and in Don Knuth's NSHO). You'll understand what is really going on, down to the specific instructions being passed to the processor.
It's not as if you'll be doing anything that really calls for OO or even block structured techniques. But when you get to that point, won't it be nice to have C to turn to.
What should a learner's language be like? (Score:2)
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?
What's the best thing about C? (Score:4)
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.
Re:Python? (Score:2)
If you post a python program on
Re:Then what language? (Score:2)
Casey
--GnrcMan--
Re:The last language (Score:2)
b. if you can't keep track of your pointers, maybe you should try an easier line of work (like pumping gas perhaps)
c. a scripting language will not do 99% of what needs to be done on a computer, and furthermore, what a scripting language _can_ do is usually done at decreased efficiency.
not an anti-perl rant, just an anti-perl-bigot rant. if you think perl is the only language that has any place in computing, you're obviously not very informed.
You are the ... (Score:1)
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.
Re:Fine way to waste your time (Score:1)
This argument MAY apply to books - depending on how good the book is and at what level you really want to learn your stuff - cause if you want to be a real expert at anything, you're better off doing the research yoruself to really learn it.
Also, it depends on where a field is - 8 years ago the web was not only the best place, but pretty much the ONLY place to learn HTML, JAVA and JavaScript.
But it most certainly does NOT apply to an instructor teaching a course - whom cannot possibly speak as fast as I can read.
Insightful (Score:3)
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--
Re:Useless like a fox... (Score:1)
Butthead! There's lots of languages out there that are "safe" (no core dumps, like perl), have automatic memory management (no malloc, like perl), and that most importantly ARE NOT PERL.
If those are the only reasons you can think of to program in perl, then you are a truly lousy advocate.
(ps. that last paragraph was a brilliant piece of prose. I aspire to such heights of rhetoric.)
re: abstraction (Score:1)
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.
Make's syntax is dumb (Score:1)
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".
Re:Then what language? (Score:2)
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--
Re:The last language (Score:2)
Are you seriously telling me that you have never goofed and used an uninitialized pointer or forgot to free allocated memory? If that's the case, I think you should quit programming and consider a career in either water-walking or faith healing. For most mortals, it is a pain.
Please spare me the "well, we just need better programmers". They aren't out there. When you find them, they cost too much. Most companies aren't looking to hire Alan Cox, Linus, or even vyesue. They want to grab some kid with a couple of years of CompSci undergrad work, pay him a dirt cheap intern's salary, and get him to write their high-traffic web portal. Perl is ideal for this.
Look at Slashdot, for crying out loud! It's a perfect example of this! Young guys hack together some scripts, make an interactive message site, and collect a few million from the IPO. That's what it's all about, man!
And, despite your snotty elitist comment, I don't see Rob and Co. pumping gas anywhere but at the self-service pump when their new gas-guzzling SUVs run dry.
offtopic: which is better? (Score:1)
Code Complete or Writing Solid Code?
Or rather, which would you recommend?
Re:Object Oriented Perl (Score:2)
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--
Website 'Stalker'...All Please Comment (Score:1)
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
Re:offtopic: which is better? (Score:1)
--GnrcMan--
Re:It's because Larry's soooo cool! (Score:1)
Why he couldn't be happy as a successful Uberhacker, and feel he had to try and flop as a comedy writer as well, is beyond me.
Clint Eastwood? As far as one liners go, more like Peewee Herman.
Re:Then what language? (Score:1)
Can you give me a reference? I'm really not being obstinate, I have a genuine interest in studying the good and bad points of various languages and I'd be fascinated to read a comparison from a Java expert's perspective.
And as a side note, I didn't mean to imply that Java is better or worse than C. Far from it. However, I'm reluctant to point a beginner to Java as a learning language.
--GnrcMan--
Re:The last language (Score:2)
I started, I admit, with a simple little toy hammer, just using it to whack screws into wood. But the problem with hammers is they don't support threaded processing. Using a screwdriver makes things a lot easier. I reckon anyone who would use a hammer or saw or (gods forbid!) a chisel for this sort of thing is just a lame luser.
I've heard plenty of morons claiming that screwdrivers don't drive nails into walls as well as other tools, but that's bu||$h!+. I've tried using a saw to whack things, and the design flaws are obvious. Stick with a screwdriver and you won't have nearly as much trouble. Or how about the time I tried building a scale model of the USS Enterprise entirely from balsa wood using only a hammer? Fiasco! And yet a screwdriver can install AND de-install screws into wood, metal and plastic with absolute ease of use. Why bother with anything else?
Lusers.
: Fruitbat :
Re:Object Oriented Perl (Score:1)
- 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 :
Re:Then what language? (Score:1)
Speaking about languages, if you really want to go the easy route, I would also recommend pascal.
Learn the simple programming structures, then recursion (i.e. towers of hanoi), this clearly helps thinking in algorithms.
Then perhaps go with c to reuse the structures you have learned in pascal + more advanced/low level concepts of the memory handling etc. .
Only after that I would try C++/Java/Eiffel to learn more "modern" concepts.
Re:Perl does NOT have just one datatype (Score:1)
Want proof? From Programming Perl:
Perl has three basic data types: scalars, arrays of scalars, and hashes of scalars, also known as associative arrays.
A scalar encompases anything from a a floating point value to a string. It doesn't matter that there are distinct types under the hood, since from a Perl programmers perspective, there is only the scalar.
--GnrcMan--
Re:You are the ... (Score:1)
The fact that the community has accomplished one of several OOP goals in a limited and non-OOP way, is kind of, well, totally fucking irrelevant.
Limited is your uninformed judgement and not the term I would use and it is not irrelevant. BTW, most of the modules on CPAN are written with a OO interface. Is OOP just an end or a means to an end.
As far as writting "real" code with Perl. Yes, I have been involved in several significant projects using Perl that was not cobbling together "real" C code. I have used Perl to replace "real" C++ code (Firewire driver) as was mentioned in a previous post in this thread. I have used Perl to develop several data acquistion systems and monitoring system complete with a browser based operator interface. I have implemented several custom e-commerce sites, FAQ generators, web based document logs, etc.
Could these have been done in C or C++ ? Sure at a much greater cost. Are they maintainable ? Yes. Maintainability is more a matter of design, style, and skill then a side-effect of a language or even a design approach (OO versus or non-OO).
Other people using Perl ? Well lets see I guess we are posting to one. Please point me to the Java or C++ equivalent. But, I am sure you consider this to be trival toy script.
mais oui (Re:Can you back that up?) (Score:1)
old thread at deja [deja.com]
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.
Re:Can you back that up? (Score:1)
perl and the x86, the ugly evolution of a silicone (Score:2)
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
Re:Object Oriented Perl (Score:1)
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.
Re:Insightful (Score:1)
Believe me, speaking as a professional developer, for any project, you have to pick the right tool for the job. I love working in Perl, but that doesn't mean that it's the best language in all situations. Projects for which I choose Perl generally have the following requirements:
1. Large amounts of string manipulation: I can beat my head against C/C++/Java/etc or I can just buckle down, and s/// my way to textual nirvana.
Especially when I have to work with databases. DBI is very nice to work with.
2. Speed is not a primary design requirement: Hey, Perl can't compete with a properly optimized bit of C/C++ code. Not to mention that there are cases where speed-critical code can be written in C and linked into your perl script using XS. It's a hell of a lot easier than JNI!
3. It's a simple task that I don't want to spend a lot of time on: Sometimes you need quick and dirty. If I have to do a one-time-only parse report for a client, I can whip it out in an hour with Perl, or slog it out with C...Hrmmmm...tough choice.
But, for large projects (applications) with more than trivial UIs, I'll choose C/C++ more often than not. The most important part about mastering Perl is learning when it's not apropriate to use Perl.
Re:The last language (Score:1)
Nonsense. Pointers are crucial to any serious language, including Perl. Without use of pointers (aka references) in Perl you cannot even write efficient subroutines.
Tips for perl as a first language... (Score:1)
- 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'tRe:Fine way to waste your time (Score:2)
It's rare that I've taken a course outside the first-year level that's provided anything more than an outline of the material (although I know of other people who received four years of spoon feeeding); the real work is done as part of readings or associated research.
--
Re:The last language (Score:2)
I'm sick of hearing all this rubbish from hammer users and saw geeks. A screwdriver is all the tool I've ever needed.
ROFL!!!!!!!!
[moderator: moderate up when done laughing]
======
"Rex unto my cleeb, and thou shalt have everlasting blort." - Zorp 3:16
Re:Website 'Stalker'...All Please Comment (Score:2)
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?
Re:Website 'Stalker'...All Please Comment (Score:2)
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
Re:This fills a void (Score:3)
Of course, the -d in Perl comes from a certain "school" as well. The test function from Unix shells.
For a experienced perl programmer at the end of the day he/she will use what's more convenient, which is good. But for someone who's learning the ropes it can be exasperating.
And this is different from learning the libraries in C (or Python) in which way?
-- Abigail
Re:Perl as A First Language Is Scary (Score:2)
Well, that isn't quite true. Strings and numbers are two different things in Perl. True, you don't see that in the program _text_, but it sure is there behind the scenes. Don't get too excited over the dozen or so numerical types in C. They aren't there to help you write better code - they main reason they are there is to help the compiler generate more efficient code. In C, one can get type "warnings" from the compiler that don't warrant warnings, or not get warnings where you should have gotten one. If you want a language with useful (strong) typing, look at something like ML where the program text doesn't contain any types, but the compilers figures out the types of the variables, and complains when there are conflicts.
-- Abigail
Re:Perl as A First Language Is Scary (Score:2)
Care to point out some large coding projects in languages that have strong typing? Don't bother showing anything in C - that isn't strong typing.
And don't get me started on Perl arrays.
What about them? At least Perl has arrays, unlike popular languages like C, which just has monsters that try to look like arrays.
-- Abigail
Re:Perl does NOT have just one datatype (Score:3)
No, it doesn't. == and eq are different operators, doing different things. They aren't the same operator giving different answers depending on the type of the operands, like / does in C. == and eq are different, just like + and * are.
-- Abigail
Re:What should a learner's language be like? (Score:2)
Well, Perl has no strong typing, but languages that do have strong typing aren't very popular as first languages either. And no, C or Python don't have strong typing either. Haskell and ML do though. I fail to see what is "quirky" about Perls handling of nested data structures. It behaves similary to Python, and it sure beats the crap out of C. I don't think beginners have any interest about whether languages are interpreted or compiled - not that Perl is interpreted; Perl gets compiled before it's executed. Proper use of local is one of the harder things to learn in Perl, if I were to teach beginners, I wouldn't tell them about local untill they are past the beginning stage.
Some typing: At the very least numbers and strings should be kept separate, even if there's no int/float distinction. The complex rules about casting strings to numbers in Perl are more confusing to a learner than requiring separate types would be.
Why? What's so special about having different types for strings and numbers? With warnings turned on, Perl will warn you if try to add "foo" to "bar", so it isn't that you can easily make errors. OTOH, you don't have to teach newbies about horrid functions like sscanf, or bother them with a battery of functions that do nothing than take a value, and return the same value, but as a different type. (atoi, atof, etc).
Interpreted: I find that interpreted languages are much easier to debug than compiled ones, and a learning programer probably cares more about that than the speed of a compiled language.
Really? What's the benefit of an interpreted language over a compiled one? I can see the benefit of not having a separate compile stage, like C or Pascal have, but Perl is compiled before executed.
Good commenting: It's never too easy to learn how to do in code documentation.
That's not a language feature, but a feature of programs.
Good libraries: This should help a beginner to write more significant and satisfying programs. If the source is included, as it should be in an interpreted language, they can also provide a good style guide.
Core libraries are typically optimized for speed. I don't think providing a style guide for newbies should be a primary task for something like libc or libm.
Any other ideas for what a language should have?
my%words;
while(<>){
foreachmy$word(split'')&nb sp;{
$words{$word}++
}
}
foreachmy$word(sortkeys%words){
print"$word:$words{$word}\n"
}
-- Abigail
Re:The last language (Score:2)
You missed the point completely. It isn't pointers aka references. A reference isn't a pointer, and a pointer isn't a reference. You can't point a reference to anywhere you want - it always has to reference something. You can't do pointer arithmetic - after all, a reference isn't a pointer. You can't segfault while dereferencing a reference - it always lead somewhere safe.
References aren't pointers.
-- Abigail
Re:Perl as A First Language Is Scary (Score:2)
When one talks about strong typing vs weak typing, one isn't referring to an on/off switch. There is a whole spectrum of relative strength. I hope everyone agrees that C is more strongly typed than Perl. I would also submit that C++ is more strongly typed than C. Your first question is meaningless since you are referring to something different than I.
As far as the second question goes, I'm just going to make this broad statement:
Perl lacks the structure that I feel is necessary for large scale development projects. I also feel that this lack of structure is an impediment to learning good programming methodology.
I will say one more thing. I use Perl on a daily basis. I use Perl as often as I use C or C++. I still stand by my statement that Perl isn't a very good language for someone just learning to program. It will take more than trolls to get me to change my mind.
Casey
--GnrcMan--
Re:Perl as A First Language Is Scary (Score:2)
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?
As far as the second question goes, I'm just going to make this broad statement: Perl lacks the structure that I feel is necessary for large scale development projects. I also feel that this lack of structure is an impediment to learning good programming methodology.
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.
It will take more than trolls to get me to change my mind.
If there's any trolling going on, it's you doing it.
-- Abigail
Re:Boy, I'm easily baited today (Score:2)
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
Re:Problem with O'Reilly books (Score:2)