I suppose this is meant to be funny.
If PHP Were British (2011)
11–20 of 47 posts
Re: If PHP Were British (2011)
#12I assume the site is coded in PHP and that's why it's down ;) Text-only cache [1] [1] http://webcache.googleusercontent.com/search?q=cache:imONA_3...
Perhaps the site has left for its afternoon tea?
Re: If PHP Were British (2011)
#13I quite enjoy exploring some of the languages linked here:
https://en.wikipedia.org/wiki/Non-English-based_programming_...
Re: If PHP Were British (2011)
#14No content of value.
Re: If PHP Were British (2011)
#15I honestly think that his "what_about-perhaps" construct is nicer than "switch-case".
Re: If PHP Were British (2011)
#16I 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). (0) my_structured_query_language_connect() (1) SHFILEOPSTRUCTW [0] (2) InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter [1] [0]…
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 sh…
>> 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".
Re: If PHP Were British (2011)
#17Previous discussions:
Re: If PHP Were British (2011)
#18Snort The idea of the super global £_BISCUIT instead of $_COOKIE - that made my morning.
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?
Re: If PHP Were British (2011)
#19Earlier quoted context omitted.
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 sh…
>> 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 wor…
> 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.
Re: If PHP Were British (2011)
#20I feel if this was done for Perl, it would already be an option ala Klingon[0]