Offtopic - re cookies, the etymology of cookie (or 'magic cookie') as an opaque value is very obscure and has a interesting social side-effect in that it's difficult for average people to get very worked up about websites serving cookies (vs say the more universally understood 'tokens' or 'tracking codes').
While I get that the term originated in the Unix/C world[1], does anyone know if it comes from a particular US dialect or something? e.g. West Coast/Boston?
I don't know why but I (UK, en-gb native) always assumed "cookie" was reference to a fortune cookie in turn a placeholder for the little slips of paper with obscure notes on them hidden inside a sweet treat (ie the website)??
Since Rasmus Lerdorf was in Canada, I wonder what this would look like if it were in Canadian English. It would retain the dollar signs and serialize(), but switch to "colour" and "centre". It would be required by law to support a French version for every keyword. All PHP developers would have the advantage of free treatment for carpal-tunnel and other RSI injuries.
exit() would be called brexit() as some of the commenters pointed out... but instead of actually exiting, it will hang indefinitely trying to choose which exit code to return.
In reality of course the only difference is that it gets spelled "colour"...
One thing I'm surprised to have seen only once is use of ¬ as an escape character, because it's so reliably unused for anything at all. (I noticed in the code that this program, which needless to say was written at a UK company, had no way of escaping ¬ itself, presumably because nobody had ever needed that.)
£ also seems a bit underused, but it's fairly specifically the UK's currency symbol, so it's not obvious else you'd use it for.
(But I suspect only UK keyboards have these chars, so it's probably no bad thing.)
¬ is one of the many 'not' symbols that has been used through history.
As to why UK keyboards include it? Probably IBM, ¬ was the negation/not symbol in Z, it wouldn't surprise me if Hursley Park petitioned the rest of the company to ensure it was on the UK PC layout.
The funny spelling of centre always gets me too, it just looks so wrong! I can get used to writing words that end in ise as ize, and colour as color. But center, fiber, liter, etc just don't sit right.
It's just a matter of getting used to. I imagine these spellings do not evoke the same feeling in you, even though they are objectively following the same rule as centre and fibre:
Centre look and sounds like “cent-ruh” rather than the rolled out sounding of err sound to make “center”. Then again, how you say it is a bit different, too.
I have to concede that I do prefer the longer abbreviations, especially nowadays when most editors have auto-completion, although of course there are limits. A healthy balance between (0) and (1). This also reminds me of those ridiculously long class names (2).
This is part of the code-as-docs ethos which has really changed how I write everything. I try to make my code as intuitive as possible to obviate comments and documentation that only explain what the code is doing. You could also call it code-as-prose.
This is impeded when languages have popular modules with names that are absolutely unintuitive, like the Python "requests" module. Requests what? Oh, HTTP? Then it should have been called http_requests. And the module that one uses, urllib3, is actually an HTTP library, not a generic URL library (URLs can be any web request, such as ftp, mailto, jdbc, etc).
>> Requests what? Oh, HTTP? Then it should have been called http_requests. And the module that one uses, urllib3, is actually an HTTP library, not a generic URL library
Python has httplib since 2.7. Also urllib in 3.7 contains all of the URL parsing routines, too.
Naming is a hard problem, so frankly I would prefer if names did not try to mimic their corresponding protocols in the first place at all.
It gets even worse when you would like to support HTTP and async HTTP; then HTTP/2, HTTPS, HTTP server, etc... Which one of these libraries are supposed to be actually called "http"? What if there's two libraries with the same functionality?
urllib? Well, yeah - simply because someone wanted to provide a simple HTTP interface. By the way - urllib also provides FTP/local file access routines. So it does mean "a library to access URLs".
> Python has httplib since 2.7. Also urllib in 3.7 contains all of the URL parsing routines, too.
> urllib? Well, yeah - simply because someone wanted to provide a simple HTTP interface. By the way - urllib also provides FTP/local file access routines. So it does mean "a library to access URLs".
You're missing my point. These are just random examples of bad naming convention. Yes, Python has some core modules which sort of relate to their name... but everyone uses "requests" and "urllib3", not "httplib" and "urllib" (and urllib3 has no FTP support). And yes, you can name a simple http module anything you want, but if it's unintuitive, it's counter-productive to the humans that have to work with it.
> It gets even worse when you would like to support HTTP and async HTTP; then HTTP/2, HTTPS, HTTP server, etc... Which one of these libraries are supposed to be actually called "http"? What if there's two libraries with the same functionality?
The common solution is to create modules that inherit from parents, to extend base modules for more specific functionality. The names then become hierarchical - io, io::net, io::net::http, io:net::http::2, io::net::http::secure, io::net::http::server, io::net::http::client, and so on.
For whatever reason, Python doesn't support this, and instead creates new unique packages rather than extending pre-existing ones. It's rather annoying for multiple reasons, but specifically to my original point, it isn't code-as-docs.
> I try to make my code as intuitive as possible to obviate comments and documentation that only explain what the code is doing. You could also call it code-as-prose.
I do this, Often I can save typing by liberal use of 'clever' features but I avoid them because if I have to stop to reason them out the poor sod reading my code (Which is often me in 6mths) will as well.
It's one of the things I dislike the most about JS, there are 18 different ways to skin the cat, some of which set the house on fire opposite but only if it's a monday and the cat isn't undefined.
It's what happens when a language accretes instead of gets designed.
