Computational feces.

I used to think that PHP was the biggest, stinkiest dump that the computer industry had taken on my life in a decade. Then I started needing to do things that could only be accomplished in AppleScript.
Tags: , ,

66 Responses:

  1. Non Intanon says:

    never try AppleScript but I'm pretty sure you're not alone!

  2. hattifattener says:

    It's true. At least PHP has something approaching a grammar.

    (I actually kinda like the event+object model that Applescript is an interface to— you can talk AppleEvents from saner languages using things like python appscript (pretty sure there are equivalents for your major scripting language of choice).)

  3. cswheeler says:

    I once found myself writing a desktop publishing automation app with AppleScript. Shortly before going insane I discovered appscript, a Python (and now Ruby and Objective-C, apparently) library that exposes the underlying Apple Events mechanism and scripting dictionaries in a reasonable way. Anything you can do with AppleScript, you can do with appscript, and that way you get to use a programming language with fancy things like stack traces! It's been years since I touched it, but it was a godsend.

  4. mobiGeek says:

    So you have never had to write a .bat script?? Lucky man!

  5. Adam Morris says:

    I completely agree; that's why I wrote Python classes that wraps around appscript. So, that way, I'm Applescripting in Python in ways that make total sense.

  6. Jack Nutting says:

    Too true. The applescript language itself is a horror to try to write in, though it's actually fairly easy to read. If perl is sometimes accused of being a "write-only" language, applescript is "read-only".

    As others have said, the model and feature-set under the language is actually pretty decent. If you need to use it without going mad, appscript is the way.

  7. David Glover says:

    Perhaps your hacks page needs an update, since it still claims "PHP is kinda cool."

    ;)

  8. Kevin Cantu says:

    Last time I checked, JavaScript was a fully supported alternative for those APIs. That doesn't necessarily make them less horrible, though. :D

  9. Michael says:

    I remember being asked to write a relatively simple app in AppleScript during an Internship, since it was a pain to set up Windows manually for display.

    It would create 9 total Instances of various Programs, resize them, move them and initialize them (say, opening web-pages in Safari).

    I can still hear the screams of the Mac I used.

  10. Jeff says:

    Back in a former life (1995, in the glory days of System 7), I found myself needing to use AppleScript in order to get a copy of FileMaker Pro to talk to my then employer's WebStar web server. At the end of the project, I abandoned my own Mac in favor of a PC and learned C shortly thereafter. I don't know how much the language has evolved since then, but based on what you've written here in the past, my guess is "not much at all".

    Regarding PHP, I think that language has actually gotten better over time. Of course, I've heard several folks utter the phrase "polishing a turd" with respect to the improvements there, so maybe it's just me.

    Is there a language you actually like using these days?

    • Can't speak for jwz, but, in no particular order,

      - C. Well, I don't _like_ it, but it works. That's at least something to respect.
      - I'm actually warming up to Python. I still think the whitespace-as-syntax thing is a bullshit gimmick, but the language is... mostly decent.
      - For quick and dirty, get-shit-done, Perl is still king. No question.

      Just to rant, what with the surge of interest in pseudo-functional programming in Javascript, can we make a licence requirement for anyone trying that to actually at least read an article on functional programming? Because I don't think the vast majority of people doing this shit understand the point of it all, other than using anonymous functions as parameters everywhere. ('Cause it looks cool!') I don't expect them to understand lambda calculus - I doubt most of them have gotten very far past basic highschool algebra - but Jeebus. I recently saw some code where someone was trying, and failing, to implement something with a textbook 4-line recursive solution, in like 70 lines of crap, all written with the trendy "functional" style. I don't know if this is more cargo-cult or trend-junky behavior, but I'd almost rather read ca. 2001 "office web guru" PHP than this shit.

    • Pete says:

      PHP is always going to have the "designed backwards" problem, no matter how many new features are piled on top of it. Nothing is ever going to remove the fact that the original version thought global variables and functions were all you needed and OO programming could be left for version 2... or maybe 5.

      Because of that glorious history, every "polished" PHP class is littered with:

      $this->foo and $this->bar()

      instead of:

      $foo and bar()

      This is my least favourite feature of the language, because with years of experience in other OO languages I keep forgetting that I need to always tell PHP to operate on the damn class I'm writing now.

      • Frank Danforth says:

        That's a rather week criticism of PHP. There is a lot wrong with PHP. But being explicit about your scope is something many argue for, and other languages behave similarly. It should be a a minor annoyance at best.

        • Pete says:

          I don't care if other week [sic] languages have the same problem. A lot of languages with retro-fitted OO syntax have a similar problem, but they generally have the excuse that they're a lot older than PHP.

          Searching global scope for functions before class local scope is a pretty clear indication of a language with its priorities bass-ackwards.

  11. Fred Clausen says:

    I think it is weird how the grammar is supposed to be "natural"... which leads to a casual, almost friendly tone... which belies the fact that you are telling all these applications what to do like some kind of cruel fascist.

    tell application "iTunes"
    go fuck yourself
    end tell

  12. MattF says:

    I'm pretty sure that, once upon a time, there was an 'unfriendly' version of Applescript, i.e., one that looked like an actual programming language. Or maybe that just happened in a dream.

    • Jesper says:

      A long, long time ago, in a galaxy far, far, Mac OS 8, AppleScript used to come in dialects - several with all the keywords in different languages (and maybe a different grammar), and a planned version with a C-like syntax ("programmer's dialect"). Then they killed them.

      Nowadays, enlightened people use the Objective-C Scripting Bridge framework/command line tool combo or the many libraries for doing the same with Ruby, Python, Perl, etc.

      AppleScript itself is pretty much spells and leeches.

  13. TomW says:

    Another +1 for appscript. It brings much sanity to the world.

  14. Once there was an applescript that could be written in OTHER NATURAL LANGUAGES other than english. Just to say how crazy that thing was. I'm so happy they dropped it.

    Even of I even used to program in applescript/italian dialect, yes. O_O

    Anyway, you silly snobby perlhead, when Perl 6 went on his "design by committee" permanent iatus, who d'you think kept the web wheels spinning? PHP got the torch. And it's not leaving it.

    Even if some of the worst programmers in the world are using it.

    Still it's hard to prove the java and .NET crowd is smarter.

  15. Bob Bane says:

    I can put up with the COBOL-level verbosity of Applescript. I have never wanted to write more than simple automate-this-application scripts in it, and I can google for appropriate incantations as needed.

    What I cannot abide is the half-ass Applescript control interface many applications have. You get the feeling that the implementers wrote interface code to enable the few scripts they tested, then stopped. If the dictionary says an object Foo contains objects Bar, you may or may not be able to iterate over the Bars in Foo.

    • Don Hopkins says:

      The fundamental problem with English-like programming languages is that they set expectations way to high, that you can write anything you want and the computer will understand it.

      Bob Bane!!! Is that you from the University of Maryland Vax Lab? Been a while. Enjoy a delicious Foo Bar!

      • Bob Bane says:

        Yep, still me. Currently at NASA Goddard - the last time I was paid to write code in a language that didn't suck rocks was ... 2002?

        Maybe it's just me and my not getting the zen of Applescript, but when the standard dictionary says an application contains windows, I expect to be able to:
        repeat with aWindow in windows
        which doesn't work. Maybe I need to look for alternative incantations...

  16. tzs says:

    The major annoyance I find with Applescript is that it is so inconsistent between apps. Take Terminal. In Terminal, this does not work:

    tell application "Terminal"
    set my_tab to first tab of first window
    get container of my_tab
    end tell

    Getting the container of something is pretty basic, and works in nearly everything. Not Terminal.

    Or consider this. This does what you would expect in Terminal:

    tell application "Terminal"
    set current settings of first tab of first window to first settings set
    end tell

    However, this code, which one would reasonably expect in a sane language to be functionally identical, does not:

    tell application "Terminal"
    set first_set to first settings set
    set current settings of first tab of first window to first_set
    end tell

    But with a slight modification, it does work:

    tell application "Terminal"
    set first_set to a reference to first settings set
    set current settings of first tab of first window to first_set
    end tell

    Blech.

    • Jesper says:

      APIs differ everywhere; what makes AppleScript so annoying is that it claims to be like a programming language but english and has little other syntax than keywords, which means that the constructs should be polymorphic. It's as if you had to type array{8} for array indexing in one program and list in another.

  17. crispy says:

    So to go along with appscript and javascript_OSA there's FScript which is a load of awesome, if you like cocoa and smalltalk.

  18. johnny says:

    Congratulations and welcome to the club!
    php though arguably worse.

    • jwz says:

      When you say "AppleScript is better than PHP" it is impossible for anyone to believe that you have actually used AppleScript. Seriously.

  19. jsz says:

    try javascript ...

  20. I had the same experience: AppleScript Insanity

    AppleScript is a bit of a nightmare - how did anyone ever think that it was a good idea?

  21. I did a little bit in PHP before I realised I had an alternative. So glad I get to work in decent languages these days.

  22. Rubén says:

    Could you please elaborate on why do you think that PHP is a pile of shit?

    • George says:

      They can't. Everytime people say this, they never back it up with any substance.
      Do you think Facebook would work nearly as well as it does if PHP was such a pile of shit?

      • jwz says:

        Give me a fucking break. Just because it's used in successful products doesn't mean it's not a stinking pile of shit.

        Take your language evangelism to your own blog.

        • Rubén says:

          I _really_ want to know your full-fledged opinion on this, not trolling or anything; I would like to know it, if possible.

          I make a living among other things, by delivering PHP-based stuff to my clients. I've done so for many years and I'm quite happy with the way I can do things in this language.

          I've done some public, web-scale projects but mostly intranet stuff with a few hundreds or low thousands of users. LAPP is my stack of choice, and as of late, Eclipse and /or Netbeans for the IDE.

          I've cringed a bit on the argument order of some functions, but in general this has been a great platform to work with.

          That being said, I know who you are and where you come from (as a programmer, through your blog) and would appreciate your opinion.

          • jwz says:

            The constant, constant stream of security flaws in PHP stems from the fact that they bolted on security (and modern innovations like, I dunno, not using global variables for everything!) long after it was deployed and in wide use. They've tried to incrementally repair all that shit, and made some progress, but can never succeed because those terrible decisions are enshrined at the lowest possible level. Cross-site scriping and SQL-injection holes are as endemic to the design of PHP as buffer overflows are to C: they are built in to the language. Sure, it's possible to write PHP code that doesn't fall into any of these tiger-pits; but in the grand scheme of things, it's unlikely. You're going to miss something, because it's fail-open instead of fail-safe.

            Also, just like the fundamental design of Perl encourages you to use regexps for everything possible (since they are far and away the most obvious tool in the box) PHP encourages willy-nilly conflation of view and model/controller, which has been widely understood to be a terrible idea since roughly the Cretaceous. So in PHP, the most obvious way to just get something simple done quickly is a terrible way to do it, and that will come back and bite you in the ass later, even though you got there by thinking, "yeah but I'm in a hurry, so just this once."

            And that's just off the top of my head. And I've been drinking. So there you go.

            • houtsnip says:

              You're right in that conflation of view and model/controller is an obvious way to do things in PHP. Any beginner (and there are lots of these in the PHP world) would think, 'Aha! I'll do it like that.' And you didn't mention another obvious way of doing things in PHP, which is to have a separate PHP file to handle each web page. This is how PHP was meant to be used in the beginning.

              But I never get bitten in the arse by these things because I never do them, because I know what I'm doing, and I'm not an idiot. I never think 'just this once', even when I'm in a hurry.

              • Breton says:

                So PHP isn't shit because you're a real man, and you know what you're doing, so stand back, ladies?

                Uhhhh.... we got a rising debate star here folks.

            • Breton says:

              Just to save some personal dignity, I didn't suggest PHP in the other thread out of any loyalty to PHP. It's just there, and convenient for quick shit jobs where I can't be bothered installing/compiling/packagemanaging some behemoth scripting environment. I'm glad you got something that sort of works in the end.

            • Rubén says:

              Thanks :-)

              Just one more: In your opinion, Which one is the language and/or framework that least encourages bad design and is least fail-open?

            • Joe Johnston says:

              All these points pale in comparison to PHP not having a sane, simple command line debugger that ships with the product. Perl, Python, Java and many, many others do. PHP has XDebug, which is is clever and maddening at the same time.

              I enjoy working in PHP more than, say, VBScript.

          • Don Hopkins says:

            I wrote this summary a while ago, and you asked, so here goes:

            If you're a PHP programmer, you're irresponsible if you're not already aware of its flaws, because you have not educated yourself by reading any of the following well publicized articles. Once you understand the flaws of PHP, you can't honestly make the statement that it's a well designed language suitable for teaching programming to kids.

            First there is this classic article, Edwin Martin's "What I don't Like about PHP" [http://www.bitstorm.org/edwin/en/php/], which goes into detail about the following fundamental flaws:

            1. Bad recursion
            2. Many PHP-modules are not thread safe
            3. PHP is crippled for commercial reasons
            4. No namespaces
            5. Non-standard date format characters
            6. Confusing licenses
            7. Inconsequent function naming convention
            8. Magic quotes hell
            9. Framework seldom used
            10. No Unicode
            11. Slow

            Then there is the mind-set of the PHP language designers and community, which is deeply flawed. Ian Bicking's "PHP Ghetto" article [http://blog.ianbicking.org/php-ghetto.html] sums up the problem with PHP's design and community pretty well:

            I think the Broken Windows [http://en.wikipedia.org/wiki/Broken_Windows] theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes [http://us2.php.net/manual/en/security.magicquotes.php]. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.

            Jonathan Ellis' "Why PHP sucks" article [http://spyced.blogspot.com/2005/06/why-php-sucks.html] makes a lot of good points and links to many other sites with more information to back up the claim that PHP sucks.

            He perfectly summarizes the yapping of the PHP apologists when he says: Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better."

            He summarizes:

            In short, PHP sucks because, PHP's authors are prone to confuse "pragmatism" (a fine design goal, if done well) with "adding random features without considering how they impact the language as a whole." Thus, its authors have found it necessary to correct obvious flaws in both minor and major releases, with the result that the recent PHP5 breaks with the past to an unprecedented degree while still leaving many fundamental flaws un-addressed. I don't know if this is because they didn't recognize those flaws, or more likely, because they were willing to impose "requires a lot of pain to upgrade" but not "requires a complete re-write."

            There is also a lot of great stuff about why PHP is so bad on http://www.ranting-wolf.info [http://replay.web.archive.org/20090530073349/http://www.ranting-wolf.info/category/technology/programming/php/] including a concise description of why the "Smarty" templating system is such a horribly ill conceive and terribly implemented idea.

            And if you're still not convinced the design of PHP is deeply flawed, because language design is HARD and should only be attempted on purpose by experienced people, here's what the Father of PHP Rasmus Lerdorf himself said in an ITConversations interview [broken link], quoted in "Why PHP sucks, Part III" [http://www.dasgenie.com/scrap/archives/000060.html]:

            "I don't know how to stop it, there was never any intend to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way".

            There you go. The designer of PHP himself admits he literally had no idea what he was doing! It's absolutely foolish to teach PHP as a first programming language. Kids deserve much better than that.

            -Don

            [Then some moron derped "Smarty is a good way to keep template designers out of your PHP code" so I followed up:]

            You are absolutely wrong about Smarty, which is a horribly conceived and implemented disaster. Don't be such a yapping apologist, just because you managed to throw together your home page in PHP without knowing any other languages.

            I am speaking from experience, having had to use PHP and Smarty, and having read the source code to Smarty in an vain attempt to figure out how it worked and why it was so difficult to get it to do even the simplest things correctly. I've been much happier using other better designed templating systems, which I will describe below.

            You should read Wolf's Rants about PHP: Truth about short open tags and Smarty [http://replay.web.archive.org/20090430054124/http://www.ranting-wolf.info/2008/03/21/php-truth-about-short-open-tags-and-smarty/].

            After this point, the discussion about the tags comes from shopt open tags to "then what should I use for templating?!? and people would go "Wooo! Smarty! Go with Smarty!", and would make me slap people senseless just for saying that. Just as hating PHP for number of damn good reasons, I have a number of hating Smarty to go along with it. Brace yourself, because here it goes:

            1. Smarty is programming language
            2. Smarty is overkill in majority of cases
            3. Speed: Smarty isn't a solution. it's the major problem.

            and here go the details about stated points above:

            1. Most people would argue, that Smarty is a good solution for templating. I really can't see any valid reasons, that that is so. Specially since "Templating" and "Language" should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is "better for designers, since they don't need to learn PHP!". Wait. What? You're not learning one programming language, but you're learning some other? What's the point in that, anyway? Do us all a favour, and just *think* the next time you issue that statement, okay?
            2. I think, that "overkill" is an understatement. You're trying to disguise simple outputting in a complex set of classes,which implements a programming language inside of it -- Definitively overkill". "But it does caching". No, not really. "Caching", in the terms of Smarty is nothing else than converting that template code into PHP. See? I told you there is no point in using Smarty. It doesn't make your life easier. It doesn't make developer's life easier, and it doesn't make server's life easier.
            3. The previous paragraph says it all about the speed slugs in Smarty, but I feel the urge to recap that:
            1. "caching" mechanism sucks. It's not a proper caching. It's just a conversion of one interpreted language to another one. and in very unoptimized way. If you want to do the proper cachin, go with APC, Zend optimiser or EAcellerator.
            2. The implementation of one interpreted language in another interpreted language does nothing but slow everything down

            [I wrote some constructive criticism about how templating should be done in the rest of the message, here: http://ask.slashdot.org/comments.pl?sid=621541&cid=24331919%5D

            • Rubén says:

              Looks like PHP is on par with Perl, Ruby. It's a solid runner to Python and in a completely different league than everything else.

              http://shootout.alioth.debian.org/

            • houtsnip says:

              I don't think the broken windows theory applies to the PHP world.

              In my opinion, people write crap PHP because the companies that pay for these sort of applications actually want a cheap, shoddy product (well cheap, mainly). Therefore they choose PHP because it's the easiest language to learn, and so they can employ cheap programmers, who are also crap. Then the companies encourage these programmers to write crap code as quickly as possible. No effort is spent on maintainability because these sorts of companies don't care about that, and they wouldn't even realize if their programmers were writing anything good or not. There is a culture of crap. It's not that there's a broken window here or there, it's just that most PHP applications were built like a shanty town right from the word go.

            • fripletister says:

              PHP5 has namespacing, magic quotes should always be off anyway, and see the mbstring extension for Unicode support.

              I agree with most of the rest of your post, though I quite like PHP (or should I say I'm very comfortable with it) due to having an intimate familiarity with the language at this point. To each his own.

      • Jeff says:

        Lets not forget that Facebook had to write their interpreter:
        http://www.sdtimes.com/blog/post/2010/01/30/Facebook-rewrites-PHP-runtime.aspx

        Do you think Facebook would have written it's own interpreter if PHP wasn't such a pile of shit?

        • jwz says:

          Facebook wrote (basically) a PHP-to-C compiler, for speed. My complaints about PHP have nothing to do with performance, and anyway, not all sites have Facebook's performance requirements.

          Damn you for making me defend PHP, but you're slamming it for the wrong reasons.

          • Jeff says:

            Thanks for the clarification. Didn't realize that FB wrote a PHP to C++ translator and than complied with g++:
            http://www.readwriteweb.com/archives/facebook_gets_faster_debuts_homegrown_php_compiler.php

            Summary
            * I was supporting the "PHP is slow" complaint voiced in other comments/links
            * Doesn't using C++ solve other PHP problems, like multi-threading?
            * Does translating to C++ imply PHP is fundamentally flawed, not just slow?
            * What language/framework should we use for websites? Python? Perl? ROR?

            Jeff's Theorem:
            All websites becomes usenet.

            • fripletister says:

              Doesn't using C++ solve other PHP problems, like multi-threading?

              No. Not only does PHP lack thread-safety (variable/object synchronization/locking), the core library functions and extensions that are currently not thread-safe will need to be rewritten to take advantage of the feature. Translating to C++ doesn't have anything to do with this.

              Does translating to C++ imply PHP is fundamentally flawed, not just slow?

              No? Why would it? PHP is flawed in many aspects, but translating to C++ doesn't address them. It just means every time a page is requested there's no interpretation going on, since the script has been translated and compiled to a native binary.

              What language/framework should we use for websites? Python? Perl? ROR?

              Use whatever you're comfortable with. I've been writing PHP for 10 years, and just because it isn't perfect doesn't mean it isn't a usable language if you understand its flaws and are aware of its limitations.

    • Don Hopkins says:

      Because monolinguistic people like you use it as their first and only language, without realizing its deep and horrible flaws.
      If you learned a second language, you'd realize that programming doesn't have to be so horrible.

      • Breton says:

        Oh hi Don, big fan of yours. I love your cranky programmer aficionado screeds, and micropolis. ^_^

      • Rubén says:

        It seems that you are a programmer of note, so kudos to you.

        But I'm not monolingual, and inferring so from a simple question it's not that smart.