Re: [Xen-devel] Re: [patch rfc 1/3] xen arch header rework.

[Steven Rostedt <srostedt@xxxxxxxxxx>]

[this is so off topic, that this is my last reply :-)]

Julian Davison wrote:

> > OK, then try this:
> >
> > # apt-get remove perl
> > Reading package lists... Done
> > Building dependency tree... Done
> > The following extra packages will be installed:
> >   gaim-data gimp-data wesnoth-data
> > Recommended packages:
> >   wesnoth-utbs wesnoth-ttb wesnoth-tsg
> > The following packages will be REMOVED
> [snip]
> > Need to get 34.2MB of archives.
> > After unpacking 1837MB disk space will be freed.
> > Do you want to continue [Y/n]? n
> > Abort.
> jade:~# apt-get remove perl
> Reading Package Lists... Done
> Building Dependency Tree... Done
> The following packages will be REMOVED:
>   alien build-essential debhelper defoma dpkg-dev ethereal fontconfig
>   intltool-debian libcompress-zlib-perl libfontconfig1 libft-perl
>   libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libmail-sendmail-perl
>   libpango1.0-0 libpango1.0-common libxft2 ntp ntp-server ntp-simple
>   perl perl-doc perl-modules po-debconf rpm ttf-bitstream-vera xterm
> 0 upgraded, 0 newly installed, 28 to remove and 0 not upgraded.
> Need to get 0B of archives.
> After unpacking 59.8MB disk space will be freed.
> Do you want to continue? [Y/n] n
> Abort.
>
>
> Of course the exact list all depends on what the box does :)
> (Incidentally, those that read carefully may have noticed 'rpm'
>  now appears to be in the list, how bizarre)
Wow, there must not be a lot done on that box.  Well, I did my apt-get 
on a box I use as an office box (lots of apps).

> > > In many cases having a tool in an 'odd' language is better than
> > > no tool at all, but in general the fewer dependencies the better.
> > I find python annoying to work with.  Is it spaces or tabs?
> Spaces :)
Well, at least for Xen development :)

> > if a:
> >   <do something>
> >   if b:
> >     <do this>
> >     if c:
> >        <do that>
> >        if d:
> >          <do another>
> >          if e:
> >            <do whatever>
> >            <and more>
> >            <and that>
> >            <and here>
> >            <and there>
> >     if f:
> >       <do this too>
> >       if g:
> >          <do that as well>
> >   <Now what if am I on???>
> >
> >
> > Using columns instead of blocks has brought me back to the old days on 
> > the old IBM Mainframes.  It sometimes gets confusing to know where 
> > you're at. And I haven't found emacs or vi helpful in telling you 
> > which "if" you are working under. (both easily show which { matches 
> > which } ).
> I've most definitely got a list of peeves about python too,
> don't get me wrong. When I first heard about python I thought
> the 'blocks-by-indentation' was completely absurd. But you get
> used to it, even if you don't ever like it.
>
> I'm hesitant to say it (as I hate people who say this sort
> of thing) but, use something that isn't emacs or vi :)
Joe?

> > But, OK, I like C better than most languages. So if I need something 
> > done I usually write it in C.  But if it has to do with string 
> > manipulation and file parsing, I'll write it in perl.
> Sounds familiar :)
>
> > Yes perl can be obfuscated, and hard to read if someone writes it that 
> > way.  But I have written lots of perl scripts where I need to work 
> > with them after a year or two, and it's never been a problem with me 
> > to understand what I did.  I just write my perl scripts like I write C 
> > and it never has been a problem.
> Though I was looking at *someone else* working with the code.
> If you can't read your own code then there's a fairly serious
> problem with the way you write. If someone who has been using
> the language for several years can't read your code, that's also
> a style problem.
That's a very good point.  Most perl scripts that I download, I have no 
problem reading.  Or even reading the code for the modules.  But for the 
perl obfuscated tests, they are like doing complex Sudoku puzzles!

> A python expert may well not be able to comprehend perl, while
> a perl expert has a far greater chance of comprehending a python
> script.
Hmm, never thought of it that way, and it may very well be true.


> > Anyway, perl vs python is just like emacs vs vi, or gnome vs kde.
> Nah, there are lots of things perl's far better suited
> for than python (and vice versa).
> emacs/vi and gnome/kde arguments are just a bunch of lunatics
> that should get on with using the thing instead of evangelising :)
You're right. I shouldn't compare it to those other flame fests. 
Although, reading some mailing lists, it looks the same.  But as I 
mentioned before, I do most my work with C, and when I need to do stuff 
with string manipulation, I use perl.  But there has been a few times 
that I needed to do number crunching with very large numbers, and python 
was ideal for that.  So where I would use perl, I would not use python, 
but there does indeed exists tasks that I would use python and not perl for.
I like to push, use the tool that's best for the job at hand, and the 
only time that python and perl fight is where either can do the job with 
the only difference being which is more preferred by the developer.  For 
example, I would have written much of Xen in perl, but those that wrote 
that code preferred python.  But so be it.
I don't get into the emacs vs vi fights. I develop in emacs, and edit in 
vi.  That is, if I'm writing a lot of code and compiling a lot, I do 
that work in emacs.  If I need to make edits to a file, or short quick 
changes to lots of files, I use vi. For those purposes I find that vi 
and emacs complement each other.
> > But just for comparison's sake:
> >
> > # apt-get remove python
> > Reading package lists... Done
> > Building dependency tree... Done
> [snip]
> > Do you want to continue [Y/n]? n
> > Abort.
> jade:~# apt-get remove python
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Package python is not installed, so not removed
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Ah, still less than perl :-)

-- Steve


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel