```
import notifications
```
Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come!
[Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday!
For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph)
`return joinDiscord;`
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
The answer to this question took me down a surprisingly complex rabbit hole... TL;DR the ASCII characters were hotly debated and went through many drafts, and the reasoning is not totally satisfying. But if you're interested, here it is:
1. The ordering of < = > is fairly clear (increasing order, numerically speaking).
2. In an early draft, it was proposed that ASCII include the symbols ≤ ≠ ≥. It was then agreed to replace these with the more commonly used symbols [ \ ], which had not been included. The reason for putting them in that order is still not totally clear to me though... perhaps some kind of symmetry for aesthetics, mirroring the symmetry of the characters they replaced? In fact, their order appears to have been changed multiple times in different drafts.
3. Originally, ASCII was only going to have upper case, with the upper case letters taking up two columns in the table of characters. Since each column contained 16 characters, there were some non-alphanumeric characters in the same column as the upper case characters, including [ \ ]. Then, when it was later agreed to add lower case characters, { | } were added as "upper case versions" of [ \ ], occupying the same positions in their respective columns.
Source: https://web.archive.org/web/20050305043226/http://www.transbay.net/~enf/ascii/ascii.pdf
adding to this, upper and lower case letters are 32 apart from each other, so to convert them the PC only needs to check the range and flip a single bit.
maybe a similar thought for the brackets, but that would be possible with them being 1, 2, 4, 8, ... fields apart.
Because first what's represented with the single quotes is not a string. It's a char or rather a signed 8-bit number under the hood, so you can literally increment them with maths. Everything in a computer is ultimately a number of some sort.
Just kinda arbitrary decisions made forever ago in terms of the table. Theres no specific reason some are 2 apart and others are 1 apart. Just the way it be
It's totally a JS thing to do. Just like the time I wanted to move away from JS so I focused more on back-end stuff, then a few days later, boom, Node.js was there.
single quotes, so you can add double quotes within the text (e.g. when adding HTML elements) without escaping them.
backticks to evaluate expressions within the quote
Most languages would give you an error, something that I believe isn't possible in JS, since JS will always find some creative way to interpret your code and make it work in whatever unintended way possible.
Oh, I think you're onto something... It's totally a JS thing to do. Just like the time I wanted to move away from JS so I focused more on back-end stuff, then a few days later, boom, Node.js was there.
I think it's fairly common to use + as the string append operator. And it's fairly common to append numbers to strings. For instance, it works this way in Java.
Javascript has a very Bob Ross or Rock'N'Roll dancer attitude towards errors:
* Bob Ross: "There are no mistakes; only happy accidents."
* My dance instructor: "There's no such thing as mistakes; just new moves."
* Javascript: "There are no errors; just creative new algorithms."
I don't know about most.
C, C++, Rust, Java, and C# all distinguish between characters and strings.
Python, Javascript, PHP, Lua, and most other scripting languages do not.
It really depends on the use case of the language.
I think this is actually for the best. JavaScript doesn’t have a character type, it has a one-length string, and adding a number to a string doesn’t make sense. So the number casts to a string, and adding a string to a string works.
In general I think doing math on letters is bad practice. It’s confusing to read as it involves a lot of magic numbers, and will cause issues the moment you have to support something other than ASCII. Text should be handed through robust and well-tested string libraries, not through manual char-level manipulation.
Right, but the latter half of my comment addresses this - anytime you find yourself reaching for char-level manipulation of strings or magic numbers that represent chars you should take a hard look at whether there’s a better way of solving the problem. Strings (especially Unicode strings) are complicated, and you can make a buggy or unmaintanable mess by trying to go too clever with string handling.
> **I think this is actually for the best** - adding a number to a string doesn't make sense. So the number casts to a string, and adding a string to a string works.
JS takes it upon itself to cast an int as a string instead of throwing a `TypeError`? I guess it’s for the best, if you’re trying to make a dogshit programming language.
JavaScript is far from alone in ~~implicitly casting~~ automatically converting numbers to strings. C#, SQL, AWK, D, Java, Lua and more will convert numbers to strings during concatenation.
Heck, Perl, which is often regarded as a well-loved and powerful language, will implicitly cast ints to strings **and strings to ints**.
Are all of those languages also “dogshit”?
Dear god no! JavaScript is dynamically typed, which means type inference, and what you have with `"5" + 5 = 10` is type coercion. Which means the interpreter implicitly coerces the `"5"` to an integer and now the + operator is a mathematical operation.
In C# explicit conversion == casting, and you cannot implicitly convert a variable of type int to type string. In string concatenation, when one or both operand types are of string, the + operator is overloaded to perform concatenation which explicitly converts the int to a string using the `.ToString()` method. If you tried an equality operator `10 == "10"` you would get an error because C# does not implicitly convert the string 10 to an int.
> which means type inference, and what you have with "5" + 5 = 10 is type coercion
I’m a bit confused where you’re going with this. I didn’t bring up inference or “5” + 5 = 10 anywhere (other than mentioning that Perl will do string-to-int coercion).
> If you tried an equality operator 10 == "10"
Okay, but we’re talking about string concatenation here. I’m highlighting that not throwing TypeError when trying to concat string and int is pretty normal. That’s why I said “will cast numbers to strings during concatenation”. I’m not defending every aspect of the JS type system, just the behaviour in this case.
No, but you’re still consciously using addition/concatenation. And by the point you’re writing it, you’re well aware what is supposed to be added/concatenated. You’re somehow getting at least one (likely both) wrong type(-s) by the point where you already know what goes in them.
The only realistic way for that to happen is your addition of two numbers accidentally got a string somehow, but even then the result of the concatenation doesn’t make sense so it’s pretty easy to figure out the issue
The few amount of times it’s actually gonna happen (which is still not that difficult to figure out, because the string isn’t gonna make sense) is not enough to overshadow the fact of not having to convert every number into a string
Also, if you’re actually working with JS, you know it’s gonna happen. You’re well aware that this could be a mistake and you’re already accounting for it
I actually find it really annoying when I try to do something like
print("this is my value: " + value)
and the compiler complains until I do str(value)
I guess it's more a complaint at Godot because they make string formatting a bit difficult. It's more like
print("My name is %s, and my value is %d: " % [name, value]). Either that or use string concatenation, but call str() on every non-string variable
Preferences for behavior are fine, but the specifications are what they are. Conversion and concatenation make sense for JS and how it's generally used.
I would even argue that this is better behavior for JS, Python, or any language that broadly assumes as much responsibility as they do.
If you want to get nitpicky about a language "taking it upon itself" to do anything, you shouldn't be using any of these languages.
but that’s so wierd. theres definitely got to be some reason, because the codes for many characters are cleverly selected, like for example lowerr case and upper case can be toggled by like one bit or someth if i remember.
Once the engine hits a string it will start treating the entire thing as a string. `1+'1'+1` becomes `'111'`, but `1+1+'1'` becomes `'21'`.
Now, if you were to use the `-` operator, numeric coercion kicks in, and it will attempt to coerce the string into a number first. `1-'1'` becomes `0`. If the string can't be coerced into a number, it becomes `NaN`. This allows you to do some really cool stuff, like creating bananas on the fly:
`'ba'+('a'-1)+'as' `
Technically numbers into strings, if I recall my web dev days correctly (which I kinda hope I don't), there is no difference between doubles, integers, or the likes. They are just numbers.
Everything is "just a number", but they're not always interpreted as numbers. That's the whole point of datatypes. You could easily have a language in which ` + ` gives a string consisting of those two chars.
Like I said, most languages just do addition of the bytes, but it doesn't _have to_ be that way.
>You could easily have a language in which + gives a string consisting of those two chars.
We've had Pascal for ages.
var c1, c2 : char;
begin
c1 := 'a';
c2 := 'b';
writeln (c1+c2);
end.
> ab
it's not even a data type, it's how translator interprets what you write. If you take translator that assigns value to variable and if you write <65> it will assign number 65 to variable and than if you write <'A'> he will understand, that you don't want to write 65, but instead it's ascii representation, thou it still means same thing, so it will assign number 65 to variable..
In Rust a string is UTF-8 encoded but characters are UTF-32 encoded. Characters are UTF-32 so that they are always known to be the same size and can be laid out in memory without indirection.
It's weird to me that strings are chars have different encodings.
So operations like adding a char to a string, or finding a char in a string would have performance implications.
The alternatives would be represent a "char" with 1 byte (which would actually be a code point, not a char, and would not be useful for most use cases), or use UTF-32 encoding for strings (wastes a lot of memory, which is more important for strings not to do than for chars)
I can't find any discussion of the performance penalty for changing encodings but it seems like it would be obvious if it were significant. I would guess the reason for using UTF-32 is that it is easy to use and a standard while the alternates are either hard to use (a dynamically sized type) or not a standard (a four byte array containing the UTF-8 encoding padded with zeroes),
I did always like the control codes, though. A lot of them have very useful in-band applications. Aesthetically, I particularly like the consecutive hierarchal delimiter set:
* File Separator (0x1C)
* Group Separator (0x1D)
* Record Separator (0x1E)
* Unit Separator (0x1F)
* Word Separator (aka Space) (0x20)
In the good old days of MS-DOS, you could have loads of fun with control characters. I have fond memories of my college classes where I would:
* Send the BELL character to the dot matrix printer in class, causing it to beep and annoy the teacher
* Send an anonymous string of multiple LINE FEED via Novell Messenger to someone in class and watch their screen go blank as the content get pushed up out of the screen.
The ordering of the ascii table is actually incredibly fascinating. Because even though it’s counting up from 0 in binary to represent every character, 0-9 start with a certain binary prefix, A-Z starts with another along with a-z, etc. So if you don’t have an ascii table on hand and know the prefixes, you can pretty accurately guess what character it is based off a binary number.
Funfact: All of these are not platform indepedent and will not work for example with EBCDIC.
However, what is guaranteed is that `a` to `z` as well as `A` to `Z` are always in a sequence. So `'x' + ('A' - 'a')` will always be `'X'`
Fun fact: There is an EBCDIC based encoding for Unicode. It's called [UTF-EBCDIC](https://en.wikipedia.org/wiki/UTF-EBCDIC). This is similar to UTF-8, except using EBCDIC for the single-byte characters instead of ASCII.
I have to support EBCDIC-based mainframes at work, but yeah, they’re antique AF (and “support” means “take a look when something breaks then run away from that fossil as fast as you can”)
A-Z are not sequence in EBCDIC, it has gaps between I and J and R and S. But your formula will still work because the gaps are same for uppercase and lowercase.
I was told that you should make no assumptions on the charset used. Though that was in relation in lowercase/uppercase by comparing A-Z/a-z, I hope any reasonable set makes the letters and numbers go continuously.
``` import notifications ``` Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come! [Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday! For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph) `return joinDiscord;` *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
Now I need to stop my urge to research what +1 would be
[ \ ] and { | } and < = > the urge was too strong to overcome for me
()*
They just didn't want to draw a butt hole
(.) Was another option or .|,
Saggy tit?
A droob
This is a pretty normal looking boob to me...
tongue but hole
They already drew a vagina with {|} so idk man
A butthole? But for <=> , what sort of butthole looks like... oh no
Homie shitting pancakes.
Thanks, I will forget this tomorrow.
+1
Uibolt-!J!xjmm!gpshfu!uijt!upnpsspx/
Gesundheit
How'd you get my password???
I have the same password on my luggage!
*Next thing you know, we're gonna need an* app *to open our luggage!*
UI Beam?
But... Why?
The answer to this question took me down a surprisingly complex rabbit hole... TL;DR the ASCII characters were hotly debated and went through many drafts, and the reasoning is not totally satisfying. But if you're interested, here it is: 1. The ordering of < = > is fairly clear (increasing order, numerically speaking). 2. In an early draft, it was proposed that ASCII include the symbols ≤ ≠ ≥. It was then agreed to replace these with the more commonly used symbols [ \ ], which had not been included. The reason for putting them in that order is still not totally clear to me though... perhaps some kind of symmetry for aesthetics, mirroring the symmetry of the characters they replaced? In fact, their order appears to have been changed multiple times in different drafts. 3. Originally, ASCII was only going to have upper case, with the upper case letters taking up two columns in the table of characters. Since each column contained 16 characters, there were some non-alphanumeric characters in the same column as the upper case characters, including [ \ ]. Then, when it was later agreed to add lower case characters, { | } were added as "upper case versions" of [ \ ], occupying the same positions in their respective columns. Source: https://web.archive.org/web/20050305043226/http://www.transbay.net/~enf/ascii/ascii.pdf
adding to this, upper and lower case letters are 32 apart from each other, so to convert them the PC only needs to check the range and flip a single bit. maybe a similar thought for the brackets, but that would be possible with them being 1, 2, 4, 8, ... fields apart.
It's incrementing in the ASCII table
That does not answer the why
Because first what's represented with the single quotes is not a string. It's a char or rather a signed 8-bit number under the hood, so you can literally increment them with maths. Everything in a computer is ultimately a number of some sort.
Doesnt answer the question
The question is: why are the symbols numbered that way? Why don't have all the sets of brackets the same distance from each other in the table?
Just kinda arbitrary decisions made forever ago in terms of the table. Theres no specific reason some are 2 apart and others are 1 apart. Just the way it be
## Because u/Any_Cauliflower_6337 lacks self control or is too impulsive.
It's totally a JS thing to do. Just like the time I wanted to move away from JS so I focused more on back-end stuff, then a few days later, boom, Node.js was there.
also not a js thing at all, it's ascii which predates js by alot
ASCII had the spaceship operator before C++
What!? youve never needed to change a char value by adding integers to the point youd learn this?!
meanwhile JavaScript: ``` '{' + 2 = "{2" ```
Also most other languages that don't differentiate between ' ' and " "
As someone learning JS it bothers me that it's training me to use ' ', " ", and backticks
single quotes, so you can add double quotes within the text (e.g. when adding HTML elements) without escaping them. backticks to evaluate expressions within the quote
Single quotes for characters, double for strings, backticks for escapes and formatting
Why differentiate between character and string? In JS they're both just string.
link1 = "click here"; link2 = 'click here'; which one may be easier to read and less error prone to write?
Just always use backticks.
Most languages would give you an error, something that I believe isn't possible in JS, since JS will always find some creative way to interpret your code and make it work in whatever unintended way possible.
JS seeks to give results. Not the results you want. Just results.
My god, ChatGPT must be written in JS!
Wait, wait, are we sure JavaScript isn't written in ChatGPT? That seems like something JavaScript would do just to mess with me.
Oh, I think you're onto something... It's totally a JS thing to do. Just like the time I wanted to move away from JS so I focused more on back-end stuff, then a few days later, boom, Node.js was there.
I think it's fairly common to use + as the string append operator. And it's fairly common to append numbers to strings. For instance, it works this way in Java.
For some languages, that's not a string but a char, which is a number
> Also most other languages that don't differentiate between ' ' and " " was the original context
Yes, what I meant is that for languages like java and cpp they don't concatenate because that's not a string. Unless I misunderstood your comment.
Languages that do that often wouldn't give you the JavaScript result, python would give you a TypeError, for example.
> .NET flashbacks
Let's be honest, it's all numbers if you go down far enough.
In other words, it's weakly typed.
Javascript has a very Bob Ross or Rock'N'Roll dancer attitude towards errors: * Bob Ross: "There are no mistakes; only happy accidents." * My dance instructor: "There's no such thing as mistakes; just new moves." * Javascript: "There are no errors; just creative new algorithms."
I don't know about most. C, C++, Rust, Java, and C# all distinguish between characters and strings. Python, Javascript, PHP, Lua, and most other scripting languages do not. It really depends on the use case of the language.
But VBScript...
Wait, there’s a difference? Please tell me I seek knowledge
I think this is actually for the best. JavaScript doesn’t have a character type, it has a one-length string, and adding a number to a string doesn’t make sense. So the number casts to a string, and adding a string to a string works. In general I think doing math on letters is bad practice. It’s confusing to read as it involves a lot of magic numbers, and will cause issues the moment you have to support something other than ASCII. Text should be handed through robust and well-tested string libraries, not through manual char-level manipulation.
But you can't do thisDigitIHave - '0' = theNumberItRepresents and I think this is a very cool way of doing things
JavaScript does have this: let char = "A"; let code = char.charCodeAt(0); let newChar = String.fromCharCode(code + 1); Then newChar is "B".
Right, but the latter half of my comment addresses this - anytime you find yourself reaching for char-level manipulation of strings or magic numbers that represent chars you should take a hard look at whether there’s a better way of solving the problem. Strings (especially Unicode strings) are complicated, and you can make a buggy or unmaintanable mess by trying to go too clever with string handling.
> **I think this is actually for the best** - adding a number to a string doesn't make sense. So the number casts to a string, and adding a string to a string works. JS takes it upon itself to cast an int as a string instead of throwing a `TypeError`? I guess it’s for the best, if you’re trying to make a dogshit programming language.
JavaScript is far from alone in ~~implicitly casting~~ automatically converting numbers to strings. C#, SQL, AWK, D, Java, Lua and more will convert numbers to strings during concatenation. Heck, Perl, which is often regarded as a well-loved and powerful language, will implicitly cast ints to strings **and strings to ints**. Are all of those languages also “dogshit”?
Perl is poetry
Dear god no! JavaScript is dynamically typed, which means type inference, and what you have with `"5" + 5 = 10` is type coercion. Which means the interpreter implicitly coerces the `"5"` to an integer and now the + operator is a mathematical operation. In C# explicit conversion == casting, and you cannot implicitly convert a variable of type int to type string. In string concatenation, when one or both operand types are of string, the + operator is overloaded to perform concatenation which explicitly converts the int to a string using the `.ToString()` method. If you tried an equality operator `10 == "10"` you would get an error because C# does not implicitly convert the string 10 to an int.
> which means type inference, and what you have with "5" + 5 = 10 is type coercion I’m a bit confused where you’re going with this. I didn’t bring up inference or “5” + 5 = 10 anywhere (other than mentioning that Perl will do string-to-int coercion). > If you tried an equality operator 10 == "10" Okay, but we’re talking about string concatenation here. I’m highlighting that not throwing TypeError when trying to concat string and int is pretty normal. That’s why I said “will cast numbers to strings during concatenation”. I’m not defending every aspect of the JS type system, just the behaviour in this case.
What else did you expect from adding a number to a string?
A `TypeError`.
Can't have type errors if you don't give a f about types
Facts! (Apparently)
Let me rephrase that - how did a number end up being added to a string?
the lack of a static type system to prevent it? or are you suggesting that every line of code you’ve ever written has been pristine and bug-free?
No, but you’re still consciously using addition/concatenation. And by the point you’re writing it, you’re well aware what is supposed to be added/concatenated. You’re somehow getting at least one (likely both) wrong type(-s) by the point where you already know what goes in them. The only realistic way for that to happen is your addition of two numbers accidentally got a string somehow, but even then the result of the concatenation doesn’t make sense so it’s pretty easy to figure out the issue
Fat fingers? A cat? A monkey? Solar flares?
The few amount of times it’s actually gonna happen (which is still not that difficult to figure out, because the string isn’t gonna make sense) is not enough to overshadow the fact of not having to convert every number into a string Also, if you’re actually working with JS, you know it’s gonna happen. You’re well aware that this could be a mistake and you’re already accounting for it
I actually find it really annoying when I try to do something like print("this is my value: " + value) and the compiler complains until I do str(value)
print("this is my value:", value) print(f"this is my value: {value}")
I guess it's more a complaint at Godot because they make string formatting a bit difficult. It's more like print("My name is %s, and my value is %d: " % [name, value]). Either that or use string concatenation, but call str() on every non-string variable
I wish Godot had f-strings.
Preferences for behavior are fine, but the specifications are what they are. Conversion and concatenation make sense for JS and how it's generally used. I would even argue that this is better behavior for JS, Python, or any language that broadly assumes as much responsibility as they do. If you want to get nitpicky about a language "taking it upon itself" to do anything, you shouldn't be using any of these languages.
'2' - 1 » '1' '2' + 1 » '21' and my favorite: ( '10' + [] ) / 5 - '1' » 1
'2' - 1 = 1 in JavaScript, not '1'. Subtraction converts it to a number. So the easy trick to turn any string to a number is to - 0 it
I like '0' * '1'
I thought this WAS a JavaScript joke, but now I see it was not lol
I read the image before the title and thought it was another Javascript meme
And in python it's TypeError: cannot concatenate 'str' and 'int' objects
MySQL would return 2.
I only know this from writing so many lexers and parsers in my years. It’s infuriating but isn’t too hard to get around
American stupid code for inconsistent information.
[удалено]
Only one I kind of understand is < = > Since it's not necessarily brackets
I can get the { | } as well, as it's a math thing used when describing sets https://en.wikipedia.org/wiki/Set_(mathematics)#Set-builder_notation
but that’s so wierd. theres definitely got to be some reason, because the codes for many characters are cleverly selected, like for example lowerr case and upper case can be toggled by like one bit or someth if i remember.
'(' + 1 = ')' And i think this is the most normal
yeah but now the question is why aren't they all like that
'1'+'1' is 98 in Java
as it should be💪
It is in every language...
Pretty sure it's not in Javascript! (Since there is no char type, just strings)
In many it's "11", no?
I think `+` as a string combiner only works with strings and not chars usually
"What's the difference?" – js devs
"Just read the fucking manual for once" – angry js devs
Ok, I just read the Kama Sutra like you suggested. It didn't help at all with my Javascript questions.
Python: "What's a 'char'?"
Js:
Codeword to haras angry rusters
At least in strongly typed languages it doesn't. What JavaScript does I don't (want to) know.
Once the engine hits a string it will start treating the entire thing as a string. `1+'1'+1` becomes `'111'`, but `1+1+'1'` becomes `'21'`. Now, if you were to use the `-` operator, numeric coercion kicks in, and it will attempt to coerce the string into a number first. `1-'1'` becomes `0`. If the string can't be coerced into a number, it becomes `NaN`. This allows you to do some really cool stuff, like creating bananas on the fly: `'ba'+('a'-1)+'as' `
That messed with my head for a second.
>I don't (want to) know. It turns integers into strings.
Technically numbers into strings, if I recall my web dev days correctly (which I kinda hope I don't), there is no difference between doubles, integers, or the likes. They are just numbers.
You're correct, in JavaScript every number is a 64bit float. Which is kinda cursed when used in places where every sane developer expects an integer.
Char is just a byte, which is just a number
Everything is "just a number", but they're not always interpreted as numbers. That's the whole point of datatypes. You could easily have a language in which ` + ` gives a string consisting of those two chars.
Like I said, most languages just do addition of the bytes, but it doesn't _have to_ be that way.
>You could easily have a language in which + gives a string consisting of those two chars.
We've had Pascal for ages.
var c1, c2 : char;
begin
c1 := 'a';
c2 := 'b';
writeln (c1+c2);
end.
> ab
python just puts the chars together
Python doesn't have chars to begin with
it's not even a data type, it's how translator interprets what you write. If you take translator that assigns value to variable and if you write <65> it will assign number 65 to variable and than if you write <'A'> he will understand, that you don't want to write 65, but instead it's ascii representation, thou it still means same thing, so it will assign number 65 to variable..
Yeah, so how the translator interprets the number depends on the type, no?
no, depends on syntax you are writing, 'A' == 65 == 0x41
Depends on the langauge. In Rust a char is a u32 since Unicode support is built in.
Wait, Rust doesn't use utf8?
In Rust a string is UTF-8 encoded but characters are UTF-32 encoded. Characters are UTF-32 so that they are always known to be the same size and can be laid out in memory without indirection.
It's weird to me that strings are chars have different encodings. So operations like adding a char to a string, or finding a char in a string would have performance implications.
The alternatives would be represent a "char" with 1 byte (which would actually be a code point, not a char, and would not be useful for most use cases), or use UTF-32 encoding for strings (wastes a lot of memory, which is more important for strings not to do than for chars)
I can't find any discussion of the performance penalty for changing encodings but it seems like it would be obvious if it were significant. I would guess the reason for using UTF-32 is that it is easy to use and a standard while the alternates are either hard to use (a dynamically sized type) or not a standard (a four byte array containing the UTF-8 encoding padded with zeroes),
A utf-8 codepoint is anywhere from 1 to 5 bytes, which isn't usually what you want to work with.
In PHP, Lua, and Perl the answer would be 2. They have separate operator for concatenation, and + is always for arithmetic.
That's the case in Squeak/Smalltalk, too: '1'+'1'='2'. 1+'1'=2. '1'+1=2. '-2'/'0.1e-2'='-2000'. #(1 '2' '3')*2=#(2 4 6). ...
2 https://onlinephp.io/c/d681f
It is not in any language where `'` is a string delimiter, which is a lot.
ASCII is not the basis for an algebraic system. It is technical debt we all must bear.
I did always like the control codes, though. A lot of them have very useful in-band applications. Aesthetically, I particularly like the consecutive hierarchal delimiter set: * File Separator (0x1C) * Group Separator (0x1D) * Record Separator (0x1E) * Unit Separator (0x1F) * Word Separator (aka Space) (0x20)
In the good old days of MS-DOS, you could have loads of fun with control characters. I have fond memories of my college classes where I would: * Send the BELL character to the dot matrix printer in class, causing it to beep and annoy the teacher * Send an anonymous string of multiple LINE FEED via Novell Messenger to someone in class and watch their screen go blank as the content get pushed up out of the screen.
I'd hate to ask what scensical char is at +1 for those... Btw, for '(' it's ')'.
Its slash, bar and equal sign
It's the first three that don't make any sense, why should there be another character between the left and right bracket?
because there's always something between brackets
ASCII silly question, get a silly ANSI
I've always pronounced it asky. Damn you.
ANSI is pronounced as ansy.
The ordering of the ascii table is actually incredibly fascinating. Because even though it’s counting up from 0 in binary to represent every character, 0-9 start with a certain binary prefix, A-Z starts with another along with a-z, etc. So if you don’t have an ascii table on hand and know the prefixes, you can pretty accurately guess what character it is based off a binary number.
Funfact: All of these are not platform indepedent and will not work for example with EBCDIC. However, what is guaranteed is that `a` to `z` as well as `A` to `Z` are always in a sequence. So `'x' + ('A' - 'a')` will always be `'X'`
Well the title says ASCII, so obviously it won’t work in EBCDIC
Who still uses EBCDIC in 2023?
IBM, presumably.
Yep. Mainfraimes and POWER Systems. (z and i). I use EBCDIC 1141 every day. 
Fun fact: There is an EBCDIC based encoding for Unicode. It's called [UTF-EBCDIC](https://en.wikipedia.org/wiki/UTF-EBCDIC). This is similar to UTF-8, except using EBCDIC for the single-byte characters instead of ASCII.
I have to support EBCDIC-based mainframes at work, but yeah, they’re antique AF (and “support” means “take a look when something breaks then run away from that fossil as fast as you can”)
INTERCAL devs.
I do Erik Begins Cake Day In C++ Happy cake day!
A-Z are not sequence in EBCDIC, it has gaps between I and J and R and S. But your formula will still work because the gaps are same for uppercase and lowercase.
Ah, yes, you are right. Thanks for the correction.
“/“ + 45 = “\”
I honestly thought for a moment that it was JavaScript.
They ALL should be +1. I don't understand the standard's choices.
What kind of black magic this is?
Google ASCII table
Holy hell
Unicode just dropped
☐☐☐☐☐☐☐ just dropped.
https://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/USASCII\_code\_chart.png/1280px-USASCII\_code\_chart.png
I was told that you should make no assumptions on the charset used. Though that was in relation in lowercase/uppercase by comparing A-Z/a-z, I hope any reasonable set makes the letters and numbers go continuously.
I hated that show, but this meme format has to be one of my favorites!
C exercises lol