Re: python vs perl lines of code
on Friday, May 19, 2006 11:26 PM [EMAIL PROTECTED] wrote: | All I would ask is what objective evidence does either of actually | have? How can you know? What is a fair way to even count line | numbers? From there how do we begin to objectively measure software | quality? That's why this discussion interests me, and why I don't | understand why you are so adamant it doesn't work. I'll agree that I | have never seen line count/char count type data used for anything other | than marketing swill and kitty litter. Doesn't mean it can't be used. | But first things first... and this one I think is solvable - their has | got to be an equitable way to count how much code was written - maybe | it isn't lines maybe it is. In truth, since you are so opposed to the | idea, I'd be curious if you can think of a way to measure the quantity | of code objectively? ANd that's it - not can we make a qualitative | statement beyond that. But simply can we quanitfy the amount of code | in some fashion that allows a reasonable comparison? This is a difficult question - one way to measure - more or less objectively - is to somehow figure out how many machine instructions (on some standard machine - Turing?) would be generated by the code Even that won't tell us much - cos it will favour inline code as somehow heavier than looping code... Now we know that inline code is faster on most machines, and looping code is more compact, - so how to say what is best? And this only covers what you computer scientists call the procedures or methods - the actual instructions that are executed by the machine - how is the memory space used to be measured and factored in? - and the running stack space needed? - specially in the case of recursions And then how do you handle an interpreted language vs a compliled language - do you count the machine instructions of the interpreter, or only the ones actually executed? - and the memory consumed by the interpreter?. - And if you count the interpreter, why not the compiler?... Not simple, not easy - in fact it's a minefield - Hendrik van Rooyen -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
George Sakkis [EMAIL PROTECTED] wrote: John Bokma wrote: George Sakkis [EMAIL PROTECTED] wrote: [ Xah Lee ] [1] He is looking for another hoster btw. This must feel really empowering huh ? I am sure I've had quite some help. Also, you made quite a mistake. I have 0 power, I just reported what I saw: repeatedly cross posting to 5 groups for the sole purpose of trolling and spamvertizing a website. And I am afraid that 5 is a limit set by Google Groups, not by your kook buddy. Funny though, how you have a problem with a thread that side steps to Perl only for 4 or 5 postings, but have no problem with a hit run post in 5 groups to spamvertize a site. Have fun with the pondering btw. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Funny though, how you have a problem with a thread that side steps to Perl only for 4 or 5 postings, but have no problem with a hit run post in 5 groups to spamvertize a site. Have fun with the pondering btw. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html Oh, I think I get it now. Spamvertizing _one_ site is worth your host's subscription; doing it for _four_ sites at your signature is perfectly ok though. A rare case of irony deficit disorder I suppose. Have a nice day. George -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
George Sakkis [EMAIL PROTECTED] wrote: Oh, I think I get it now. Spamvertizing _one_ site is worth your host's subscription; doing it for _four_ sites at your signature is perfectly ok though. Do yourself and many others a favour before you post again, educate yourself on Usenet. It might stop you from making stupid remarks like the one you just made. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
A little out-of-order execution seems useful here. ;) John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: I can readily believe that the community frequenting the newsgroups, mailing lists, and blogs don't encourage it anymore. But that's a tiny fraction of all perl programmers, and most of them have no exposure to this little clique. Pfft, you are just guessing around now. How many organizations have you worked at? How much exposure to coders whose daily job description doesn't include the word programming? I've been at Fortune 100 companies with thousands of programmers and support staff, and at startups with a half dozen employees. I've been employed at 3 universities from small to huge. I know full-time software developers, software testers, sys admins, network admins, managers, web developers, graphic artists, physics researchers, bioinformatics researchers, instructors, librarians, consultants, contractors, hardware engineers, forensic analysts, and even a law professor. They all code perl to some degree. Many of them don't even know what a newsgroup is, and you can have their cookbook when you pry it from their cold dead hands. Guessing? Hardly. Just not trapped in your insular world of who makes up the perl community. Don't forget that most of the book was written around 1998. Yes, 8 years ago. Doesn't matter. Yes it matters. 8 years is a lot of time in IT. In 1998 Perl5.005 was announced (22 July). [1] Which should tell you a lot if you indeed have 3 years of Perl skills. Tell that to everyone who relies on the cookbook. It gets their job done. They don't care if it was written in the dark ages. Until a replacement comes along, that's what they'll use. Of course Perl itself has moved on, that's not the point. If they are serious with their study they know that a 8 year old book is hardly up to date. I tend to take most IT related books I use that are older then 3-4 years with quite a grain of salt. I am not going to take an 8 year old Java CookBook very seriously for example. Many/most people aren't serious with their study of perl. They just want to get things done. Perl 5 works for them now, it will work for them 10 years from now. Unless something significantly better comes along to justify the cost of switching, they'll stick with what they know. And that includes perl 6. One would hope an updated cookbook is out before then. Or maybe it's not needed because the current one works just fine. Time isn't a great measure of language change. A C++ book from 8-10 years ago is just as good as one today in most respects (maybe exceptions and templates are a bit underused). A C book from 20 years ago is perfectly fine for most purposes (how well does KR stand the test of time?). C99 and C++0x aren't revolutionary changes (ISO committees frown on such things). God only knows how far back useful LISP resources go. You can even find examples on my site that use imported functions (which I will fix, because I frown upon it :-) ). But I doubt you can find a majority in the perl community that *encourages* the use of imported functionality. I'm not arguing what best practices the hardcore community recommends. Many/most perl programmers aren't part of that community, their only exposure is the perl books (especially the cookbook), and they'll do whatever it says in there. Call perl a victim of its own success (a nice position to be in). For many people, whatever the cookbook says goes. If it's wrong, update it. Well, contact the authors or O'Reilly. Sorry, I've got a bad case of not my problem. ;) Seriously, are you using 8 year old Python recipes without thinking? Sure, if they do the job and an updated reference isn't handy. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: A little out-of-order execution seems useful here. ;) No, not interested in a pissing contest. Your statement that the Perl community encourages importing is *encouraged* (over using OO without importing) is false. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: A little out-of-order execution seems useful here. ;) No, not interested in a pissing contest. Your statement that the Perl community encourages importing is *encouraged* (over using OO without importing) is false. The cookbook says otherwise. So it depends how you define community. You lecturing people on pissing contests, that's rich. Nice way to duck the issue and sound like a winner. Wake me when you decide to address the substance of my arguments. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott wrote: John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: A little out-of-order execution seems useful here. ;) No, not interested in a pissing contest. Your statement that the Perl community encourages importing is *encouraged* (over using OO without importing) is false. The cookbook says otherwise. So it depends how you define community. You lecturing people on pissing contests, that's rich. Nice way to duck the issue and sound like a winner. Wake me when you decide to address the substance of my arguments. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net Not trying to be as ass, but can you take this offline or at least in a perl newsgroup ? Arguing on a particular fact or speculation about the perl community is rather unproductive and offtopic for a python newsgroup. Thanks, George -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott wrote: This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. I'm in the process of converting some old perl programs to python. These programs use some network code and do a lot of list/dict data processing. The old ones work fine but are a pain to extend. After two conversions, the python versions are noticeably shorter. The first program does some http retrieval, sort of a poor-man's wget with some extra features. In fact it could be written as a bash script with wget, but the extra processing would make it very messy. Here are the numbers on the two versions: Raw -Blanks -Comments lines chars lines chars lines chars mirror.py 16746321324597 1184009 mirror.pl 30958362115647 1844790 I've listed line and character counts for three forms. Raw is the source file as-is. -Blanks is the source with blank lines removed, including lines with just a brace. -Comments removes both blanks and comment lines. I think -Blanks is the better measure because comments are a function of code complexity, but either works. By the numbers, the python code appears roughly 60% as long by line and 80% as long by characters. The chars percentage being (higher relative to line count) doesn't surprise me since things like list comprehensions and explicit module calling produce lengthy but readable lines. I should point out this wasn't a straight line-for-line conversion, but the basic code structure is extremely similar. I did make a number of improvements in the Python version with stricter arg checks and better error handling, plus added a couple minor new features. The second program is an smtp outbound filtering proxy. Same categories as before: Raw -Blanks -Comments lines chars lines chars lines chars smtp-proxy.py 2617788 222 7749 205 6964 smtp-proxy.pl 96624110 66023469 45214869 The numbers here look much more impressive but it's not a fair comparison. I wasn't happy with any of the cpan libraries for smtp sending at the time so I rolled my own. That accounts for 150 raw lines of difference. Another 70 raw lines are logging functions that the python version does with the standard library. The new version performs the same algorithms and data manipulations as the original. I did do some major refactoring along the way, but it wasn't the sort that greatly reduces line count by eliminating redundancy; there is very little redundancy in either version. In any case, these factors alone don't account for the entire difference, even if you take 220 raw lines directly off the latter columns. The two versions were written about 5 years apart, all by me. At the time of each, I had about 3 years experience in the given language and would classify my skill level in it as midway between intermediate and advanced. IOW I'm very comfortable with the language and library reference docs (minus a few odd corners), but generally draw the line at mucking with interpreter internals like symbol tables. I'd like to here from others what their experience converting between perl and python is (either direction). I don't have the sense that either language is particularly better suited for my problem domain than the other, as they both handle network io and list/dict processing very well. What are the differences like in other domains? Do you attribute those differences to the language, the library, the programmer, or other factors? What are the consistent differences across space and time, if any? I'm interested in properties of the code itself, not performance. And just what is the question to the ultimate answer to life, the universe, and everything anyway? ;) Sorry, I don't buy this. I can write REALLY short programs that don't handle exceptions, don't provide for logging for debugging purposes, don't allow for future growth, etc. I find that 60% of my code has nothing to do with the actual algorithm or function I'm trying to accomplish. It has more to do with handling user's bad input, exceptions, recovering from hardware or communications failures, etc. Inexperienced programmers can write some pretty short programs that get the job done, but can't handle the real world. Also, many years ago I wrote a number of applications in APL. We often referred to programs written in APL as write only code because going back to read what you had written after-the-fact was very hard. You could write in one line of APL what takes 1000's of lines of C or even Python and it was pretty efficient also (for applications that needed to manipulate vectors or
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: You lecturing people on pissing contests, that's rich. Nice way to duck the issue and sound like a winner. Then you've missed what a discussion really is. It's not about winning, it's about learning. Sadly you missed that point. Wake me when you decide to address the substance of my arguments. I have done so. If you don't consider it enough and think that code in a book based on 8+ year old modules is the current state of Perl programming, fine with me. As a final word, I quote from chapter 12.10 of Learning Perl Objects, References, Modules [1]: As seen earlier, *the normal means* of using an object-oriented module is to call class methods and then methods against instances resulting from constructors of that class. This means that an OO module *typically exports nothing*, ... Which is in general recommended as the book one has to read after Learning Perl (IIRC it will be renamed in a next edition to reflect this). -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
George Sakkis [EMAIL PROTECTED] wrote: Not trying to be as ass, but can you take this offline or at least in a perl newsgroup ? Arguing on a particular fact or speculation about the perl community is rather unproductive and offtopic for a python newsgroup. Use a real Usenet client, and you can make it skip a thread. Like I said, I am not interested in a(n OT) pissing contest, but when people make silly statements like Edward did, I think its a good thing to point out that import is *not* encouraged by the Perl community. It has been used (abused IMO) a lot in the past, and yes, those modules are still around. But in general OO is perferred, except in those cases that import extends the language with for example constructs like try / catch or case etc. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
George Sakkis wrote: Not trying to be as ass, but can you take this offline or at least in a perl newsgroup ? Arguing on a particular fact or speculation about the perl community is rather unproductive and offtopic for a python newsgroup. No offense taken. It's definitely OT. I left it here because 1) comp.lang.python seems pretty lax about going OT when it's related to the thread, which in this case it was, and 2) the general discussion about what constitutes a community seemed kinda useful. That said, I definitely think the discussion has run its course. It's getting dangerously close to flaming at this point, which indicates it's time to go offline. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Larry Bates wrote: Sorry, I don't buy this. I can write REALLY short programs that don't handle exceptions, don't provide for logging for debugging purposes, don't allow for future growth, etc. I find that 60% of my code has nothing to do with the actual algorithm or function I'm trying to accomplish. It has more to do with handling user's bad input, exceptions, recovering from hardware or communications failures, etc. Wow, only 60%, I'm surprised it's that low :). When I say the algorithms are roughly equivalent, I'm including the amount of input verification and error checking that they do. To me, that's part of the algorithm. Inexperienced programmers can write some pretty short programs that get the job done, but can't handle the real world. Tell me about it. I've taught intro comp sci, things can get real ugly real quick. :) Also, many years ago I wrote a number of applications in APL. We often referred to programs written in APL as write only code because going back to read what you had written after-the-fact was very hard. You could write in one line of APL what takes 1000's of lines of C or even Python and it was pretty efficient also (for applications that needed to manipulate vectors or matrices). Of course. Comparing line counts between assembly and Prolog is pretty useless given the vast discrepancy in their expressive power. Perl and Python are roughly comparable in expressiveness, so it doesn't seem unreasonable to compare their line counts. It might not tell you much, there are undoubtedly better comparisons to make, but I don't think it's grossly unfair the way you suggest. I'm all ears if you have another metric I can test as easily. I understand what you are trying to say, but I can't support your conclusions as presented. What would those be? I tried hard not draw any conclusions. I just want to see how other people's data compares to mine. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: George Sakkis [EMAIL PROTECTED] wrote: Not trying to be as ass, but can you take this offline or at least in a perl newsgroup ? Arguing on a particular fact or speculation about the perl community is rather unproductive and offtopic for a python newsgroup. Use a real Usenet client, and you can make it skip a thread. That's funny, coming from the same guy that's been harassing Xah for OT posts. Oh, the irony. George -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
George Sakkis [EMAIL PROTECTED] wrote: John Bokma wrote: George Sakkis [EMAIL PROTECTED] wrote: Not trying to be as ass, but can you take this offline or at least in a perl newsgroup ? Arguing on a particular fact or speculation about the perl community is rather unproductive and offtopic for a python newsgroup. Use a real Usenet client, and you can make it skip a thread. That's funny, coming from the same guy that's been harassing Xah for OT posts. Oh, the irony. Xah was harassing 5 groups with a cross post without setting a follow-up to for the sole purpose of spamvertizing his website [1] repeatedly. If you are that clueless, don't post. [1] He is looking for another hoster btw. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: George Sakkis [EMAIL PROTECTED] wrote: John Bokma wrote: George Sakkis [EMAIL PROTECTED] wrote: Not trying to be as ass, but can you take this offline or at least in a perl newsgroup ? Arguing on a particular fact or speculation about the perl community is rather unproductive and offtopic for a python newsgroup. Use a real Usenet client, and you can make it skip a thread. That's funny, coming from the same guy that's been harassing Xah for OT posts. Oh, the irony. Xah was harassing 5 groups with a cross post without setting a follow-up to for the sole purpose of spamvertizing his website [1] repeatedly. And somehow this made all real usenet clients unable to skip his thread. If you are that clueless, don't post. I will seriously ponder upon this, rest assured. [1] He is looking for another hoster btw. This must feel really empowering huh ? George -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott wrote: For inquiries into real-world code, it's enough to believe that I'm not lying Yeah, well, this is the internet -- I've gotten emails trying to sell me ex-soviet rocket-launchers and child porn.* So I don't make assumptions about people without some kind of evidence. There *are* plenty of bad guys out there, so one learns both to have a thick skin and to rely on that which is reasonably proven, rather than making casual assumptions of good will. That'd be like leaving your car in downtown LA overnight with the doors unlocked. Cheers, Terry *In the same email, no less. This is of course an extreme example, but there are *loads* of merely irritating behaviors like trolling. -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Terry Hancock wrote: Edward Elliott wrote: For inquiries into real-world code, it's enough to believe that I'm not lying So I don't make assumptions about people without some kind of evidence. There *are* plenty of bad guys out there, so one learns both to have a thick skin and to rely on that which is reasonably proven, rather than making casual assumptions of good will. That'd be like leaving your car in downtown LA overnight with the doors unlocked. So lookup my post history in comp.lang.python on google groups. Do I behave like a scammer or troll? Have I wasted time posting in other threads just to build credibility and dupe everyone here? You make judgements about people in the real world all the time on significantly less information. If you really think I'm making all this up, feel free to ignore to me. Or reserve judgement until you have more data for comparison. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Quoting relevant material for response (was: Re: python vs perl lines of code)
OT, sort of, but... [EMAIL PROTECTED] wrote: If that quoting mechanism is available on the web interface and I haven't found it - I'd love to know how to use it. Click show options and THEN hit reply. It's a bit counterintuitive, but the entire message to which you reply is then shown. It is best to (as I've just done) erase the parts you aren't replying to. If you are replying to multiple selected parts of the message it is good form to indicate the gaps with ellipses (...). It's worth noting that this group predates Google by severalyears, that usenet predates it by well over a decade, and that Google is only one of several alternative ways of participating (though it is my own preference) and that its conventions have emerged for good reasons. see http://en.wikipedia.org/wiki/Usenet and http://en.wikipedia.org/Google_Groups mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But if a 1 person, using 1 language, with the same set of tools withing a 3 month period implements the same algo without bugs - I'll bet you the shorter one was theone written second. You might lose that bet very often. I see often that additional checks are added to algorithms to handle special cases overlooked, or documentation added because a co-worker had problems with the notation. I am not the one generalizing my statement. Adding the things above, does not count as implementing the same thing. It would implementing a new thing. And what you describe could be just be more bloat - not indicating quality. I rarely see my scripts shrink, they often grow. The only time they shrink is when I factor one or more modules out of it :-) The fact that you many ppl will state the shorter line count of rewrites is a sign of improving skill I disaprove if you want to make it a general rule. I have seen too many exceptions. Two points here. I have since the beginning stating a HYPOTHESIS - a theory. One which my experince leads me think MIGHT be true. I am much more interested in figuring out a way to validly compare line counts (a distinct challenge in itself) Then we might be able to test the hypothesis. Two -I am not trying to declare an absolute rule. Would I advocate someone think about line count when implementing? No. Do I think there might be some useful analysis of code that includes line count and char count - yes. Is it proven - no. So while far from conclusive, the fact that I find my code gets shorter the second time - and it is usually done more skillfully, it seems there is a correlation of some sort between lines of code and quality. Yup, and this is exactly what frightens me the whole time in this thread. People looking for quality rules based on line count. It's wrong. Please note my original hypothesis was maintainability - not quality! important important distinction - and one I may have muddles myself as I got drawn into the conversation. And what frightens me are people who are so dogmatically convinced becasue of their long 10 years of experience - that they know exactly what does and doesn't matter, and have no intellectual curiosity anymore. There are no objective tests for maintainability that I am aware of. So neither of us is arguing from a position of evidence - just experience. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: John Bokma wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But if a 1 person, using 1 language, with the same set of tools withing a 3 month period implements the same algo without bugs - I'll bet you the shorter one was theone written second. You might lose that bet very often. I see often that additional checks are added to algorithms to handle special cases overlooked, or documentation added because a co-worker had problems with the notation. I am not the one generalizing my statement. Adding the things above, does not count as implementing the same thing. It would implementing a new thing. And what you describe could be just be more bloat - not indicating quality. Yes, like the shorter version might be overlooking many real world situations and is naive code. As for generalization, if you bet that the shorter one is later written, that's to me a generalization. I agree that there is a change that after reexamining the code, and algorithm can be written shorter, but I have also seen algorithms refactored for better readability. Two points here. I have since the beginning stating a HYPOTHESIS - a theory. One which my experince leads me think MIGHT be true. Enough to bet on it ;-) Yup, and this is exactly what frightens me the whole time in this thread. People looking for quality rules based on line count. It's wrong. Please note my original hypothesis was maintainability - not quality! Aren't those closely related? important important distinction - and one I may have muddles myself as I got drawn into the conversation. And what frightens me are people who are so dogmatically convinced becasue of their long 10 years of experience - that they know exactly what does and doesn't matter, and have no intellectual curiosity anymore. There are no objective tests for maintainability that I am aware of. Because it depends a lot on the skill level of the maintainer. By just counting lines and characters you can't measure quality IMO. It's a naive way of measuring and it reminds me of the early days of search engines. And if you mistake understanding that it's not a good way to measure things as having no intellectual curiosity, you're again mistaken. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Yes, like the shorter version might be overlooking many real world situations and is naive code. As for generalization, if you bet that the shorter one is later written, that's to me a generalization. I agree that there is a change that after reexamining the code, and algorithm can be written shorter, but I have also seen algorithms refactored for better readability. All very good points - I need to be more specific. I've been working on some data analysis stuff etc, lately - so I'm often time just reimplementing a specific algo or library I've written. The actual program as a whole generaly does get larger. But I was really thinking about a handful of data manipulation or aggregation algo's that were functionaly fine - but I realized could be done better. Two points here. I have since the beginning stating a HYPOTHESIS - a theory. One which my experince leads me think MIGHT be true. Enough to bet on it ;-) I'm a gambling man, what can I say? Yup, and this is exactly what frightens me the whole time in this thread. People looking for quality rules based on line count. It's wrong. Please note my original hypothesis was maintainability - not quality! Aren't those closely related? Yep, but not the same thing. Maintainability is a subset of quality. important important distinction - and one I may have muddles myself as I got drawn into the conversation. And what frightens me are people who are so dogmatically convinced becasue of their long 10 years of experience - that they know exactly what does and doesn't matter, and have no intellectual curiosity anymore. There are no objective tests for maintainability that I am aware of. Because it depends a lot on the skill level of the maintainer. By just counting lines and characters you can't measure quality IMO. It's a naive way of measuring and it reminds me of the early days of search engines. And if you mistake understanding that it's not a good way to measure things as having no intellectual curiosity, you're again mistaken. All I would ask is what objective evidence does either of actually have? How can you know? What is a fair way to even count line numbers? From there how do we begin to objectively measure software quality? That's why this discussion interests me, and why I don't understand why you are so adamant it doesn't work. I'll agree that I have never seen line count/char count type data used for anything other than marketing swill and kitty litter. Doesn't mean it can't be used. But first things first... and this one I think is solvable - their has got to be an equitable way to count how much code was written - maybe it isn't lines maybe it is. In truth, since you are so opposed to the idea, I'd be curious if you can think of a way to measure the quantity of code objectively? ANd that's it - not can we make a qualitative statement beyond that. But simply can we quanitfy the amount of code in some fashion that allows a reasonable comparison? -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] wrote: But first things first... and this one I think is solvable - their has got to be an equitable way to count how much code was written - maybe it isn't lines maybe it is ANd that's it - not can we make a qualitative statement beyond that. But simply can we quanitfy the amount of code in some fashion that allows a reasonable comparison? Maybe a count of identifiers and keywords. Symbols like ()[];,. don't add much beyond where to parse the code. And even though operators like +-*/^| et al convey semantics, they need expressions to operate on, in which the identifiers are already counted. You could make a case either way but I'd leave them out for simplicity. The question is how to count explicit names like module.class.func; should that be 1 identifier or 3? Counting as 3 would reward things like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. I'm inclined to just count explicit names as 1. It's still a single object, and I'm not sure a.b.c is more work to process than just c anyway. If you don't care where c is, they're equivalent. If you do care, you've got to remember where the naked c lives, so it just shifts the work from the code to your brain. Then you've got problems with implicit variables/operations. Should perl's $_ be counted? What about python's copy-slice [:]? You can drive yourself crazy worrying about such things, so I'd just start with the simple case by ignoring them. This id-keyword count would appear to be related to how much information you must process to read through the code. Unfortunately you need a parser for each language to measure it. If anyone can provide such a beast, I'll gladly run it against my code. In the meantime, line/char counts are the best I've got. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: The question is how to count explicit names like module.class.func; should that be 1 identifier or 3? Counting as 3 would reward things like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: The question is how to count explicit names like module.class.func; should that be 1 identifier or 3? Counting as 3 would reward things like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. Well it's all over the Perl Cookbook. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: The question is how to count explicit names like module.class.func; should that be 1 identifier or 3? Counting as 3 would reward things like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. Well it's all over the Perl Cookbook. Yeah, sure, all over. Maybe check the book again. It is used in some examples, sure. And it even explains how it works. Don't forget that most of the book was written around 1998. Yes, 8 years ago. You can even find examples on my site that use imported functions (which I will fix, because I frown upon it :-) ). But I doubt you can find a majority in the perl community that *encourages* the use of imported functionality. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. Well it's all over the Perl Cookbook. Yeah, sure, all over. 125 occurences in 78 recipes. Sure looks like all over to me. Maybe check the book again. It is used in some examples, sure. And it even explains how it works. Yep, 125 times. In 78 recipes. Out of 105 total recipes with 'use'. I'd say a 3:1 ratio is pretty strong encouragement. Don't forget that most of the book was written around 1998. Yes, 8 years ago. Doesn't matter. It's still the standard example reference. People use it heavily. They don't magically know what parts are now deprecated. You can even find examples on my site that use imported functions (which I will fix, because I frown upon it :-) ). But I doubt you can find a majority in the perl community that *encourages* the use of imported functionality. I can readily believe that the community frequenting the newsgroups, mailing lists, and blogs don't encourage it anymore. But that's a tiny fraction of all perl programmers, and most of them have no exposure to this little clique. For many people, whatever the cookbook says goes. If it's wrong, update it. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: like from X import * which are generally frowned on in python while 'use MOD qw(id)' is encouraged in perl. Not by me, and I doubt it is in general. Well it's all over the Perl Cookbook. Yeah, sure, all over. 125 occurences in 78 recipes. Sure looks like all over to me. Maybe check the book again. It is used in some examples, sure. And it even explains how it works. Yep, 125 times. In 78 recipes. Out of 105 total recipes with 'use'. I'd say a 3:1 ratio is pretty strong encouragement. Don't forget that most of the book was written around 1998. Yes, 8 years ago. Doesn't matter. Yes it matters. 8 years is a lot of time in IT. In 1998 Perl5.005 was announced (22 July). [1] Which should tell you a lot if you indeed have 3 years of Perl skills. It's still the standard example reference. People use it heavily. They don't magically know what parts are now deprecated. If they are serious with their study they know that a 8 year old book is hardly up to date. I tend to take most IT related books I use that are older then 3-4 years with quite a grain of salt. I am not going to take an 8 year old Java CookBook very seriously for example. You can even find examples on my site that use imported functions (which I will fix, because I frown upon it :-) ). But I doubt you can find a majority in the perl community that *encourages* the use of imported functionality. I can readily believe that the community frequenting the newsgroups, mailing lists, and blogs don't encourage it anymore. But that's a tiny fraction of all perl programmers, and most of them have no exposure to this little clique. Pfft, you are just guessing around now. For many people, whatever the cookbook says goes. If it's wrong, update it. Well, contact the authors or O'Reilly. Seriously, are you using 8 year old Python recipes without thinking? [1] http://history.perl.org/PerlTimeline.html -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Sorry, data about reports about X *is* data about X unless you believe the reports are uninfluenced by X. Like any proxy measure, it introduces noise and uncertainty, but it is still data. I can't imagine a motivation for Edward to make this up, so I accept his anecdotes as data. While it is possible to imagine developing a lab experiment to compare the terseness of Python and Perl, it is unlikely that funding is or should be available for the effort. This doesn't make it an uninteresting question. Is the widely held belief that real-world Perl is terser than real-world Python true? So far we have only the two reports from Edward. Still anyone programming in the dynamic languages world would acknowledge that they are quite striking and provocative. I don't see the purpose of this controversy, but it reminds me of some rather cynical attacks on climate science, and I don't like it at all. We don't always have the luxury of vast data of impeccable quality, but we still need to make judgements about the world. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
I am trying to understand why Edwards post generated such a negative response. I am neither agreeing or disagreeing with his statement - because I don't think he is making one. He posted a data point, and asked others to post the samething. About the only thing he could say, is that for his coding style, Python appears to be more terse. He went out of his way to describe mitigating factors and didn't draw any general conclusions. It seems to me the discussion could actually be beneficial. If several different coders gave similar responses, ie code line/character count comparisons, we might be able to see if there is a trend of any sort - the more anecdotes given and we start to have trends - or maybe we don't. The UFO comparison is silly, UFO sightings being based on time and space coordinates are inherently unreviewable. Ed's code and his analysis methods can be repeated (didn't say they were repeated, just they can be). Perhaps some ppl who switched from python to perl could do something similar, reversing the skill bias Edward admitted too? If we wanted to pursue more study of the phenomenon we could choose some stylistic rules about perl and python for test code, etc to help normalize the data. Lastly, Ed - can you post the code? That may be putting your head in the lion's mouth so to speak and make the whole thread even worse - and your coding style will get shredded by perl advocates... ok nevermind don't post it.' Ok I'm going to end with a flamebait - but I would posit, ALL OTHER THINGS BEING EQUAL - that a smaller number of characters and lines in code is more maintainable than larger number of characters and lines in the code. duck -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It seems to me the discussion could actually be beneficial. If several different coders gave similar responses, ie code line/character count comparisons, we might be able to see if there is a trend of any sort - the more anecdotes given and we start to have trends - or maybe we don't. What's the point? So you can say: Perl code has on average 1.727 more lines compared to Python? What's the point, both are tools. People who use both Perl and Python pick one to solve a problem because they want to pick what they believe is the right tool. I doubt that the number of lines is often on their mind. People who just know either Perl or Python don't care much about such figures, or so I hope. Lastly, Ed - can you post the code? That may be putting your head in the lion's mouth so to speak and make the whole thread even worse - and your coding style will get shredded by perl advocates... ok nevermind don't post it.' And not by Python advocates? Ok I'm going to end with a flamebait - but I would posit, ALL OTHER THINGS BEING EQUAL - that a smaller number of characters and lines in code is more maintainable than larger number of characters and lines in the code. And I think that's why a lot of people posted very negative, in the hope that people would not be tempted to make the above very dumb statement. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: The UFO comparison is silly, UFO sightings being based on time and space coordinates are inherently unreviewable. Ed's code and his analysis methods can be repeated (didn't say they were repeated, just they can be). Until we get the code to examine independently, all we have is an anecdote. Thus the comparison to UFO sightings. -- \Madness is rare in individuals, but in groups, parties, | `\ nations and ages it is the rule. -- Friedrich Nietzsche | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
THe interest, on my part, is more academic than practical. I find data, particularly dirty data very fascinating, and I like trying to find ways to make useful statements when all you have is bad data. Maybe a pipe-dream, but it's still fun to try. So this little exercise would be quite enjoyable - a horribly dirty data set that nobody thinks could be useful. The good guys always fall for the bad data!! At an architectural or even development management perspective - there is always someone, somewhere who wants to evaluate developer efficiency or something similarly vague concept for which there aren't good tools for evaluation. Let's face it in the corp world these kind of figures are sometimes percieved to have value. SO if I were a corp programmer in python and a manager says to me my output is way behind the perl guys - I could pull this silly fact and well you see. My quick comment about his code being torn apart by perl advocates was mainly because his post seems to be complimentary to python - but your right both sides would tear him apart. ANd you took the flame bait so I'll respond :D Perhaps - ALL OTHER THINGS BEINGS EQUAL - should better be read as WRITTEN BY ME!! For the most part I have found it easier to maintain the shorter programs I have written and found it more time consuming to maintain longer programs. Really what's so dumb about this? Have you found, as a general trend you spend more time maintaining your shorter programs? I did say it was flame bait, and I never said the statement is useful - all other things are never equal in the real world. I am constantly amused by how we, as programmers, spend so much time quantifying everything else, react so negatively when anyone suggests quantitative analysis of code for anything except execution time. Course what interests me now - is how could we prove if my statement was in fact very very dumb or not? In all honesty I don't know, but it sure tastes good grilled. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Until we get the code to examine independently, all we have is an anecdote. Thus the comparison to UFO sightings. touche! Ed post the code, please - it'll be fun. We won't hurt you. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It seems to me the discussion could actually be beneficial. If several different coders gave similar responses, ie code line/character count comparisons, we might be able to see if there is a trend of any sort - the more anecdotes given and we start to have trends - or maybe we don't. What's the point? So you can say: Perl code has on average 1.727 more lines compared to Python? That's more than we know right now. You never know what data will reveal until you collect and analyze it. BTW I'm not limiting this discussion to lines of code. That was simply the most convenient metric available. If people have other metrics to consider, by all means post them. What's the point, both are tools. People who use both Perl and Python pick one to solve a problem because they want to pick what they believe is the right tool. I doubt that the number of lines is often on their mind. What's the point in learning trigonometry? People who survey land just want to mark off boundaries, not solve a bunch of equations. The Pythagoreans built a religious cult on the study of geometric figures. They didn't know or care that their discoveries would be useful in engineering and science. More knowledge = more choice = better tools. When all you have is a hammer, everything looks like a nail. It's as simple as that. If you're happy playing with your hammers, fine. Go away and post in some other thread. People who just know either Perl or Python don't care much about such figures, or so I hope. I don't know Ruby, but if you could show me it produced significantly shorter code with comparable readability to Python, I'd certainly look into it. Lastly, Ed - can you post the code? That may be putting your head in the lion's mouth so to speak and make the whole thread even worse - and your coding style will get shredded by perl advocates... ok nevermind don't post it.' And not by Python advocates? I don't care who rips my code to what. I haven't posted code because people will dissect it to death and lose sight of the big picture. Code can always be improved, it's a question of resources. The point is not what could be done better in my code, but what was done with my skill and my time committment, and what others have done with their skill and their time committment. At some point I may post small snippets of each so others can gauge my style and experience, but I'm afraid it will devolve into a code crtitiquing fest. Ok I'm going to end with a flamebait - but I would posit, ALL OTHER THINGS BEING EQUAL - that a smaller number of characters and lines in code is more maintainable than larger number of characters and lines in the code. And I think that's why a lot of people posted very negative, in the hope that people would not be tempted to make the above very dumb statement. That's not a dumb statement, it's a sensible and testable hypothesis. The more people post their own experiences, the more patterns emerge and testable hypotheses form, which can then be confirmed or debunked with further study. The journey of 1000 miles starts with a single step, etc, etc. Didn't your mother ever tell you how science works? It's not all bunsen burners and test tubes. To everyone who thinks this thread is pointless or a bad idea: please just go away. Your objections have been noted, at this point you're not contributing anything to the discussion. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Thank you Ed for your eloquent statement. From now on I will avoid humor in posts on this thread , my previous attempts were not useful or productive - and I think there is something interesting in this discussion. It might be interesting to come up with a coding assignment for developers to attempt in both perl and python. Ask the developers to submit such items as length of time coding in each language, which they think is their stronger language, age, level of formal education in computer science and related, number of years programming all together, country of origni, Operating System perference, etc. Then perform analysis on the code an attempt to normalize for the above factors. In addtion to line/char counts we could look at execution time, memory consumption, number of detected bugs. Of course this means getting a bunch of developers interested in the task - and the words of Andrew Tannenbaum come to mind. But it would still be interesting - perhaps nothing could be proven - but that in itself might be useful. Physical beauty in humans is an area where some quantitifiable analysis can be performed (referring to a strong correlation between symmetry and percieved beauty). Beauty in poetry - to the best of my knowledge - has never been shown itself to be subject to quantitative analysis. Sometimes knowing what doesn't work - and proving it doesn't work - can be very useful. Don't believe me? Thgis is a bad example, but look at hidden variables theorems in quantum physics. Back the 40's Turing provided (a flawed) proof that no hidden variables theory could explain the quantum effects witnessed. Hence no viable hidden variable theories were even posited and this area of research nearly died out. It has had a slight resurgance, after Turing's proof was found to relate to specific subset of hidden variable theorems, rather than a truly generic proof. But I think it illustrates the value of proving a negative. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ok I'm going to end with a flamebait - but I would posit, ALL OTHER THINGS BEING EQUAL - that a smaller number of characters and lines in code is more maintainable than larger number of characters and lines in the code. And I think that's why a lot of people posted very negative, in the hope that people would not be tempted to make the above very dumb statement. Since it's too late to avoid such temptation, could you explain why you are willing to go so far as to call that statement very dumb? I, for one, consider it rather wise. When I am teaching programming, or advocating Python, I generally try to include the following advice, attributed to A. de St.-Exupery: La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever. The relevant corrolary is, he programs best who programs least. I would have thought this was conventional wisdom among all dynamic language communities. Isn't that the whole point? By all means go back to C++ if you like to have three lines for each idea instead of the other way around. However, since I habitually make such a fuss about this, I'd hate to be wrong. Please do explain why you think this idea that terseness is a virtue is foolish. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: THe interest, on my part, is more academic than practical. I find data, particularly dirty data very fascinating Me less, maybe that's why I originally had gg kill filed... I prefer quotes. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: John Bokma wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It seems to me the discussion could actually be beneficial. If several different coders gave similar responses, ie code line/character count comparisons, we might be able to see if there is a trend of any sort - the more anecdotes given and we start to have trends - or maybe we don't. What's the point? So you can say: Perl code has on average 1.727 more lines compared to Python? That's more than we know right now. You never know what data will reveal until you collect and analyze it. 1.727 is meaningless. It says nothing about your code, nor mine. BTW I'm not limiting this discussion to lines of code. That was simply the most convenient metric available. If people have other metrics to consider, by all means post them. The number $ characters per square furlong. More knowledge = more choice = better tools. When all you have is a hammer, everything looks like a nail. It's as simple as that. If you're happy playing with your hammers, fine. Go away and post in some other thread. At least I am not as silly to claim that hammer A is better then hammer B because the handle of hammer A came from an oak tree that had a owl hooting 13 times at the full moon 7 times a year. People who just know either Perl or Python don't care much about such figures, or so I hope. I don't know Ruby, but if you could show me it produced significantly shorter code with comparable readability to Python, I'd certainly look into it. Yeah, I could have guessed that. [ .. ] Code can always be improved, it's a question of resources. The point is not what could be done better in my code, but what was done with my skill and my time committment, and what others have done with their skill and their time committment. If we have no way to see your skills, there is not really a point. At some point I may post small snippets of each so others can gauge my style and experience, but I'm afraid it will devolve into a code crtitiquing fest. At least people can learn from that. If you don't understand that everbody has his/her own coding style, you have a lot to learn. Ok I'm going to end with a flamebait - but I would posit, ALL OTHER THINGS BEING EQUAL - that a smaller number of characters and lines in code is more maintainable than larger number of characters and lines in the code. And I think that's why a lot of people posted very negative, in the hope that people would not be tempted to make the above very dumb statement. That's not a dumb statement, it's a sensible and testable hypothesis. So you *do* still have a lot to learn. Isn't one Xah Lee enough? step, etc, etc. Didn't your mother ever tell you how science works? It's not all bunsen burners and test tubes. Nor is it: I have have examined some random samples of which I give only a vague description. Now get your own random samples, and lets talk science. To everyone who thinks this thread is pointless or a bad idea: please just go away. Your objections have been noted, at this point you're not contributing anything to the discussion. Welcome to Usenet. How it really works can be seen by having a peek at the archives. Since you love science, you'll will find the answer very fast. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Michael Tobis [EMAIL PROTECTED] wrote: The relevant corrolary is, he programs best who programs least. I would have thought this was conventional wisdom among all dynamic language communities. Isn't that the whole point? By all means go back to C++ if you like to have three lines for each idea instead of the other way around. You disagree: go back. A true zealot. Programming is about writing down ideas in a *clear* and *consistent way*, so that not only the original author is able to read and understand it after 3 months, but also peers. According to your silly rule the shortest book on a subject would be the best. Now why is that false? Why are Perl golf scripts so hard to understand? -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: Until we get the code to examine independently, all we have is an anecdote. Thus the comparison to UFO sightings. Except UFO sightings comprise a large body of data containing a vast number of known false reports and others that appear to be in the same vein with no verified positives despite many concerted efforts to produce such evidence. Here we have a single data point with no positive or negative corroborations. It's like a guy saying he saw a cloud that looks like a python. The cloud's gone now, but other people can watch other clouds and report what they see. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: Until we get the code to examine independently, all we have is an anecdote. Thus the comparison to UFO sightings. Except UFO sightings comprise a large body of data containing a vast number of known false reports and others that appear to be in the same vein with no verified positives despite many concerted efforts to produce such evidence. Here we have a single data point with no positive or negative corroborations. It's like a guy saying he saw a cloud that looks like a python. The cloud's gone now, but other people can watch other clouds and report what they see. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John, Your hilarious... I mean it, and as a compliment. But seriously, I think your taking a discussion about trends and twisting them to be about absolutes. Maybe others are too. But, forgive the cheesy paraphrasing, but the solution should be as simple as possible, and no simpler. There is no real problem with choosing a set of coding principals and sticking with them. Honestly, I don't think there currently exists a good method of comparing true software quality. So most discussion on which coding principals are actually useful, is kinda like talkin to miss Cleo. Still there is some value in seeing how closely software can align with certain principals. Right now we are asking questions about terseness. The obvious follow up is what relation does terseness have to quality? We are in a better postition to answer the second question if we know the first. When our preconceived notions cause us to study something, they should be encouraged. When our preconceived notions cause us to say, forget it, a waste of time, we should question them. I don't think anyone in this discussion has shown themselves to be a zealot. For the most part we've just been asking questions. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: corroborations. It's like a guy saying he saw a cloud that looks like a python. The cloud's gone now, but other people can watch other clouds and report what they see. Good comparison, now does the cloud gazing make them better programmers? -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
According to your silly rule the shortest book on a subject would be the best. Now why is that false? No, according to the rule, the shorter of two books **containing the same information** would be best. I don't think I'm a zealot. The original quote said all else equal. Certainly legible code is better than, hence not equal to, illegible code. I would say that having played Python golf once, the complexity of the competitive keystroke-minimizing code is much higher than the complexity of the equivalent sane, readable, maintainable code. (Actually, it also turns out to involve a good deal of coding that isn't in the final source, but let's not go there.) The point is I did NOT say he programs best who *types* least, and I don't believe that. In fact, that's what makes the comparison interesting. I had always thought that Pythonistas type more than Perlists, though I prefer Python anyway. The presumption was based on the fact that Perl (as language and culture) takes delight in saving keystrokes at the expense of clarity ($_ and all that) while Python makes no special effort in that direction. If real world Python code is substantially more terse *despite* this cultural difference, it is a fact worthy of some note. Let me add my voice to those clamoring for Edward to release his code while I'm here, though. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: John, Your hilarious... If you learn to quote, you don't need to address me. But it's beyond you I understand, so bye. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Michael Tobis [EMAIL PROTECTED] wrote: According to your silly rule the shortest book on a subject would be the best. Now why is that false? No, according to the rule, the shorter of two books **containing the same information** would be best. What is the same information? In fact, that's what makes the comparison interesting. I had always thought that Pythonistas type more than Perlists, though I prefer Python anyway. The presumption was based on the fact that Perl (as language and culture) takes delight in saving keystrokes at the expense of clarity ($_ and all that) Then you're very mistaken about the Perl culture, or you consider a small group *the* Perl culture, which is also a mistake IMNSHO. I have never see someone recommend unclear Perl code over clear code, except in golf. But we're not talking about golf here. while Python makes no special effort in that direction. Nor does Perl. That one can do something doesn't mean one has to do it. If real world Python code is substantially more terse *despite* this cultural difference, it is a fact worthy of some note. Maybe you got the Perl culture wrong. I think you do. Let me add my voice to those clamoring for Edward to release his code while I'm here, though. Yup, I agree on that. Since I am learning Python (well, I read Dive into Python, and the Python documentation), and have quite some Perl experience, I am curious. Yes, I might comment on the Perl code, but isn't the goal to learn? -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Michael Tobis wrote: John Bokma wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ok I'm going to end with a flamebait - but I would posit, ALL OTHER THINGS BEING EQUAL - that a smaller number of characters and lines in code is more maintainable than larger number of characters and lines in the code. And I think that's why a lot of people posted very negative, in the hope that people would not be tempted to make the above very dumb statement. Since it's too late to avoid such temptation, could you explain why you are willing to go so far as to call that statement very dumb? The problem with the idea is that simplicity is not quite equal to a smaller number of characters. For example, of each of the following pairs, which is clearer: lslist cpcopy mvmove Or to ask it another way, Which is easier to *read*? Although I have long since come to take the former spellings for granted, and they are undeniably shorter, the latter would've actually been easier for people to remember. The insistence of using the longer, more mnemonic form is a major characteristic of Python. The wisdom behind this is that Python's design takes into account the observation that source code is read many times more than it is written. To do this, it sacrifices some brevity compared to other languages (the classic example being Perl which uses lots of arcane symbols and tends to use shorter, more Unix-like naming). However, this turns out to be a big win, in that you don't waste so much time trying to remember abbreviated names. There are, for example several ways of abbreviating a word like quantity: q Q quant qtty quanty qnty Qtty QNT etc. But there's only one standard spelling. If I only have to remember that Python prefers to use the standard spelling as a rule of thumb, then I will usually get the right answer (there are still significant exceptions such as dict instead of dictionary and def instead of define -- but they are fewer than in most languages). Anyway, since humans tend to parse whole words as symbols when reading, rather than individual characters, the choice between using symbols or abbreviations versus whole standard-form words is not believed to matter (I think it would be a strong claim to say that this is proven, but it does seem likely to me). Frankly, even when typing, I find it slightly easier to type unmount than umount -- I always pause after the u to remember the funky Unix spelling. It's only a split-second delay, but those things add up, and each one represents a possible bug, if the output is source code. Even dictionary is hardly different from dict -- I've already learned to type common English morphemes without thinking about the process, so it just doesn't make any difference from my PoV. That's why I always find the hoops people will jump through to avoid typing a couple of extra keystrokes to be silly (are they typing with their noses?* ;-) ). It would frankly be harder for me to remember the extra mechanics than to just type the extra letters. The claim is ironic -- even counter-intuitive -- considering this conventional lore. But the real point is that no one here can make any reasonably objective assessment of whether your data is meaningful unless you post examples. That's what creates the hostility, I think. Cheers, Terry *With apologies to anyone who's actually using assistive tech to type their code -- but I'm sure you already know how to use macros to get what you want typed. -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Terry Hancock wrote: But the real point is that no one here can make any reasonably objective assessment of whether your data is meaningful unless you post examples. That's what creates the hostility, I think. Fair enough. But see my other posts on why I'm not interested in objective assessments of my code. For inquiries into real-world code, it's enough to believe that I'm not lying, e.g. that I have the programs and ran the tests described. The actual file contents are almost irrelevant. Nothing one can say about my code tells us anything about typical code in the wild. Producing more data points _will_ tell us that. If my data are an outlier, they may be worthless anyway. That's what I'm interested in. Others are interested in analyzing my code. Which is fine, it's just not what I'm after. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Hmm, and I thought it was respectful to actually address someone you are talking to. Must every statement be a reaction to a quotable comment? In any case, I realize I was completley wrong. Please allow me to retract my statement. -- http://mail.python.org/mailman/listinfo/python-list
Quoting relevant material for response (was: Re: python vs perl lines of code)
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Hmm, and I thought it was respectful to actually address someone you are talking to. On Usenet, it's respectful to all readers if you give a short quoted passage from the message you're responding to, so we can follow the discussion with context. gmail allows you to do this. You have the option to edit a quoted version of the message, removing the parts irrelevant to your response, and putting your response following each relevant part. Must every statement be a reaction to a quotable comment? Not necessarily. But if you're only making new statements, you should compose your message as a new topic, instead of as a reply to an existing message. In any case, I realize I was completley wrong. Please allow me to retract my statement. It's hard to see what that is, since you don't provide any context. Are we expected to re-read the entire thread to guess what you're referring to? -- \ Not using Microsoft products is like being a non-smoker 40 or | `\50 years ago: You can choose not to smoke, yourself, but it's | _o__)hard to avoid second-hand smoke. -- Michael Tiemann | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
As a coder, I wouldn't normally use the two different conventions. you show in your examples. So it does little to tell us about the importance or lack there of line count. Let me state clearly - to use line count , in absence of other considerations, IS meaningless. But if a 1 person, using 1 language, with the same set of tools withing a 3 month period implements the same algo without bugs - I'll bet you the shorter one was theone written second. The fact that you many ppl will state the shorter line count of rewrites is a sign of improving skill I think actually presents some anecdotal evidence that there is some truth that shorter code is better code. My skill level increases a lot faster than my coding style changes over time. So while far from conclusive, the fact that I find my code gets shorter the second time - and it is usually done more skillfully, it seems there is a correlation of some sort between lines of code and quality. -- http://mail.python.org/mailman/listinfo/python-list
Re: Quoting relevant material for response (was: Re: python vs perl lines of code)
Thanks Ben, I actually don't spend a whole lot of time on newsgroups. I don't use my gmail account and use the groups thru the web interface. If that quoting mechanism is available on the web interface and I haven't found it - I'd love to know how to use it. Also i use the threaded view on the web client, so I have little trouble figuring out what is being referenced. My comment about John being funny in fact was a generic comment, and while the remainder of my response was on topic - it still was not in response to 1 specific statement or another. Quoting previous comments is useful, but not required to be in thread - IMHO. In any case, I realize I was completley wrong. Please allow me to retract my statement. It's hard to see what that is, since you don't provide any context. Are we expected to re-read the entire thread to guess what you're referring to? Secondly, I meant I was wrong about John being hilarious - and in that context the quotes would have been useful. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: Terry Hancock wrote: But the real point is that no one here can make any reasonably objective assessment of whether your data is meaningful unless you post examples. That's what creates the hostility, I think. Fair enough. But see my other posts on why I'm not interested in objective assessments of my code. For inquiries into real-world code, it's enough to believe that I'm not lying, e.g. that I have the programs and ran the tests described. The actual file contents are almost irrelevant. Nothing one can say about my code tells us anything about typical code in the wild. Producing more data points _will_ tell us that. If my data are an outlier, they may be worthless anyway. That's what I'm interested in. Others are interested in analyzing my code. Which is fine, it's just not what I'm after. In that case I think it's safe to say that a majority of Perl code out in the wild is extrememly badly coded. Just download 10 free Perl CGI scripts to see my point. I wouldn't be amazed if this is not the case for Python, or at least way less. But be very carefull to draw any conclusion out of this :-D. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Quoting relevant material for response (was: Re: python vs perl lines of code)
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: quoting mechanism is available on the web interface and I haven't found it - I'd love to know how to use it. http://groups.google.com/support/bin/answer.py?answer=14213 Also i use the threaded view on the web client, so I have little trouble figuring out what is being referenced. I mark messages as read when I have read them, so without a context I have no idea what Joh, I disagree (for example) is about, especially since I don't just post one message a day. Also, due to how Usenet works, not everybody sees the messages in the same order as you do, or might even miss out a message or two (or several). Finally, since Google provides a search engine for Usenet, it might be perfectly possible that your reply without a quote is the first result in such a search. I always recommend to write your reply in such a way that when you print it, and read it 3 months later you're able to understand the message when you read it top down. My comment about John being funny in fact was a generic comment, and while the remainder of my response was on topic - it still was not in response to 1 specific statement or another. Quoting previous comments is useful, but not required to be in thread - IMHO. True, but if it's not a reply to the previous person, then you might want to start a new thread, or you're replying to the wrong person. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But if a 1 person, using 1 language, with the same set of tools withing a 3 month period implements the same algo without bugs - I'll bet you the shorter one was theone written second. You might lose that bet very often. I see often that additional checks are added to algorithms to handle special cases overlooked, or documentation added because a co-worker had problems with the notation. I rarely see my scripts shrink, they often grow. The only time they shrink is when I factor one or more modules out of it :-) The fact that you many ppl will state the shorter line count of rewrites is a sign of improving skill I disaprove if you want to make it a general rule. I have seen too many exceptions. My skill level increases a lot faster than my coding style changes over time. After 10 years that will change the other way around I guess. At least that's my experience. So while far from conclusive, the fact that I find my code gets shorter the second time - and it is usually done more skillfully, it seems there is a correlation of some sort between lines of code and quality. Yup, and this is exactly what frightens me the whole time in this thread. People looking for quality rules based on line count. It's wrong. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Hi Edward
Raw -Blanks -Comments
lines chars lines chars lines chars
mirror.py 16746321324597 1184009
mirror.pl 30958362115647 1844790
Maybe somebody would change his style
and had a lot of such statements before:
if ( something )
{
do_something()
}
which can be expressed in one
line:
do_something() if ( /something/ );
This has a 1:4 line count then.
Or, somebody used identifier like:
sub GetTheseSamplesHereOut {
...
...
}
and later:
sub SampleExtract {
...
...
}
and saved ~40% characters.
You got my point? ;-)
Regards
M. Wahab
--
http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. Without seeing the actual code this is quite meaningless. Evaluating my experiences yes, relating your own no. What would the point be? Most important to me would be: am I happy with the result? And that rarely has to do with the number of lines of actual code or the programming language. A language is just a tool. -- John Bokma Freelance software developer Experienced Perl programmer: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Mirco Wahab wrote: Maybe somebody would change his style and had a lot of such statements before: which can be expressed in one line: This has a 1:4 line count then. Or, somebody used identifier like: and later: and saved ~40% characters. You got my point? ;-) Hey I completely agree that line counts leave out a lot of information. Measures of the code like complexity, readability, work performed, etc hinge on many more important factors. I don't pretend that lines of code represents any indication of inherent superiority or fitness. But line counts do convey some information. Even if it's only how many lines a particular programmer used to convey his ideas. Real-world and average-case data are more compelling than theoretical limits on how compact code can be. Besides compactness isn't the point, communication is. Maybe line count is a good rough first-cut approximation of that. Maybe it's not. Probably it's both, depending on the case. Talking about the numbers can only shed light on how to interpret them, which as always is 'very carefully'. I'm not saying lines of code necessarily reflects anything else. All I'm saying is, I noticed some properties of my code. I'd like to know what objective properties others have noticed about their code. This is not meant to be a comparison of languages or programming technique, just a sampling of collective wisdom. That always has value, even when it's wrong. By the looks of it, this group is uninterested in the discussion. Which is fine. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: Evaluating my experiences yes, relating your own no. What would the point be? Most important to me would be: am I happy with the result? And that rarely has to do with the number of lines of actual code or the programming language. A language is just a tool. The point is knowing how to pick the right tool for the right job. Anecdotes aren't the answer but they can be the beginning of the question. Besides, whatever happened to pursuing knowledge for its own sake? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
In article [EMAIL PROTECTED], Edward Elliott [EMAIL PROTECTED] wrote: Fair enough, but advocacy isn't at all what I'm after. Anecdotes are fine, after all what is data but a collection of anecdotes? :) The plural of anecdote is not data. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I saw `cout' being shifted Hello world times to the left and stopped right there. --Steve Gonedes -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
It probably says something about your coding style, particularly in perl. I've found (anecdotally of course) that while perl is potentially the more economical language, writing *legible* perl takes a lot more space. -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Without any more information I would say the biggest contributor to this dissimilarity is your experience. Having spent an additional five years writing code you probably are better now at programming than you were then. I am fairly confident that if you were to take another crack at these same programs in perl you would see similar results. One of the bigger differences might have been language changes over time. If you had written this in python five years ago (assuming the python rewrites are relatively current, otherwise this list gets bigger) you would not have generators, iterators, the logging package, built in sets, decorators, and a host of other changes. Some of these features you may not have used, but for every one you did python would have had more weight. Other than that it all boils down to how the algorithm is implemented. Between those three factors you can probably account for most of the differences here. The real important question is: what has perl done in the last five years to make writing these scripts easier? -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
In article [EMAIL PROTECTED], Edward Elliott [EMAIL PROTECTED] wrote: This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. I'm in the process of converting some old perl programs to python. These programs use some network code and do a lot of list/dict data processing. The old ones work fine but are a pain to extend. After two conversions, the python versions are noticeably shorter. You've got some hidden assumptions in there somehere, even if you aren't admitting them to yourself. :) You have to note that rewriting a program, even in the same language, tends to make it shorter, too. These things are measures of programmer skill, not the usefulness or merit of a particular language. Shorter doesn't really mean anything though, and line count means even less. The number of statements or the statement density might be slightly more meaningful. Furthermore, you can't judge a script by just the lines you see. Count the lines of all the libraries and support files that come into play. Even then, that's next to meaningless unless the two things do exactly the same thing and have exactly the same features and capabilities. I can write a one line (or very short) program (in any language) that does the same thing your scripts do just by hiding the good stuff in a library. One of my friends likes to talk about his program that implements Tetris in one statement (because he hardwired everything into a chip). That doesn't lead us to any greater understanding of anything though. *** Posted via a free Usenet account from http://www.teranews.com *** -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: Evaluating my experiences yes, relating your own no. What would the point be? Most important to me would be: am I happy with the result? And that rarely has to do with the number of lines of actual code or the programming language. A language is just a tool. The point is knowing how to pick the right tool for the right job. True, and I don't think that the number of lines is going to be a good guideline. Anecdotes aren't the answer but they can be the beginning of the question. Besides, whatever happened to pursuing knowledge for its own sake? Sure, but research without being able to peer review the set up is a bit difficult. If you want an anecdote: three years ago my Perl coding was different from now, and I am sure that my Python coding (when I get there), will be different compared to if I had learned the language 3 years ago. Mind, I am not saying that I am going to program Python the Perl way, just that in 3 years I have learned stuff I can use in other languages as well. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
The plural of anecdote is not data. It's a pithy quote, but it isn't QOTW in my book, simply because it isn't true in general. Talk to some paleoclimatologists. There is no way to get uniform measures of ancient climate. What should we do then? Should we ignore the information we have? Are the fortuitously preserved fossils of the very deep past to be ignored just because we can't get an unbiased sample? In fact, the more difficult it is to get systematic data, the more valuable the anecdote. There is a number that represents the character ratio for equivalent skill applied to equivalent tasks across all domains to which both languages are applied. A single programmer's results on this matter do in fact constitute a sample. A single sample is not a very good estimator, but it is not devoid of skill or information either. In the present case Edward gave us some advice that he thought he was making a fair comparison, one which would appear counterintuitive to anyone who has worked in both languages. Perlists tend to giggle and cackle every time they save a keystroke; Pythonistas do not have this personality quirk. If Python is nevertheless terser it is a strong argument in Python's favor vis-a-vis Perl. Edward also asked if others had similar experiences. If others did, the assemblage of their opinions would in fact consttitute data. I have no idea why people are giving him such grief over this request. My only data point, er, anecdotal evidence, is this. To take things to an unrealistic extreme, consider the puzzle at http://pycontest.net (Python Golf). When I first thought about this, I assumed that Perl would defeat Python in the character count, but as I worked at the puzzle I came to the (to me) counterintuitive realization that it probably would not. I'd be interested in seeing the results of an inter-language golf contest. Of course, such games don't tell us much about real code, but I'm inclined to agree with Edward's impression that Python is, in practice, terse compared to Perl, and I, too, would like to hear about other examples, and because I think the plural of anecdote is, in fact, data. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Michael Tobis [EMAIL PROTECTED] writes: The plural of anecdote is not data. It's a pithy quote, but it isn't QOTW in my book, simply because it isn't true in general. Talk to some paleoclimatologists. There is no way to get uniform measures of ancient climate. What should we do then? Should we ignore the information we have? Are the fortuitously preserved fossils of the very deep past to be ignored just because we can't get an unbiased sample? Those samples can be independently verified by any skilled observer at another time. This is what distinguishes them from anecdotes, and breaks your analogy. -- \ I know you believe you understood what you think I said, but I | `\ am not sure you realize that what you heard is not what I | _o__) meant. -- Robert J. McCloskey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
brian d foy wrote: You have to note that rewriting a program, even in the same language, tends to make it shorter, too. These things are measures of programmer skill, not the usefulness or merit of a particular language. I completely agree. But you have to start somewhere. Shorter doesn't really mean anything though, and line count means even less. The number of statements or the statement density might be slightly more meaningful. Furthermore, you can't judge a script by just the lines you see. Count the lines of all the libraries and support files that come into play. Even then, that's next to meaningless unless the two things do exactly the same thing and have exactly the same features and capabilities. For an objective measure of which language/environment is more optimal for a given task, your statement is completely accurate. OTOH for a quick-and-dirty real-world comparison of line counts, and possibly a rough approximation of complexity, the libraries don't matter if they offer more-or-less comparable functionality. Especially if those libraries are the standard ones most people rely on. I'm not attaching any special significance to line counts. They're just a data point that's easy to quantify. What if anything do they mean? How does one measure statement density? What's the divisor in the density ratio - lines, characters, units of work, etc? These are all interesting questions with no easy answers. I can write a one line (or very short) program (in any language) that does the same thing your scripts do just by hiding the good stuff in a library. One of my friends likes to talk about his program that implements Tetris in one statement (because he hardwired everything into a chip). That doesn't lead us to any greater understanding of anything though. Of course. Extreme cases are just that. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
achates wrote: It probably says something about your coding style, particularly in perl. I've found (anecdotally of course) that while perl is potentially the more economical language, writing *legible* perl takes a lot more space. I'm sure it does. My perl (from 5 years ago) may be considered verbose (or not, I don't know). I avoid shortcuts like $_, use strict mode, etc. Then again I frequently use short forms like statement if/unless (blah); when appropriate. So there's a big personal component in there. But again, the interesting thing to me isn't what could one do, it's what are people actually doing in the real world? -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: But again, the interesting thing to me isn't what could one do, it's what are people actually doing in the real world? In that case: there is probably more Perl out there that makes us cry compared to Python :-D. -- John Bokma Freelance software developer Experienced Perl programmer: http://castleamber.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Adam Jones wrote: Without any more information I would say the biggest contributor to this dissimilarity is your experience. Having spent an additional five years writing code you probably are better now at programming than you were then. I am fairly confident that if you were to take another crack at these same programs in perl you would see similar results. I am in complete agreement with that statement. One of the bigger differences might have been language changes over time. If you had written this in python five years ago (assuming the python rewrites are relatively current, otherwise this list gets bigger) you would not have generators, iterators, the logging package, built in sets, decorators, and a host of other changes. Some of these features you may not have used, but for every one you did python would have had more weight. Absolutely. Other than that it all boils down to how the algorithm is implemented. Between those three factors you can probably account for most of the differences here. s/probably/maybe. The factors you list are certainly big contributors, but are they most of it? I don't know, there are good arguments both ways. If you removed those factors, would the resulting python be shorter, as long as, or longer than the corresponding perl? Would that mean anything about code complexity, readability, maintainability, etc? I'm not comfortable drawing any conclusions, but asking the questions is good. The real important question is: what has perl done in the last five years to make writing these scripts easier? That's another very good question. One I can't answer. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Michael Tobis wrote: Edward also asked if others had similar experiences. If others did, the assemblage of their opinions would in fact consttitute data. I have no idea why people are giving him such grief over this request. Thank you, Michael. It was starting to feel like I'd asked about the best way to club baby seals in here. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: Those samples can be independently verified by any skilled observer at another time. This is what distinguishes them from anecdotes, and breaks your analogy. Anyone who has my source files can run the same tests. The measures are repeatable and reliable, even if at the moment few can perform them on my code. They don't just let anybody walk into the Louvre and cut off a piece of the Mona Lisa for spectral analysis. :) Before the days of cheap video, lots of scientific data was gathered by lone observers recording unrepeatable events. You build statistics by accumulating a vast number of such observations over time. In any case, I never asked for scientific-quality data in the first place. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] writes: Ben Finney wrote: Those samples can be independently verified by any skilled observer at another time. This is what distinguishes them from anecdotes, and breaks your analogy. Anyone who has my source files can run the same tests. Which we don't. Currently all we have is an anecdote. I'm making no comment on the veracity or interest of the anecdote, but currently that's all we have. I responded to a post that seemed to claim that anecdotes about events can be treated as data about events. They can't; that's what I'm arguing. -- \ It is hard to believe that a man is telling the truth when you | `\ know that you would lie if you were in his place. -- Henry L. | _o__) Mencken | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ben Finney wrote: I responded to a post that seemed to claim that anecdotes about events can be treated as data about events. They can't; that's what I'm arguing. And conveniently ignoring the key part of my post. Here it is again for those who missed it: Before the days of cheap video, lots of scientific data was gathered by lone observers recording unrepeatable events. You build statistics by accumulating a vast number of such observations over time. Sounds like anecdotes can become data to me. It's a stupid argument anyway. Anecdotes *are* data. Some data is repeatable, some is not. All data has an associated confidence level. Single anecdotes are relatively low, as you gather more the confidence level rises (for the aggregate). Eventually you reach the maximal level by definition: the sum of all anecdotes is the universe of available data. No one's saying anecdotes are 100% reliable. But they aren't 0% reliable either. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] writes: Ben Finney wrote: I responded to a post that seemed to claim that anecdotes about events can be treated as data about events. They can't; that's what I'm arguing. And conveniently ignoring the key part of my post. Here it is again for those who missed it: Before the days of cheap video, lots of scientific data was gathered by lone observers recording unrepeatable events. You build statistics by accumulating a vast number of such observations over time. Sounds like anecdotes can become data to me. Note the transformation though. You're not collecting data *about the unrepeatable events*, you're collecting data *about the reports*. Thus my assertion: anecdotes about events cannot be treated as data about those events. At best, they are data about *reports* of events. It's a stupid argument anyway. Anecdotes *are* data. They're a different kind of data though. Anecdotes about UFO sightings says *nothing* for or against the existence of UFOs, only about the incidence of people reporting sightings of UFOs. Treating an anecdote about X as though it were a data point about X is a fallacy. Treating an aggregate of anecdotes about X as though it were data about X is a very common practice, but is equally a fallacy. -- \ The reward of energy, enterprise and thrift is taxes. -- | `\ William Feather | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
python vs perl lines of code
This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. I'm in the process of converting some old perl programs to python. These programs use some network code and do a lot of list/dict data processing. The old ones work fine but are a pain to extend. After two conversions, the python versions are noticeably shorter. The first program does some http retrieval, sort of a poor-man's wget with some extra features. In fact it could be written as a bash script with wget, but the extra processing would make it very messy. Here are the numbers on the two versions: Raw -Blanks -Comments lines chars lines chars lines chars mirror.py 16746321324597 1184009 mirror.pl 30958362115647 1844790 I've listed line and character counts for three forms. Raw is the source file as-is. -Blanks is the source with blank lines removed, including lines with just a brace. -Comments removes both blanks and comment lines. I think -Blanks is the better measure because comments are a function of code complexity, but either works. By the numbers, the python code appears roughly 60% as long by line and 80% as long by characters. The chars percentage being (higher relative to line count) doesn't surprise me since things like list comprehensions and explicit module calling produce lengthy but readable lines. I should point out this wasn't a straight line-for-line conversion, but the basic code structure is extremely similar. I did make a number of improvements in the Python version with stricter arg checks and better error handling, plus added a couple minor new features. The second program is an smtp outbound filtering proxy. Same categories as before: Raw -Blanks -Comments lines chars lines chars lines chars smtp-proxy.py 2617788 222 7749 205 6964 smtp-proxy.pl 96624110 66023469 45214869 The numbers here look much more impressive but it's not a fair comparison. I wasn't happy with any of the cpan libraries for smtp sending at the time so I rolled my own. That accounts for 150 raw lines of difference. Another 70 raw lines are logging functions that the python version does with the standard library. The new version performs the same algorithms and data manipulations as the original. I did do some major refactoring along the way, but it wasn't the sort that greatly reduces line count by eliminating redundancy; there is very little redundancy in either version. In any case, these factors alone don't account for the entire difference, even if you take 220 raw lines directly off the latter columns. The two versions were written about 5 years apart, all by me. At the time of each, I had about 3 years experience in the given language and would classify my skill level in it as midway between intermediate and advanced. IOW I'm very comfortable with the language and library reference docs (minus a few odd corners), but generally draw the line at mucking with interpreter internals like symbol tables. I'd like to here from others what their experience converting between perl and python is (either direction). I don't have the sense that either language is particularly better suited for my problem domain than the other, as they both handle network io and list/dict processing very well. What are the differences like in other domains? Do you attribute those differences to the language, the library, the programmer, or other factors? What are the consistent differences across space and time, if any? I'm interested in properties of the code itself, not performance. And just what is the question to the ultimate answer to life, the universe, and everything anyway? ;) -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott [EMAIL PROTECTED] wrote: This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. Without seeing the actual code this is quite meaningless. -- John MexIT: http://johnbokma.com/mexit/ personal page: http://johnbokma.com/ Experienced programmer available: http://castleamber.com/ Happy Customers: http://castleamber.com/testimonials.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. Without seeing the actual code this is quite meaningless. Evaluating my experiences yes, relating your own no. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott wrote: John Bokma wrote: Edward Elliott [EMAIL PROTECTED] wrote: This is just anecdotal, but I still find it interesting. Take it for what it's worth. I'm interested in hearing others' perspectives, just please don't turn this into a pissing contest. Without seeing the actual code this is quite meaningless. Evaluating my experiences yes, relating your own no. But why would anecdotal accounts be of interest... unless there's an agenda :) Differing skill levels and problem scenarios would tangle the results so much no one could ever unravel the skein or pry out any meaningful conclusions. I'm not sure what's to be gained ...even if you're just evaluating your own experiences. And, as you suspect, it almost certainly would devolve into a pissing contest. This subject thread may be of great interest but I think an language advocacy mailing list would be a better forum. -- Charles DeRykus -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Edward Elliott wrote:
John Bokma wrote:
Without seeing the actual code this is quite meaningless.
Evaluating my experiences yes, relating your own no.
Well, quality of code is directly related to its author. Without knowing
the author personally, or at least seeing the code, your anecdote
doesn't really mean anything.
A colleague of mine, who is efficient at programming, and pretty decent
at Perl, routinely does something like:
if ($var =~ /something and something else/) {
$var =~ /(something) and (something else)/;
my $match1 = $1;
my $match2 = $2;
...
}
Needless to say, this adds a lot of unnecessary redundancy, which will
go towards increasing your character count. Being an avid Perl Golfer
(although not one of the best) I can almost guarantee that any python
code can be written more succinctly in Perl, although readability will
suffer. Plus, the extensibility argument is very subjective, and is
closely related to personal coding style.
Btw, do you include space chars that go toward indentating Python code
in your count? If not, you should since they are required. Not so for Perl.
--Ala
--
http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Charles DeRykus wrote: This subject thread may be of great interest but I think an language advocacy mailing list would be a better forum. Fair enough, but advocacy isn't at all what I'm after. Anecdotes are fine, after all what is data but a collection of anecdotes? :) Seriously, anecdotes are valuable: they give you another perspective, reflect common wisdom, and can tell you what/where/how to look for hard data. Of course if anyone already has hard data that would be welcome too, but it's hard to even pin down what 'hard data' means in this situation. I'll grant you though, asking for non-value-judgement-laden anecdotes on newsgroups may be asking too much. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl lines of code
Ala Qumsieh wrote: Btw, do you include space chars that go toward indentating Python code in your count? If not, you should since they are required. Not so for Perl. All chars are counted on lines which are counted. The perl and python versions use the same amount and type of indentation, which in this case is tab characters. In any case, I wouldn't strip the whitespace out of the perl code just because it's unnecessary for the interpreter. How people deal with code is far more interesting than how machines do, and for us whitespace is necessary (not strictly, but a really really good idea). -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
