Editing 1537: Types
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 8: | Line 8: | ||
==Explanation== | ==Explanation== | ||
− | + | {{incomplete|Title text not explained. More details before the list.}} | |
− | Most regular programming languages distinguish types, e.g. integers, strings, lists… all of which have different behaviours. | + | This comic is a series of programming jokes about a ridiculous new programming language, perhaps inspired by [https://www.destroyallsoftware.com/talks/wat Gary Bernhardt's CodeMash 2012 lightning talk] on JavaScript's unpredictable typing. In the talk, the (highly technical) audience was unable to correctly guess the results of adding various JavaScript types and roared with laughter when they were revealed. The programming language shown in this comic has types even more unpredictable than JavaScript. |
+ | |||
+ | Most regular programming languages distinguish a number of types, e.g. integers, strings, lists… all of which have different behaviours. The operation "+" is conventionally defined over more than one of these types. Applied to two integers, it returns their addition; applied to two strings (denoted by being enclosed in quotes) it concatenates them: | ||
+ | |||
+ | <code>> 2 + 3 | ||
− | |||
5 | 5 | ||
> "123" + "abc" | > "123" + "abc" | ||
− | |||
− | While these behaviours are standard, conventional, and intuitive, there is a huge amount of variation among programming languages when you apply an operation like "+" to different types. One logical approach is to always return an error in all cases of type mixing, but it is often practical to allow some case mixing, since it can hugely simplify | + | "123abc"</code> |
+ | |||
+ | While these behaviours are standard, conventional, and intuitive, there is a huge amount of variation among programming languages when you apply an operation like "+" to different types. One logical approach is to always return an error in all cases of type mixing, but it is often practical to allow some case mixing, since it can hugely simplify an operation. Variation and lack of a clearly more intuitive behaviour leads some languages to have weird results when you mix types. | ||
− | + | # <code>2 + "2"</code> uses the <code>+</code> operator on a number and a string. In some programming languages, this might result in the number <code>4</code> (addition), or <code>"22"</code> (string concatenation); however, the new language converts the string to an integer, adds them to produce <code>4</code> and converts back to a string. Alternately, it may instead be adding 2 to the ASCII value of the character <code>"2"</code> (50), resulting in the character <code>"4"</code> (52). This is (somewhat) consistent with the behavior for item 4. | |
− | # <code>2 + "2"</code> uses the <code>+</code> operator on a number and a string. In some programming languages, this might result in the number <code>4</code> | + | # <code>"2" + []</code> adds a string to an array or list, this time. This first inexplicably converts the string to a number again, and then it literally adds the number to the list by appending it (this would make sense if it was <code>[] + 2</code>, but usually not the other way around). And then the result (the entire array) is converted to a string again. |
− | # <code>"2" + []</code> adds a string to an array or list. This first inexplicably converts the string to a number again, and then it literally adds the number to the list by | + | # <code>(2/0)</code> divides <code>2</code> by <code>0</code> and quite reasonably results in <code>NaN</code> (not a number), though in most languages, as prescribed by the IEEE 854 standard for floating point numbers, dividing a nonzero number by zero would instead return an infinity value. |
− | # <code>(2/0)</code> divides <code>2</code> by <code>0</code> and quite reasonably results in <code>NaN</code> | + | # <code>(2/0)+2</code> adds <code>2</code> to <code>NaN</code>. <code>2</code> is "added" to the string <code>"NaN"</code> (again, the number is converted to a string for apparently no reason), which produces <code>"NaP"</code>. If the language's convention is to add to the ASCII value of a character or string, then in this case it added 2 to the character <code>"N"</code> (78), resulting in <code>"P"</code> (80). |
− | # <code>(2/0)+2</code> adds <code>2</code> to <code>NaN</code>. <code>2</code> | + | # <code>""+""</code>: In many languages, two consecutive double-quote characters denote an empty string, so this expression would concatenate two empty strings, resulting in an empty string. However, it appears that this language treats only the outermost quotes of the expression as the string boundary, so all of the characters between them become part of the literal string, producing '<code>"+"</code>'. |
− | # <code>""+""</code>: In many languages, two consecutive double-quote characters denote an empty string, so this expression would concatenate two empty strings, resulting in an empty string. However, it appears that this language treats only the outermost quotes of the expression as the string boundary, so all of the characters between them become part of the literal string, producing '<code>"+"</code>' | ||
# <code>[1,2,3]+2</code> seems to test whether it's sound to append <code>2</code> to the list <code>[1,2,3]</code>, and concludes that it doesn't fit the pattern, returning the boolean value <code>false</code>. It could conceivably also be the result of an attempt to add <code>2</code> to the ''set'' <code>[1,2,3]</code>, which already contains that element (although <code>{1,2,3}</code> would be a more common notation for sets). | # <code>[1,2,3]+2</code> seems to test whether it's sound to append <code>2</code> to the list <code>[1,2,3]</code>, and concludes that it doesn't fit the pattern, returning the boolean value <code>false</code>. It could conceivably also be the result of an attempt to add <code>2</code> to the ''set'' <code>[1,2,3]</code>, which already contains that element (although <code>{1,2,3}</code> would be a more common notation for sets). | ||
# <code>[1,2,3]+4</code> returns <code>true</code> for much the same reason. | # <code>[1,2,3]+4</code> returns <code>true</code> for much the same reason. | ||
− | # <code>2/(2-(3/2+1/2))</code> is a floating point joke. Floating point numbers are notoriously imprecise. With precise mathematics, <code>(3/2+1/2)</code> would be exactly 2, hence the entire thing would evaluate to <code>2/0</code> or <code>NaN</code> in Randall's new language. However, the result of <code>(3/2+1/2)</code> is "just slightly off," which makes the result "just slightly off" of <code>NaN</code>, which would be ridiculous in a real language. The ironic thing is that fractions with 2 in the denominator are ''not'' the kind of numbers that typically suffer from floating point | + | # <code>2/(2-(3/2+1/2))</code> is a floating point joke. Floating point numbers are notoriously imprecise. With precise mathematics, <code>(3/2+1/2)</code> would be exactly 2, hence the entire thing would evaluate to <code>2/0</code> or <code>NaN</code> in Randall's new language. However, the result of <code>(3/2+1/2)</code> is "just slightly off," which makes the result "just slightly off" of <code>NaN</code>, which would be ridiculous in a real language. The ironic thing is that fractions with 2 in the denominator are ''not'' the kind of numbers that typically suffer from floating point impreciseness. Additionally, if there was indeed a rounding error, the actual calculation becomes something like <code>2/0.0000000000000013</code>, which should not return a <code>NaN</code> since it is not division by zero. |
− | # <code> | + | # <code>range(" ")</code> normally wouldn't make any sense. However, the new language appears to interpret it as ASCII, and in the ASCII table, character #32 is space, #33 is <code>!</code>, and #34 is <code>"</code>. So, instead of interpreting <code>" "</code> as a string, it seems to be interpreted as <code>34, 32, 34</code> (in ASCII), and then <code>range</code> appears to transform this into <code>34, 33, 32, 33, 34</code> (the "ranges" between the numbers), which, interpreted as ASCII, becomes <code>['"', '!', ' ', '!', '"']</code>. |
− | # <code>+2</code> | + | # <code>+2</code> refers to the Chinese/Japanese (Kanji) number system, where the plus sign is instead the symbol <code>十</code>. In Chinese, this symbol represents the number ten, and if you translate the <code>2</code> into Chinese, you get <code>二</code>. Therefore, in full Chinese the code is <code>十二</code>, which is equivalent to the number <code>12</code>. Alternately, it could simply be attempting to add 2 to the line number 10 to get 12. |
− | # <code>2+2</code> would normally be <code>4</code>. However, the interpreter takes this instruction to mean that the user wishes to increase the actual value of the number <code>2</code> (aka the "literal value") by <code>2</code> for the remainder of the program, making it <code>4</code> and then reports that the work is "Done". The result can be seen in the subsequent lines where all <code>2</code>s are replaced by <code>4</code>s. This could be a reference to languages like Fortran where [http://everything2.com/title/Changing+the+value+of+5+in+FORTRAN literals could be assigned new values] | + | # <code>2+2</code> would normally be <code>4</code>. However, the interpreter takes this instruction to mean that the user wishes to increase the actual value of the number <code>2</code> (aka the "literal value") by <code>2</code> for the remainder of the program, making it <code>4</code> and then reports that the work is "Done". The result can be seen in the subsequent lines where all <code>2</code>s are replaced by <code>4</code>s. This could be a reference to languages like Fortran where [http://everything2.com/title/Changing+the+value+of+5+in+FORTRAN literals could be assigned new values]. |
− | #<code> | + | # <code>range(1,5)</code> would normally return <code>[1, 2, 3, 4, 5]</code>. However, since the value of <code>2</code> has been changed to <code>4</code>, it returns <code>[1, 4, 3, 4, 5]</code>, and this even affects the line number (which is 14 instead of 12). |
− | #<code> | + | # <code>floor(10.5)</code> should return <code>10</code> (the "floor" of a decimal number is that number rounded down). However, it instead returns {{w|ASCII art}} of the number on a "floor." |
− | The title text contains three further examples relating to color. <code>color.rgb("blue")</code> returns the hexadecimal code for pure blue (as would be used in HTML, for example), which is how a real programming language might work. The lookup for "yellowish blue" returns "NaN" (Not a Number) again, which makes sense at one level because there is no such color as "yellowish blue" (yellow and blue are opposites on the | + | The title text contains three further examples relating to color. <code>color.rgb("blue")</code> returns the hexadecimal code for pure blue (as would be used in HTML, for example), which is how a real programming language might work. The lookup for "yellowish blue" returns "NaN" (Not a Number) again, which makes sense at one level because there is no such color as "yellowish blue" (yellow and blue are opposites on the color wheel, making yellowish-blue an {{w|impossible colour}}, which can only be perceived with great difficulty through contrived figures). However a more typical result would have been a failure indicating that the color database does not include the name, in the same way that a typo such as "bluw" would. Similarly sorting the colors would normally produce some defined ordering, such as alphabetical, but in this language it generates the string "rainbow". It seems that Randall's new language understands color theory in an unusually deep way. |
==Transcript== | ==Transcript== | ||
− | + | My new language is great, but it has a few quirks regarding type: | |
− | + | <pre> | |
− | + | [1]> 2+"2" | |
− | + | => "4" | |
− | + | [2]> "2"+[] | |
− | + | => "[2]" | |
− | + | [3] (2/0) | |
− | + | => NaN | |
− | + | [4]> (2/0)+2 | |
− | + | => NaP | |
− | + | [5]> ""+"" | |
− | + | => '"+"' | |
− | + | [6]> [1,2,3]+2 | |
− | + | => FALSE | |
− | + | [7]> [1,2,3]+4 | |
− | + | => TRUE | |
− | + | [8]> 2/(2-(3/2+1/2)) | |
− | + | => NaN.0000000000000013 | |
− | + | [9]> range(" ") | |
− | + | => ('"','!'," ","!",'"') | |
− | + | [10]> +2 | |
− | + | => 12 | |
− | + | [11]> 2+2 | |
− | + | => DONE | |
− | + | [14]> RANGE(1,5) | |
− | + | => (1,4,3,4,5) | |
− | + | [13]> FLOOR(10.5) | |
− | + | => | | |
− | + | => | | |
− | + | => | | |
− | + | => |___10.5___ | |
− | + | </pre> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{comic discussion}} | {{comic discussion}} | ||
− | [[Category: | + | [[Category:Programming]] |
− | [[Category: | + | [[Category:Language]] |