blob: 97bd2e2e47cae9403b810cf4fd6f3e7025d55186 [file] [log] [blame]
Guido van Rossum2ba9f301992-03-02 16:20:32 +00001Path: cwi.nl!sun4nl!mcsun!uunet!cs.utexas.edu!convex!usenet
2From: tchrist@convex.COM (Tom Christiansen)
3Newsgroups: comp.lang.perl
4Subject: Re: The problems of Perl (Re: Question (silly?))
5Message-ID: <1992Jan17.053115.4220@convex.com>
6Date: 17 Jan 92 05:31:15 GMT
7References: <17458@ector.cs.purdue.edu> <1992Jan16.165347.25583@cherokee.uswest.com> <=#Hues+4@cs.psu.edu>
8Sender: usenet@convex.com (news access account)
9Reply-To: tchrist@convex.COM (Tom Christiansen)
10Organization: CONVEX Realtime Development, Colorado Springs, CO
11Lines: 83
12Nntp-Posting-Host: pixel.convex.com
13
14From the keyboard of flee@cs.psu.edu (Felix Lee):
15:And Perl is definitely awkward with data types. I haven't yet found a
16:pleasant way of shoving non-trivial data types into Perl's grammar.
17
18Yes, it's pretty aweful at that, alright. Sometimes I write perl programs
19that need them, and sometimes it just takes a little creativity. But
20sometimes it's not worth it. I actually wrote a C program the other day
21(gasp) because I didn't want to deal with a game matrix with six links per node.
22
23:Here's a very simple problem that's tricky to express in Perl: process
24:the output of "du" to produce output that's indented to reflect the
25:tree structure, and with each subtree sorted by size. Something like:
26: 434 /etc
27: | 344 .
28: | 50 install
29: | 35 uucp
30: | 3 nserve
31: | | 2 .
32: | | 1 auth.info
33: | 1 sm
34: | 1 sm.bak
35
36At first I thought I could just keep one local list around
Serhiy Storchaka45ec3282015-04-03 19:42:32 +030037at once, but this seems inherently recursive. Which means
Guido van Rossum2ba9f301992-03-02 16:20:32 +000038I need an real recursive data structure. Maybe you could
39do it with one of the %assoc arrays Larry uses in the begat
40programs, but I broke down and got dirty. I think the hardest
Serhiy Storchaka45ec3282015-04-03 19:42:32 +030041part was matching Felix's desired output exactly. It's not
Guido van Rossum2ba9f301992-03-02 16:20:32 +000042blazingly fast: I should probably inline the &childof routine,
Serhiy Storchaka45ec3282015-04-03 19:42:32 +030043but it *was* faster to write than I could have written the
Guido van Rossum2ba9f301992-03-02 16:20:32 +000044equivalent C program.
45
46
47--tom
48
49--
50"GUIs normally make it simple to accomplish simple actions and impossible
51to accomplish complex actions." --Doug Gwyn (22/Jun/91 in comp.unix.wizards)
52
53 Tom Christiansen tchrist@convex.com convex!tchrist
54