From: Julian Davison <julian-xen_devel@tech.cbhs.school.nz>
To: xen-devel@lists.xensource.com
Subject: Re: Re: [patch rfc 1/3] xen arch header rework.
Date: Mon, 16 Oct 2006 09:21:22 +1300 [thread overview]
Message-ID: <45329842.8080903@tech.cbhs.school.nz> (raw)
In-Reply-To: <45303DAF.3020507@redhat.com>
Steven Rostedt wrote:
> Julian Davison wrote:
>> Gerd Hoffmann wrote:
>>> I don't think adding perl as build dependency is a big problem, almost
>>> everyone has it on the machine anyway. Try "rpm -e perl" on any linux
>>> distro and watch the error message with the long list of stuff which
>>> depends on perl.
>>
>> While I realise this is drifting from the topic somewhat,
>> if I could just say:
>> jade:~# rpm -e perl
>> rpm: To install rpm packages on Debian systems, use alien. See
>> README.Debian.
>> error: cannot open Packages index using db3 - No such file or
>> directory (2)
>> error: cannot open /var/lib/rpm/packages.rpm
>>
>> Perl is most certainly on that system, but 'perl is everywhere'
>> is a little like 'rpm is everywhere'.
>
> 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)
> So, Gerd's example of using rpm was bad, and I wouldn't compare having
> perl to having rpm.
In the grand scheme of things neither would I. (Hence the 'little
like' :) I was aiming at highlighting the fact that what was
ultimately happening here (IMHO) was broad assumptions/assertions
were being made based on what's true in the individuals surrounding
environment.
>>> Wrt. readability of the scripts: That is IMO more a matter of the
>>> programming style than of the programming language. Sure you can easily
>>> write unreadable perl code, but you don't have to. And you better
>>> shouldn't, just in case you have to touch the scripts again one year
>>> later.
>>
>> I spend far more time with python than I do perl, I confess,
>> however one of my colleagues spends no time with either and
>> has far less trouble understanding python than perl.
>> In terms of novice-readability perl has a whole bunch of
>> (really useful) line noise constructs. =~, say.
>
> But that is an extremely more powerful tool than anything in python.
Undoubtedly.
>> 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 :)
>
> 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 :)
> 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.
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.
> I picked up perl a lot faster than I picked up python, and I still don't
> have a strong urge to go the python route.
While I don't mind python (or perl) the primary reason I've
done so much in it is due to the environment here at work.
The intranet is running on Plone/Zope/Python, which leads to
python being a better (and easier) choice than perl.
Which was a point in this discussion that I thought quite
important - the more things that are the same the easier
it is to get a handle on the whole (once you can grasp
a part)
> 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 :)
> 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.
> No snipping needed :-)
Indeed :)
--
Julian Davison
Note: 1) This may have come from an address @cbhs.school.nz
but isn't necessarily the (or even an) official view
of Christchurch Boys' High School
2) While replying to this address may get into my mailbox
it will almost certainly be filtered into a mailing list
folder. To actually reach actual me, strip off the bit
after the '-' in the name.
next prev parent reply other threads:[~2006-10-15 20:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-05 9:05 [patch rfc 0/3] xen arch header patches kraxel
2006-10-05 9:05 ` [patch rfc 1/3] xen arch header rework kraxel
2006-10-05 12:27 ` Jan Beulich
2006-10-05 13:08 ` Gerd Hoffmann
2006-10-11 9:16 ` Gerd Hoffmann
2006-10-11 9:44 ` Keir Fraser
2006-10-11 10:40 ` Jacob Gorm Hansen
2006-10-11 10:50 ` Keir Fraser
2006-10-11 11:54 ` Gerd Hoffmann
2006-10-11 13:47 ` Jacob Gorm Hansen
2006-10-11 14:49 ` Gerd Hoffmann
2006-10-11 20:38 ` Julian Davison
2006-10-14 1:30 ` Steven Rostedt
2006-10-15 20:21 ` Julian Davison [this message]
2006-10-16 14:56 ` Steven Rostedt
2006-10-17 13:28 ` Jacob Gorm Hansen
2006-10-17 20:10 ` Julian Davison
2006-10-11 11:39 ` Gerd Hoffmann
2006-10-11 11:43 ` Keir Fraser
2006-10-11 12:21 ` SPAM: " Gerd Hoffmann
2006-10-11 12:04 ` John Levon
2006-10-05 9:05 ` [patch rfc 2/3] xen arch header rework, fixups kraxel
2006-10-05 9:05 ` [patch rfc 3/3] xen arch header rework, check utility kraxel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45329842.8080903@tech.cbhs.school.nz \
--to=julian-xen_devel@tech.cbhs.school.nz \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.