* [Lustre-devel] Language choice for Lustre tests @ 2012-10-23 18:36 Nathan Rutman 2012-10-23 19:39 ` Jacques-Charles Lafoucriere 2012-10-23 20:05 ` [Lustre-devel] " Kilian Cavalotti 0 siblings, 2 replies; 9+ messages in thread From: Nathan Rutman @ 2012-10-23 18:36 UTC (permalink / raw) To: lustre-devel At LAD'12 we proposed a plan for improving the Lustre test framework as an important part of the Lustre quality story. One of the discussion points there was that the bash language of the current tests was lacking in a variety of areas. We're moving forward with this work but need community agreement on the best course. Given the requirements and language options below, the reasonable choices rapidly diminish to a showdown between perl and python. I think we're leaning at this point toward perl, based on it's superior speed and inter-version compatibility. The final piece of the puzzle is the knowledge of existing Lustre test writers, so please chime in. (But note that "popularity" is the reason we chose bash the first time, and look where that got us...) requirements 1. easy to use 2. strict structure 3. universally available 4. widely maintained 5. widely understood 6. good filesystem interface: posix API 7. fast - replace e.g. createmany with embedded function 8. operate remote instances 9. inter-version compatibility options bash - capable, but too flexible, easy to abuse perl - forward compatible, universal, more widely understood, xperior, compact; hard to read later posix::open, opendir, lseek, etc. parallel::MPI ~2x faster than python more version compatible python - very clear structure, swig module for c inclusion; non-standard installations, support os.open: all c flags MPI bindings tab/space requirements make remote editing more difficult cucumber - ruby based, difficult deployment java - easy deployment, dev environ, debugger, fast; must compile ruby - compact http://silicainsilico.wordpress.com/2012/03/26/switching-from-perl-to-python-speed/ http://tenser.typepad.com/tenser_said_the_tensor/2006/08/python_vs_perl_.html http://opennomad.com/content/performance-different-scripting-languages-shell-v-perl-v-python-v-ruby http://hentenaar.com/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121023/3ba94dff/attachment.htm> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] Language choice for Lustre tests 2012-10-23 18:36 [Lustre-devel] Language choice for Lustre tests Nathan Rutman @ 2012-10-23 19:39 ` Jacques-Charles Lafoucriere 2012-10-23 20:31 ` [Lustre-devel] [lustre-devel] " Bruce Korb 2012-10-24 6:31 ` [Lustre-devel] " Roman Grigoryev 2012-10-23 20:05 ` [Lustre-devel] " Kilian Cavalotti 1 sibling, 2 replies; 9+ messages in thread From: Jacques-Charles Lafoucriere @ 2012-10-23 19:39 UTC (permalink / raw) To: lustre-devel hello all I personally always had difficulties with perl ... the code is generally very hard to read, and the language brings very quickly to tricky optimization only experts understood python is a more generic language, very easy to learn and if we make the right basic object definitions, it will help a lot for future improvement and code structure at CEA our admin tools like shine or cluster-shell are python based and this choice allows us in getting scallable/reliable tools For example, the initial version of shine (~6 years ago) was perl based and we were pleased to move to python for the new design The target is lustre developers (ie kernel developers), it will be much easier for them to learn python than perl. it will also be easier for them to get the right "python" way of programming than the right "perl" way of programming (in both cases the worst way is to use the new language as bash, which can arrive much quickly with perl than with python) about python, what do you mean by non standard installation ? if your python configuration is right, the local differences should be hidden to the test framework Bye JC On 10/23/2012 08:36 PM, Nathan Rutman wrote: > At LAD'12 we proposed a plan for improving the Lustre test framework > as an important part of the Lustre quality story. One of the > discussion points there was that the bash language of the current > tests was lacking in a variety of areas. We're moving forward with > this work but need community agreement on the best course. > > Given the requirements and language options below, the reasonable > choices rapidly diminish to a showdown between perl and python. I > think we're leaning at this point toward perl, based on it's superior > speed and inter-version compatibility. The final piece of the puzzle > is the knowledge of existing Lustre test writers, so please chime in. > (But note that "popularity" is the reason we chose bash the first > time, and look where that got us...) > > requirements > 1. easy to use > 2. strict structure > 3. universally available > 4. widely maintained > 5. widely understood > 6. good filesystem interface: posix API > 7. fast - replace e.g. createmany with embedded function > 8. operate remote instances > 9. inter-version compatibility > options > bash - capable, but too flexible, easy to abuse > perl - forward compatible, universal, more widely understood, xperior, > compact; hard to read later > posix::open, opendir, lseek, etc. > parallel::MPI > ~2x faster than python > more version compatible > python - very clear structure, swig module for c inclusion; > non-standard installations, support > os.open: all c flags > MPI bindings > tab/space requirements make remote editing more difficult > cucumber - ruby based, difficult deployment > java - easy deployment, dev environ, debugger, fast; must compile > ruby - compact > > > http://silicainsilico.wordpress.com/2012/03/26/switching-from-perl-to-python-speed/ > http://tenser.typepad.com/tenser_said_the_tensor/2006/08/python_vs_perl_.html > http://opennomad.com/content/performance-different-scripting-languages-shell-v-perl-v-python-v-ruby > http://hentenaar.com/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html > > > > > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121023/6616133b/attachment.htm> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] [lustre-devel] Language choice for Lustre tests 2012-10-23 19:39 ` Jacques-Charles Lafoucriere @ 2012-10-23 20:31 ` Bruce Korb 2012-10-24 6:31 ` [Lustre-devel] " Roman Grigoryev 1 sibling, 0 replies; 9+ messages in thread From: Bruce Korb @ 2012-10-23 20:31 UTC (permalink / raw) To: lustre-devel Hi, On Tue, Oct 23, 2012 at 12:39 PM, Jacques-Charles Lafoucriere < jacques-charles.lafoucriere@cea.fr> wrote: > hello all > > I personally always had difficulties with perl ... > the code is generally very hard to read, and the language brings very > quickly to tricky optimization only experts understood > At first blush, I had a hard time reading C code. I was looking at the first implementation of the C preprocessor and nobody had figured out how to write clean code yet. Truly awful. I also had a professor who claimed he could make any language look like FORTRAN. I believe him to this day. It takes effort, care, examples and some training to write clean comprehensible code in any language, beit C or bash or perl or python or ruby. it will also be easier for them to get the right "python" way of > programming than the right "perl" way of programming > (in both cases the worst way is to use the new language as bash, which can > arrive much quickly with perl than with python) > In both cases, you need to find good examples of language usage, characterize what makes the good examples good and then emulate that. Perl can be clean and comprehensible. Even bash can be clean and comprehensible. And Python can be illegible. It takes effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121023/fca398f5/attachment.htm> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] Language choice for Lustre tests 2012-10-23 19:39 ` Jacques-Charles Lafoucriere 2012-10-23 20:31 ` [Lustre-devel] [lustre-devel] " Bruce Korb @ 2012-10-24 6:31 ` Roman Grigoryev 2012-10-24 7:18 ` Kilian Cavalotti 1 sibling, 1 reply; 9+ messages in thread From: Roman Grigoryev @ 2012-10-24 6:31 UTC (permalink / raw) To: lustre-devel Hi JC, all, I should say more words about compatibility. In comparing with server-only tools(which are often pretty good maintained and controlled on limited node set), test tools often work on wider sets. Minimally, it should work on some clients and also on clients with different versions then servers, include clients in real clusters, developers virtual clusters and so on. As I know, Lustre users could have environment with Lustre latest servers and 1.8 clients, some companies use RedHat5.x clients and RedHat6.x(SL6.x) server, other use Ubuntu. RH5 has only python2.4, SL61 has python2.4 and python2.6, and looks like only last Fedora will have python3. In same time, Ubuntu says that from next release want to have only Python 3. Which version should we use and how long backward compatibility will be supported by Python and distros//for selected version/?/ Precision Python version could be installed from non standard repos, compiled from sources also as used "non standard installation". Last item also mean testing own installation on wide set of distros. Also we should remember about external Python libraries which also could be touched by breaking legacy compatibility. I think, testing system should be friendly to developers as possible and pushing to install precision version while one or more pythons already in os could not be the simplest solution. Now Lustre tests compatibility for wide set of system is solved by shell and standard utilities. Perl also has great compatibility history, many scripts could work on latest version as 10 years ago. It is reason why I see Perl as good decision. From compatibility(and my) point of view, also Java is preferable solution then Python. It has few good described ways of installation, proved compatibility, great library managers (maven, ant+ivy) and could support scripting languages(JPython, JRuby and more). But it needs more memory and pretty big start time. Thanks, Roman On 10/23/2012 11:39 PM, Jacques-Charles Lafoucriere wrote: > hello all ....... > about python, what do you mean by non standard installation ? > if your python configuration is right, the local differences should be > hidden to the test framework > > Bye > > JC > > On 10/23/2012 08:36 PM, Nathan Rutman wrote: >> At LAD'12 we proposed a plan for improving the Lustre test framework >> as an important part of the Lustre quality story. One of the >> discussion points there was that the bash language of the current >> tests was lacking in a variety of areas. We're moving forward with >> this work but need community agreement on the best course. >> >> Given the requirements and language options below, the reasonable >> choices rapidly diminish to a showdown between perl and python. I >> think we're leaning at this point toward perl, based on it's superior >> speed and inter-version compatibility. The final piece of the puzzle >> is the knowledge of existing Lustre test writers, so please chime in. >> (But note that "popularity" is the reason we chose bash the first >> time, and look where that got us...) >> >> requirements >> 1. easy to use >> 2. strict structure >> 3. universally available >> 4. widely maintained >> 5. widely understood >> 6. good filesystem interface: posix API >> 7. fast - replace e.g. createmany with embedded function >> 8. operate remote instances >> 9. inter-version compatibility >> options >> bash - capable, but too flexible, easy to abuse >> perl - forward compatible, universal, more widely understood, >> xperior, compact; hard to read later >> posix::open, opendir, lseek, etc. >> parallel::MPI >> ~2x faster than python >> more version compatible >> python - very clear structure, swig module for c inclusion; >> non-standard installations, support >> os.open: all c flags >> MPI bindings >> tab/space requirements make remote editing more difficult >> cucumber - ruby based, difficult deployment >> java - easy deployment, dev environ, debugger, fast; must compile >> ruby - compact >> >> >> http://silicainsilico.wordpress.com/2012/03/26/switching-from-perl-to-python-speed/ >> http://tenser.typepad.com/tenser_said_the_tensor/2006/08/python_vs_perl_.html >> http://opennomad.com/content/performance-different-scripting-languages-shell-v-perl-v-python-v-ruby >> http://hentenaar.com/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html >> >> >> >> >> _______________________________________________ >> Lustre-devel mailing list >> Lustre-devel at lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20121024/75f5193c/attachment.htm> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] Language choice for Lustre tests 2012-10-24 6:31 ` [Lustre-devel] " Roman Grigoryev @ 2012-10-24 7:18 ` Kilian Cavalotti 2012-10-24 8:44 ` Roman Grigoryev 0 siblings, 1 reply; 9+ messages in thread From: Kilian Cavalotti @ 2012-10-24 7:18 UTC (permalink / raw) To: lustre-devel Hi Roman, On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev <roman_grigoryev@xyratex.com> wrote: > RH5 has only python2.4, SL61 has python2.4 and python2.6, and looks like > only last Fedora will have python3. I agree that inter-version compatibility could be a problem with Python. But to take this argument literally, the best way to avoid compatibility issues is to use the widest-spread and most version consistent language across supported distributions, ie. bash. > In same time, Ubuntu says that from next > release want to have only Python 3. Since only RHEL, CentOS and SLES are supported, should we really care about python versions in Ubuntu? When installing Lustre in Ubuntu, users already have to do their own packaging, so I'm not sure that having to install a specific version of a scripting language would make much of a difference. > Now Lustre tests compatibility for wide set of system is solved by shell and > standard utilities. Perl also has great > compatibility history, many scripts could work on latest version as 10 years > ago. It is reason why I see Perl as > good decision. So what's wrong with bash again? If it's just "too flexible, easy to abuse", I'm afraid there's little in Perl to prevent falling into the same pitfalls. :) Cheers, -- Kilian ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] Language choice for Lustre tests 2012-10-24 7:18 ` Kilian Cavalotti @ 2012-10-24 8:44 ` Roman Grigoryev 2012-10-24 16:30 ` DEGREMONT Aurelien 0 siblings, 1 reply; 9+ messages in thread From: Roman Grigoryev @ 2012-10-24 8:44 UTC (permalink / raw) To: lustre-devel Hi Kilian, if you want I could try to explain why not bash from my point of view. I agree that bash is language which could be used for test frameworks and test-framework.sh prove it. But some bash feature make current framework support pretty hard. For example, I don't see good way to use bash unit tests for test-framework.sh More structured requests: 1) Language features. Perl/Python/Java has many features which allows simple write complex logic (OOP,AOP and so on) 2) Pretty wide set of libraries. 3) powerful and useful unit test frameworks. 4) support tools, e.g. inline documentation, schema generator based on code, coverage collectiors, copyright checkers Ubuntu is building by Intel (http://build.whamcloud.com/job/lustre-b2_3/), so looks like it is important platform. Thanks, Roman > Hi Roman, > > On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev > <roman_grigoryev@xyratex.com> wrote: >> RH5 has only python2.4, SL61 has python2.4 and python2.6, and looks like >> only last Fedora will have python3. > I agree that inter-version compatibility could be a problem with > Python. But to take this argument literally, the best way to avoid > compatibility issues is to use the widest-spread and most version > consistent language across supported distributions, ie. bash. > >> In same time, Ubuntu says that from next >> release want to have only Python 3. > Since only RHEL, CentOS and SLES are supported, should we really care > about python versions in Ubuntu? > When installing Lustre in Ubuntu, users already have to do their own > packaging, so I'm not sure that having to install a specific version > of a scripting language would make much of a difference. > >> Now Lustre tests compatibility for wide set of system is solved by shell and >> standard utilities. Perl also has great >> compatibility history, many scripts could work on latest version as 10 years >> ago. It is reason why I see Perl as >> good decision. > So what's wrong with bash again? If it's just "too flexible, easy to > abuse", I'm afraid there's little in Perl to prevent falling into the > same pitfalls. :) > > Cheers, ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] Language choice for Lustre tests 2012-10-24 8:44 ` Roman Grigoryev @ 2012-10-24 16:30 ` DEGREMONT Aurelien 2012-10-24 20:32 ` [Lustre-devel] [lustre-devel] " Christopher J. Morrone 0 siblings, 1 reply; 9+ messages in thread From: DEGREMONT Aurelien @ 2012-10-24 16:30 UTC (permalink / raw) To: lustre-devel Hello I've developed in Perl and Python for several years in both languages. I enjoyed both. Regarding starting a new project, for testing framework, here is several points which are the key points for choosing the right language. - Longevity Perl as a long history behind it, is available in all distros, that's true. But Perl is there for compatibility for running projects which were starting a long time ago. Nobody is starting a really big and fancy project in Perl nowadays. All new hackers are only speaking of Python or Ruby. You will not attract contributors with Perl. Perl 5 is very compatible because no new changes is really added to this language. And do not tell me that Perl 6 is coming. If Perl 6 is an option, then there is no issue with Python 3 and forget your compatibility. - Compat Developping in Python, for a large number of environment means coding for Python 2.4+. This will run nicely on Python up to 2.7 As long as only Python 2 only is concerned, compat for Python is fine. But I agree that Python 3 is coming, and at long term, it should be taken in account even if no major distro is using it right now. (No Python 3 before RHEL7 or next Ubuntu LTS (14.04)) -Lustre is for system people Lustre is developped by system guys, which mainly use vim or emacs to develop in Lustre. Very few of them are using IDE or stuff like Maven. Population developing Java with Maven is the exact opposite of guys coding in C, for Kernel code. Moreover, JVM are awful to install regarding a standard Python, Perl or Ruby interpreter in all major distro. My choice would go for Python 2 with a clear path to migrate to Python 3 when needed (in 1 year) Aur?lien Le 24/10/2012 10:44, Roman Grigoryev a ?crit : > Hi Kilian, > > if you want I could try to explain why not bash from my point of view. > > I agree that bash is language which could be used for test frameworks > and test-framework.sh prove it. But some > bash feature make current framework support pretty hard. For example, I > don't see good way to use bash unit tests for test-framework.sh > > More structured requests: > > 1) Language features. Perl/Python/Java has many features which allows > simple write complex logic (OOP,AOP and so on) > 2) Pretty wide set of libraries. > 3) powerful and useful unit test frameworks. > 4) support tools, e.g. inline documentation, schema generator based on > code, coverage collectiors, copyright checkers > > Ubuntu is building by Intel > (http://build.whamcloud.com/job/lustre-b2_3/), so looks like it is > important platform. > > Thanks, > Roman >> Hi Roman, >> >> On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev >> <roman_grigoryev@xyratex.com> wrote: >>> RH5 has only python2.4, SL61 has python2.4 and python2.6, and looks like >>> only last Fedora will have python3. >> I agree that inter-version compatibility could be a problem with >> Python. But to take this argument literally, the best way to avoid >> compatibility issues is to use the widest-spread and most version >> consistent language across supported distributions, ie. bash. >> >>> In same time, Ubuntu says that from next >>> release want to have only Python 3. >> Since only RHEL, CentOS and SLES are supported, should we really care >> about python versions in Ubuntu? >> When installing Lustre in Ubuntu, users already have to do their own >> packaging, so I'm not sure that having to install a specific version >> of a scripting language would make much of a difference. >> >>> Now Lustre tests compatibility for wide set of system is solved by shell and >>> standard utilities. Perl also has great >>> compatibility history, many scripts could work on latest version as 10 years >>> ago. It is reason why I see Perl as >>> good decision. >> So what's wrong with bash again? If it's just "too flexible, easy to >> abuse", I'm afraid there's little in Perl to prevent falling into the >> same pitfalls. :) >> >> Cheers, > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] [lustre-devel] Language choice for Lustre tests 2012-10-24 16:30 ` DEGREMONT Aurelien @ 2012-10-24 20:32 ` Christopher J. Morrone 0 siblings, 0 replies; 9+ messages in thread From: Christopher J. Morrone @ 2012-10-24 20:32 UTC (permalink / raw) To: lustre-devel We can pick a completely new language so no gets their current favorite. I nominate go (http://golang.org/). :) On 10/24/2012 09:30 AM, DEGREMONT Aurelien wrote: > Hello > > I've developed in Perl and Python for several years in both languages. I > enjoyed both. > Regarding starting a new project, for testing framework, here is several > points which are the key points for choosing the right language. > > - Longevity > > Perl as a long history behind it, is available in all distros, that's > true. But Perl is there for compatibility for running projects which > were starting a long time ago. Nobody is starting a really big and fancy > project in Perl nowadays. All new hackers are only speaking of Python or > Ruby. You will not attract contributors with Perl. Perl 5 is very > compatible because no new changes is really added to this language. > And do not tell me that Perl 6 is coming. If Perl 6 is an option, then > there is no issue with Python 3 and forget your compatibility. > > - Compat > > Developping in Python, for a large number of environment means coding > for Python 2.4+. This will run nicely on Python up to 2.7 > As long as only Python 2 only is concerned, compat for Python is fine. > But I agree that Python 3 is coming, and at long term, it should be > taken in account even if no major distro is using it right now. > (No Python 3 before RHEL7 or next Ubuntu LTS (14.04)) > > -Lustre is for system people > > Lustre is developped by system guys, which mainly use vim or emacs to > develop in Lustre. Very few of them are using IDE or stuff like Maven. > Population developing Java with Maven is the exact opposite of guys > coding in C, for Kernel code. Moreover, JVM are awful to install > regarding a standard Python, Perl or Ruby interpreter in all major distro. > > > My choice would go for Python 2 with a clear path to migrate to Python 3 > when needed (in 1 year) > > > Aur?lien > > > > Le 24/10/2012 10:44, Roman Grigoryev a ?crit : >> Hi Kilian, >> >> if you want I could try to explain why not bash from my point of view. >> >> I agree that bash is language which could be used for test frameworks >> and test-framework.sh prove it. But some >> bash feature make current framework support pretty hard. For example, I >> don't see good way to use bash unit tests for test-framework.sh >> >> More structured requests: >> >> 1) Language features. Perl/Python/Java has many features which allows >> simple write complex logic (OOP,AOP and so on) >> 2) Pretty wide set of libraries. >> 3) powerful and useful unit test frameworks. >> 4) support tools, e.g. inline documentation, schema generator based on >> code, coverage collectiors, copyright checkers >> >> Ubuntu is building by Intel >> (http://build.whamcloud.com/job/lustre-b2_3/), so looks like it is >> important platform. >> >> Thanks, >> Roman >>> Hi Roman, >>> >>> On Wed, Oct 24, 2012 at 8:31 AM, Roman Grigoryev >>> <roman_grigoryev@xyratex.com> wrote: >>>> RH5 has only python2.4, SL61 has python2.4 and python2.6, and looks >>>> like >>>> only last Fedora will have python3. >>> I agree that inter-version compatibility could be a problem with >>> Python. But to take this argument literally, the best way to avoid >>> compatibility issues is to use the widest-spread and most version >>> consistent language across supported distributions, ie. bash. >>> >>>> In same time, Ubuntu says that from next >>>> release want to have only Python 3. >>> Since only RHEL, CentOS and SLES are supported, should we really care >>> about python versions in Ubuntu? >>> When installing Lustre in Ubuntu, users already have to do their own >>> packaging, so I'm not sure that having to install a specific version >>> of a scripting language would make much of a difference. >>> >>>> Now Lustre tests compatibility for wide set of system is solved by >>>> shell and >>>> standard utilities. Perl also has great >>>> compatibility history, many scripts could work on latest version as >>>> 10 years >>>> ago. It is reason why I see Perl as >>>> good decision. >>> So what's wrong with bash again? If it's just "too flexible, easy to >>> abuse", I'm afraid there's little in Perl to prevent falling into the >>> same pitfalls. :) >>> >>> Cheers, >> _______________________________________________ >> Lustre-devel mailing list >> Lustre-devel at lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-devel > > _______________________________________________ > lustre-devel mailing list > lustre-devel at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/lustre-devel-opensfs.org > . > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Lustre-devel] Language choice for Lustre tests 2012-10-23 18:36 [Lustre-devel] Language choice for Lustre tests Nathan Rutman 2012-10-23 19:39 ` Jacques-Charles Lafoucriere @ 2012-10-23 20:05 ` Kilian Cavalotti 1 sibling, 0 replies; 9+ messages in thread From: Kilian Cavalotti @ 2012-10-23 20:05 UTC (permalink / raw) To: lustre-devel Hi, On Tue, Oct 23, 2012 at 8:36 PM, Nathan Rutman <nathan_rutman@xyratex.com> wrote: > Given the requirements and language options below, the reasonable choices > rapidly diminish to a showdown between perl and python. I think we're > leaning at this point toward perl, based on it's superior speed and > inter-version compatibility. I myself tend towards Python, but that's perfectly knowing this couldn't be very different from the recurring, almost religious "emacs vs vim" or "kde vs gnome" flame wars. It's a matter of taste, and it's almost pointless to try to convince somebody to adopt the other one once their choice is made. I would only recommend reading this : http://www.strombergers.com/python/python_perl_slurp_file.html. And the obligatory XKCD: http://xkcd.com/353/ Cheers, -- Kilian ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-10-24 20:32 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-23 18:36 [Lustre-devel] Language choice for Lustre tests Nathan Rutman 2012-10-23 19:39 ` Jacques-Charles Lafoucriere 2012-10-23 20:31 ` [Lustre-devel] [lustre-devel] " Bruce Korb 2012-10-24 6:31 ` [Lustre-devel] " Roman Grigoryev 2012-10-24 7:18 ` Kilian Cavalotti 2012-10-24 8:44 ` Roman Grigoryev 2012-10-24 16:30 ` DEGREMONT Aurelien 2012-10-24 20:32 ` [Lustre-devel] [lustre-devel] " Christopher J. Morrone 2012-10-23 20:05 ` [Lustre-devel] " Kilian Cavalotti
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.