Lines of code that changed everything(slate.com)
slate.com
Lines of code that changed everything
https://slate.com/technology/2019/10/consequential-computer-code-software-history.html
86 comments
It’s significant, for sure, but I’d probably go with XMLHttpRequest as even more significant for web apps.
I'd almost say jQuery pasting over the inconsistencies is what made XMLHttpRequest and AJAX in general the killer feature it became.
yea. swap out roomba routing (srsly?) and replace it with "jquery made dynamic websites economically feasible" which led to practically the entire internet becoming dynamic in some form.
I'd say jQuery forcing people to actually learn XMLHttpRequest by leaking memory on each request was a killer feature.
Downvote me all you want.
https://bugs.jquery.com/ticket/10824
https://bugs.jquery.com/ticket/10824
Looks like this is only in internet explorer and was clearly not a priority issue for anyone
>only in internet explorer
Main advantage was unified experience across all browsers.
>[memory leak on each request] not a priority issue for anyone
Exactly my point.
Main advantage was unified experience across all browsers.
>[memory leak on each request] not a priority issue for anyone
Exactly my point.
I make webpages without JQuery... what's the big deal? Am I missing out on something serious?
This is about history. Nowadays it's not a big deal as the browser engines and JS adapted.
I'd go even further and say:
document.write(...)
>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.
Excellent!! You'd be surprised that not everyone agrees with the idea of browsers becoming their own micro-OS.
Excellent!! You'd be surprised that not everyone agrees with the idea of browsers becoming their own micro-OS.
oh man that brings back memories... I think people nowadays vilify it just because it's cool to bash jQuery but without it, the web wouldn't be where it is now.
That was important, sure, but cgi was way earlier.
You're not wrong, but did this really require a throwaway account?
why does that even matter?
Because throwaway accounts are usually made by people who want to share something personal and don't want it tied to their public/internet/work persona. So it made me think you work for a FAANG where everyone has to pretend they love React/Angular/etc, and you didn't want to catch any flak for it.
If you click on someone's name, it will show you their profile, and you can see that you are not talking to a throwaway account, even if the word is in their username.
The four "lines of code that changed everything" arguably could be:
#!/usr/bin/env perl
use strict;
use warnings;
use CGI;
Good old cgi, brings back memories :-D
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
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
What is CGI?
Man I feel old. :-/
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. 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.
> before 1998 or so
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.
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.
Man I feel old. :-/
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.
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.
> > 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 :).
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...
2 - https://en.wikipedia.org/wiki/FastCGI
> 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...
2 - https://en.wikipedia.org/wiki/FastCGI
Not true, according to here
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. 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.
> > Not true, according to here
> 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...
> 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...
You are technically correct, the best kind of correct.
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).
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).
I understood the first three lines :P
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? 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?
> I understood the first three lines :P
> 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
1 - https://en.wikipedia.org/wiki/Fork%E2%80%93exec
2 - https://en.wikipedia.org/wiki/FastCGI
> 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
1 - https://en.wikipedia.org/wiki/Fork%E2%80%93exec
2 - https://en.wikipedia.org/wiki/FastCGI
I like reading old Perl code. It's much more interesting than the Javascript code that displays stupid YouTwitFace plugins.
BTW, is this kind of specialised fork-exec code that writes back HTML code to the parent process still in use?
BTW, is this kind of specialised fork-exec code that writes back HTML code to the parent process still in use?
> 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 ;-).
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 ;-).
This is the same way that PHP works if you don't use the fast CGI modules. The webserver runs the php executable just as apache would've run perl in the gp's example.
Flashback to the days when URLs ended with “/cgi-bin”
> What is 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
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
you're a monster. not wrong, but still...
> you're a monster. not wrong, but still...
The monster I be, is when on the fifth line you see:
The monster I be, is when on the fifth line you see:
eval { local $/; <STDIN> };
Or:
require "cgi-lib.pl";I'd add Garbage Collection (Lisp was first I think) which transformed how we write programs, allowing more focus on solving the real problem, and less on memory management.
Also vms/containerization is worth a mention? The basis for the cloud.
Also vms/containerization is worth a mention? The basis for the cloud.
Brilliant suggestion. All my most proficient and excellent times while programming were among the purview of garbage collectors. They have assisted my career in more ways than any conference talk ever has. In fact, I'd say GC basically saved me from burnout.
I wish I could garbage collect my ex the same way that D rocks my garbage for me!
I wish I could garbage collect my ex the same way that D rocks my garbage for me!
Maybe lisp should have been mentioned in the list. Homoiconicity, macros, metacircular evaluation, conditionals, multimethods, and more I'm sure, all come from lisp.
Also "rm -rf /*". It taught generations of sysadmins and programmers not to run code they don't understand.
To err is human, to really foul up requires the root password.
More generally, it taught us to be careful with string substitution and interpolation.
There's actually (at least) two versions of GP's comment - unsafe code/data, what you appear to be referring to:
rm -rf $FOO/*
rm -rf . /*Well, "us" except Unix and Unix-like developers, where "rm -rf /*" still works like it always did, unless your rm added --no-preserve-root or some similar ugly hack.
:(){:|:&};:
Another clueless rant against null-terminated strings.
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:
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.
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.
> The flaw isn't the null termination but the lack of encapsulation.
> 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.
> 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.
You're arguing about requirements. Of course when Thompson and Ritchie went for null terminated strings, they knew that NUL would be excluded. That's the specification at the requirement level; it's not a "oh crap, we unwittingly excluded NUL from strings" bug.
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.
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.
I apologize for that last remark. In fact, the first ASCII document from 1963 uses NULL!
http://worldpowersystems.com/ARCHIVE/codes/X3.4-1963/page5.J...
This got shortened to NUL in 1965.
http://worldpowersystems.com/ARCHIVE/codes/X3.4-1963/page5.J...
This got shortened to NUL in 1965.
The banner at the top is wrong. It should be simply
while(*dest++ = *src++);
It’s not wrong, just not as short as it can be. Comparing things that aren’t booleans with zero explicitly is a common style choice.
Well, the article is about the historical context of the idiom, and they got the context wrong. The full context (K&R second edition at least) is working through pointers and trimming down strcpy(). The '\0' one is version 2, and the following is version 3.
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.
> the notational convenience is considerable,
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().
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().
Well, it's a self-replicating bit of code. That's arguably a virus. Granted, it doesn't infect anything else, but it does self-replicate.
As I scrolled through the article, I was surprised to see that they quoted a piece of my published code. Section "Introduction of the JPEG", function "NaiveDct_transform()".
In a way I feel the MP3 format and the digital music revolution in terms of both easy of releasing, sharing and cross-device listening was even more significant than what JPEG did for photos.
I thought they explained null terminated strings pretty well. But I feel they misled a bit on buffer overflows, which are more due to using raw pointers and not having a runtime that does bounds checking than anything else.
I enjoyed the stories, many were new for me, but this was a major foul:
> 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.
> 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.
Or more specifically, the lack of a length that accompanies a pointer that can be used for bounds checking.
Nitpick: hyperlinks don't work w/o name resolution, arguably the prior advancement that is oddly missing from this history.
I'd also argue for the inclusion of Leonard Kleinrock's seminal paper on communication networks.
I'd also argue for the inclusion of Leonard Kleinrock's seminal paper on communication networks.
Torrents/filesharing and ransomware would be possible additions to this list.
Napster predates torrents by a little bit, and seemed to be the real gateway for file sharing for most people IMO.
[deleted]
Like button counter evolved from what it was the RSS reader counter from blog post called Feedburner.
Some things come from pure evolution not necesary revolution.
I'm surprised some form of Comet didn't make the list (early approaches for AJAX / XMLHttpRequest / Long Polling / etc).
Another one I can think of:
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.
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 think the lines of code that changed everything is when a guy changed "utf8" from 6 bytes to 3 bytes somewhere in a commits of https://github.com/mysql/mysql-server.
I failed to bookmark it nor find it. Sorry.
I failed to bookmark it nor find it. Sorry.
What does MySQL have to do with this? It seems it was RFC3629¹ that restricted the domain of UTF-8 to cap at U+10FFFF and therefore remove 5- and 6-byte encodings.
¹https://tools.ietf.org/html/rfc3629
¹https://tools.ietf.org/html/rfc3629
Weird that they went back to 1755 but skipped the universal Turing machine.
Surely the most influential line of code was written in Algol,
let there = light
let there = light
I'd add telnet (not the same as telenet) and ftp.
$scope
diff and patch
time and uptime
uuidgen and ping
...?
time and uptime
uuidgen and ping
...?
#!/bin/sh (long-lived)
Great article !
$(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.