I can't believe you're bashing Python's OO system. It is the cleanest, most intuitive, and most powerful OO model ever innovated. Guido is a pure genius. Look at the alternatives: C++ or Java.
Just the fact you only list two languages as "the alternatives" shows you've got a lot to learn.
Nobody in Python ever calls stupid getpwent functions and `whoami` and `uname` calls.
That's because of Python's superior OO-model, right?
I am so fucking tired of maintaining code written by an idiot.
Me too. Perhaps Perl is so simple even idiots can use, and Python is too difficult? I dunno. Writing maintainable code is more a matter of the person, than of the language. Granted, for huge projects lasting several years with hundreds of programmers of various capabilities whose average turn around time is less than the time sceduled for the project, Perl wouldn't be the right choice. Python would be a better choice, but there are even better choices than Python in that case: Eiffel for instance, and probably Ada. However, most projects aren't huge, but rather small. Perl in that case is often an excellent choice - and so is Python. Neither is better or worse.
What the hell is wrong with Perl that there is so much bad code? It's got to be the language.
Nah. There are more bad novels in English than there are in Navajo. That doesn't have anything to do with the language. Come back when there is as much Python code as there is Perl code - and we compare again.
They're in for a quick hack
I've never heard some argue before that coding in Python takes a long time.
Read the manpage my ass. Windows doesn't have manpages, you know.
Wrong, grasshopper. Any distribution of Perl comes with more than 1200 pages of documentation. For Unix, for Windows, for the Macintosh, for the Cray, for VOS, for VMS and for all those other systems Perl runs on. Windows might not have a man command, it does have man pages. Hence, to help out the poor people on Windows, there's a command distributed with Perl called perldoc Guess what it does? *drumroll* It displays the man pages. Isn't that neat? But, it has been recognized typing might be too difficult for Unix-haters, so the Activestate distribution of Perl also comes with aim-and-shoot man pages - they're converted to HTML. Now, if that's still not enough, there are also filters to translate the man pages to Postscript, TeX, PDF and other formats.
Python is much better because it doesn't have any manpages for you Unix bitches to yell at us about.
I think you should at least give a look at Python before giving that type of answer. Perl is one of the worse ever invented, Python one of the best; and there is nothing more different in those languages than the OO.
Oh, I did. I'm not your average slashdotter who makes unfounded comments. I've bought and studied both "Learning Python" and "Programming Python", one of the reasons because it was said that Pythons OO was so good, and I'm fed up with Perls. I knew Perls OO was based on Pythons, so, it didn't come to me as a surprise that while Pythons OO is better (cause everywhere were Perl went different, it went wrong), it still looks to much like Perls.
Perl is really really really suboptimal as a language
For you perhaps, others think otherwise.
the thread was about an algorithmic book written for a "scripting" language
Uhm, the thread was about an algorithms book for Perl. The thread is about the book, not the language. Furthermore, what is your definition of a "scripting" language?
Being one of the technical reviewers of the book, I wish I could recommend this book. However, I don't think this books is worth its money. The problem I see with this book is that it's trying to be 3 things at once: an introduction to algorithms, a manual of some modules found on CPAN, and a bag of tricks. By trying so, it failed on all accounts.
Some parts of the book don't contain more than "if you want to do `foo', just call the function (or method) called `foo' in this package". I really, really don't need a book to state what I can find easily in a manual as well.
In the parts they do discuss algorithms, they often get side-tracked, by either explaining language features, or showing a trick that saves 0.5% of your execution time. The important things get burried in the details. It has been argued that having "real code" and not pseudo-code is a feature. In my opinion, this books makes an excellent argument in favour of pseudo-code. Pseudo code doesn't have to bother with language details, and people writing pseudo-code have to waste time wondering whether an alternative construct saves 1% of time. An algorithms book should focus on algorithms, not on the language.
If you want a bag of tricks, get Effective Perl Programming, if you want a bag of useful code snippets, get The Perl Cookbook, if you want to know modules, read their man pages, and if you want to learn algorithms, get a real algorithms book, like Cormen, Leierson, Rivest, Knuth's The Art of Computer Programming, or something from Wirth or Mehlhorn.
Doesn't Larry Wall (creator of Perl) work at O'Reilly now? If I'm remembering correctly, why is it that we haven't seen any Perl books written by him except the Camel book?
The CLR text is required for my algorithms course next term.
Good for you. I've teached grad students from this book, and it's a very good textbook on algorithms and datastructures. I need to get myself a new copy as well - mine is falling apart.
Problem A is NP-complete if there are no problems in the set NP that are harder than A.
You're all wrong.
The set of NP problems consists of a set of problems in NP which are all P reducable to each other. Hence, if one problem of the set of NP-complete problems is found to be in P, they all are. NP-hard problems are "harder". One can P reduce an NP-complete problem to an NP-hard problem, but not the other way around. Hence, discovering that NP-complete == P doesn't solve the P ?= NP question; as it doesn't prove that the NP-hard problems are in P.
The classes *I* took used "NP-complete", "NP-hard" and "hard for NP" synonymously.
Call me old fashioned, but I think that C is probably one of the best languages to learn first because the language itself is very simple unlike perl, it forces you to think about memory management (which IMO is a good thing, if only to gain an understanding of how it works).
It's lack of memory management is one of the reasons C sucks as a first language. It makes the beginning programmer get lost in details better left to the computer; taking away his/her time from focussing on the problem. Perl as a first language sucks too, but for different reasons. Python, Java, LPC, Ada or something from the ML family are much more suitable.
I think you mean 'C'. If you know Unix shell programming, Tcl comes easy. Perl remains excessively incoherent.
I've never been much of a C programmer, and have more experience with shell programming. Yet, Perl was quite easy for me, and I might say, I can code a thing or two in Perl.
What can you do in Perl that you cannot do in Python?
Nothing of course. Just like you cannot do anything in Python you can't do in Perl. Or VB for that matter - they're all Turing equivalent.
Overuse the characters %&@$ etc. that you hardly need to touch in Python, and
Pretend the tacked-on hack of an OO system is useful, as opposed to a real OO language like Python.
But you need far less parens in Perl, and because of the use of $ and friends, you can interpolate variables in strings, leading to less punctuation characters. In the end, it evens out. (Now, why doesn't anyone complain about English? All those comma's, periods, question marks, parens, etc, etc?)
As for the OO system in Perl, it sucks. But then, it's copied from Pythons.
There's one thing that makes it hard to learn Python, and that are the extremely cryptic error messages. Specially compared to Perls.
Now, why does anything remotely Perl related on Slashdot always ends up in Perl bashing? The topic here is the book "Mastering Algorithms in Perl", not "my favourite pet language is Python and Perl sucks".
If you'd like an online tutorial, you might want to check out The CGI Resource Index, which is made by the same guy as Matt's Script Archive.
That's worse than looking at Microsoft on how to design Operating Systems - at least Windows works for certain values of "work", which is more that you can say from Matts scripts. There are daily complaints in comp.lang.perl.misc about people having problems with his scripts.
Your intellectual property? You probably mean "your IP address". However, the programmers at Amazon.com aren't that stupid. They know that there are millions out there sharing a limited set of IP addresses (for instance, flocks of AOLers using a handful of proxies), and millions that select an IP address from a pool (dynamic IP allocation after dialing in).
Although cookies are far from perfect, they'll work fine for enough people to make it worthwhile for sites like amazon.com to use them. Cookies, in principle, uniquely identify a browser - or a browser/user combination on systems that have multiple users. That's often enough to uniquely determine a person, as most people only browse from one account, using one browser. One multiple user systems, unrelated people sharing an account is pretty rare (sure, there are public terminals, but they are relatively rare compared to the number of systems out there). On single user systems, there's usually a small set of people using that machine, who are often related as well. Like spouses. While sometimes a nuisance, cookie sharing doesn't cause a problem often enough for sites like amazon.com not using them.
BTW, I went to amazon.com and tried to order a book with just one mouse-click - but no dice, that's not possible.
What if during this project somebody figures out a clean power solution that eventually eliminates pollution?
That would be very nice. But what makes you think only a Mars mission could bring that result? Such side effects can come from other projects as well - what do you think can happen if you can spend $200 billion on research to eliminate pollution?
The problem I have with these kind of petitions is that they don't show anything. Sure, people want to have a nice expedition to Mars. But I'm sure that if you make a petition asking if people want lower gas prices, free health care, more mass transport, scolarships for everyone, and all potholes fixed, you get a lot of people signing as well.
The fact millions of people would like to see it happen isn't a surprise. In fact, not getting a million people to sign in just less than a year would be a major surprise. But the petition doesn't mention costs.
The petition would have made some impact if it said "It's ok to raise taxes the next 15 years", "I am willing to flip burgers instead of getting a scolarship", "I deal with traffic for the rest of my life instead highway improvement", "I don't think I will be old - I don't need care then", "I don't mind potholes" or "I won't upgrade my computer for the next 10 years - I invest in the Mars mission".
Even more impressive would be asking for a small contribution. Say, $100 dollars or so. Then, when the petition is presented, one can say "here are a million signatures, and a 100 million dollar cheque. It will barely get you away from Earth, and not bring you to Mars at all, but it's a start.
If you wanted to make an experiment of the affects of radiation on the growth of animals, would you want to have hundreds of fruit flies to test on, or would just 9 be enough?
You are suggesting that even if we use hundreds of fruit flies to test on, it would only show the effects of radiation applied by people wearing white lab coats, and it doesn't prove anything about radiation applied by people wearing pink lab coats.
There's neither any experimental, statistical or theoretical evidence that there's a correlation between stability of atoms and the planet you are on.
Unfortunately, but in what seems to have become a rather typical event on/., the posting here, and responses to it focus in on the first few lines of the article and does not examine the topic in any depth.
Worse, it's not just the posters, it's the moderators as well. The article you are referring to got positive moderation points.
However, changing from 32->64 bit will affect those as well (sizeof(everything) changes, etc). Why not shove in one additional change at the same time?
Because that's the *entire* problem. It's fine if you don't have existing data to consider, or synchronize with other computers. But as soon as you have existing data and communication channels, problems occur. If there wouldn't, we would have changed to 4-digit years a decade ago, and there wouldn't have been a Y2K issue. But switching from 2 digit years to 4 digit years, or from years since 1900 to years since 0 was never trivial on a large scale: existing data and synchronization make it a hard problem.
I gave the example of a file system. Recompiling your kernel such that time_t is now a 64 bit value doesn't magically update the bytes on disk. What happens is that as soon as you bring up the file system, the kernel tries to read 8 bytes - half of them containing bogus data. (And a file system is just an example - there are thousands of other cases which have the same problem)
Who are we to say that these things "CAN'T" exist when the only proof we have of what exists outside of our little solar system is what happens to come flying INTO our solar system?
There's no evidence that the laws of physics change when leaving our Solar system.
"By the time 2038 comes around, nobody will be using 32 bit CPUs".
Well, that didn't help us much for the Y2K problem, did it? Or are many people still running computers with do decimal arithmetic, and have punchcard interfaces?
You _do_ have the source to everything, right?
That doesn't solve a bit. Just switching from a 32 bit time_t value to a 64 bit one might be fine for applications that don't read or write time related data (either to file, or to another process), but it isn't so simple for everything else. Take for instance a file system, that somewhere reserves 4 bytes to write the last modification time of a file. Now you recompile your kernel, and suddenly have 8 byte time values. How are you going to fit those 8 bytes in the 4 allocated bytes? How are you going to communicate with computers that haven't upgraded yet?
Solaris 7 is a 64-bit OS. Sun's Ultra-5 is 64-bit hardware. Yet, time_t still is 32 bits, for good reasons. Somewhere on Sun's website there's a timeline for when Sun will migrate to a 64 bit set of time related functions and data structures. It will be years from now, and the process will take years as well. It's not at all simple. (After all, we couldn't "solve" the y2k problems by just going to 4 digit years either).
Slashdot Mirror
Nope, I'm not a professor. However, I used to have a research position at a university, and part of the job involved teaching.
Does it get easier than the bogus cs crud they make us do in high school?
That would be very doubtful. Universities don't tend to be easier than high schools. Far from that.
-- Abigail
Just the fact you only list two languages as "the alternatives" shows you've got a lot to learn.
Nobody in Python ever calls stupid getpwent functions and `whoami` and `uname` calls.
That's because of Python's superior OO-model, right?
I am so fucking tired of maintaining code written by an idiot.
Me too. Perhaps Perl is so simple even idiots can use, and Python is too difficult? I dunno. Writing maintainable code is more a matter of the person, than of the language. Granted, for huge projects lasting several years with hundreds of programmers of various capabilities whose average turn around time is less than the time sceduled for the project, Perl wouldn't be the right choice. Python would be a better choice, but there are even better choices than Python in that case: Eiffel for instance, and probably Ada. However, most projects aren't huge, but rather small. Perl in that case is often an excellent choice - and so is Python. Neither is better or worse.
What the hell is wrong with Perl that there is so much bad code? It's got to be the language.
Nah. There are more bad novels in English than there are in Navajo. That doesn't have anything to do with the language. Come back when there is as much Python code as there is Perl code - and we compare again.
They're in for a quick hack
I've never heard some argue before that coding in Python takes a long time.
Read the manpage my ass. Windows doesn't have manpages, you know.
Wrong, grasshopper. Any distribution of Perl comes with more than 1200 pages of documentation. For Unix, for Windows, for the Macintosh, for the Cray, for VOS, for VMS and for all those other systems Perl runs on. Windows might not have a man command, it does have man pages. Hence, to help out the poor people on Windows, there's a command distributed with Perl called perldoc Guess what it does? *drumroll* It displays the man pages. Isn't that neat? But, it has been recognized typing might be too difficult for Unix-haters, so the Activestate distribution of Perl also comes with aim-and-shoot man pages - they're converted to HTML. Now, if that's still not enough, there are also filters to translate the man pages to Postscript, TeX, PDF and other formats.
Python is much better because it doesn't have any manpages for you Unix bitches to yell at us about.
Not having man pages is a feature?
-- Abigail
Oh, I did. I'm not your average slashdotter who makes unfounded comments. I've bought and studied both "Learning Python" and "Programming Python", one of the reasons because it was said that Pythons OO was so good, and I'm fed up with Perls. I knew Perls OO was based on Pythons, so, it didn't come to me as a surprise that while Pythons OO is better (cause everywhere were Perl went different, it went wrong), it still looks to much like Perls.
Perl is really really really suboptimal as a language
For you perhaps, others think otherwise.
the thread was about an algorithmic book written for a "scripting" language
Uhm, the thread was about an algorithms book for Perl. The thread is about the book, not the language. Furthermore, what is your definition of a "scripting" language?
-- Abigail
Some parts of the book don't contain more than "if you want to do `foo', just call the function (or method) called `foo' in this package". I really, really don't need a book to state what I can find easily in a manual as well.
In the parts they do discuss algorithms, they often get side-tracked, by either explaining language features, or showing a trick that saves 0.5% of your execution time. The important things get burried in the details. It has been argued that having "real code" and not pseudo-code is a feature. In my opinion, this books makes an excellent argument in favour of pseudo-code. Pseudo code doesn't have to bother with language details, and people writing pseudo-code have to waste time wondering whether an alternative construct saves 1% of time. An algorithms book should focus on algorithms, not on the language.
If you want a bag of tricks, get Effective Perl Programming, if you want a bag of useful code snippets, get The Perl Cookbook, if you want to know modules, read their man pages, and if you want to learn algorithms, get a real algorithms book, like Cormen, Leierson, Rivest, Knuth's The Art of Computer Programming, or something from Wirth or Mehlhorn.
-- Abigail
Perhaps because he isn't employed as an author?
-- Abigail
Good for you. I've teached grad students from this book, and it's a very good textbook on algorithms and datastructures. I need to get myself a new copy as well - mine is falling apart.
-- Abigail
No, it's not. The halting problem isn't computable.
-- Abigail
NP-hard means "reduce to NP in polynomial-time".
NP-complete means "NP and NP-hard".
That would mean that NP-hard == N-complete, yet you write:
NP-complete and NP-hard are not synonymous.
-- Abigail
You're all wrong.
The set of NP problems consists of a set of problems in NP which are all P reducable to each other. Hence, if one problem of the set of NP-complete problems is found to be in P, they all are. NP-hard problems are "harder". One can P reduce an NP-complete problem to an NP-hard problem, but not the other way around. Hence, discovering that NP-complete == P doesn't solve the P ?= NP question; as it doesn't prove that the NP-hard problems are in P.
The classes *I* took used "NP-complete", "NP-hard" and "hard for NP" synonymously.
You should ask your money back.
-- Abigail
It's lack of memory management is one of the reasons C sucks as a first language. It makes the beginning programmer get lost in details better left to the computer; taking away his/her time from focussing on the problem. Perl as a first language sucks too, but for different reasons. Python, Java, LPC, Ada or something from the ML family are much more suitable.
-- Abigail
I've never been much of a C programmer, and have more experience with shell programming. Yet, Perl was quite easy for me, and I might say, I can code a thing or two in Perl.
What can you do in Perl that you cannot do in Python?
Nothing of course. Just like you cannot do anything in Python you can't do in Perl. Or VB for that matter - they're all Turing equivalent.
But you need far less parens in Perl, and because of the use of $ and friends, you can interpolate variables in strings, leading to less punctuation characters. In the end, it evens out. (Now, why doesn't anyone complain about English? All those comma's, periods, question marks, parens, etc, etc?)
As for the OO system in Perl, it sucks. But then, it's copied from Pythons.
There's one thing that makes it hard to learn Python, and that are the extremely cryptic error messages. Specially compared to Perls.
Now, why does anything remotely Perl related on Slashdot always ends up in Perl bashing? The topic here is the book "Mastering Algorithms in Perl", not "my favourite pet language is Python and Perl sucks".
-- Abigail
No, it's not. It's bad code, and because it's bad code, it's a very bad starting point.
-- Abigail
That's worse than looking at Microsoft on how to design Operating Systems - at least Windows works for certain values of "work", which is more that you can say from Matts scripts. There are daily complaints in comp.lang.perl.misc about people having problems with his scripts.
-- Abigail
Your intellectual property? You probably mean "your IP address". However, the programmers at Amazon.com aren't that stupid. They know that there are millions out there sharing a limited set of IP addresses (for instance, flocks of AOLers using a handful of proxies), and millions that select an IP address from a pool (dynamic IP allocation after dialing in).
Although cookies are far from perfect, they'll work fine for enough people to make it worthwhile for sites like amazon.com to use them. Cookies, in principle, uniquely identify a browser - or a browser/user combination on systems that have multiple users. That's often enough to uniquely determine a person, as most people only browse from one account, using one browser. One multiple user systems, unrelated people sharing an account is pretty rare (sure, there are public terminals, but they are relatively rare compared to the number of systems out there). On single user systems, there's usually a small set of people using that machine, who are often related as well. Like spouses. While sometimes a nuisance, cookie sharing doesn't cause a problem often enough for sites like amazon.com not using them.
BTW, I went to amazon.com and tried to order a book with just one mouse-click - but no dice, that's not possible.
-- Abigail
(Besides, do you really think they stay in budget, and won't go way over $20 billion?)
-- Abigail
I think lifting people off Earth with a higher rate than people are born is a far more difficult problem than deciding where to go.
-- Abigail
That would be very nice. But what makes you think only a Mars mission could bring that result? Such side effects can come from other projects as well - what do you think can happen if you can spend $200 billion on research to eliminate pollution?
-- Abigail
That would have learned us a lot more than sending exact replica's of the explorers of North America to Mars.
Mars isn't exactly the environment where you can roam around freely, live of the land, and communicate with the natives.
-- Abigail
The fact millions of people would like to see it happen isn't a surprise. In fact, not getting a million people to sign in just less than a year would be a major surprise. But the petition doesn't mention costs.
The petition would have made some impact if it said "It's ok to raise taxes the next 15 years", "I am willing to flip burgers instead of getting a scolarship", "I deal with traffic for the rest of my life instead highway improvement", "I don't think I will be old - I don't need care then", "I don't mind potholes" or "I won't upgrade my computer for the next 10 years - I invest in the Mars mission".
Even more impressive would be asking for a small contribution. Say, $100 dollars or so. Then, when the petition is presented, one can say "here are a million signatures, and a 100 million dollar cheque. It will barely get you away from Earth, and not bring you to Mars at all, but it's a start.
-- Abigail
You are suggesting that even if we use hundreds of fruit flies to test on, it would only show the effects of radiation applied by people wearing white lab coats, and it doesn't prove anything about radiation applied by people wearing pink lab coats.
There's neither any experimental, statistical or theoretical evidence that there's a correlation between stability of atoms and the planet you are on.
-- Abigail
Worse, it's not just the posters, it's the moderators as well. The article you are referring to got positive moderation points.
-- Abigail
Can't you read the article for some reason? The reasons are all explained.
Makes me wonder why you got a positive moderation point.
-- Abigail
Because that's the *entire* problem. It's fine if you don't have existing data to consider, or synchronize with other computers. But as soon as you have existing data and communication channels, problems occur. If there wouldn't, we would have changed to 4-digit years a decade ago, and there wouldn't have been a Y2K issue. But switching from 2 digit years to 4 digit years, or from years since 1900 to years since 0 was never trivial on a large scale: existing data and synchronization make it a hard problem.
I gave the example of a file system. Recompiling your kernel such that time_t is now a 64 bit value doesn't magically update the bytes on disk. What happens is that as soon as you bring up the file system, the kernel tries to read 8 bytes - half of them containing bogus data. (And a file system is just an example - there are thousands of other cases which have the same problem)
-- Abigail
There's no evidence that the laws of physics change when leaving our Solar system.
-- Abigail
Well, that didn't help us much for the Y2K problem, did it? Or are many people still running computers with do decimal arithmetic, and have punchcard interfaces?
You _do_ have the source to everything, right?
That doesn't solve a bit. Just switching from a 32 bit time_t value to a 64 bit one might be fine for applications that don't read or write time related data (either to file, or to another process), but it isn't so simple for everything else.
Take for instance a file system, that somewhere reserves 4 bytes to write the last modification time of a file. Now you recompile your kernel, and suddenly have 8 byte time values. How are you going to fit those 8 bytes in the 4 allocated bytes? How are you going to communicate with computers that haven't upgraded yet?
Solaris 7 is a 64-bit OS. Sun's Ultra-5 is 64-bit hardware. Yet, time_t still is 32 bits, for good reasons. Somewhere on Sun's website there's a timeline for when Sun will migrate to a 64 bit set of time related functions and data structures. It will be years from now, and the process will take years as well. It's not at all simple. (After all, we couldn't "solve" the y2k problems by just going to 4 digit years either).
-- Abigail