Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
PHP The Internet

'Why PHP Still Beats Your Next Favourite Alternative' (youtube.com) 85

Posted by EditorDavid from the hypertext-preprocessing dept.
Long-time Slashdot reader Qbertino writes: On PHPday in Verona (Italy) Rasmus Lerdorf, creator of PHP, gave an enlightening talk on PHP and its history. 25 years of PHP (video of the talk) is ripe with details on PHP, the design choices behind the web's favorite server-side templating language and with explanations on why what you may think of as an inconsistent mess actually makes perfect sense just the way it is. Very insightful, fun, interesting and a must-watch for PHP lovers and haters alike.
Introducing one slide, Lerdorf remembers that in the 1990s, "the web looked like this -- CGI bins written in C."

But he also shows his first computers from the 1980s at the beginning of the talk, before moving on to screenshots of Gopher, and then of the Mosaic browser. "This changed everything. And not just for me, for everybody...

"Everybody around at the time, playing with this stuff, and having had UUCP addresses and playing with Usenet and bulletin boards -- it was very easy to see that this was going to change the world."
This discussion has been archived. No new comments can be posted.

'Why PHP Still Beats Your Next Favourite Alternative' More

'Why PHP Still Beats Your Next Favourite Alternative'

Comments Filter:

  • cgi-bins (Score:4, Funny)

    by jrumney ( 197329 ) on Saturday August 31, 2019 @06:49PM (#59144826)

    My recollection of early web is that it was not so much cgi-bins written in C, as cgi-bins written in perl. Perl was of coure known as a write only language, so good luck with maintenance.

    • My recollection of early web is that it was not so much cgi-bins written in C, as cgi-bins written in perl.

      That is my recollection as well. I've seen a lot of very old perl on web servers, but hardly any C (well, okay, excluding the OS that is).

      Perl had the advantage of being mostly portable, whether you were on HP-UX or AIX or Solaris. What's kind of funny is nowadays this might be arguably somewhat less important, what with the ubiquity of Linux servers nowadays. But scripting languages have already won the game.

      • I remember writing a big thing in C back in the day and being happy when I discovered PHP 3. They didn't teach Perl at my school, all I knew back then was C, C++ and Java.
      • He didnâ(TM)t mention perl there bc he knows PHP doesnâ(TM)t win that comparison. PHP: itâ(TM)s better than writing a web site in C!
    • This. It was perl for a good 10 years before I ever heard of PHP.

    • Perl is no worse than the PHP, the visual basic of the internet

      • Re: (Score:2, Funny)

        by KiloByte ( 825081 )

        Perl is a lot more idiot-proof, which is why idiots moved to PHP and Visual Basic.

        • Perl scripts are like farts. Mine are the only ones that don't stink.

          • Perl scripts are as good as their comments.

            As such, it is a language suited to people who would rather talk than write code, or true geniuses.

            If you don't comment your code, then only Perl geniuses will be able to comprehend it later. That's okay for them, for madness for anyone else.

            I always commented the living shit out of my Perl, at least any lines that weren't essentially self-commenting because of use of comprehensible variable names. As a result, I could understand it when I needed to change it. Any

        • Unlike PHP, Perl etc. it has static typing. Regexp is weak, but otherwise it has most of what a modern language has.

          OK, so it uses End If instead of {}. End If is actually better, but it hardly matters.

          It could, in theory, be compiled to very efficient code but that is not needed for the types of applications that it is used for.

      • I actually wrote a few CGI scripts in Visual Basic in the late 90s. NT Workstation running Apache 1.x...

        The move to LAMP was a fantastic improvement for me....

      • Re: (Score:2)

        by Bigbutt ( 65939 )

        I write perl scripts and have for many years. They work great for my sysadmin work. But being at several companies where internet access by servers is restricted, sometimes heavily, php was a better choice for web pages as it just worked without pulling from CPAN. And I had immediate access to mysql for data storage.

        [John]

    • You are correct, of course. For me at least, it was Perl's flexibility in string manipulation and native regex that really made it shine for cgi-bins. Today I do a fair amount of work in Python and every time I have to do parsing/matching/manipulation I think back longingly to the old days of Perl.

      • So why do you bother with Python? For any kind of string work, Perl is massively superior -- even for basic ASCII. And with Unicode, both Python 2 and Python 3 are a shitstorm.

        • Er, the bulk of the work I'm doing these days isn't manipulating strings, but rather data analysis, so it's not as important....but there are occasions where I do use Perl for preprocessing/data normalization.

        • Python 3 unicode looks actually pretty straight forward to me: https://docs.python.org/3/howt... [python.org]

        • I'm afraid that with Unicode, almost _everything_ is a shitstorm. I'm very unhappy with the careless insertion of Unicode where it has absolutely no use and actively hinders safe, reliable computing. Cleaning up after it has been a consistent part of my debugging work for _years_.

        • Re: (Score:2)

          by guruevi ( 827432 )

          Back in the day, we had to parse every pieces of data into our own strings and into arrays etc. nowadays all that string parsing is handled by libraries, things we couldn't afford to waste space and cycles on way back when.

          Yes programming is better now but there is a reason we had Perl although it is superseded for commercial purposes, having at least a cursory knowledge helps real programmers write better.

    • Re: (Score:1)

      by HGG ( 176028 )

      Yep, all Perl in the early days. There were "hello world" examples for CGI in an assortment of languages (including Forth?) but real life was Perl and CGI.pm. .

      PHP: There were and are some useful apps in PHP. But I don't trust it or them. I maintained a Fortune 100's OSS toolkit for over a decade. Was responsible for getting security upgrades, building them from source, and getting them distributed to in-house developers. PHP and all things developed in PHP were regulars on the security ag

      • Re: (Score:2)

        by Megane ( 129182 )

        #1 was not Perl's fault. Any lone developer's first app in a language is likely to be crap. Maybe even the second or third too. And manglement will prevent cleaning up technical debt code no matter the language, which is why COBOL is still a thing.

        My big problem with Perl is that some of its implementors took TMTOWTDI too seriously and put in brain-twisting atrocities like "(statement) IF (condition)" and the even more evil "(statement) UNLESS (condition)", letting "clever" people play fast and loose with

    • I believe Apache came with a few c CGI programs - imagemap maybe - but, yes, the rest was Perl.

      Anybody who spent an hour learning the basic sigils and data types could maintain it just fine.

      PHP came along and promised to remove annoying things like having to say 'use CGI;' and shoved everything into global variables so confusing things like scoping and type checking wouldn't stand in "programmers'" way.

      The lowest common-sense bars to writing server-side code were removed and everybody who felt security was

      • PHP came along and promised to remove annoying things like having to say 'use CGI;'

        First we were using C, Perl, or even shell scripting to do CGI. ColdFusion came along and showed us what it was like to inline code into HTML. PHP brought that to the masses. What really killed Perl for web pages was that mod_perl didn't inline perl into HTML like mod_php does. That's what people wanted. Perl didn't provide it, so they went to PHP. It had nothing to do with use statements, or blizzards of punctuation characters.

        Ironically you can inline multiple scripting languages into one webapp with IIS,

        • Re: (Score:2)

          by jrumney ( 197329 )

          As he says in his talk, what killed mod_perl is that it was too powerful to be used on shared hosting. The inlining into HTML is a nice to have, but proper templating is better, and possible in any language.

          • As he says in his talk, what killed mod_perl is that it was too powerful to be used on shared hosting.

            Too powerful? Too unsupported. Virtually no hosting companies offered mod_perl.

            • Re: (Score:2)

              by jrumney ( 197329 )

              Hosting companies didn't offer mod_perl because it allows you to intercept pretty much any stage of the request handling within Apache (too powerful), which opens up all kinds of security holes on a shared hosting site. As he says in his talk, before VM based virtual private servers, the only way you could get mod_perl was to pay for your own dedicated hardware.

    • Re: (Score:2)

      by unity ( 1740 )
      I was happy to find that archive.org has my free perl cgi scripts library from 1997 archived.

    • Perl was of coure known as a write only language, so good luck with maintenance.

      Maintenance: Just let your cat walk across the keyboard. Chances are high that this will end up being a syntactically correct perl 1-liner that might successfully fix your bug. :3

    • Re: (Score:2)

      by Megane ( 129182 )
      Unless someone completely rewrote it in something else, Slashdot is not just written in Perl, it uses mod-perl, which hooks the Perl interpreter directly into Apache.
    • I love being the one-eyed man in the land of the blind. I can read perl fine.

    • Re: (Score:2)

      by sad_ ( 7868 )

      perl was once known as the duct tape of the internet.

  • cgi-bin in Turbo Pascal (Score:3)

    by lsllll ( 830002 ) on Saturday August 31, 2019 @08:29PM (#59144966)
    I wrote a complete application in 1996 with login and everything for a client's remote offices to view customer bills via a web interface, all in Turbo Pascal and using cgi-bin. Slow it was, but it didn't need to server thousands (or even hundreds) of users at the same time, so it did the job. Those were the days.

    • Re: (Score:2)

      by godrik ( 1287354 )

      Yeah... th good old days. I wrote a website in bash to prove a point once. And I wrote an other one in ocaml to learn that language. Good old cgi-bin...

  • php beaten by almost everything (Score:3, Insightful)

    by iggymanz ( 596061 ) on Saturday August 31, 2019 @08:35PM (#59144970)

    PHP attracks developers with low motivation and skills, it's like the person who joins the band to play the kazoo or rhythm sticks

    PHP has awful security record, it's the main reason linux servers get hacked. The wares written in it have awful security record.

    PHP, just say no. Use something else.

    • I'm certain WordPress would get the same exact amount of Linux servers hacked if it was written in Rust instead.

    • PHP attracts all kinds of developers. The good and the bad ones. The reason is that PHP is so easy. Easy to write and easy to deploy. Itâ(TM)s not PHPâ(TM)s fault that so many people suck at writing code. So, itâ(TM)s not PHP with the awful security record, itâ(TM)s those many PHP developers with an awful security record. Itâ(TM)s not difficult to write a secure website with PHP. Take a look at this PHP framework [banshee-php.org] for example. Proofs that there is nothing wrong with PHP.

    • mod-php:

      - We don't have memory-leaks, we have timeouts. Shitty code in a shitty file? No problem. If it calls, it fails. Everything else just keeps working.

      - I can host 100 000 Projects on a single instance of LAMP and still have 0% cpu load.

      - This is deployment for a PHP project: Copy. Paste. Finished.

      - If Apache isn't running, you're either on default Windows or the power has gone out. ... So, how is babysitting your favourite Java/Scala/Whatnot appserver or node cluster 24

      • Think the biggest issues with PHP are the low cost of entry/lack of barriers to implementation/deployment and the fact that there are a ton of old bad code examples out there that are still at the top of various search results that new coders copy/paste into their code, introducing issues that were fixed 2 or 3 PHP releases ago

      • wordpress has popular garbage plugins that make it the biggest blight on enterprise server security.

        the fact that you use the unstable toy database of MYSQL on back end shows you are part of the problem.

        the java ee machines I admin are doing just fine, I don't spend the days on them like the php folk do with their shit Wordpress crap.

  • Where did Java Servlets fit in? (Score:3)

    by AlanObject ( 3603453 ) on Saturday August 31, 2019 @10:12PM (#59145116)

    My career path never put me much in contact with either Perl or PHP, and when I learned Python it wasn't for web programming.

    In my space-time continuum there was (is?) a lot of activity around servlets back in the day. Followed shortly by JSP, then JSF, and there was one more template language I can't remember in there based on servlets. For me it wasn't Perl vs PHP it was Java versus everything else. This very day I am doing REST interfaces using javax.ws.rs.*. That's basically a wrapper for servlets.

    Did anyone else see these two worlds collide?

    • Re: (Score:3)

      by Tool Man ( 9826 )

      Yup, I did lots of server-side web programming for work.

      CGIs are essentially stateless programs run for each and every request. That is, the runtime cost of launching them repeatedly can add up, and because they're ephemeral, they have no in-memory state to rely on either. So, it's back to reading files, or databases. The web server passes any parameters needed, it answers the request, and shuts down. Still though, Perl started up pretty quick, Python wasn't bad, and C was usable once you had some decent st

    • Re: (Score:3)

      by jrumney ( 197329 )

      I did a lot of Java Servlet work back in the early 2000's, and used to look down on PHP. I also did some hobby coding at home, and hosted my own Tomcat server at home. But in 2008, I moved home, and my new ISP blocked incoming HTTP, so I had to go out and look for offsite hosting. The RAM requirements for running a Java server pushed the cost up beyond what I could justify for hobby sites, so I started looking at alternatives and found CakePHP, which had a similar MVC model as what I was used to with Ser

  • PHP like ASP and JSP mix code and models with content and presentation violating the Separation of Concerns principle.

    • I agree, but you don't actually have to write ASP or PHP like that. JSP you do, because the pre-compiler depends on it.

      • Re: (Score:2)

        by jrumney ( 197329 )

        JSP has had taglibs and Java Beans since the early days, so you have never needed to mix code and models into JSP. If anything, I would say PHP encouraged that, since the emergence of MVC frameworks and proper templating for PHP only came after other languages like ruby came along and started taking users from PHP.

    • Only if you do it wrong.

      Good written PHP/JSP only has display code mixed with html fragments, and the and the data and business logic is either put in a different layer, when using PHP, or written in pure Java in the JSP case.

      • This is the way my PHP code is setup. I perform business logic first in its own separate classes, and the business logic has no concept of a view and only exposes enough information to be useful into a generic model object. Then afterward I render all the HTML and everything using PHP inline, sort of like Razor, using the information in that model object.

        The source of PHP's greatest power is also its greatest weakness in that, like C, it is very flexible, doesn't hold your hand and gives you enough rope to

    • Trouble is, any language/markup scheme designed to separate presentation from logic will gradually acquire features until it becomes Turing-complete, people will start using it for logic and someone will have to invent a new language/markup to take over the presentation...

      Of course, there's CSS, which is engaged in an exciting race to see whether it will become usable for logic before it becomes usable for presentation...

  • Design Choices in PHP (Score:4, Funny)

    by aberglas ( 991072 ) on Sunday September 01, 2019 @01:47AM (#59145468)

    Interesting concept. That there was any design at all in PHP.

    I always it was just hacked together by someone that new C and shell and nothing else at all about software.

    • Re: (Score:1)

      by Anonymous Coward

      Interesting concept. That there was any design at all in PHP.

      Interesting, and fictional. I mean, I have used ASP, PHP, Perl etc in the past (not too much as I am not a web dev) and I can understand the other two, PHP is the only one filled with "WTF are they complete idiots" moments. If it is by design, they are bigger idiots, because I assumed most crazy things came from conflicting ideas within the dev group. Then, most of the people who actually use PHP seem to be even worse! If I am asked to work on existing PHP code I am ready for nightmares...

      • PHP started out as utter crap from a language design (and security, and consistency, and predictability) point of view, yes. But it also started out as REALLY easy for less capable people to use.

        But things have moved on a long way since then. They even got rid of some of the horrible design decisions, like all GET parameters being set as globals, first by default, and then that being a default 'on' setting, before finally defaulting it to off (and they might have removed it completely in PHP7, I'd need

  • That's all that needs to be said, really.

  • I coded in perl for a few years and was unenthusiastic about it. But PHP was easy to learn and it worked like a charm. Coding in PHP has made me shitloads of money over the last 10~15 years and it didn't cost me a cent. :)

    So feel free to rag on PHP, I don't care. It works for me and I'll just smile while you rage about how it's "not really a language" or that "the language is a mess" (which it definitely is).

    I don't care, I'll just keep cashing my checks (or enjoying the direct deposits) while the haters st

    • And please don't give me that "it's so insecure!" shit- you know perfectly well that you can write bad code in ANY language, period.

      Is there another language that will let me run script inserted into a log file, just because it has a ?php? wrapper around it?

      It's not just that the language is insecure, it's that it reduces the security of any server that has it installed.

      • Is there another language that will let me run script inserted into a log file, just because it has a ?php? wrapper around it?

        What kind of a shit log parser will run inserted code willy-nilly without any kind of security? Sounds like that's a log parser or server-stupidity problem more than the fault of PHP. How can you blame PHP for what the server or log utility does?

        Also, you could easily make the argument that what you describe proves the versatility of PHP, but I'd guess that kind of blind "see code, run code" could easily work with javascript or python or other scripting languages. If it does work, is that the fault of java

        • Yeah, it's totally unheard of...

          https://www.owasp.org/index.ph... [owasp.org]

          PHP is /designed/ to run anything it sees, and it's a common real world configuration.

          "If it does work" doesn't apply to any other language that I'm aware of, hence the question you didn't answer.

          Additionally; because PHP is "easy" there's a lot of advice in PHP project INSTALL files about how to turn off the security in the server, everything from disabling "safe mode" (that wasn't) to disabling selinux, so "poorly-managed dumpster fire" appe

  • You kids .... (Score:4, Insightful)

    by yelvington ( 8169 ) on Sunday September 01, 2019 @05:35PM (#59147390) Homepage

    Most of you kids aren't old enough to know what Rasmus was talking about.

    In 1994 there was no guarantee of Perl being installed on a server. There weren't a thousand ISPs with point-and-click credit card interfaces to spin up a webserver. If you had a webserver, it probably was running Solaris or AIX or Sys V. It almost certainly had a C compiler csh, ksh or (if you were really lucky) bash. So you downloaded and compiled Steven Grimm's uncgi tool:
    http://www.midwinter.com/~kore... [midwinter.com]

    It grabbed CGI args, cooked them nicely and stuck them in the environment. Suddenly any Unix tool could be used to crunch and spit out HTML.

    I wrote half a dozen tools as shell scripts -- a microblogging tool (before blogs existed) for weathercaster Paul Douglas, a photo caption contest, various other data-submission microtools.

    Yeah, it probably wasn't secure by modern standards, but the 1995 Internet wasn't totally infested with assholes.

    PHP everywhere was a blessing, and it enabled the explosive growth of the Internet.

Slashdot Top Deals

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Close