The first, but maybe the most important, of many changes that will allow PHP to achieve a more elegant feel is to remove that symbol so beloved by the US and replace it with something altogether more refined. More solid. More … sterling.
£variable_name
I remember living in Japan and being really weirded out by “C:¥Windows¥System¥” until I realized I was not weirded out by $variable.
IIRC this is caused by some non-ascii character code used in Japan mapping the yen symbol to the ASCII code point for a backslash? Obviously there’s no principled reason why the symbol for the American currency should be an acceptable sigil character in programming contexts but not the symbol for Japanese currency, but I think this isn’t an attempt to use the ¥ character syntacticallly but rather a text presentation bug due to incompatible character encoding systems.
See https://en.wikipedia.org/wiki/Shift_JIS. Even after the shift to Unicode, Japanese users expected to see ¥ instead of /, and for example on Mac OS Sonoma the input source preferences have toggle for ’ “¥” key generates: ¥ (Yen sign) / (Backslash)’.
When I was a PhD student in Swansea, we moved into a refurbished floor of one of the towers and I got to name the two small rooms off our main lab. The one where we drank tea / coffee was called the Smalltalk room and the seminar room with views out over the bay was called the C++ room.
What about an abstract language that would have a common AST (compiler, runtime, libraries…) and various source code dialects? :-) Like ASN.1 that can be written in BER, XER, PER or other encodings.
The French government required Microsoft to translate VBA into French to be able to sell Office to the government. Unfortunately, they indulged in a bit of malicious compliance and stored the code in documents as text, rather than a parsed AST (or even the canonicalised English version) so they ended up with documents not being interoperable between the two versions.
In about 1992 I had to install a new printer on a DOS PC at the Venezuelan Embassy in London. It ran MS Works as its main app. My (Spanish) boss sent me because I spoke a little Spanish and he was too busy.
It’s burned in my mind for 2 reasons. 1 is relevant.
After some hours of fighting I found that MICROS~1 in its very finite wisdom translated file extensions and what in English was a .PRD file – printer description – was in Spanish a .DIM file: descripción de impresora. (My guesses!)
Rename the file with a different extension and Spanish Works immediately picked it up and worked perfectly. This took me all morning.
The two secretaries sharing the office were grumpily working on typewriters in the interim, desultorily chatting. They discussed how the young man (me) was clearly not having a good time and they probably wouldn’t get the computer back today and maybe they’d have to start using the old machines soon.
Eventually one asked the other if she’d like a coffee, and got up from her desk to go and make it. Before she left the room, I said, in Spanish, that I’d love one and milk and two sugars please.
A brief but very painful, embarrassed silence followed.
I got my coffee, they were both mortified – and very worried that they’d discussed anything confidential. I wouldn’t have understood if they did. They hadn’t though to ask or check if I understood, even though I was trying to fix a computer that was 100% in Spanish or even to offer me a coffee.
My points here:
Always remember Hanlon’s Razor.
100% on-brand for MICROS~1. Both ways. Malice and incompetence.
There is similar problem with MS Excel and CSV files (comma separated values). In some localizations is uses standard commas, but in others, it uses semicolons. This is totally ill implementation. There might be multiple localized user interfaces, but there must be one interoperable machine-readable representation.
If you could parse French source code to common AST and then translate it back to e.g Czech or English source code, it might be useful. But if this lossless conversion step is missing and different localizations of the same product are incompatible, it is really silly.
I remember living in Japan and being really weirded out by “C:¥Windows¥System¥” until I realized I was not weirded out by $variable.
IIRC this is caused by some non-ascii character code used in Japan mapping the yen symbol to the ASCII code point for a backslash? Obviously there’s no principled reason why the symbol for the American currency should be an acceptable sigil character in programming contexts but not the symbol for Japanese currency, but I think this isn’t an attempt to use the
¥character syntacticallly but rather a text presentation bug due to incompatible character encoding systems.I believe the
$variableconvention is from older versions of BASIC, where I learned it stood for “string”. But don’t quote me on that.BASIC of the 80s did use the ‘$’ to designate string variables, but they were at the end, like
A$, not beginning.Oh man you’re right, it has been so long… I’m actually quite proud I’ve managed to forgotten so much old BASIC.
See https://en.wikipedia.org/wiki/Shift_JIS. Even after the shift to Unicode, Japanese users expected to see ¥ instead of /, and for example on Mac OS Sonoma the input source preferences have toggle for ’ “¥” key generates: ¥ (Yen sign) / (Backslash)’.
I now want a language with perchance statements and actually-I-do-mind clauses.
SPL (https://en.wikipedia.org/wiki/Shakespeare_Programming_Language) seems open for those kinds of enhancements
Be careful what you wish for, it comes with objection-oriented exceptions.
I think this is what the C Preprocessor is for.
only if the compiler also responds with british humor when trying to find out why it doesn’t compile
Surely there’s a
SmalltalkTeabanter dialect in this idea …When I was a PhD student in Swansea, we moved into a refurbished floor of one of the towers and I got to name the two small rooms off our main lab. The one where we drank tea / coffee was called the Smalltalk room and the seminar room with views out over the bay was called the C++ room.
Amazing 👏🏾
I want a programming language with Greenlandic syntax. It uses prefixes and suffixed extensively which could make for something kind of facinating.
What about an abstract language that would have a common AST (compiler, runtime, libraries…) and various source code dialects? :-) Like ASN.1 that can be written in BER, XER, PER or other encodings.
The French government required Microsoft to translate VBA into French to be able to sell Office to the government. Unfortunately, they indulged in a bit of malicious compliance and stored the code in documents as text, rather than a parsed AST (or even the canonicalised English version) so they ended up with documents not being interoperable between the two versions.
In about 1992 I had to install a new printer on a DOS PC at the Venezuelan Embassy in London. It ran MS Works as its main app. My (Spanish) boss sent me because I spoke a little Spanish and he was too busy.
It’s burned in my mind for 2 reasons. 1 is relevant.
.PRDfile – printer description – was in Spanish a.DIMfile: descripción de impresora. (My guesses!)Rename the file with a different extension and Spanish Works immediately picked it up and worked perfectly. This took me all morning.
Eventually one asked the other if she’d like a coffee, and got up from her desk to go and make it. Before she left the room, I said, in Spanish, that I’d love one and milk and two sugars please.
A brief but very painful, embarrassed silence followed.
I got my coffee, they were both mortified – and very worried that they’d discussed anything confidential. I wouldn’t have understood if they did. They hadn’t though to ask or check if I understood, even though I was trying to fix a computer that was 100% in Spanish or even to offer me a coffee.
My points here:
There is similar problem with MS Excel and CSV files (comma separated values). In some localizations is uses standard commas, but in others, it uses semicolons. This is totally ill implementation. There might be multiple localized user interfaces, but there must be one interoperable machine-readable representation.
If you could parse French source code to common AST and then translate it back to e.g Czech or English source code, it might be useful. But if this lossless conversion step is missing and different localizations of the same product are incompatible, it is really silly.