Perl spamming script available

On September 12 I posted an entry here asking about Perl scripts to spam friends with party invitations.  My young genius friend Will Crawford was over for lunch today and we implemented the proposed improvements to Ryan Tate’s original design.  The final script is available at http://philip.greenspun.com/software/brunch-spam.pl.txt and enables you to populated a structured text file with email addresses, full names, an affiliation reminder, and keywords (so you can have a mass invitation or one just to poker friends or one just to friends with young kids).


[Update:  Ryan posted an improved version of the feature-enhanced script at http://www.ocf.berkeley.edu/~ryantate/brunch-spam2.pl.txt]

11 thoughts on “Perl spamming script available

  1. Philip, it never ceases to surprise me that with all the praises you sing about Tcl, whenever outside of AOLserver, you are just another Perl whore!

  2. What praises did I ever sing about Tcl? The only computer languages in which I might qualify as an expert are Lisp and SQL. I chose AOLserver in 1995 as the best available tool for making RDBMS-backed Web sites because it was the first server to do connection pooling and to have a script interpreter built in (about a 100X performance improvement over CGI scripts reopening Oracle). AOLserver happened to have Tcl built in so I used it to merge HTML templates with the results of SQL queries. That doesn’t make me a Tcl advocate or even a Tcl programmer since I’ve never built anything larger than a Web page with Tcl.

    One thing that IS kind of sad is how moribund computer software tools are. AOLserver was written by two guys in a few months in 1994/95. My friends who have been coding with Microsoft .NET tell me that in many ways they were more productive using AOLserver. My students who used Java got so little done that they had to drop the class. The PHP crowd struggles with language implementation bugs. By this time, nearly a decade after the introduction of AOLserver, I would have expected to see standard tools where programmers concentrated on specifying the page flow, the data model, and the transactions that happened on each page. Instead the tools have changed so little that the only way to increase programmer productivity (output per $ of labor) is to find programmers in Third World countries who will work for fewer $$.

  3. I guess you have a point there, you were mainly singing AOLserver’s paraises – with good cause.

    I am working on a reasonably complex app (is anythign these days?) in AOLserver in my spare time again now. It’s amazing how fast I work. I don’t mind Java much – as long as you stay away from any of those much touted “frameworks” everyone says you need – but AOLserver still kicks butt; in ease/speed of development, performance and reliability. (and predictability, as compared to PHP!)

    I think the main problem for the lack of those tools you want is that once you use a tool, you limit what you can do; how things look and how things work. And it’s exactly the kind of companies that could afford that kind of tool are the ones the have comities that design website that, above all and at all cost in usability, want to be different from everyone else.

    Though you have put a thought into my head now! 🙂

  4. What do you use to store all your names, addresses, etc. as a matter of interest? I keep them in the palm desktop application, for what it’s worth. Personally, I usually do stuff like this by pulling a text file export into excel, sorting out the columns I actually need, doing any search-and-replace in Word and then mailing in a regular mail package. I guess I just don’t do that many mailings …

  5. I switched from a flat text file edited in Emacs to MSFT Outlook when I got a PalmOne Treo (huge mistake!) in 2002. I’m glad that I have standardized on Outlook because now I can sync with any new device that I get, e.g., the Motorola phone that I just bought to replace Treo #10 that died.

    I do about 3 mailings per month and might start doing more now that I can narrow by interest.

  6. At risk of paraphrasing some of the Panda book, at some point, rather than mourning the sad state of the tools that you have, you have to move beyond that to the next level. Engineers do not endlessly quibble over whether ball peen hammers are better than claw hammers, they look at the overall process. The sad thing about software – and why it is still very expensive – is that noone has really figured out what makes programmers productive, and how to reproduce that productivity. In my opinion this is why a lot of coding has moved to the third world. Lots of hype about how Programmer X is 10x/100x more productive than programmer Y, but no real quantifiable facts. So the natural inference is that Programmer X making 50K a year is less productive than the programmer making 5K a year, no matter what. Of course there is still lots of money to be made making the process (measuring programmer productivity) look like black magic, so people keep spinning that, trading local gains for global losses.
    The number one constraint I see on software development is what a stats prof of mine called a “Type III Error” – solving the wrong problem. Not meeting customer needs, or meeting customer needs but bankrupting them in the process. A process problem, not a tool problem. It doesn’t matter what tool you use if you don’t actually use it to build something that people want. And that is still hard, labor-intensive work.

  7. yawn.

    I hear a lot of whinging about the lack of good software tools, and to some extent it’s justified — whenever you’re doing enterprise programming, for example, it’s pretty clear that Java and .NET add an awful lot of complexity for very little in return.

    For Web programming, it’s just not true. Languages like Tcl and Java
    are simply not suited to Web programming; I’m not sure why. In my experience Perl and especially Python (and probably Ruby) allow you to do a great job of separating “business logic” from presentation etc. PHP strikes me as the worst of all combinations for anything serious: limited programming language combined with serious foundational problems.

    I learned much of what I know about Web programming from Greenspun advocates and it all holds; I just got sick of the general lack of encapsulation & spaghetti programming encouraged by Tcl, and switched to Python. Now I’m happy.

    Java, .NET, and PHP are all straw men, for various reasons. Learn Python & implement a Web app using Quixote (my pref) or one of the other Web frameworks and then tell me that there’s a lot of unnecessary cruft on page… I dare you ;).

    (Perhaps PHP and Tcl solve opposite problems to Java and .NET? PHP and Tcl are great for simple little pages but do a poor job of encapsulation and extension; Java and (by rep) .NET are great for certain kinds of site frameworks, but suck for the simple little pages that make up the (easy) 99% of Web sites.)

    –titus

  8. Titus, it’s not the tool, it’s the programmer. Saying spageti code is “encouraged” by Tcl is a very misinformed statement. You may use Tcl any way you like and I can assure you that there is no spageti code in any of my projects.

    What surprises me even more is that you seem to like Python and its OO programming, yet you don’t like Java. (are you mistaking Java for “Enterprise Java Beans”?)

    Sounds to me like you are comparing programming straight JSPs or ADPs without writing much library code to writing Perl/Python using a seperate presentation layer. That’s comparing apples and oranges.

  9. Most of the Tcl tutorials & libraries & code I’ve seen is spaghetti code. I haven’t written enough programs in [incr Tcl] to know if the OO layer slapped on top helps encourage abstraction, but I don’t think Tcl does by itself.

    Most of the Java tutorials & libraries & code I’ve seen is over-engineered OOgunk. Java certainly encourages this.

    Sure, it’s possible to write beautiful code in pretty much any language, even assembly. What I personally enjoy about Python is the way it encourages abstraction & rewards re-use. I haven’t seen this with any other scripting language. YMMV ;); I’m only familiar with Java, Tcl, C/C++, Python, and Perl.

    Regardless, complaining about how moribund software tools are is silly when you’re still coding in straight Tcl. IMNSHO.

  10. I used to work for a company that also used Tcl for web development based in Apache/Tcl/XML.

    Most of the web development framework was based in ideas from the AOLServer. And boy I do miss those development days.

    I am yet to see a web development environment as cool as that one.

Comments are closed.