[Pdx-pm] Fwd: Genomics at OHSU

[Thomas J Keller]

Just to finish this thread. Thanks for all the help with this. Here's  
my last message to the 'Python snob':

Begin forwarded message:

> From: Thomas J Keller <kellert at ohsu.edu>
> Date: November 29, 2005 10:09:56 AM PST
> To: Aaron Cohen <cohenaa at ohsu.edu>
> Subject: Re: Genomics at OHSU
>
> Hi Aaron,
> First a disclaimer: I'd only started in on this 'cause you called  
> yourself a "Python snob" which implied Perl lost out in comparison.  
> I had only meant to give you a little jibe in return. And Python is  
> undoubtedly an effective language to work in. But my gosh, it must  
> be a long time since you seriously looked at Perl. Perl is a very  
> well developed language. It's been used successfully for many,  
> many, really large and successful projects. As my friend Austin  
> says  "...the flexibility, expressiveness, and power of Perl make  
> development faster than in any other language I've yet to work  
> with, and the supporting libraries add much on all three counts.  
> Our team uses it every day, and we support far more applications  
> per developer than other development teams within our company."  
> Austin Schutz <tex at off.org>.
>
> And though it is quite different from languages with computer  
> science roots. (Perl's roots are in linguistics), that's not really  
> a weakness. One of the more opaque features is that meaning is  
> context dependent in Perl. So
>  my $data   = $line =~ /($some_regex)/;
>  my ($data) = $line =~ /($some_regex)/;
>
> These mean different things. But once you understand list vs scalar  
> context, it's easy. And also flexible and powerful.
>
> The big push amongst the people here in Portland [The people who  
> help me: pdx-pm.org.] is reusability and testing. Objects work well  
> with those goals. And in fact most of the recent additions to CPAN  
> (If you haven't looked at cpan lately, you will be amazed at how  
> many solutions are already there) are object oriented. You should  
> especially take a look at the BioPerl modules.  I know Python has a  
> BioPython project too, and it may be great, but the BioPerl project  
> is a fantastic resource.
>
> As you suggested earlier, there should be a wide variety of tools  
> available and the best one for the job should be used.
> "Best" can be defined in many ways of course, and personal  
> preference of the person doing the work is an important one.
>
> As I said, I was only reacting to the "snob" comment at first. But  
> now, I'd like to suggest that you need someone with perl expertise  
> in your group.
>
> That probably sounds pugnacious, but I don't mean it to be. I have  
> been arguing for a while now that OHSU needs to develop its in- 
> house computing base: programmers, not just more servers. So I'd  
> argue we need more Perl, Python, Java, C, C++, etc., programmers  
> around here and the research community needs a way to get them  
> involved in their research and informatics needs. I hope this  
> Genomics Track project helps to accomplish that.
>
>
> Yours truly,
> Tom
>
>
>
> On Nov 28, 2005, at 1:31 PM, Aaron Cohen wrote:
>
>> Tom:
>> I don't know of any jobs right now. I may have something if my  
>> grant gets funded.
>>
>> I have no gripe with Perl for what you are using it for. For small  
>> programs mine is mostly an aesthetic preference.
>> My needs are different, and I needed something that scales to  
>> large programs well. Did I mention that Python is object oriented?
>> I thought that they were enhancing Perl with objects, is that  
>> available yet.
>> I'll take a look at the Stein article.
>>
>> Thanks,
>> -Aaron
>>
>>>>> Thomas J Keller <kellert at ohsu.edu> 11/28/2005 12:54 PM >>>
>> Hi Aaron,
>> I agree with the "best tool for the job" concept in principle. But
>> for people like me, for whom programming and software development is
>> not in our primary job description, the "Swiss army knife" of
>> languages turns out to be a good choice. My reasoning was that I
>> really only had time to learn one language; so it's got to do
>> everything I needed. It's funny too about what people consider
>> readable; there is a large subjective component. I can generally grok
>> a perl program, but I do a lot of borrowing and customizing for my
>> own purposes, so I'm used to that. Perl is a great "glue" language.
>> So for me, managing a core facility's service lab, the need to
>> extract data, change it, and feed it to something else is really
>> important; and perl excels at that. This (http://www.stanford.edu/
>> class/gene211/handouts/How_Perl_HGP.html) is an old article by
>> Lincoln Stein, but I think his points are still valid.
>>
>> I did enjoy the linux article too.
>> Thanks,
>> Tom K.
>>
>> PS. An old pdx-perlmonger colleague used to work in Bioinformatics
>> when he was at Columbia. He passed these to me and I pass them on in
>> case you're interested. Do you have any job openings? Jeff would be a
>> good choice.
>>
>> Zucker, J., Chase, H., Molholt, P., Soliz, E., Kahn, R. M.,  
>> Conceptual
>> Modeling Techniques for Online Curriculum Design. 1997 AMIA fall
>> symposium.
>>
>> Zucker, J., Chase, H., Molholt, P., Bean, C., Kahn, R.M., A
>> Comprehensive Strategy for Designing a Web*Based Curriculum. IN
>> Proceedings of the 1996 AMIA Annual Fall Symposium. Hanley & Belfus,
>> Inc., 1996. pp. 41*46.
>>
>> Zucker, J., Kahn, R., and Molholt, P., An Electronic PDR Using  
>> Fielded
>> Searches in HTML. IN Proceedings of the Nineteenth Annual  
>> Symposium on
>> Computer Applications in Medical Care (SCAMC '95). McGraw*Hill, 1995.
>> p.1012.
>>
>> Kahn R.M., Molholt P. and Zucker J., CPMCnet: An Integrated  
>> Information
>> and Internet Resource. IN Proceedings of the Eighteenth Annual  
>> Symposium
>> on Computer Applications in Medical Care (SCAMC '94). McGraw*Hill,
>> 1994.
>> pp. 98*102.
>>
>> DuBois K., Zucker J. and Galashaw D., A computer Assisted Psychiatric
>> Nursing Review: Modeling Nursing/Computer Analyst Collarboration. IN
>> Proceedings of the Eighteenth Annual Symposium on Computer  
>> Applications
>> in Medical Care (SCAMC '94). McGraw*Hill, 1994. p.1020.
>>
>> Zucker J., Kahn R.M. and Natarajan N., Clinical, Scholarly and Campus
>> Information Hypertext Tools At Columbia*Presbyterian Medical Center.
>> IN
>> Proceedings of the Seventeenth Annual Symposium on Computer  
>> Applications
>> in Medical Care (SCAMC '93). McGraw*Hill, 1994. pp. 539*548.
>>
>> Zucker, Jeff, Kahn, Robert M., Natarajan, Narayanan, 'Health Sciences
>> Hypertexts at Columbia-Presbyterian Medical Center,' Proceedings  
>> of ACM
>> Hypertext'93 -- Demonstrations, 1993, pp. 15.
>>
>>
>>
>>
>>
>> I guess we should all work in the language we are most productive in.
>> I am thinking about branching out a bit into "Ruby on Rails".
>>
>> On Nov 28, 2005, at 10:44 AM, Aaron Cohen wrote:
>>
>>> Tom:
>>> Challenges are good when they lead to interesting discussions.
>>> Here's my two cents.
>>>
>>> I can't argue against the fact that Perl is good for one line
>>> string manipulations. However, old-fashioned Unix tools such as sed
>>> do the same thing.
>>> Python isn't geared towards this kind of brevity. The reason that I
>>> like Python is that it makes me more productive, and I have been
>>> able to use it as a single language
>>> to do lots of things, both small and large quickly.
>>>
>>> I think that any Python lover (not just me) would admit that Python
>>> doesn't provide the "least characters" way of doing things. But
>>> they would also consider
>>> that a low priority compared to programmer productivity, debugging
>>> time, ability to understand other's code, etc. The problem with
>>> using brevity as a measure of goodness is that it becomes
>>> irrelevent for programs of any decent size. I like Python because I
>>> have writing all kinds of complex programs (genetic optimizers,
>>> machine learning classifiers, statistical analyzers, video editors,
>>> Sudoku solvers, etc.) and months or years later I can still
>>> understand the programs that I wrote.
>>> My gripe against Perl is that I can't make heads or tails out of
>>> someone else's code without a language manual by my side. Do you
>>> have any experience in taking and adapting someone else's largish
>>> Perl code? Perhaps your experience is different.
>>>
>>> That said, one should always pick an appropriate tool for the job,
>>> and if Perl works for what you're doing, great. I think that you
>>> implied that Perl is your first language, so you may want to look
>>> into another as a comparison. I like Python, but I have heard some
>>> nice things about Ruby. And of course, Java is always a good
>>> language to know something about.
>>>
>>> -Aaron
>>>
>>>>>> Thomas J Keller <kellert at ohsu.edu> 11/25/2005 9:30 AM >>>
>>> Hi Aaron,
>>> As you can see, once I'm given a challenge, I don't easily let it  
>>> go:
>>>
>>> After sending my last message, I realized there was an even shorter
>>> perl method from the command line
>>> $ perl -pe 'y/Z/5/'
>>> ATGACTTGACZTTCGGATCCATG
>>> ATGACTTGAC5TTCGGATCCATG
>>>
>>>
>>> Tom
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/pdx-pm-list/attachments/20051129/55df9b1e/attachment-0001.html