Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Being Popular

by bikeNomad (Priest)
on Aug 02, 2001 at 10:05 UTC ( #101588=perlmeditation: print w/replies, xml ) Need Help??

I just read Paul Graham's essay Being Popular at and had some thoughts about it. You probably want to read this article if you're interested in Perl and the future of languages. Although he's talking about how Lisp could regain some popularity, he has some interesting things to say about Perl. He makes several good points about language popularity (italics mark direct quotes):
  • The opinions of expert hackers matter because they're influential.
  • To be popular, a language has to be the scripting language of a popular system. Perl, of course, is the scripting language of Unix and, later, web servers.
  • Hackers like languages that let them write brief, expressive programs. A language designer should act as if it matters how much a programmer has to type. Perl, of course, cares about this; it's interesting to note that Perl 6 will probably be briefer in some cases (dot instead of arrow, for instance).
  • Hackers should be able to do whatever they want to do with a language. Let them get to the "knobs on the back of the set". Only offer them protection if it makes their jobs easier; don't deny them access. They may not need this kind of access often, but when they do, it's essential that they have it. A good programming language should have features that make people who use the term "software engineering" shake their heads disapprovingly. Having just spent some time while writing Class::Prototyped with package symbol tables, @ISA, %::ISA::CACHE::, etc., I'd have to agree. I hope that Perl 6 will still allow this kind of access.
  • To be attractive to hackers, a language ... has to be good for writing throwaway programs. Of course, throwaway programs have a tendency to grow up. To be good for writing throwaway programs, a language has to be available, interactive, with a command-line interface, and start up fast. And it should be brief.
  • Of course, library functions matter greatly when we're talking about brevity. Paul makes what I thought was an important point here: Programming language design will not be about whether to make your language strongly or weakly typed, or object oriented, or functional, or whatever, but about how to design great libraries. He also says: Perl wins because it has large libraries for manipulating strings. ... Many Perl programs probably begin as just a couple of library calls stuck together.
  • Syntax may not matter as much as Lisp apologists think it does. He says: Perl syntax can be pretty incomprehensible, but that has not stood in the way of Perl's popularity. If anything it may have helped foster a Perl cult.
  • To have an efficient language and libraries, it's more important to have a good profiler than it is to, say, make a language strongly typed. If people can find out what's expensive, they'll fix things. Maybe we should highlight slow parts of the programs in our editors. Efficiency will probably matter more as more and more programs get stuck on application servers.
  • The last ingredient a popular language needs is time. No one wants to write programs in a language that might go away, as so many programming languages do. Of course, Perl has gotten past that part of the curve. It may take Perl 6 a while, though.
  • Programming languages, especially, don't get redesigned enough.
He finishes up with a description of the hacker's dream language. Although Perl fits some points, it has a ways to go in others. I hope Perl 6 succeeds in those dimensions. Read the essay; it's worth your time.

update: I asked Paul to make an ASCII version available as well; he put it up at

Replies are listed 'Best First'.
Re: Being Popular
by grinder (Bishop) on Aug 02, 2001 at 15:00 UTC

    That awful typeface is such a blight. I don't know why people persist using it. Still, you are right, reading it is time well spent.

    [...] Early Lisps let you get your hands on everything. A good deal of that spirit is, fortunately, preserved in macros. What a wonderful thing, to be able to make arbitrary transformations on the source code.

    I would love to be able to rewrite the op-code tree in a Perl program. I know it is possible, that there are modules that let you get your hands on that sort of stuff, but it's not something I've spent any time researching.

    For instance, a reccurring code pattern I encounter is iterating through a list, and processing each element, but also having an if condition in that loop that can only be true once. It would be nice that once that path was taken and acted upon, to rewrite the op-tree so that the if condition just disappears and the loop tightens up and runs faster (i.e. by having more code fitting in the CPU cache). This happens to me all the time.

    I do have significant reserves, however, as to what that could do to the comprehensibility of the program, both in terms of reading the code and following execution in, say, a debugger. But if it were "done right", I would use it. There are other ways to achieve this explicitly, such as falling out of the loop with the if, into a loop without the if, but then this leads to having the same code in different locations on the code. (And if you're in a tight loop, you probably don't want the cost of calling a subroutine that factors the code anyway)...

    We can get rid of (or make optional) a lot of parentheses by making indentation significant. That's how programmers read code anyway: when indentation says one thing and delimiters say another, we go by the indentation. Treating indentation as significant would eliminate this common source of bugs as well as making programs shorter.

    I beg to differ. I agree that we go by indentation, but everybody has their own style of indentation. The canonical way to understand code written in a style other than your own is to run it through a pretty printer, be it B::Deparse, PerlTidy or something else. Assigning semantic information to indentation is, IMHO, wrong.

    For instance, the other day, I was writing some code to generate some tables. CGI offers some useful short-cuts for generating code, such as passing references to lists, in order to generate multiple HTML elements of the same kind, e.g.:

      print $q->ul( $q->li( [@INC] ));

    This will print out your INC array in a bulletted list. And you can't get much more compact than that. There are times, however, when it's just too much effort to try and pull that off, especially when dealing with nested tables, because then you have to juggle tables, TRs and tds. CGI lets you import special names, such as:

      use CGI qw/*table *TR *td/;

    ... that will define the methods start_table(), end_table(), start_TR and so forth. So I wound up using indentation to help me keep track of what was happening. The code looked something like this:

    print $q->start_table( {-bgcolor=>'#000000', -align=>'center'} ), $q->start_TR( {-valign='bottom'} ), $q->start_td( {-bgcolor=>'#ffe0a0'} ); foreach( @list ) { # do lots of wierd stuff and emit nested tables } print $q->end_td, $q->end_TR, $q->end_table;

    Now I have no idea what Python would make of that, but I suspect it would have a fit. Creative use of whitespace goes a long way, in terms of letting you line things up correctly, to make sure that everythings comes out balanced. What is opened, is closed, what is pushed, is popped, and so on. This should not be under-estimated.

    So, in practice, the way to get fast code is to have a very good profiler, rather than by, say, making the language strongly typed. [...] you need to be able to find out where the bottlenecks are.

    [...]Language designers like to write fast compilers. That's how they measure their skill. They think of the profiler as an add-on, at best. But in practice a good profiler maydo more to improve the speed of actual programs written in the language than a compiler that generates fast code.

    Yes! I was pleasantly surprised the first time I used Devel::DProf to find out just how infinitesimal the slowdown was when just counting subroutines. (I've never had to resort to counting lines, so I don't know if that's painful or not). I have memories of C programs taking really huge speed hits when profiled.

    I have long wished for a development environment that would take the profiled output of run n-1 and use that to make informed guesses as to how the code should be generated in version n. It could rearrange the way code blocks are ordered in the output bytesteam to ensure that the code branches as little as possible, or that frequent references to different code (e.g. subroutines) are coalesced into arenas that fit on a page. There are a number of optimisations a compiler could perform if it had access to the way the code was likely to behave.

    g r i n d e r
      I beg to differ. I agree that we go by indentation, but everybody has their own style of indentation. The canonical way to understand code written in a style other than your own is to run it through a pretty printer, be it B::Deparse, PerlTidy or something else. Assigning semantic information to indentation is, IMHO, wrong.

      I clearly second this. Fortran made use of indentation as syntactic/semantic information representation. I have been told it is a mess.

      As for the essay itself: Itīs a nice subsumption of some views on the reasons for a language becoming popular. It is worth a read even for those that evidently donīt like Lisp (like me). Iīm really into programming since 1987. Have done so before, but rational programing for 14 years now. Why did perl become my popular language?

      The answer is simple: 95% because its features match my needs best, and 5% because I saw cool people practicing perl. It was really a shock 1995, when I (used to some "my lang is better than your lang"), after converting from C to C++ (feeling itīs mightier but not the right thing) saw how perl-hackers looked at all this "which lang is the best" with a ENORMOUS amount of peace and humor which only could mean that they had found something.

      Then I was told to do a project I wanted to do in C in perl...
      I didnīt like this command but obeyed. About one week later I was happy like a kid in a toy shop for having the possibility to work with such a great lang.

      If only there was a good Prolog<->Perl interface. (hint hint) :-)


Re: Being Popular
by AidanLee (Chaplain) on Aug 03, 2001 at 18:25 UTC
    I'm having difficulty finding a windows program for reading postscript files. Can anyone offer a suggestion for those of us who don't have our own *nix box?
      I have unix machines, but none of them run X, so having Unix is necessary but not sufficient.

      I have Adobe's Acrobat Distiller, so I was able to convert the file to PDF and read that. If that is not an option for you, there are versions of Ghostscript for Windows.

      g r i n d e r
      If you cannot print out the PS file directly to a Postscript printer Ghostscript will do the job. Ghostscript is available for Unix, Windows,Macs, and maybe some other plattforms. E.g. Ghostscript will allow you with the "ps2pdf" command to translate PS-Files to PDFs.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://101588]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2022-08-19 23:26 GMT
Find Nodes?
    Voting Booth?

    No recent polls found