Lines of code that changed everything
slate.com
slate.com
$(document).ready(function(){});
If it wasn't for jQuery, no one would be programming web applications the way we do today. jQuery was THE single advancement in creating the modern web.
Main advantage was unified experience across all browsers.
>[memory leak on each request] not a priority issue for anyone
Exactly my point.
Well now you don't
document.write(...)
Excellent!! You'd be surprised that not everyone agrees with the idea of browsers becoming their own micro-OS.
#!/usr/bin/env perl
use strict;
use warnings;
use CGI;
Common Gateway Interface. It's a specification for how web servers can process HTTP(S) requests dynamically.
EDIT: If you are wondering what modern equivalents are, AWS Lambda[1] and Azure Functions[2] are Liskov substitutable[3] as they pertain to CGI programs. Both of these products provide benefits beyond what a "classic CGI system" could offer, of course.
0 - https://en.wikipedia.org/wiki/Common_Gateway_Interface
1 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
2 - https://docs.microsoft.com/en-us/azure/azure-functions/funct...
3 - https://en.wikipedia.org/wiki/Liskov_substitution_principle
Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbatim. There was no PHP, no Rails, no Django, and certainly no Node. If you wanted to do anything dynamic - like serving up content that you, the webmaster, did not write yourself - you had to write a custom webserver. Remember, this was back when C was the most popular programming language, Java was for hardware devices, Python was for academics, and Javascript didn't exist. Not many people wanted to write their own webserver.
CGI was a specification that would allow the webserver to launch an external program - written in any language you wanted - in response to an HTTP request, send it the request data, run arbitrary code, and write the response back to the web browser. The query params and other information about the request (path, user agent, host, request method, etc.) would be passed in environment variables. POST data would be passed on STDIN. The program would write the output HTML to STDOUT, and the webserver would echo that directly back to the browser.
It was slow, it was clumsy, it was insecure, and it was magical, because you simply couldn't do simple stuff like read from a database and dynamically generate a webpage otherwise, unless you wanted to write your own webserver.
The lines that the grandparent posted would fire up a Perl script and then import the CGI module to parse all the input data (no such thing as JSON back then; if you wanted the actual query params, you got "/reply" in your $ENV['PATH'], and "id=21654788&goto=item%3Fid%3D21648568%2321654788" in your $ENV['QUERY_STRING'], and had to parse them yourself). It also enabled some warnings and error checks for Perl to avoid some of the worst security nightmares. This was even more magical, because Perl offered string parsing & construction utilities and database libraries that were much easier than C, and so you could quickly write useful websites that did stuff instead of hand-typing HTML into your editor.
Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbatim.
You should probably be feeling a bit older (and perhaps forgetful :).
PHP was around in the mid 90s, as were FastCGI, NSAPI and Javascript, Java's initial public target was web pages. Things like what eventually became AOLServer are also of that '95-ish vintage. CGI lived a long happy life in shared hosting, small project and development environments but in commercial use, it didn't last very long - it was just too slow.
> You should probably be feeling a bit older (and perhaps forgetful :).
Perhaps we all should :).
> PHP was around in the mid 90s ...
True, and according to the PHP site[0]:
PHP as it's known today is actually the successor to a product named PHP/FI. Created in 1994 by Rasmus Lerdorf, the very first incarnation of PHP was a simple set of Common Gateway Interface (CGI) binaries written in the C programming language.
> ... Java's initial public target was web pages.
Not true, according to here[1]:
In 1991, a small group of Sun engineers called the "Green Team" believed that the next wave in computing was the union of digital consumer devices and computers. Led by James Gosling, the team worked around the clock and created the programming language that would revolutionize our world – Java. The Green Team demonstrated their new language with an interactive, handheld home-entertainment controller that was originally targeted at the digital cable television industry.
> CGI lived a long happy life in shared hosting, small project and development environments but in commercial use, it didn't last very long - it was just too slow.
Not quite true either. Unless one considers the following projects no longer in use:
- https://httpd.apache.org/docs/2.4/howto/cgi.html
- https://docs.microsoft.com/en-us/iis/configuration /system.webserver/cgi
- https://docs.python.org/3.4/howto/webservers.html
- http://www.yolinux.com/TUTORIALS/BashShellCgi.html
And, of course, FastCGI[2] is a welcomed optimization and to be preferred, but fundamentally is just that. An implementation optimization of CGI.
0 - https://www.php.net/manual/en/history.php.php
1 - https://www.oracle.com/technetwork/java/javase/overview/java...
I said public target. The thing was aimed at web pages, the sell was applets.
Not quite true either.
I didn't say CGI just stopped existing and emphasized commercial use - it was too slow too once you hit even relatively medium-ish traffic. FCGI, NSAPI, in-process-tcl, plopping-piles-of-C-in-your-own-custom-apache-build were all solutions to that problem.
> I said public target.
You are technically correct, the best kind of correct.
> I didn't say CGI just stopped existing and emphasized commercial use - it was too slow too once you hit even relatively medium-ish traffic.
And I agreed by stating:
> And, of course, FastCGI[2] is a welcomed optimization and to be preferred, but fundamentally is just that. An implementation optimization of CGI.
For efforts which do not need to scale, "classic CGI" can be a good fit. FastCGI can help increase the scale ceiling. Proprietary extensions can further do so.
Now the industry finds itself rediscovering CGI in the form of AWS Lambda[0] and Azure Functions[1], albeit addressing traffic concerns via "the cloud."
Funny how what was old is now new, eh?
0 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
1 - https://docs.microsoft.com/en-us/azure/azure-functions/funct...
Hah, no, I was the regular kind of correct, you just misread what i wrote - the best kind of read.
As to the other thing, I wasn't arguing about the merits of CGI just that the commenter's recollection was a few years off. A lot of stuff happened in that '94ish-'98ish period as the web went commercial.
Whether lambda is a forgotten CGI, it's a different tangent but I'm not sure I agree. The share-nothing architecture is still (give or take) the norm in HTTP request handling. CGI's attractive feature was implementation-language independence. Lamda's attractive feature is scaling independent of some big unwieldy discrete compute unit (hence 'server-less', you don't scale in servers).
So... what would be an example of such an external program? Something that accesses a SQL database and changes values on the HTML page? I ask this specifically since you mention that database access would be prohibitively slow.
Or would you e.g. use CGI to call some script that changes the HTML? Let's say, post something that was written in an input box?
> So... what would be an example of such an external program?
The external program is responsible for producing the entirety of an HTTP response; headers and the message body (see here[0] for details). CGI allows a web server to provide what it knows from an HTTP request to an arbitrary program and expects it to write the response as it sees fit.
Think of it as a specialized case of "fork-exec"[1] where the "child process" has the responsibility of writing the raw HTTP content to the "parent process" (the web server).
In the CGI model, each request causes a "fork-exec"[1] and, as such, any interaction with other services (such as a database) requires connecting, using it, then disconnecting each time. This can quickly swamp server resources, which lead to the definition of FastCGI[2] to help alleviate this type of thrashing.
HTH
0 - https://tools.ietf.org/html/rfc2616#section-4
BTW, is this kind of specialised fork-exec code that writes back HTML code to the parent process still in use?
Yes, but is most likely found in intranet situations. As others have noted, commercial offerings typically use an application server style approach, as that greatly contributes to being able to scale.
However, not everything has to scale ;-).
Yeah, it's a bit older than that. According to Wikipedia, the CGI standard is from 1993 so it probably predates Apache itself by quite a bit (which was forked from the NCSA httpd which already had CGI support).
By 1998 mod_perl and mod_php had already taken over for most people and dynamic content was generated in-process. FastCGI existed but sadly didn't really take off, and the code languished until for some reasons a decade later it had a sudden and unexpected renaissance.
The monster I be, is when on the fifth line you see:
eval { local $/; <STDIN> };
require "cgi-lib.pl";Back in the day this little book I wrote on it had 500,000 people read it http://expertwebinstalls.com/cgi_tutorial/index.html
Remember parsing Apache logs to see who visited your sites? :-D
Also vms/containerization is worth a mention? The basis for the cloud.
I wish I could garbage collect my ex the same way that D rocks my garbage for me!
rm -rf $FOO/*
rm -rf . /*The flaw isn't the null termination but the lack of encapsulation.
No string representation is error-proof, if the application programmer open-codes the manipulations of it, taking on the responsibility for maintaining all necessary invariants of the representation, including memory management. If applications take on the responsibility of constructing and maintaining length + data strings, there will be bugs.
Null-terminated strings are actually a very good choice of string representation that is to be directly manipulated by programs, instead of just through opaque handles via library functions.
Null-terminated strings allow for elegant tail recursion like:
const char *my_strchr(const char *str, char c)
{
if (!str)
return NULL;
else if (*str == c)
return str;
else
return my_strchr(str + 1, c);
}
(defun findel (list el)
(cond ((null list) nil)
((eql (car list) el) list)
(t (findel (cdr list) el))))
Compilers can merge string literals that have a common suffix; if "pet" and "carpet" occur in the same program, they can share storage.
Null terminated strings of byte-wide characters can be transmitted with no byte order issues. Not so when length fields are involved.
Being able to split a null-terminated string in-place according to some delimiter characters, by overwriting them with null bytes, is also handy, and greatly simplifies some programs which open-code this logic rather than relying on string libraries.
Null termination is nice for lexical scanning. Why? Because every string has an accessible byte that is one position past its last character, and has a unique value which can treated as a member of the input alphabet, and thus integrated into the pattern matching logic. Code which scans a null-terminated string for a lexical pattern doesn't have to do anything ugly and extraneous like checking an index against a maximum length; it just contains cases that handle zero as a part of the syntax.
Stream scanning code that looks for and handles EOF return from getc can easily be turned into string scanning code if it just handles zero instead of EOF.
> Null-terminated strings are actually a very good choice of string representation that is to be directly manipulated by programs, instead of just through opaque handles via library functions.
You seem to be having it both ways.
As I see it, "NULL" is a valid ascii character, but not a valid element of a C string - except as a terminator external to the string of characters being represented. It's fundamentally broken as an abstraction for managing variable length strings of ASCII. It is incapable of representing all strings of ASCII characters.
There are 32 control characters, and DEL. The purpose of all those characters is to carry some kind of meaning. The designers of the null-terminated string decided that the meaning of NUL will be reserved for that termination. That still leaves 31 control characters and DEL which can be stored in a string, which programmers can use for other meanings. That turns out to be plenty.
The "unreasonable effectiveness" and ubiquity of null terminated strings shows that the world is perfectly capable of getting along without NUL in the middle of a string. Basically, the intuition that we can steal NUL for string termination was right (and to some extent self-fulfilling, due to the subsequent proliferation of the convention).
The idea that all possible code points of a character set are valid characters that must be stored in a string is outdated in the age of Unicode, which contains codes which are not character code points.
Null terminated strings are now the representation of a path name every major OS that has any non-negligible installed base. The choices leading to this situation weren't made by complete idiots.
And, by the way, NUL is the ASCII character; NULL is the pointer constant in C.
http://worldpowersystems.com/ARCHIVE/codes/X3.4-1963/page5.J...
This got shortened to NUL in 1965.
while(*dest++ = *src++);
As the final abbreviation, observe that a comparison against
'\0' is redundant, since the question is merely whether the
expression is zero. So the function would likely be written
as
/* strcpy: copy t to s; pointer version 3 */
void strcpy(char *s, char *t) {
while (*s++ = *t++)
;
}
Although this may seem cryptic at first sight, the notational
convenience is considerable, and the idiom should be mastered,
because you will see it frequently in C programs.
You are right of course - but this is a moment in time thing. ++ and it's equivalents aren't so convenient now. One of the things that strikes me about modern languages is the disappearance of integers, and the associated integer arithmetic such as the s++ in this example.
It turns out we were using integers as a poor mans iterator, and s++ simply meant "next item please". Once we starting using "for element in sequence" to access iterators many of the integers disappeared - they are only used to represent integer things in the real world now. Just about every instance of ++ also disappeared because "next item in iterator" was it's main use. Turns out integers modelling things in the real world rarely need incrementing. So much so that modern languages don't bother including ++ or the Pascal equivalent, succ().
> But the RSA encryption algorithm—one of the basic building blocks of modern cryptography—is elegant enough that it can be written out in just four dense lines of Perl code … short enough to fit on a T-shirt.
And of course it has nothing to do with the elegance of RSA, but the largeness of Perl.
I'd also argue for the inclusion of Leonard Kleinrock's seminal paper on communication networks.
rails new blog
Think about how many frameworks over the years have copied or looked to Rails for inspiration. Rails pretty much changed what people expected from frameworks.
I failed to bookmark it nor find it. Sorry.
let there = light
(No idea what language is that, just guessing the output)
time and uptime
uuidgen and ping
...?