 Yeah, I'm gonna be talking up technologies that are often talked down. And I'm not going to talk about where they are today or their suitability to purpose. Now, some of them are still great. Some of them, no matter what flag they get, you know, in others, well, they have their place in history. Most are still widely used, though. And I'm also not going to talk about why people like to talk them down. Instead, we're gonna be positive. And talk about how did they get to the point where they were popular enough to actually be popularly unpopular. To do this, we're gonna be traveling back in time. We're traveling back in time to when the web was young and everyone was writing templating libraries. Now, it knows I did. So we're gonna start with MySQL 3. Now, MySQL 3 is not the MySQL that we have today. It was an SQL-based network-accessible database. Had no transactions and it had a limited subset of SQL. And the authors' stated intent for it was that it should be ideal for storing things like logs and other data sets with lots of new rows, high-volume inserts. That's what it was originally designed for. And it was great. But before we talk about that, let's talk about when this time was. This was 1998. Netscape had just been purchased by AOL. 256 kilobit was still considered broadband. PHP 3 was brand new. And hooking a database up into a website was cutting edge and people were actually still writing books going, you should give this a try. I know you haven't thought of it before. You should really put a database back there. You are a self-taught web developer because that's really the only kind there are. And you need a database for your CGI scripts to talk to because that's how most dynamic websites are made in 1998. And you've used flat files on the server, text files. There's Berkeley databases, which are a key value store. But, and those work well enough, but they fall down once you start to get a lot of requests. And they also mean that you can't scale to multiple machines. And that was always like, that was part of the revolution that made the web was moving towards platforms where we just add more machines to get more, you know, to scale out further. And it doesn't allow that because it has to be able to have a shared file between all your web requests. And the locking slows it down so that even if you have a really beefy machine, there comes a point where you're serializing all your web requests, it's not gonna work. So my goal was ideal in many ways. It was freely available to download and try out, although it wasn't actually free software yet. But the license was inexpensive and they were doing good work. So many places thought it was a fantastic deal. Many places just didn't buy a license, just downloaded it and used it anyway. By contrast, oracle licensing is prohibitively expensive. It can cost from tens of thousands to hundreds of thousands of dollars. And installation from my school is incredibly easy. There's really no setup required to get going. Drivers are already widely available because one of the interesting things that MySQL did is they took the protocol of a previous database system and they just used that for their own. And by doing that, you know, people had already ridden those drivers. It was MSQL, incidentally, which I don't think I've ever used. I'm not sure I've ever met anyone who's used it, but it's there. Hey, look, we've got a couple. So setting it up is something any sys admin can do. And that's important because most databases at that time, most of big SQL databases, you had to have a database administrator on staff. And if you're a small organization, you can't afford to have somebody whose job it is to just run the database. Especially if you've never had a database before. It doesn't have any established value at your company. And MySQL just works out of the box. I mean, it works to the point where you can, you know, just install the package and you're basically done. Oracle, even with the DBA, takes hours to set up. Postgres, which at the time was still PostgresQL because, you know, they were still going, well, we used to not do SQL, so we need to make it clear. It existed, but it was also, it wasn't as out of the box as MySQL was. And that little bit of friction matters when setting up databases software isn't actually part of your job. Of course, you still need to learn SQL. But that's not so bad because MySQL had extensive documentation on the web. And even though it was sometimes dry reference material, also had a user comment section. And the user comment section was surprisingly fantastic. It had elaborations on examples and some amount of question and answer between users, probably it worked because the community was small enough that it wasn't totally overwhelmed. But there was this period of time in the web's history where comments on web pages were a viable form of community. As weird as that seems now. Also kind of surprisingly important to MySQL and how it worked for everyone was that it was incredibly fast when it was accepting new connections. And this is not like the area that most databases think they need to worry about. Oracle, like it was an expensive connection time and that meant if you were connecting to it from a CGI script, you might have added a couple seconds to your latency just to connect to the Oracle database. Postgres was better than Oracle but it wasn't as fast as MySQL. MySQL's connection times were as fast as HTTP. And that was because most users were using CGI or PHP, both of which had to set up their connections on every request. It was a difference of night and day. So that's really all I have to say about MySQL. MySQL, it was pretty great and it was the database, we needed a database and it was the database we had. And it's evolved a lot since then. But you have to talk to the database with something. So PHP 3. PHP 3 was also released in 1998. And I'm sure most people know, it's a three-year-old web-focused scripting language primarily found in embedded web servers, embedded in web servers. It was PHP 3 is the first version of PHP that gained widespread popularity. Didn't have any object orientation yet. And yeah, 1998 again. Surfers are super expensive, smaller websites can't afford their own servers. Virtual servers aren't a thing. The cloud is nothing more than a blob in your network diagram. So you settle for a shared hosting account where your web pages are served by the same web server as other people's services but there's no separation that virtual hosting gives you. And this was very inexpensive but running software there was extremely limited. It was fine as long as you had a static site which you could actually get away with. But as soon as you wanted to have dynamism you probably had to go to CGI scripts. And CGI scripts were often uncomfortably slow. So who are you? So in this case we're gonna start with you're working at a web hosting company and your users want dynamic websites. You've grudgingly let your users use CGI scripts because they're running code on your computer. How can that possibly be safe? And frankly it can't, that's the problem. Even still they use up a lot of system resources because they have to be, the whole program is run again from scratch on every request. And most of those CGI scripts are written in Perl although other languages get used to because CGI scripts, they don't care what language you use but you'd really like something more performant. But it still needs to meet that key thing of being able to run in a shared environment. Popular scripting languages have plugins for Apache at this point. And so those are things like ModProl and ModPython where you can embed a copy of your scripting language interpreter in the Apache web server itself. But they aren't well suited to shared hosting. They're designed for, well I have a web server and that's my application. And that's where we are now but that's not where we were then. They provide, they're persistent interpreter across the requests which you can do all kinds of things to improve your speed with. But it means that they share memory. And so you really can't serve up software from one person and software from another. And there were attempts to make this work but they were all pretty, I wouldn't trust them. I would trust them even less than shared CGI solutions. Which is really saying something. And they also had the problem that they kept their memory routine requests. And if you've got a bunch of programmers who've been writing CGI scripts, well they don't have to worry about memory management because all their memory goes away at the end of the request. And now you've got this thing, this server that stays around all the time and your process gets bigger and bigger and bigger and pretty soon your servers are falling over. And then they were also finicky to get set up right. Even if you weren't leaking memory they tended to use more memory than you had been accustomed to so you needed to put it some sort of proxy on the front end which again, no one was really doing that yet. So, here comes along PHP. PHP 3 in particular. PHP 2 is where it first got public visibility and PHP 3 is where it finally took off. And it was extremely easy to set up which is kind of a theme here. Like that reducing friction is one of the key things to making a technology adoptable. And it had the same memory model as CGI scripts which is to say every request it threw away all the memory the interpreter was holding. And so there was no state between requests. And that was huge because that meant that like you don't have to worry again, you don't have to worry about running out of memory. You don't have to mean it means you can't like store variables between requests but hey, you've got my skill for that, right? And it was kind of a kitchen sink included language. It's standard library is absurdly large especially if you do the default compile and take in all of the modules that are bundled with it. It really has everything you could possibly want to do just built in. I mean, sometimes the names are a little weird but they're there. And that's really nice from a posting point of view because it means that your users aren't bugging you to install modules all the time. With CGI, somebody goes well, I need this pro module to do this thing and you're like, ah, we're gonna have to install that and then we're gonna have to install any new systems we make and no, you just can't happen. PHP is already there. And if it's not, well, PHP didn't really have a module system in PHP 3. It could include files essentially. So you just put the file in your directory and you require it. It's good. And because it was so easy to set up, you could basically just install it with your Linux distribution and that was it. You could do more complicated things but you didn't have to. And because most web hosting companies were small and strapped for time and cash, anything that saved money was valuable. So that kind of explains like why it was available in the ecosystem is that it was a cheap thing to make available and it solved people's problems. But as a web developer, why do you want it? Well, you're working a web design firm or a small business. You're not working in a large shop because large shops have their own servers and you're probably using something else, maybe Java at this point. Or I don't know if ASP is out yet, maybe. Yeah, okay. But you need someone to host dynamic websites for your customers or for yourself. And so, first of all, it just has to be available. You have to be able to buy this server somewhere and your choices are pretty limited. PHP is really nice because it runs so much faster than CGI because it's built into the web server because it doesn't have to go and run another program every time you do anything. And your web hosting company is way more happy to give you access to that than, well, if you wrote a mod-perl application and you're trying to get it hosted somewhere, no one does that. It's just, no. You'd have to have a dedicated server. You'd have to have sysadmins. You'd have to set all of that up yourself. And another aspect of what made PHP as appealing as it was is that so many CGI-based sites at the time didn't use any templating. They just printed fragments of HTML to the output. And by the time it was done, it kind of put together a valid HTML document or kind of valid. And browsers did the best they could. But this was really hard to maintain and nobody who, which is why everyone was writing templating libraries is because it was terrible. And PHP said, well, we're just going to embed code in HTML. And so because that was the default mode of interaction, this made it really easy to start with a static layout and then start adding dynamism to it. So you could have your graphic designer who maybe knows how to use one of the site generators to put together some HTML for you. And then you can go in there and start editing that to add in, to make it do the things that needs to do. Also made the language feel much more web native than any of the other languages. It was one of the first languages developed specifically to support websites. And because it encouraged this incremental approach, it was much easier to actually get people who hadn't been programmers before to start adding dynamic content of their own. Because they looked and they went, I can just have this little snippet and it does that thing. This is great. And so we got an entirely new generation of web developers. Like just from that, it was the same visibility where you could just go in and view the HTML and see how it worked. You could now do that with your Pyraman language too. And with all the libraries that are built in, you can do almost anything you'd want to from custom graphics to email to database access. It was all there and it was all already there. You just had to go and look for it. And it too had extensive web-based documentation and it was all obviously available. Some of the site, I was thinking about this and some of the software at the time had pretty good documentation but they hid it away. It wasn't like the first thing you saw in the site. Whereas with PHP, the very first thing you saw in the site at that time was the search box which searched their documentation. And of course because all their modules were just built into the core language, it searched all the documentation. Like you go to Pearl's documentation and you search it at the time, it searched the core language documentation which told you nothing about the tools you're going to use to build a website whereas you do that on PHP. And it's like, well, here's image magic. Here's the DB layer. And they had translations into many languages all in the same place and they had it for, they had it across all of that documentation. Again, this is a, when you have a more distributed ecosystem, it's harder to get that consistency of translation, that consistency of presentation. And so it was really valuable at the time. You also didn't have to worry about like requiring modules or dependency management because it was all just built in all the time. You could not have them. And surprisingly, again, it had comments that were actually useful to people who were learning this stuff. Corrections to documentation, examples, question and answer sections. It all existed there and it was surprisingly helpful. So PHP, it was a critical, I mean, I think it's surprisingly impactful for all the flak that it gets. It was a critical piece of the web at a specific time. So we're going on to something else. XML, which is extensible markup language. And it's a set of rules for creating markup languages like HTML. It's our ugly stepchild of the web. And again, this is 1998 because apparently 1998 was a pivot year in the web. I didn't realize this before I started writing the talk and I'm like, everything was in 1998? Apparently so. You know, five year anniversary of the web, right? Something like that. And that's when everything started to happen. So the web and HTML are truly taking over the world and everyone wants to hook up their legacy data sources to the internet to share them with each other. And your writing software that integrates disparate computer systems and you need to interchange format of some kind. Traditionally, either you folks would, either the folks you're integrating with or you would have to make up a format just on the fly and then write a custom parser or importer for it. And then if you ever made any changes, well, that was going to be a whole hassle. And because if you were doing a binary file format, well, what if you need to add a field and now your old parser, your old importer doesn't work at all. And if you're doing a text format, does it support loading new things? What happens if you give the new data to the old program? It was awkward. And we dealt with that for, you know, 40 years, 50 years. But, hey, there's this, you know, XML. It's made by the same folks who made HTML. It looks like HTML, but you can make up your own tags. That's like its key thing. And it's way more regular. So writing parsers for it, just generic parsers for it, it's a lot easier. And most parsers, like it's defined in the spec that you, you know, if you get an error, you error out. Which is really nice because it means that if you write your own parser, you don't have to worry about getting sloppy input. Whereas with HTML, heh heh heh heh. We have it defined now. We'll just say that. But we didn't have it defined then. So XML was only finalized in January of 1998. But because it was so easy to parse, it was already, there were already parsers, like by the time it was finalized, there were parsers widely available for all the popular languages. And by having this like meta file format, you can plug a standard parser into, or a standard emitter into, and you can actually just talk about like the thing that you actually care about, which is your data. You don't have to think about like, how is it, you know, you still have to think about some bits, like, how am I going to serialize this date? That's not defined. It's string between tags, but still a big improvement over what we had before. And hey, maybe you can finally convince those mainframe folks to stop giving you fixed with text exports. If I do, I think that still took another decade. But it also introduced UTF-8 as the default, which probably wasn't noticed that much at the time, but having Unicode, that was where Unicode started to be everywhere. And it even came with both document and stream-based parsers on most platforms. And so the document-based parsers are way easier to work with when you've got a small document. And if you've got large documents, well, stream-based parsers means that you can handle arbitrarily large data sets way beyond the amount of memory you have. So both are necessary and they're actually there from the start. Because of how it's designed, you can add new tags to your tag format and your old code is probably gonna continue working. It's always possible to write something that'll break when you extend it. But you kind of had to go out of your way with XML. And that finally allowed you to decouple the process of writing your side from process of writing the side of the person you're integrating with. And that tight coupling had been the bane of this kind of integrations programming for an extended period of time. And there have been a number of attempts, mind you, XML is hardly the first language to do this. It's just the one that you took over the web. Probably because it looks like HTML. So, yeah, yay, XML. It saved us from the world of fixed-width file formats and binary file formats. And I used a record statement in Pascal and wrote it out to disk and that's good enough. It's ugly as sin, but it's there for a reason. And we've got possibly better things now, but it depends on what you're doing. So, moving on, Perl, near and dear to my heart. It's a Unix scripting language at its heart. It was written by Sysadmins for Sysadmins. We're gonna talk specifically about Perl 5 and its introduction, which is this is 1996. And the web is young. And folks with dynamic websites are few and far between. Well, there are some proprietary solutions available at this point. Things like Netscape server allows you to have server tags in the middle of your HTML, JavaScript running in them. For instance, the very first server-side JavaScript. And they weren't even the first to put scripting languages in the middle of webpages. But most folks are still using CGI scripts to power their websites with where anyone's doing anything at all. Usually in small ways like forum processors and things like that, but larger sites are being built too. The CGI scripts are simple. They're just an executable program. We get a known set of environment variables with the information about the request and then they print out what they want sent back to the user. So Perl with its start as a Sysadmin language was widely adopted by the time the web came along. And well, it wasn't a part of a standard stock install in many flavors of Unix. It was almost always added later. It was very rare to log into a Unix system that didn't have Perl. And it was a key part of every Linux distribution that I'm aware of. And the ascension of Linux started, and this was just as the ascension of Linux was starting to become more obvious outside of the community that had been using it. So who are you? Your Sysadmin or Systems Programmer has been asked to put together a website for your organization because you're the tech person and they don't really know anyone else to ask. And you're like, well, I can figure it out. How hard could it be? So you need to pick a language for your CGI scripts. Well, everyone you know knows Perl. You could write your CGI scripts in C and certainly some folks do, but maintaining a C program is substantially more time-consuming than writing a Perl program. Doubly so, because most of what CGI scripts are doing is reading and writing strings, which Perl is great at and C is terrible at. Perl is kind of built on text processing. What's more, it's trivial to write Perl programs that are actually portable across Unix systems. And this means you can develop it on your Linux desktop and then deploy it to your Solaris server and everything still works. And that can't be said for C scripts. It can't even be said for shell scripts. Perl 5 is the new hotness, but Perl 4 is still used widely and many installations you'll see both installed side-by-side. Some of the earliest web-related libraries are available for Perl 4 from LibWWWW, which was actually essentially, I think the second web library ever written after Tim Berners-Lee's C-based LibWWW and CGI Lib, which was the Perl 4 CGI processing. So Perl 5 is even more exciting as excellent libraries for dealing with the web in both LibWWW and CGI PM. And it has the CPAN, which is this grand new experiment in sharing modules for programming languages. Started as a centralized FTP archive. And since these are machines that you admin, getting libraries installed is no problem. And this is actually in this year that the CPAN's been around for about a year at this point, but this is the year that the package manager for it is actually first published. So you can actually start installing things with a command. No one's done this before. And the archive is largely uncurated. There's a central index at this stage that is curated, but you can go to your author directory and upload wherever you want and anyone can come and get it. So we're starting to see this experimentation that we've not seen before, this sort of thing. This is where Perl had like joke libraries. It has a whole ACME namespace full of libraries that are kind of funny, like ACME don't, which it's like the do command except it doesn't run the code. And it works because an apostrophe is a valid part of syntax in Perl that does not mean string when it shows up in the middle of a thing. So yes, so Perl is a fantastic choice and it's the choice that many people make. But let's look away from the web just for a moment. Visual basic. Visual basic was not actually breaking new ground, but it was bringing something to people that most people have never seen before. It's basic for Windows essentially, but it had some special features. So it's 1993, I'm back further. Windows for Work Groups has been spreading like wildfire. Many small departments and large companies have been setting up their own file and print servers. NCSA and Mosaic exists, but you've probably never even heard of it. If you're listening to TechHype, maybe you've heard of the web, but it's hardly a thing ordinary folks have. When you think software, the only kind you think is the kind that comes on a floppy disk you install on your computer. So you're working for a shop that previously had been writing DOS applications, but wants to get into this Windows thing. Or maybe you're an IT department worker who's finding the need for greater flexibility than things like spreadsheet templates and macros can provide. What you really need is an easy to use Windows application. Almost everybody who knows how to program knows basic in this world. And Visual Basic provides a bunch of quality of life enhancements to basic. It's essentially, if you've used QBasic and DOS or TurboBasic, they're basically the same, very similar. And your other option is C. And C is finicky, and it's always been hard to teach people pointers. And it's harder to find folks who are, it's just harder to find folks who are comfortable with C. And Visual Basic has that kind of, you can tinker with it until it works thing going on. And it has that because it's kind of an amazing experience. You start it up and you get a form designer. And this is your designing the new window that you want to have displayed. So you're working visually with what you need. Not really unlike how HTML and the web experience work. You're directly designing what you want. And even better, you're not even writing tags or code. You're just directly manipulating stuff on the screen to make it look like what you want. And then you double click on something and it lets you enter like, when this button is pressed to run this code and it pops up a little window and you type in the code you want it to run. And you can actually see all your code at once in the early versions. But on the other hand, it means that you're never looking at more than one like small piece. So it forces you to keep your context tight. And while other language environments did come with form designers that looked a lot like the one that Visual Basic had, the big difference is that they were code generators. So you'd press the generate button and then you go make changes to that code and now you can't use the form designer anymore. Because if you do, it's just gonna regenerate the code and overwrite all your changes. Later on, we'd get things were even better that like could reflect it back and forth, but we weren't there yet. And the code generators were generating this opaque code full of all these things that you don't know anything about because you didn't write it. So it's all this stuff that's necessary to like create a graphics context and instantiate a dialogue box and keep it open until this happens. And none of which have you encountered until you press that generate button. And because Visual Basic is easy to teach, many community colleges at that point had already started to build it into curricula. And this meant that finding new coworkers didn't always mean teaching them the language, which in many places in the country at that time, anytime you hired you had to teach them whatever language you used in house. So the idea that you wouldn't have to teach somebody the language that you were using was really appealing. So Visual Basic definitely had its place and having that kind of back and forth, you know, you can keep editing your form and edit your code. Like I think that was kind of perfected with Delphi because with Delphi, you could actually like, it would essentially generate the code then you could edit the generated code and go back to the form designer and it would take the edits. It was completely magic. Also had a lot less cruft because they wrote the language specifically for the graphical environment. But this isn't about Delphi. This is several years before Delphi is a thing. So Visual Basic, we're gonna move on to Tickle TK. You may never have heard of Tickle TK unless you're of a certain age. I'm including it because if you have heard of it, it's probably been grousing. And I've done my share. So this is kind of my penance. Tickle is a string-centered scripting language. Although kind of not in the way that Perl is. Like in Tickle, literally everything is a string and then it just kind of pretends they aren't. So like even the arrays are conceptually implemented internally as strings. It's kind of weird, but it works. But what it was designed to be was easy to embed. And no other language at the time was easy to embed. But it was really trivial to take a C program that you'd written and go, I want a scripting language built into my C program and then you could just compile and tickle and there it is. In its heyday, this is really what set it apart from everything else. These days, Lua has largely taken on that role. But so the other part there is the TK. And that's the GUI library. We're coming back to that. So when was the Tickle TK heyday? Early to mid 90s, maybe later 90s. And you'd use it because you're in the need of a cross-platform GUI environment. Or your web developer looking to best-in-class web server integration and weirdly Tickle is kind of where it's at for that for a little while. Or maybe your router runs Tickle programs. Stranger things have happened. Like that whole like you can embed it means it showed up everywhere. It had much smaller runtime and a faster startup times than that new upstart Java. And so Tickle TK was one of the few good options for rating truly cross-platform GUI apps. Programs written in Tickle TK can run on fancy SGI workstations, Solaris desktops, Macintosh computers and PCs with Linux and Windows. And so that was unheard of. Well, the user interface really only looked at home in the early versions of Tickle TK. It really only looked home on Unix and Linux machines, particularly ones using Motif. It did eventually add native widgets and it was more like using a native app. It never really achieved that. But your program could run everywhere. So that was something. And you didn't have any other choice. So you used it. So as a web developer, why would you use it as a web developer? Well, you want to create a highly performant database backed website and you want the state of the art. You want to be able to talk to an Oracle database and not have those multi-second latencies. Well, you'd use Navi server, which is later renamed to AOL server because AOL has possibly the worst naming in the world. And also because apparently all APIs have to be prefixed with NS, it's just one of the laws. Because you've got Navi server and then Mozilla has NS for Netscape and then of course OS X has NS for Next Step. So everyone's in S. So yes, with the expensive database connections, it was extremely valuable. I missed a slide. Excellent. This is because it's a multi-threading server. It's persistent like the much later things like ModPurl and ModPython. So it can actually has connection pooling built in. So you can have your database connections and they can be there and you pull them out of the pool when you need them. And it had these in like 1994, which is basically unheard of at that stage of the game. And there was some impressive software written on it later on, but it was all in tickle. And it just slowly fell, it never managed to catch on in part because Navi server was proprietary all the way up until 1999. So it missed its window because by then people were using PHP and MySQL and no one wanted to talk about Oracle licenses or setting up their own servers or anything else. So anyway, tickle.tk, it was a thing. Kind of that's kind of the summation of the talks. They were things, they were great. We've come a long way and our technology is getting better. I am always happy with the current state of our technology stack. It's so much better than it was five years ago and five years before that and five years before that. Let me tell you, I can go on for a while. So thank you all for joining me in my historical boosterism. If you're curious about the genesis of this talk was come say hi in the hall. I'd be happy to talk to you about it. Or if you've got your own favorite, talk down tech to talk up. I love hearing those stories too. That's all.