Slashdot Mirror
Beginning Perl, 2nd Ed.
Beginning Perl is a conversational-style tutorial that will guide you through your first steps into the Perl world and even a little beyond. The first two-thirds of the book cover the basics of programming with Perl including data types, flow control and IO.
The casual flow through here will help prevent fledgling programmers from suffering information overload. The authors handle the need to provide enough information, though, by revisiting topics repeatedly, going a little deeper each time. Unfortunately, this hurts the volume's use as a reference, as it's quite a challenge to go right to something. (Example: The built-in join() is covered in the chapter on "Regular Expressions," which is certainly not the first place I would look.) The index is decent and can guide you through these problems, if you remember to start there.
In keeping with the book's tone, side-trips and diversions are fairly common. Early on, these center around topics like "How to Think Like a Programmer" and "What Exactly is a Binary Number." I mention this because I know some readers appreciate this level of detail, while the interruptions annoy others. I found many of the discussions insightful, but it did occasionally get carried away with itself. (Example: There is a whole page on Perl's versioning scheme that goes so far as to discuss what a "patch pumpkin" is. Interesting or not, it seems out of place in here.)
One of Beginning Perl's real strengths is its constant encouragement of the programmer in training to experiment as a means of further learning. The text often suggests things to try and each chapter ends with a set of exercises. Answers to exercises are provided in an appendix. The only way to really learn programming is to program, so I was glad to see this push in the right direction.
The final third of the book digs a little deeper, examining references, object oriented programming, the CGI protocol and interfacing with an external database. Make no mistake, these are only introductions, but they are a nice addition to a beginner's book that will have you doing a little practical programming quickly. The "Introduction to CGI" and "Perl and DBI" (database interface) chapters really stood out here.
Two chapters were rocky enough to mention. "Regular Expressions" does not handle its content well, I'm afraid. You spend most of the chapter seeing if a pattern matched, but not what it matched. That's an important distinction for me. Learning regular expressions can be tricky and you need to see exactly what's going on. This issue is finally address near the end of the chapter, but it needed to come sooner. True beginners will likely need considerable experimentation of another book to really catch on to regular expressions.
"Object-Oriented Perl" was also problematic. Frankly the chapter bit off more than it could chew and doesn't really manage to teach much because of it. (Example: Inheritance isn't even addressed.) I think a better use of the chapter would have been to outline only the use of objects as a setup for later chapters, leaving the creation of objects to a volume that could spare the space to do the topic justice. Again, beginners will definitely need more material to be comfortable with object oriented programming.
To summarize, if you've wanted to learn Perl but haven't yet taken the plunge, you could do a lot worse than to start with this book. It's a casual tour of the basics with a few teasers for further study opportunities.
You can purchase Beginning Perl, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.
Looks like somebody screwed his editing job again...
I'd like to know who wrote it. Thanks for the info.
Violence is the last refuge of the incompetent - Salvor Hardin
Comment removed based on user account deletion
was there really a market for another beginner's book in Perl?
Learning Perl (O'Reilly) did an absolutely exquisite job at introducing people to programming and Perl simultaneously.
"All that glitters is not gold"
I would actually consider Perl to be one of the best starting languages actually (unless you plan on going on to be a professional coder).
I learned Perl before any other language and found that the Llama book was a perfect introduction to programming techniques and Perl alike.
"All that glitters is not gold"
My favorite Perl book was the first one, published by O'Reilly, back in the 90's, by Randal. They've all seemed so dry since. :-\
A feeling of having made the same mistake before: Deja Foobar
Only a 7/10 score? What did the author ever do to you to deserve such a cutting insult? He must have had to kill your cat, steal your girlfriend, or erase your SNES emulator saved-game directory! Possibly he even put the toilet seat down at your house, causing you to accidentally leave a few pee drops on the seat when you took a midnight piss while tired and bleary-eyed. I can't say. I honestly can't imagine what it would take to send a man over the edge and only give a 7 for such an excellent book.
There are also a lot of free resources out there to help you learn Perl without having to buy a book. The following website's tutorials listing helped me get started:
http://www.perlmonks.org/index.pl?node=Tutorials
YMMV of course, and you may very well wind up buying a book anyway, but still check that out!
It assumes no prior knowledge of Perl or of programming in general.
Does it mention the need for chicken blood, human tallow candles and pentagrams made from ground baby skull? Sorry, I liked Perl Back In The Day but the OO is just bolted on and I can't do anything with it I can't accomplish with Python (or Ruby although I'm still learning that).
Trolling is a art,
I'd hardly call HTML a programming language...
I'd recommend C, which any decent *nix install should include, then move to perl.
but then I love C...
A feeling of having made the same mistake before: Deja Foobar
Considering Perl has a "do what I mean" style, has no pointers, has no "real" object-orientedness, has very little structure, and is generally very loose on types, I would argue its perhaps the best tool to begin experimenting with programming.
...but I'd have to say Perl is easily the most "fun" to work with - perhaps thats as good a reason as any to have it as you're first language.
I've worked with a lot of languages - C/C++, Delphi, Java, Perl
I see nothing wrong with learning Perl first (other than the fact I tell everybody they shouldn't touch Perl with a ten-foot pole). Perl was one of the first languages I got into and it's very easy to get started. Sure, there's twenty different ways to do things and things can get really complicated and complex, but if you're just beginning programming you're not gonna be doing the hard stuff.
Using Perl is a good way (as good as anything else) to get accustomed to programming constructs and variables.
As for learning HTML first.. well that's not even a programming language and wouldn't teach you a thing about programming. PHP would be a good one, but you have to know a little HTML first. (Sorry if that's what you meant by HTML, PHP).
I remember when legal used to mean lawful, now it means some kind of loophole. - Leo Kessler
don't forget to pick up a copy of the new perl 6 book!
- tristan
Generally, bash is superior to python in those environments where python is not installed.
HTML? Isn't that a markup language, and not a programming language? How does HTML teach you any programming concepts?
... PHP. *shudder*. "Like Perl without the toolbox, like C without the speed".
And then
You give no reason why you wouldn't recommend Perl as a starting language, so I can't rebutt them. However, I would, for one reason:
It allows programming to be FUN. Ideally, everyone would learn ASM first, then C, then Lisp, then Python, then Perl, then Ruby. But you'll probably have killed most people's desire to program with the first two, and freaked them out with the third.
+Pete
Score:-1, Funny
I don't understand. What is he talking about?
*is run over by rotten tomatoes*
Perl is a great beginner's language. You don't have to compile it, the required variable prefixes clearly allow newbies to see what's a scalar, array, etc at least until you get into the more complicated dereferencing, and the user can be introduced to the more natural-language forms first, so they don't get parenthesization shock (e.g. $i = 2 unless $this or $that;)
Someone had to do it.
Comment removed based on user account deletion
People have cut their teeth in assembly language and C. Perl is much more easy (easy as in getting your job done quickly). Besides, in Perl there are many ways of doing things. If a beginner is not comfortable thinking in one way, he can always choose another. He might end up being a better programmer. Except he might be eternally corrupted by Perl and keep asking for Perlish features in other languages (can I have split and join in Java, please?)
This is a great beginner's book. And if you're a beginner with no cash it's an even better book, since the first edition is available as per-chapter PDFs. Get 'em here.
S2education is no substitute for intelligence
HTML? HTML is a markup language (it's in the name), not a programming language. This is like calling the garbage that Word spits out programming code.
Anyway, it's a good idea for anyone to learn HTML (or even better, XHTML), since it's everywhere now. However, learning php as a first programming language is a bad idea. Don't get me wrong, php is THE language I use for work (a little Perl and C++ on the side), but it won't allow a person to learn any other programming languages any easier.
I started with Pascal, then C++, and later Perl, PHP, and many more. Pascal is actually a VERY good starter language, but doesn't have a whole lot of real-world applications. Perl is a good starting place, but people should learn the "right" way to do it instead of the way it's commonly used. use strict and turn on warnings is the best way to do this. Then Perl is a good starting point and will making learning more complicated languages (C++, Java, etc) or simpler languages (PHP, Basic, Python) much easier.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
#!/usr/bin/perl -w
I think the reason perl was the easiest language for me to grasp from the get-go was because variables were just that
Perl just seems to connect better with me, in that any given variable can be any given thing. A number. A string. An array. A hash. A reference to any of these things. It can even be an object, or subroutine. All things are mutable and transient.
Now if this makes perl a good starting language or not I don't know -- maybe it makes learning other languages harder, because you always with that the other language was more like perl.
At least I do.
d. Taylor Singletary,
reality technician techra.el
Comment removed based on user account deletion
The reviewer is a frequent poster to Ruby-talk, an email list devoted to Ruby.
That's the truth. Back in the early 80's we had BASIC and you could dink around and get immediate results. It even used variable names like $firstname, with dollar sign like Perl does. :) If you wanted to be hardcore you could peek & poke, which doesn't really apply anymore these days (kernel won't allow you to access arbitrary memory) but you can still do stuff with Inline::ASM if say you have mmap'd a framebuffer and want to play around with putpixel-type algorithms.
All in all you could do a lot worse than Perl for a beginner language. I mean, some people start out with Java. *shudder* Somebody I know had the misfortune of sitting through some Java class at uni and it totally turned him off programming.
And all you elitist motherfuckers who think non-programmers shoudln't code: go eat a dick.
Maybe it's just me, but I wouldn't recommend Perl
Agreed. Python is the way to go for a newb.
I like a nice peach sometimes :-)
I'd say that that HTML isn't any kind of language, just a ASCII file format with delusions of grandeur.
I've been programming computers for over 25 years, and sometimes a variable can still be hard to grasp: Is it the data value? Is it the storage slot? Is it a reference to the storage slot? Is it the name of the variable? Is it the binding between the name and storage? Does the value have different names in different scopes? Does the storage slot have a type? Does the value have a type? Is the value mutable? Do I have to manage the storage allocation myself? What are the exact lifetimes of all of the above? In what scopes are they visible? Does it exist in a strange place like a closure?
Some languages expose most all of these concepts to the programmer (Perl is one of them, even though it doesn't usually make you explicitely deal with most of these), and things can get tricky.
HTML? Isn't that a markup language, and not a programming language? How does HTML teach you any programming concepts?
... which was a revelation for me, and for many others. In my case, at least, cobbling together my first pointless, amateurish "this is my homepage hope you like it" Web page led, slowly but quite directly, to a programming career. And I don't think I'm unique in this.
Actually, HTML is a very good thing for people who have never done any programming in their lives to learn, because it does teach what I consider not only a "programming language concept," but the very idea of programming: giving the computer a series of instructions which produce an output noticeably different from the input. This is fundamentally different from the way most people use computers, in which output immediately follows input, and one is obviously a product of the other.
No, HTML isn't Turing-complete, and no, learning it won't teach you any of the theoretical basis of programming. But it will teach you how to write something that can meaningfully be called "code," and let you see the results of your work
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Same reviewer different lang, not exactly for begginers, but I think Ruby is far better suited as 1st programming lang than "old hat perl"
/ 1843240&tid=156&tid=6/
Programming Ruby: The Pragmatic Programmers' Guide
http://books.slashdot.org/article.pl?sid=04/10/13
nope, not related to the authors...jeez
I think one's first programming language should also be a strongly typed language, else you'll never be able to troubleshoot Perl. It's the same reason why JavaScript shouldn't be your first language.
:)
Remember the quote, "Perl is Internet Yiddish."
What's so strange about a closure?
-30-
I do like Perl a lot: it allows me to do many things in just a few lines of code (or a few thousands)...
But my biggest complain is that perl allows you do use obscure syntax and invisible variables. You end up with poeple writing code completly unreadable that you have to maintain.
I'll avoid talking about using CPAN, now I try to get the modules I need using apt-get.
Perl's a great beginner's language until you go beyond single-dimensional arrays.
l ).
@b=((0.8,0.9,1),2,3,4);
$b[0] => 0.8
because it flattened out the list for some reason.
Gotta love those at-signs and dollar-signs.
You have to say
@b = ([(0.8, 0.9, 1)], 2, 3, 4);
So the inner list needs brackets.
Why didn't the outer list need brackets?
Then you can say $b[0] and get ARRAY(0xb75eb0).
Well, maybe @b[0] will work, no that gives
ARRAY(0xb75eb0) also.
What you have to say is @($b[0]). Of course, how could I have missed that??
(The preceding cribbed from http://www.garshol.priv.no/download/text/perl.htm
PHP lets you do useful stuff without the slop. It also has documentation which is better suited for a person who doesn't know the language.
Perl has a lot of history behind it... which if you don't know the history, you're SOL. I mean stuff like if you're trying to use a library, you'll have to know an awful lot about what the author did. Toss an object to a person who's never heard of objects, or show some cryptic bit twiddling or make them troubleshoot some random Perl guy's overzealous use of regular expressions. Ouch. Yeah it applies in all languages, but in Perl, there's more of them.
The only good thing about Perl for learning might be that it is forgiving, you can be creative in how you manipulate data.
And hey, while HTML isn't a language, and should never be considered such, would you really want to teach Perl to somebody who couldn't grasp HTML?
Progressing to PHP from HTML might not be such a bad idea. People can figure out the difference between the browser and the server, then learn about simple things like variables, functions, loops, arrays, etc, while dealing with some hard guidelines they need to conform to in their output.
With that little skill, they can do some cool stuff with a web site. They can do stuff they find useful, show off, or solve problems. With Perl alone, they're locked in an ugly box on their Windows machine, trying to figure out CGI, or waiting for their skills to develop to the point that they can interface with various toolkits.
Teaching them Perl alone is giving them access to a suite of tools which they'll probably never figure out why they need it... but...
... once they know the basics of functions, loops, interation and so forth... then a language like Perl might be o.k., if they're a sysadmin, crunching text and/or have a need for CPAN...
...but then... you might wind up with the problem I see all the time... people writing shell scripts in Perl. Ugh. Very unnecessary.
Perl is a great beginner's language.
Nonsense.
You don't have to compile it,
which is a bad thing, because it means that even their typos don't show up until it actually tries to run that part of the program. So they think they've succeeded, when really they still have a buggy mess.
the required variable prefixes clearly allow newbies to see what's a scalar, array, etc
Yeah, because of course that's far more relevant than the things Perl makes very hard to tell - like what's a number and what's a string!
Nope, start them with something that requires a bit of B&D. Using a strongly and statically typed compiled programming language will give them some feel for what programs actually do, and it will give them some idea of what they can get wrong.
THEN show them Perl - and they might appreciate the liberation, or they might have more sense, but either way they will be able to make an INFORMED choice about whether they want to sell their safety and execution speed in return for fast development times.
erm, I think you meant @{ $b[0] }. note difference in parenthesis.
The reason the [ ] are needed in the original declaration is because they create an array reference. (Much like @{} dereferences). The ARRAY(0xb75eb0) is simply the reference itself.
Additionally, you can access the inner arrays via $b->[0][$var] for direct access. No one I've explained perl too has particular difficulty with these topics.
As to compiling, beginner's aren't developers. Perl's ability to chew through bad code makes it *more* educational because you get to see what the bad code did. It also makes it a lot less frustrating when users don't have to pass syntax checks before they even try to run their code. (Developers, on the other hand, can test syntax with commandline switches.)
In Perl, a number is a string and a string is a number. How the value contained in a scalar is interperated is a context matter. So to say Perl makes it hard to tell what is a number and what is a string, is to misunderstand what a perl scalar is.
And as far as security goes, perl doesn't crash its own stack nor will it munge data of nearby variables due to a miscast. I would never trust a newbie coder to write secure code, but then, if I did, it had sure as hell be in a higher level language to avoid buffer overflows.
I like C, too, and I do think using it leads to a better understanding of the actual data manipluations a program performs. But the question is in the merits of teaching programming concepts, and that understanding is only one concept among many. C can't be beat for speed. But when you are learning how to program from scratch, speed is of no concern.
Someone had to do it.
I didn't have any real brain blocking in learning a programming language until I tried one that was very strongly typed, where you have to set the possible size of said variable ahead of time... know how many slices an array might have ahead of time, etc.
Funny... I'm having difficulty thinking of a language like that. None of the modern statically typed languages I've ever used - Haskell, ML, and such like - require you to declare the size of variables in advance. You just use them - just like in Perl.
The difference is that you CAN declare them in advance, if you want to - and they complain if you are using them inconsistently. Perl, meanwhile, makes no complaint if you use a string as a number... even though 99% of the time this represents a bug, and the remaining 1% of the time it's not really very arduous to add an explicit type conversion.
As a beginning programmer I can say that between the handful of popular scripting languages Ruby is hands-down the easiest, most logical one to pick up. Most things just make sense and don't seem like bolted on pieces added on after the fact. I have checked out Perl, Ruby, C++, and Java and acknowledge that there are different tools for different jobs. But for someone starting out I've been 10 times more efficient coding applications in Ruby. Plus what other programming language can you hop on a mailing list and have your question answered in an hour or even join an IRC channel where the language's author is usually listed as being in the channel as well? Offtopic granted, but reading about a beginner's guide for Perl kind of struck a chord with me.
Yeah, but that can be ugly and nonintuitive. For example, in the Perl Cookbook, one of the very first things one reads about arrays is:
Woof... that is ugly to these eyes. And then there's the horrific typing (or lack thereof) issues... Is it really sensible that "Hello" + 2 is a valid value? And is the behavior of something like (3+2) x 4 something that should be clear to a beginner?
Nah... give me something like Haskell as a beginning language. And before anyone starts screaming about monads or I/O, it's possible to introduce them in a gentile, sensible way.
-30-
+1
It assumes no prior knowledge of Perl or of programming in general.
Books that assume no prior knowledge of programming should also give the student an idea of what else they need to know beside programming before they can do any real work.
A partial list would be:
I also recommend:
Also, alert the student that it takes 5 years to become proficient and every 5 years half of what he knows is obsolete.
(can I have split and join in Java, please?)
What? There is no split or join in Java?? I know there isn't in Visual Basic or VBA, but then, what do you expect from VB* anyway...
But Java, and even javascript, I would have thought to be a little more programmer-friendly.
Well, I see there are still many good reasons to stay with Perl...
As the documentation indicates.
Because of context, as the documentation indicates.
You didn't read the documentation. If you had, you'd know that the parentheses don't do anything besides expression grouping. You'd know that arrays can only contain scalars. You'd know how to store a list in a scalar by using an anonymous array or array reference.
You can agree or disagree with that decision, but until you understand context in Perl and its implications, Perl will continue to confuse you.
how to invest, a novice's guide
which is a bad thing, because it means that even their typos don't show up until it actually tries to run that part of the program. So they think they've succeeded, when really they still have a buggy mess.
Well that's not necessrily a compiled vs. interpreted issue. Give 'em an interactive REPL like with Haskell, OCaml, Lisp, Scheme, etc., and that will catch any of the errors that the compiler would catch -- without having to stop and recompile all of the time. Plus, you get type inferencing goodness with the languages like ML and Haskell which make bugs easier to spot, and essentially do away with the need for explicit type annotations.
-30-
(if (parses (your brain) (things that way)) (is (lisp fun)))
To be honest mine doesn't (which is probably why the above is quite wrong), but I do know people who seem to find it far more "natural" and "readable".
Jedidiah.
Craft Beer Programming T-shirts
Perl was very easy for me to pick up and make usefull. It seems like a very good starting language.
"I use a Mac because I'm just better than you are."
Even so, it's hardly an issue...
-30-
"It seems that when people become desperate they consult the gods, and when the gods become desperate they tell lies." -
"Object Oriented" means a lot of different things to a lot of different people.
If you cite examples of your designs or pieces of code of yours, I'm sure I can find some things that could look nicer or be better implemented via Python's OO mechanisms, and I am not just talking about the C++ kind of OO (encapsulation/inheritence/polymorphism) but also about Python's __getattr__ and other powerful features inherent in its OO design).
There's no join() but Java 1.4 introduced a split() method that returns a String[] with the pieces in it.
Python, Perl and Ruby?
Those three are redundant: pick one, either Python or Ruby (Perl is a mess IMHO)..
As for Lisp, I don't know: it could also be Haskell, OCaml, Scheme, Erlang.. Choosing one is difficult!
Make a paralell to algebra...that's what I always did.
It allows programming to be FUN.
A succinct case for Perl as a first language is made by Simon Cozens, one of the co-authors of the book:
There's an informed discussion of the question at PerlMonks.
A more interesting question is what is the best second language. Now that programming has your attention, should you move to something that teaches the fundamentals like Assembler or C or do you move to something with a broader scope like C++ and Java? Or do you choose something mind-expanding like Lisp or Smalltalk?
PHP is a programming language?
Perl Programmer for hire
What's wrong with CPAN? I have never had any problems with installing modules using ppm.
Perl Programmer for hire
Why is it that the people who complain about Perl are usually complaining about its flexibility? Yet those same people take liberties with everyday English? Isn't the expression of ideas more important than a rigid structure for presenting those ideas? I'd like to see the Perl-bashers exhibit a little logical consistency and start doing their posts in well-formed XML -- just so we know can be clear about they are saying... ;)
I wish I had done things in this order. 1. a shell like ksh 2. c 3. Then Perl.. I missed a great deal I had to go back to with not learning the first two to start with.
James Loo. That kind of mistake in a review is unacceptable.
After waiting for a bunch of students to raise their hands, he continued with, "You people are going to be at a serious disadvantage in this class."
Perl is not a great beginner's language. It's not even an adequate one. Anyone who learns it will learn bad habits that are in opposition to all the principles of good software engineering.
Python, on the other hand, is a great beginner's language.
|>oug
Actually everything in perl is an object of class SCALAR.
.
SCALAR is a polymorphic object that can behave like a number, a string, a pointer, . .
The behavior the SCALAR exhibits is context dependent.
I would actually consider Perl to actually be one of the best actual starting languages actually, (unless you actually plan on going on to be an actual professional coder).
I actually learned Perl before any other actual language and actually found that the Llama book actually was a perfect introduction to actual programming techniques and Perl alike, actually.
YMMV
I suppose when you are misunderstood in English, you can just moan on about the recipient being too stupid to understand, rather than god forbid, you didn't bother to articulate properly.
On the otherhand, if you are misunderstood when coding, you won't get the results you hope for.
So, expression of ideas is massively important, but to say that it isn't important that those ideas are understood seems to make the expression pointless.
This signature intentionally left blank
This article originally showed "James Loo" as the author, and that has now been corrected, so this thread can die now. Lee. Not Loo.
Full Disclosure: James and I worked on Hacking Linux Exposed together, and he's a damned fine chap and killer Perl guru. He's the one who badgered me into learning Perl years back, and I don't thank him nearly often enough for it.
Nah... give me something like Haskell as a beginning language
You're kidding, right? Haskell doesn't have the support base perl does. It doesn't have the documentation that perl does. I found it horribly confusing when I last sank hours of my life into it, and I've got a degree in mathematics, and have been programming professionally since 1991.
Haskell sounded straightforward enough, but looks can be decieving. After writing my first program without a hitch, I spent several hours trying to code a simple proof-of-concept Sieve of Erostrathenes in Haskell, and kept getting a bizare "Unification would lead to Infinite Type" error.
There was no documentation on what Infinite Types were, or why they were a problem. Nothing in the documentation explained what set was being unified with what other set, nor why.
The function definiton I used was mathematically correct, and should have worked from a strictly mathematical basis. Haskell was unable to understand it correctly, and unable to tell me what went wrong in a reasonable way. I found this very, very frustrating.
The error appeared to be "haskell-speak" for some sort of error caused by taking the floor of a the square root of a number in a function that returned an integer. I worried that haskell wasn't able to handle the notion of a function that mapped an integer to an integer, but used as it's definition a real valued computation. This is certainly valid in mathematics.
At the time, the web site promoting Haskell (haskell.org?) had some wierd sort of precursor to a wikki, where anyone who wanted to could add, edit, or overwrite the page. No mention was ever made about whether the page was even backed up, and so I wondered if I should mess with it. All the postings were months, if not years old, so I didn't bother.
The newsgroup referenced wasn't even language specific (comp.languages.functional, rather than comp.languages.functional.haskell). Perhaps the language has matured a bit, but it's no where near as popular as perl.
Haskell, like all functional languages, is based upon the assumption that recursion is a good thing. This assumption is nearly universally false.
Recursive algorithms are complex, and hard to understand and maintain, so much so that an entire branch of mathematics is based on simplifying recurrance relations into a simple, closed form solution. Recursive algorithms must be made none recursive (using tail recursion, if possible) just to make them reasonably efficient.
And is the behavior of something like (3+2) x 4 something that should be clear to a beginner?
When you know that (3+2) is 5, and you know what the repetition operator "x" does, then yes, it's pretty darn clear. Repetition is a simple operation, and even a six year old can understand "do this four time".
But if you're talking about opaqueness of documenation, are terms like "fixity declaration", "non-terminating expression", "lamda abstraction", or "infinite data structure" (*boggle!!!*) really more clear? No. Your "Gentle Introduction to Haskell" is anything but.
Try explaining to a six year old how the infinite type definition of the fibbonacci sequence, using the wierd zip function on different parts of the same infinite string is supposed to work. Tell me if you manage it before the kid is ten.
Haskell is a fun toy language for academics; but perl gets work done. Teaching a beginner haskell is probably a good way to scar them for life.
--
AC
Shop as usual. And avoid panic buying.
All in all, it was the ease of use that kept me going and enabled me to appreciate stricter things later on when I could understand why they're needed. Perl is a good first language for precisely all the reasons that someone might later object to: it's sloppy, but it's fun, and you sometimes need the latter to keep you going. Finally, and I know this isn't a feature of the language, but Perl Monks kicks ass.
Shop as usual. And avoid panic buying.
Then you should read this one.
And Latin doesn't have the support base Chinese does. Which is easier to learn? Which teaches you more about other languages?
Haskell sounded straightforward enough, but looks can be decieving. After writing my first program without a hitch, I spent several hours trying to code a simple proof-of-concept Sieve of Erostrathenes in Haskell, and kept getting a bizare "Unification would lead to Infinite Type" error.
Wow... what were you doing? Sieve in (idiomatic) Haskell:
Your "Gentle Introduction to Haskell" is anything but.
Well, I was referring to section 8.1 of the intro (on the IO monad), which is mostly straightforward in the way it presents IO -- it could easily be dumbed down a bit so you can say, "Here's how you do basic input and output. We'll teach you what's going on under the covers a little later when you learn a bit more about the language."
Haskell, like all functional languages, is based upon the assumption that recursion is a good thing. This assumption is nearly universally false.
Recursive algorithms are complex, and hard to understand and maintain
Really? This is hard to understand (in OCaml)?:
Compare that to the iterative solution and the recursive solution is much cleaner and more direct (And yes, I know that this solution is less efficient that an in-place modification version of the algorithm, so spare me that old sawhorse... If you want to do that style, you're perfectly free to). There are entire classes of problems like this that are more naturally solved in a recursive fashion, like working with trees. The definition of a binary tree in Haskell:Care to show me how the iterative definition of a tree is more clear than that? Yeah, that's what I thought...An entire branch of mathematics is based on simplifying recurrance relations into a simple, closed form solution
Yeah, and there are people that have spent their lives working on the essentially simple concept of factoring integers. Just because a concept has a deep, dark, complex underbelly doesn't mean that it doesn't have a very simple face that is all most people need to see.
-30-
Well I was complaining more about the horrible way of referencing the elements of the array. It's especially confusing when you learn that even though $tune[0] refers to the array @tune in some way, the variable $tune doesn't.
-30-
is here.
Fair enough. That is confusing.
Shop as usual. And avoid panic buying.
So, Haskell proved that one of your functions would go off into an infinite loop and use up all memory, and you're complaining?
Comment removed based on user account deletion
Yeah, beginner A can always code in his comfortable subset, right up until he has to debug beginner B's program, and B's subset and A's don't intersect. Which is why Perl is a write-only language.
It's crackers to slip a rozzer the dropsy in snide.
Saunders MacLane is also a gentile who covers monads in a sensible way in chapter VI of Categories for the Working Mathematician.
It's readable in the sense that I can ignore all the operators and rearrange the words into something meaningful.
In any other sense it is not.
This first version of the book was written by Simon Cozens.
When it came to writing the second edition, Simon didn't get the job owing to his reluctance to carry it forward to future revisions, due to work restraints. So, someone else was hired, but Simon was promised 50% royalties, since it was going to be based largely on his work.
Based on Simons latest blog post, the publishers have conveniently forgotten this agreement. He's now not goint to get any royalties for the book, despite having written much of the material!
So, rather than buying the new edition (and supporting a publisher who rips off their authors), you should go read the Creative Commons licensed version of the first edition that Simon has posted here.
This post will enter the public domain 70 years after my death, unless Disney buys another extension.
And Latin doesn't have the support base Chinese does. Which is easier to learn? Which teaches you more about other languages?
:: [Int] -> [Int]
Chinese teaches more about eastern languages, latin, about western. Both are documented. Haskell wasn't documented. Undocumented languages are bad.
Wow... what were you doing? Sieve in (idiomatic) Haskell:
sieve
sieve [] = []
sieve (h:t) = h : sieve [x| x
I tried something like that: it didn't work. I tried several variations on syntax, nothing seemed to work, and there was no documentation to explain the error. No perlmonks, no perl.org, no thousands of people ready to help and explain. Just an error with no supporting context. No fun.
I suppose I could have tried to read the source code to the interpreter, but for all I knew it was bootstrapped in a native language and mostly written in Haskell.
Really? This is hard to understand (in OCaml)?:
let rec quicksort l =
match l with
[] -> []
| h::t ->
let less,greater = List.partition (fun x -> x
What's rec? What's l? What's h? What's t? What's fun? What's less? What's greater? It's not documented, and I don't want to read up on OCAML to find out that it isn't documented, either.
It's rare that a problem needs to be solved recursively, and the recursive solution is, as you admit, usually more expensive than a more iterative counterpart. Certainly a fibbonnaci series computed in a loop runs faster than the equivalent recursive solution.
Compare that to the iterative solution and the recursive solution is much cleaner and more direct (And yes, I know that this solution is less efficient that an in-place modification version of the algorithm, so spare me that old sawhorse... If you want to do that style, you're perfectly free to). There are entire classes of problems like this that are more naturally solved in a recursive fashion, like working with trees. The definition of a binary tree in Haskell:
Tree manipulation is generally a toy problem. The real world applications that really need trees usually don't have the luxury of an inefficient recursive solution.
What's more, I can write recursive solutions in perl if I really have to. I don't have to worry about the the whole ugly idiom being constantly rammed down my throat, though. I don't use recursion whenever I can avoid it, because I know recursion is confusing to maintenance programmers, (some of whom have never heard of the term) and thus likely to be misunderstood.
When a recursive solution does appear to be a good solution to a common problem, there's usually a highly optimized, non-recursive solution (for efficiency reasons) available as a module already.
In any case, as this discussion proves, Haskell is (or was) not for the novice. It's poorly supported, and relies too heavily on counterintuitive notions like recursion and currying. Novices need more support than Haskell has historically provided. If a professional programmer can't learn it in a small amount of time, do you really want some poor high school kid trying to struggle with it, getting bored, and going home?
Give him LOGO, BASIC, or something easy like that. Only give him a copy of Haskell after he's got a Masters degree in computers, and slip him a copy of the secret documentation, and then maybe he'll get it. Maybe.
Yeah, and there are people that have spent their lives working on the essentially simple concept of factoring integers. Just because a concept has a deep, dark, complex underbelly doesn't mean that it doesn't have a very simple face that is all most people need to see.
We're programmers. We do need to understand that complex underbelly. We often need to prove that we're using exactly the correct function, and that it operates in the smallest amount of time, using the fewest resources possible. That's the dark underbell
Chinese teaches you about whatever dialect of Chinese you learned, and I believe a bit about Korean. Latin gives insight into French, Spanish, Italian, and a lot of English, plus a leg up in understanding legal terms, medical terminology, etc. (Although I'm sure some linguist could come around now and point out all of my errors...)
What's rec? What's l? What's h? What's t? What's fun? What's less? What's greater? It's not documented, and I don't want to read up on OCAML to find out that it isn't documented, either.
rec indicates that the function is recursive (something covered in section 1.1 of the OCaml manual). l, h, t, less, and greater are (prepare for shock and awe) variable names, representing the following values: l is the list being sorted, h is the head of that list, t is the tail of the list, less is the list of values that are less than the head of l and surprisingly greater is the list of values greater than (or equal to) h. If you have trouble telling what a variable is, it's no wonder Haskell befuddled you (Do you look at a function like let f x = x + 3 and ask, "What's x? What's 3?"). By the way, before you ask, List.partition is a function that partitions a list into two sublists according to some predicate. I'd apologize for it not being documented, but well... it is.
Certainly a fibbonnaci series computed in a loop runs faster than the equivalent recursive solution.
Well that certainly depends on whether you mean recursive in the sense of the process or in the sense of the procedure (see SICP if you don't know the difference. The difference in performance between a for loop and something like:
Unless, of course we're talking about a memoized version. But if you want one, it's actually pretty damn easy to wrap a recursive function with a memoizing wrapper. By the way, do you really want to be talking about speed and efficiency in a thread about Perl?
Tree manipulation is generally a toy problem.
Tree manipulation is a toy problem? Last time I checked, trees (and heaps and treaps, and all sorts of other recursive data structures) are all over programming.
What's more, I can write recursive solutions in perl if I really have to.
And I can do imperative programming in OCaml if I really have to. Your point was what again?
We're programmers. We do need to understand that complex underbelly.
So you know all about the properties of the semiconductors making up your machine? You can tell me how to build a J/K filp-flop and a shift register? You know all about circuit layout optimization? The inner workings of a DVD burner? See, that's one of the nice things about programming. You only need to strip off a certain number of layers of abstraction to do your job well -- sometimes you need to go deeper, sometimes you don't need to go deep at all.
We often need to prove that we're using exactly the correct function, and that it operates in the smallest amount of time, using the fewest resources possible.
And so you're advocating Perl?!? It's nigh impossible to reason at all about imperative programs and prove them correct, but when you've got a language that essentially encourages willy-nilly programming styles (yes, I know you can code clean Perl, but it takes a lot more effort than other languages) and highly mutable state like Perl than pretty much all hope i
-30-
Chinese teaches you about whatever dialect of Chinese you learned, and I believe a bit about Korean. Latin gives insight into French, Spanish, Italian, and a lot of English, plus a leg up in understanding legal terms, medical terminology, etc. (Although I'm sure some linguist could come around now and point out all of my errors...)
How many non-latin derived languages are made clear by studying latin? Very few, I'd warrant. Latin is important because latin was popular, and so were it's decendants.
Assembly Language (imperitive style) is the latin of programming. Functional programming is, what, esperanto? Useful in some limited circles, but generally unpopular?
rec indicates that the function is recursive (something covered in section 1.1 of the OCaml manual).
Showing off your mastery of OCaml doesn't help anyone understand Haskell better, nor does it advance the principle that Haskell is easy to learn. You're substituting arrogance in one language I don't know for another one, but not explaning much of use.
l, h, t, less, and greater are (prepare for shock and awe) variable names, representing the following values: l is the list being sorted, h is the head of that list, t is the tail of the list, less is the list of values that are less than the head of l and surprisingly greater is the list of values greater than (or equal to) h.
And basic programming in an imperative style requires that you document the names of your variables and choose meaningful names. This is especially helpful when presenting an algorithm in an unfamiliar language. It's the whole functional languages camp lack of documentation that I was protesting, and you didn't help the matter at all with undocumented variables. Again, not helpful to a novice.
If you have trouble telling what a variable is, it's no wonder Haskell befuddled you.
Please don't be so insulting! Of course I know what a variable is: but I can't tell a variable from a function call in an unfamilar language without any context or explanation. I found Haskell to be poorly documented, despite initial hype, (though I note that the situation has since improved), and I really didn't want to have to struggle to learn another new functional language just to discuss Haskell, and how hard I found it to learn.
(Do you look at a function like let f x = x + 3 and ask, "What's x? What's 3?").
In an unfamiliar language? I can guess that the meaning is the one that I assume, but I wouldn't expect that without a proper definition of the rules and operators of the language.
Even in mathematics, x could be a n by n matrix,and 3 an n by n matrix of the number 3. Or something more esoteric.
In a programming language, "+" could be string concatenation, for example, so that "hello" + 3 yields "hello3".
By the way, before you ask, List.partition is a function that partitions a list into two sublists according to some predicate. I'd apologize for it not being documented, but well... it is.
Yes, I'm sure it is, somewhere.
Where is the next obscure functional language that you're planning on discussing documented, so I can try to read ahead, and decipher what you're saying?
And that's hardly a reasonable description of a recursive procedure for counting backwards from n. A better recursive procedure for that is:
Is n 0? If yes then stop, else say n then count backwards from (n-1).
But yeah, I can see how that's real hard to undersand...
Actually, the example I gave was straight from the (minimal) introduction to functional programming I got in school. Which re-enforces my point that functional programming isn't so simple, if I got it wrong.
Gee, that's sweet... you came up with a recursive definition for squaring a number that no one would ever use. You do realize that there's nothing wrong with saying x * x in a functional language don't you?
Affiliate link in post. Mod Amazon money spammer down.
Well, assembly is more like the Latin of the von Neumann architecture (and thus very important to learn), while a functional language like Haskell is more along the lines of the Latin of the mathematics of computation, and thus also important to learn.
Showing off your mastery of OCaml doesn't help anyone understand Haskell better
a) I switched to OCaml, because I am more familiar with it (and able to write proper code off the top of my head in it) and for an example like quicksort, it's very close to Haskell (without the list comprehensions). b) As for showing off my "mastery" of the language, as I pointed out, the definition of rec is in section 1.1 of the OCaml manual. It is the sixth line of OCaml code that someone looking in the manual would see. And if you care, here's quicksort in Haskell (from Haskell.org):
And basic programming in an imperative style requires that you document the names of your variables and choose meaningful namesYes. And I suppose I should have used lst or theList for l, head for h, and tail for t. But h, t, and l are so common in ML literature and code (much like i and j as throwaway loop counters, and foo, bar, and baz in pseudocode), that a brief amount of exposure to the language would make them instantly familiar. Besides, my use of less and greater didn't seem to help...
BTW: Imperative programming requires that? Since when? Why is it that Perl has its reputation for looking like line noise? Have you looked at the IOCCC entries lately? Crap variable names and lack of documentation are available in all languages...
In a programming language, "+" could be string concatenation, for example, so that "hello" + 3 yields "hello3".
Yeah, in a language with horrible typing properties, but that's a rant for a different time.
Yes, I'm sure it is, somewhere.
Yeah, right at the spot I linked to. In the OCaml manual, under the section that documents the List module.
Actually, the example I gave was straight from the (minimal) introduction to functional programming I got in school. Which re-enforces my point that functional programming isn't so simple, if I got it wrong.
So you got a minimal (and apparently pretty damn poor) education in recursion and FP, and you're using that experience to damn a whole class of programming languages? Does that really make sense to you?
My point was that recursion is usually more complicated than an imperative alternative.
And my point was that you pulled a contrived example of recursion out of a hat and used it to damn FP. As I said, that's akin to my using Duff's device or this example of printing some strings to damn C. The oddball cases don't tell you anything about the average ones...
Doesn't the recursive version need to put n -1 lists on the stack, (until it unwinds to the empty list), each of size one smaller? I get n-1(n-2)/2 space usage for an operation that should take 2*n space. Am I wrong? Is this a bad example?
Well, depending on how you implement it, yes. As a pure recursive process, it will consume linear space instead of constant space (in terms of stack frames). However, you can use an iterative (tail-recursive) process (with a recursive procedure) to use constant stack space. Ex:
-30-
Oh, no wonder you're not sarging, you fucking KJ.
The theory of computation is largely that, theoretical. It has little or no real bearing on getting real world tasks done, because it abstracts away too much of the underlying implementation details.
O(n) sounds great, but if the constant it hides is 10**50, the algorithm is useless for all practical purposes.
I switched to OCaml, because I am more familiar with it (and able to write proper code off the top of my head in it) and for an example like quicksort, it's very close to Haskell (without the list comprehensions). b) As for showing off my "mastery" of the language, as I pointed out, the definition of rec is in section 1.1 of the OCaml manual. It is the sixth line of OCaml code that someone looking in the manual would see.
But I don't know OCaml, and I had no desire to surf the web to read up on it, just so you could use it to try to explain to me just how easy to learn Haskell is.
But h, t, and l are so common in ML literature and code (much like i and j as throwaway loop counters, and foo, bar, and baz in pseudocode), that a brief amount of exposure to the language would make them instantly familiar.
ML!?!!! But that's yet another functional language I don't know! How many other functional languages will I need to learn before I'll understand your explanations about how "easy" Haskell is to learn for a total novice?
So you got a minimal (and apparently pretty damn poor) education in recursion and FP, and you're using that experience to damn a whole class of programming languages? Does that really make sense to you?
Yes, of course it makes sense, and no thanks for the slur on my education. I'm "damning" them on the very basis of their complexity; and specifically, how hard they are to learn. With no programming education, none, at a much younger age, I successfully learned all sorts of imperative languages. Soon after, I was able to use them succesfully in a real world workplace.
On the other hand, we have my experience with functional languages. I had huge advantages on my side. I had a university educated professor, who's very job was to teach students programming. I had peers who were fellow programmers. I was no longer a 14 year old boy trying to sneak a peek at programming books between classes, but a full time, adult scholar dedicating my time to the subject. If FP was anywhere near as easy as imperative programming, I should have understood it then.
However, I, and many fellow students, found functional programming to be excessivly complicated and hard to understand. I tried it again, five years later with Haskell, and as you've heard, I didn't fare any better. It's five years later... perhaps I should try again? At least this time the HUGS error messages are documented.
And my point was that you pulled a contrived example of recursion out of a hat and used it to damn FP.
The point stands that recursion is hard. That's a valid basis to damn FP, because recursion is the common case for FP: the whole system is presented in terms of recursive, or mutually recursive functions.
So far, you've had to resort to special FP specific tricks like "memoization" and "tail-recursion" in order to try to match normal imperative programming results. Why not just program the easy way to begin with?
However, you can use an iterative (tail-recursive) process (with a recursive procedure) to use constant stack space. Ex:
And here's an iterative solution in Perl. I think it's simpler, and easier to follow.
ML!?!!! But that's yet another functional language I don't know!
Sigh... you may or may not have been joking here, but I want to make it clear that I said ML instead of OCaml is because it's common across the ML family of languages, just as some concept may be common to *nix or *TeX.
Yes, of course it makes sense, and no thanks for the slur on my education
Hey, you're the one who said you only had a minimal introduction to recursion. And since you said that the horrific example of recursion you gave came straight from that introduction, I'd have to surmise that it was a very poor introduction. You've certainly given me no evidence to the contrary... Especially when you say things like:
So far, you've had to resort to special FP specific tricks like "memoization" and "tail-recursion" in order to try to match normal imperative programming results.
Memoization and tail recursion are hardly FP specific.
I'm not sure I'm interpeting your example correctly, but this is what I think it does, and the minimal mental operations required to process it:
Close-ish, but not quite right. It's more like:
(1) Define a function map that takes f and lst as parameters
(2) Define a function map_helper, local to map that takes three parameters, f, lst, and acc. This function does the following:
(3) Pattern match on lst. If lstis an empty list
(4) Reverse acc
(5) Return it
(6) Otherwise split lst into its first element and a list of the remaining elemets, call these head and tail.
(7) Apply f to head
(8) Cons the result onto acc.
(9) Overwrite the current stack frame with a new one where f is the same as it was before, lst is replaced with tail, and acc is replaced with the value computed in (8) -- Goto (3)
(10) Call the function defined in (2) passing it f as f, lst as lst and an empty list as acc.
(11) Return whatever value this hands back to you.
Note that there is no stack growth (well, there is one new frame appended for the first call to map_helper [I think... the compiler may optimize this call away as a tail call as well -- I'll have to see if that's the case]), and then for every additional call to map_helper, the current stack frame is just reused. And so we have the following concepts to handle: Define a function, apply a function, add and remove elements to/from the head of a list, return a value. That's all...
Of course there are a few neat things that go on under the hood here. For example, the compiler is able to determine the following things about map:
map_helper's f must be a function that takes something of unknown type 'a and return a value of unknown type 'b ('a -> 'b). It knows this because we apply it to head in step (7).
map_helper's lst must have type ('a list). It knows this because f (of type 'a -> 'b) is applied to head in step (7), so head must be of type 'a, and the list it came from must be an 'a list (as OCaml lists are homogeneous).
acc must have type 'b list, because we stick (f head) in it, and f returns values of type 'b.
map_helper is a function of type (('a -> 'b) -> 'a list -> 'b list -> 'b list) because it takes f, lst, and acc of the first three types and returns the reversed acc, which has the same type as acc
map's f and lst are of type ('a -> 'b) and 'a list respectively, because that's what it passes into map_helper's f and lst, and it
-30-
Which was taught by a university professor of computer science. If he can't understand FP well enough to teach it in a few classes, how is FP easy? I learned imperative programming faster, with less work, with no teacher.
Memoization and tail recursion are hardly FP specific.
But both concepts were born in the FP world: you don't need tail recursion if you don't recurse, and you don't need memoization if you can compute a function faster than you can look it up in a cache. In other languages, you take advantage of direct memory access in hardware to acess variables: in FP, from all the descriptions I've heard, you define functions and shuffle the data around betwen them on the stack. Both techniques were an ugly attempt to make LISP programs run faster.
Plus function calls in FP languages are generally faster than The Flash and cheaper than dirt
Compared to what? You've still got to stuff the data on a stack, and branch, under the hood. What makes a FP function call faster than an imperative function call?
Type checking in languages is a mixed blessing: it's more work to catch a specific class of bugs, and you may or may not care. If you care it's a win, if you don't, it's a loss, because of the added development cost (time spent thinking about irrelavent issues).
Things get even better when you get into functions like fold, which take an accumulating function, a list, and a base value and returns the accumulation of the list
I find the second, iterative definition simpler, because the function called hasn't been abstracted away from me while I'm trying to read it. This may be a poor example. In that case, how would you use fold in this context (if you would), and (if not) where would you use it?
From my point of view, I can see how to maintain the iterative function easilly. I don't see the same thing for the FP solution, but maybe there's a maintainable application using fold. Suppose marketing tells me that suddenly, for the sum function, the value of every 7th element should be set to zero if the total would be greater than 20 ( "every 7th call free for customers who spend over $20/month"). I just rewrite my sum function, and rename it appropriately.
I don't even know where to begin with the fold solution. I'd have to re-think the section from scratch, and for a large project, that's more error prone than testing a single changed function.
It's nice in an abstract sense. It's nice in the academic sense of beautifully abstracted. I don't think it's at all nice to teach to a novice.
It depends on understanding six helper functions, which all call each other in complicated ways.
I think it:
1) destructively constructs a list of all the odd elements of lst.
2) deallocates lst, since it's no longer of use.
3) Runs across lst2, and c