I think that violates the “only X, but in different fonts” dictum. Those are technically different glyphs and therefore very distinct names. A font would be the same character tagged in different ways, those are absolutely different characters. Aside from the visual similarity, a computer would never be confused into think they’re even remotely similar (kind of how to us 1000000001 and 10000000001 look almost indistinguishably similar, but are almost impossible for a computer to confuse).
That seems obviously true, except it is actually incorrect, at least as far as Python (3) goes.
The following are all interpreted as X in variable names: XⅩＸ𝐗𝑋𝑿𝓧𝔛𝕏𝖃𝖷𝗫𝘟𝙓𝚇
And these are all interpreted as x: xˣₓⅹｘ𝐱𝑥𝒙𝓍𝔁𝔵𝕩𝖝𝗑𝘅𝘹𝙭𝚡
I.e. 𝖃𝖝, 𝕏𝕩 and Xx all represent the same variable!
Edit: As a mathematician, this is actually kind of annoying. Sometimes I would love to have different variables named x and 𝐱, or whatever. Oh well, at least I can have θ, λ, φ, π, etc. Autohotkey macros make them easy to type.
Sure, that's true in Python. Python has some reasonable assumptions built into it in this ares. The X programming language, on the other hand, was built by someone whose prior work in language creation was so egregious as to warrant a court order against further such activity. (Only to be overturned, one would presume, on 1st amendment grounds)
“Language P has a mechanism by which it conflates several different glyphs into a canonical form for the sake of variable names” is not an “actually not true” kind of exception.
A mathematician such as yourself (and myself too) should recognise that asserting different things to be functionally equal is an entirely distinct phenomenon from what is being discussed here, which is differentiating a unique glyph based on a formatting that (font).
This bit is the incorrect bit: "a computer would never be confused into think they’re even remotely similar". Python is treating different glyphs as if they're the same but formatted differently.
I'm pretty sure the first two links refer to something very different than the third:
The first two are about a way to encode maths using unicode, as in conventions and special characters allowing e.g. to write fractions, aligned equations, etc.
So, this would essentially furnish an alternative to the "math" subset of latex (think mathjax or katex) or mathml.
The third is a package for latex, and allows to use unicode symbols (greek letters, math symbols, etc.) in your math environments + something related to the use of unicode in the output (requiring compatible fonts); it seems the second part is the main one but I'm not sure what that means exactly.
The Latex package says "Maths input can also be simplified with Unicode since literal glyphs may be entered instead of control sequences in your document source." So it at least includes a similar idea.
Superficially similar, yes, but my point was just that it may seem from your bunching up the links together that all refer to the same thing, while they don't.
Fair enough, I've edited it. I just tried using the Latex package with a formula typed using Unicode symbols, and it does work, but doesn't follow all the UnicodeMath rules.
Symbolically same but semantically different characters are most of the time represented differently in the byte level so that searching in large text can still be implemented as simple byte comparison, if Unicode can be called simple.
"simply byte comparison" is not a term associated with Unicode. Unicode is usually in strings, and reverse engineering a string is -- very hard, and surprisingly I haven't found a paper proving whether it is NP complete.
That's the opposite of the rule for CJK characters, right? For those, symbolically-same characters get the same codepoint regardless of semantics (language) or shape (glyph).
"Since each variable has a corresponding color, assignment is easily represented with background colors. For instance, A denotes the assignment of the number 12345⅔ to the variable #F00BA2. Note that this could also be written as rm -rf /, because we are removing the arbitrary indirect association between text and meaning to focus only on the clear meaning conveyed by the formatting."
"Programming languages have not always been text-based. Early work explored many diverse paradigms. For example, the first widely used programming language, Build-A-New-Machine-For-Each-Task, did not employ text at all, nor did its popular successor, Plug-Wires-Into-Different-Places."
I do not exclude nothing weird since learning that indentation is a structural part of Python. I was convinced that it is just a joke, first. Now I am just sad.
> I do not exclude nothing weird since learning that indentation is a structural part of Python.
That is not that weird. In fact a more formal (and optional) version (the "offside rule", which is what Haskell uses) was part of Landin's Iꜱᴡɪᴍ:
> (c) Indentation, used to indicate program structure. A physical Iꜱᴡɪᴍ can be defined in terms of an unspecified parameter: a subset of phrase categories, instances of which are restricted in layout by the following rule called "the offside rule." The southeast quadrant that just contains the phrase's first symbol must contain the entire phrase, except possibly for bracketed subsegments. This rule has three important features. It is based on vertical alignment, not character width, and hence is equally appropriate in handwritten, typeset or typed texts. Its use is not obligatory, and use of it can be mixed freely with more conventional alternatives like punctuation. Also, it is incorporated in Iꜱᴡɪᴍ in a systematic way that admits of alternatives without changing other features of Iꜱᴡɪᴍ and that can be applied to other languages.
> I was convinced that it is just a joke, first. Now I am just sad.
If you consider the long and rich history of computing, Python is not uncommon. Just an example: in COBOL, the 7th character of a line has special meaning, for example, comments must begin at the 7th character. Code body usually starts at the 8th character of a line. If you don't follows these rules, compiler won't accept your code. It makes sense when you consider that COBOL was initially written on punchcards.
I am disappointed that the references at the end are made up and are not the prior art in the obviously important field of non-textual languages. I'd really love to learn about that "system for aromatic computation and its applications in cheese production [7]"!
WysiScript ie. "what you see is Script", smart word play with the acronym well known in the industry. What we are missing now is WYSYMNG editor ("what you see you might not get", see Beastie Boys song).
Curious... I can't figure out if this is completely serious. There are what are either tongue in cheek remarks, or they are taking themselves very seriously...
> "removing the awkward necessity of writing text"
> "as powerful as other languages and significantly more colorful"
> "we believe it will appeal to many types of students who may not have an interest in traditional text-based programming, including painters, graphic designers, and the illiterate."
I think it might be more effective to teach the illiterate to read first rather than code... Maybe it's worth it if learning to code inspires them to become literate?
> I can't figure out if this is completely serious.
"Most programming languages in use today use only a single color for all numeric literals, which is unnecessarily confusing and makes it impossible to distinguish different numbers using only a spectrometer"
“Future versions of the language may relax this restriction by adding support for additional colors not representable in RGB, such as ultraviolet, infrared, and plaid.”
> In order to support quantum computing, which makes use of value superposition and probabilistic algorithms, future versions of WysiScript may make use of the alpha channel in color specifications.
Yeah, I'm pretty sure they're not entirely serious.
Back in the late nineties I worked with a software called Origin. It had a BASIC like programming language where variable names consisted of single letters. If you now think 26 variable names should be enough: Some of the letters, like X and Y, had special predefined meaning and you couldn't change that. If you used seem you encountered strange behaviour, like values changing behind your back. To add insult to injury I could never find documentation about which variables were special, so I stuck with the few I new were safe, which were not many...
Like registers in a processor. e.g. the ARM1 had 16 32-bit registers, some of which were special (e.g. one was the pointer to the next instruction). From the point of view of a running program, those registers are the only true 'variables' that the processor had. Everything else was achieved by swapping them in and out of memory. I guess its the same for all processors. So a language with a restricted number of variables is actually pretty realistic - it represents the bare metal quite well.
The old TRS-80 Model 1, Level 1 had 4KB of memory and the only permitted variables were integers (A-Z), and two strings A$ and B$. No decimals, floats etc.
Level 2 allowed any number of letters in a variable name... but only the first two were recognised as unique. CUSTORDER was seen as the same variable as CUSTLINE.
> allowed any number of letters in a variable name... but only the first two were recognised as unique.
That was a well-known Microsoft BASIC feature that got passed down licensed descendants like TRS-80 and Commodore BASIC, and lasted through earlier 6502 BASIC implementations.
There was a basic programming cartridge for the Atari 2600. It was limited to programs that could fit on a single low-res screen (I think six lines?) and only allowed one or two variables, if I recall correctly. I remember trying to write a simple program on a friend's Atari and found something that seemed really fundamental (maybe altering the value of an index variable in a for loop) was not allowed.
> That's just a "template" file, which I use search and replace in order to generate the three monomorphized go files.
They were using a separate codegen step (really just a sed run) to actually "do generics". In fact, that was the entire reason this thing was introduced[0], the structure originally used interface{} for its items.
The "generic" part was then moved to a `go_` file from which monomorphisations on bool, ArrayT and ScalarT got generated.
Also
> Go allows characters from the Canadian Aboriginal Syllabics for identifiers
I'd expect just about any language which supports unicode identifiers to allow this, as canadian aboriginal syllabics is a "normal" abugida, and its "textual" components are (properly) tagged as XID_Start and XID_Continue.
A good set of variable names could be found in Unicode’s confusables list, starting at line 3795 (or search for CANADIAN SYLLABICS FULL STOP → LATIN SMALL LETTER X)
But it makes reflection so easy. I've never known a "modern" language to have such simple reflection without a bunch of boilerplate (Java, C#, Python gets close, Scala)... People harp on PHP a ton, but it's really darn powerful if used correctly. The trick is finding people who know how to use it correctly.
Oof, I'm not a PHP coder and I didn't know it had this feature before reading
these comments but I definitely do not envy it in the languages I use. The
potential for abuse is immense, this is one step removed from generating code at
runtime by concatenating strings and calling eval() on them.
I'm sure there are situations where this feature can be really valuable (and I
do sometimes use getattr/setattr in python, which is somewhat similar) but I
think the developers should really think hard and make an educated decision
about when to use it. As such having it require a bit of boilerplate is a
feature more than a bug IMO. I definitely wouldn't want to have to maintain code
written by someone who abuses these types of indirections everywhere.
I can definitely imagine a novice coder using these "variable variables" in lieu
of a proper hash table or dictionary object for instance.
I mean it suffices to read some of the comments to the article posted above to
find a bunch of people posting code snippets which, IMO, are a very poor way of
implementing what they want. For instance:
class foo {
function bar() {
$bar1 = "var1";
$bar2 = "var2";
$this->{$bar1}= "this ";
$this->{$bar2} = "works";
}
}
$test = new foo;
$test->bar();
echo $test->var1 . $test->var2;
I'd probably quit if I had to maintain code written like that. Having
boilerplate would at least make it obvious that something unusual is going on
with these variables and make the intent clear while reading the code.
And to add to that. Once reflection becomes a "tool in your toolbox" so many problems can be solved easily with it in other languages. Then you bash your head against poor documentation and slow execution (looking at you Scala).
> (...) the Whitespace interpreter ignores any non-whitespace characters (...) A consequence of this property is that a Whitespace program can easily be contained within the whitespace characters of a program written in another language (...) making the text a polyglot.
This is actually pretty brilliant as a sort of steganography in code type thing.
So one could write an interpreter for Whitespace along with Whitespace code to run in the interpreter, so that the interpreter interprets itself. Hard to do better at maximizing the usage of negative space!
I once made a language that translated directly to Whitespace, but used images as source code. Pixels where red channel had the highest value were like Whitespace's spaces, green channel - tabs, and blue channel - new lines. If the highest value was shared across multiple channels, it was ignored.
Algol-60 (and its younger cousin Algol-68) did actually use boldface to distinguish special keywords such as "if", "begin", "true", etc, from the namespace of ordinary identifiers. But that was only used in publications, not in machine-readable source code, since few encodings could support boldface. Instead various stropping[0] methods were used in the implementations of Algol. Today there is really no technical reason why rich text can't be used, but my guess is that syntax highlighting serves a similar purpose without complicating file formats and parsers.
Useful - for what? Do you want that link to be written & maintained by you, or to be automatically generated by the tools? Because we already have the latter... (e.g. in many IDEs, ctrl-/cmd-click on symbols performs useful actions, eg. takes you to the definition or finds all references if you're at the definition site).
It does, but in dynamically typed languages it's obviously less capable.
To deal with this one could of course have a static type system instead, but that necessitates learning the DSL behind it and its idioms - the lack of which is the main appeal of dynamic typing to begin with.
I actually did code hinting for PHP in a fairly popular commercial product, more than 10 years ago - and I disagree with you that it has to be less capable. You can use heuristics - people are forgiving because they understand you can't get everything right. You can use configuration files & user hints to help the semantic analysis. You can absolutely get the hints mostly right - and it's automatic, so probably closer to being correct than anything that'd have to be maintained by hand.
It's very hard to survey with precision the exact state of a body of rich text. I don't even like using rich text editors for prose, for this reason. HTML/Markdown are the closest thing we have to "rich text that's explicit and precise", but at that point you're back to plain text with special machine-readable syntaxes. And who wants to write out explicit formatting directives solely so that formatting can then drive program behavior?
I think this hits close to home. I wish creators of new programming languages would reuse syntax of existing programming languages (ideally the ones in the mainstream). Or at least think about it.
Also think if you even need a new language. It seems that too many new languages have features that can be handled by functions or macros in existing languages.
Some languages like Forth, Lisp or Haskell are very powerful, have strong metaprogramming facilities, and most likely can already do anything that would need a new language and new syntax.
Think about it - if you avoid creating another syntax variation, and work with an existing syntax (or better existing language), your chances of somebody actually using your efforts will vastly increase.
After following Make A Lisp [1] and seeing how easy it is to parse and get all that power, other syntax just seems sadistic for both the language developer and the users.
Conversely, I’ve found it useful that Erlang has very different syntax than most languages, because it helps me think about the distinct semantics it offers.
Plus it’s very concise, which spoiled me to the point where I find it difficult to look at Elixir.
I heard a story that someone giving a talk at IAS only used M's on the chalkboard (lowercase, uppercase, doublestroke, script, etx) before he was told to cut it out. I can't remember who it was if anyone else heard the story.
I had a class in grad school where the textbook ran out of english, greek, and hebrew letters and subscripts and resorted to serif vs sans fonts. It was interesting.
I am delighted to see an xkcd comic make it to Hacker News's front page, but also a little disappointed it happened to be this one. It's a perfectly fine comic, but there are so many others that could have engendered even more interesting discussions, which I'd love to have been able to read.
I'm also really missing the xkcd forums. The quality of the discussion was below what I'd expect to read on HN†, but it was still nice to have something for each of the comics.
† No disrespect intended to anyone who was on those forums—you're all great people, but there's less of you, and, well, there's nothing quite like HN.
> This is also a jab at mathematicians who are in addition to using variable names which are short and nondescript (e.g. "x"), are also "typeface sensitive" (in addition to case sensitive). In other words, one can typically find a statement involving three different "X" variables, referring to three different objects, and they are distinguished by their font and case.
The pain, across math, engineering, and physics, is all of the formulae with overloaded notation, sometimes from the Greek, sometimes the Roman alphabet.
Formulas are great as a summary and reminder for the seasoned practitioner, but can be a huge barrier to entry for the student.
Perhaps GitHub repos with well-written code and test cases for the neophyte can, as they say these days, "flatten the curve".
I remember always being annoyed at spherical coordinates when I was taking both math and physics classes in university. They use the same symbols but two of them are swapped.
Well, to be fair, sometimes the X is a Greek upper case Chi. Mathematics ran out of Greek and Roman a while back and Hebrew has appeared - א (as in "Aleph Null")
I did a category theory class a few months back. Huge barrier at times - so many moving pieces. "Err, which properties do 𝒞 and mumble(𝒟) have here, in this paragraph???"
I wanted to create an interactive version of some topics. Just mouseover elaboration and graphics, to reduce the amount of state one has to keep track of mentally, and its associated cognitive load. But the state of in-browser rendering of category diagrams wasn't quite there yet.
Best part of the class was the "after-math" (that's a 3-interpretation pun). An iterative improvement on past versions of the class, formalizing an observed custom - after the 1 hr math lecture, the room was reserved for a second hour, so people could hang out, with the instructors, in front of blackboards. In part, clarifying and explaining things in different ways.
One instructor observed something very vaguely like "I'd never approach things the way I do in lecture, if I was tutoring someone one-on-one."
One can imagine technical fixes. Mouse-over equations. FAQs. Presenting the material from multiple perspectives.
Many of them could implemented on clay tablets. And that newfangled wood pulp. My best understanding is, that as a society, incentives are poorly aligned with creating non-wretched education content in the sciences, and I assume in math.
So my hope for XR in education, is not just the power of tools like eye tracking, but that incentives are disrupted enough to get us unstuck.
Consider eye tracking. When I show people this video[1](IBM's STM stopmotion) in person, it was very common for them to ask me "what are the ripples?". Apparently it was enough of a thing for IBM to do supplementary content on it. But if I'm not there, what UI would youtube need to have a similar dynamic?
Someone did an art project. You sit by yourself and watch a drama. An interesting drama. But why is it interesting? The video is a graph, like one of those old "choose your own adventure" games. And there's an eye tracker. So if your gaze shows you're interested in character A...
Why not ripples? Imagine the richly interwoven tapestry of science and engineering as that graph, adaptively explored, driven by interest, misconceptions, and learning objectives.
And imagine being able to watch someone's gaze patterns as they try to understand a paragraph of math. Backed by a database of everyone's patterns. And being able to respond. Not as well as an excellent human tutor in some ways, but in some ways even better.
Or we could just copy the usual wretched content into 3D and call it a day.
"Consider eye tracking... imagine being able to watch someone's gaze patterns as they try to understand"
Let's not? Ever? It reminds me of dystopias where a government tries to sense how really interested people are in the latest propaganda and punishes those who are too bored. Or just a small school ran as a totalitarian regime where you're not even allowed to be bored.
Back in high or middle school, I wrote a Tetris game. Being terrible at programming, I stuffed all of the row clearing logic into one function, which ended up having variables named, x, xx, xxx, xxxx... I think I stopped at four x's. You can imagine the inner loops. No, it never worked right.
I think the conversations here are more valuable than the comic itself, which is, uh, not really a joke. Some shitty drawings and half an idea, like many xkcd comics. But the comments here have pointed me to some cool stuff, so...
What makes XKCD so great? Is it that he sticks to noncontroversial subjects - everytime people pull up a "relevant xkcd" it's something most of the people agree on.
Even with controversial subject - the covid lockdown, he chose to highlight facts where everyone (well ~90%) agree on.
https://unicode-table.com/en/blocks/mathematical-alphanumeri...