Two JavaScript Challenges

Challenge 0: Find a value of type number to assign to n such that

[n,n,n,n,n,n,n,n,n,n,n,n].map(parseInt);

evaluates to an array of size 12 containing 4 distinct elements: one appearing 5 times, one appearing 4 times, one appearing twice, and one appearing once.

Challenge 1: Find a value of type number to assign to n such that

[n,n,n,n,n,n,n,n,n,n,n,n,\
n,n,n,n,n,n,n,n,n,n,n,n,\
n,n,n,n,n,n,n,n,n,n,n,n,\
n,n,n,n,n,n,n,n,n,n,n,n,\
n,n,n,n,n,n,n,n,n,n,n,n].map(parseInt);

evaluates to an array of size 60 containing 14 distinct elements.

Advertisements

A Contributional Solution to Uniqueness-Dependent Namespace Collisions

Once someone else has picked a username in a site, chances are you can’t have that username now. This is also true of several other namespaces, inside and outside of the computer world.

There are extensive problematic things about this. Perhaps you’ve been to a site that allows one-character usernames, and then modified the URL from a profile page to see who the lucky ones were that got the one-character usernames, and discovered many accounts where barely any activity has occurred beyond the creation of the account. What a waste! This could even be done maliciously, to claim an account that’s a natural moniker for someone before that person can get to it. There’s in fact this entire TLD that’s pretty much a namespace extortion market.

But this problem could be solved. A provider of a namespace could select a set of usernames that could be desirable, and assign pre-specified levels of contribution (maybe measured by posts, publications, victories, or some combination of what’s available in a site) necessary to actually be able to acquire that username permanently. Other usernames that one would expect would not be competed over can be guaranteed permanent upon acquisition, just not these particular ones, one-character and two-character usernames, and often-desired usernames like “dragon”, “monkey”, and “shadow”. (Bonus thought inquiry: is the state of password standards of the populace still so despondent that if you implemented this standard on the password field people would still fight for the convenience?) Thus, if you turn out to be a major contributor to the site (measured in some means), and someone just parked such a username and did nothing with it, you become entitled to have that username instead.

Thus, we have a system for which:

  1. One can’t successfully just prevent others from getting nice or appropriate usernames by parking an account.
  2. If one wants a permanent username but is worried about their level of contribution, there’s still a large set of usernames that one could choose from.
  3. One who picks a username that is tentative knows there’s a threshold after which they are safe and can be assured they have that username permanently, and doesn’t need to worry about future username-seizing by other users.

I’m curious why this seems to not have been implemented anywhere prominent yet, actually: I’m sure I can’t be the first to think of this. There is an alternative solution to this problem that I have seen, utilized by Discord, for example, where all usernames have a site-assigned number suffixed to them, so that multiple people can in fact choose the same username, and have them still be distinguishable. I like this solution as well, my only complaint (and a small one) being that one then doesn’t have full control over what becomes their particular unique identifier.

Failures in Referential Nomenclature

Suppose you heard the term “inaccessible island rail”. What do you think this term refers to? When I heard it, my mind conjured an image of a train line that connected really inaccessible islands.

And that sounds weird. Did someone undertake a project just to create such a rail line? It sounds incredibly costly. And it also sounds like it’d be something cool enough that I would’ve heard about it by now. Nevertheless, what else could this term refer to?

It turns out that a rail is a type of bird. Go figure. So it’s a type of bird that only lives in really remote islands. That makes much more sense than the train situation. Okay.

Except that that isn’t even specifically what this species of bird is. It is a species of rail that only lives on one island, literally named Inaccessible Island. It’s slightly southwest of Tristan da Cunha.

So actually, I slightly lied in the text in the first paragraph, by lowercasing “inaccessible” and “island”. But here’s the thing: you don’t hear capitalization in verbal speech. The uppercase letter hints would not be available to you if someone was orally communicating the term for this bird species to you (and even if you were reading this in text, maybe you would’ve thought the capitalization was probably for other emphasis than to hint that it referred to an island literally named that way). Also note that whereas realizing ‘rail’ probably did not refer to the context of trains could have happened via considering the context of the sentence in which it is used, context would very likely not have helped hint at the ‘Inaccessible Island’ issue.

I claim that ‘Inaccessible Island’ is a poor choice of name for this island. Names should be useful, distinguishing handles, and this name is not that. It was an attempt to reference the island’s inaccessibility, but it decided to do so via a term that would naturally be used anyway to describe islands, thus vastly increasing possibilities of confounding in all terms that refer to it. Calling the sort of bird a ‘rail’ is also unhelpful, but this part is not as problematic, for the reasons stated above.

This sort of naming failure in attempting to make a reference or hint at a metaphor is pervasive in computer science. When looking back at my learning process for many ideas in computer science, I find that this was a massive reason I often got stuck or was confused. People that name tools or ideas relating to computers often try to give them names that refer to parallel entities or processes outside the world of computers, and in doing so make usage of terms often extremely ambiguous.

Continue reading “Failures in Referential Nomenclature”

Gradescope is a Pleasant Surprise of Well-Thought-Out Design in Academic Software

Having been a TA for 3 semesters (and a college student for 11) has taught me that most academic software is insanely bad. Like, really, really bad. Gradescope is, among this vast wasteland of despair, not only an oasis, but a really pleasant one.

Given the baseline, I of course fear that I may just be judging Gradescope on too excessively low a bar. Am I giving it credit just for being able to have expected middle-click functionality?

I don’t think so. I believe that for a reasonable bar for software quality, Gradescope not only meets expectations, but exceeds them. Gradescope is actively nice to use, particularly from a staff perspective, and from what I’m used to with academic software, this is completely incredible, and deserves a treasure trove of praise.

In short: most software comes with negative surprises, realizations that it is harder to use than it looked like it was. Gradescope often comes with positive surprises, realizations that it is easier to use than expected.

Someone on the Gradescope team really understands quality user interface design. Elements of Gradescope typically do precisely what one expects them to do; they are given helpful names that well describe their functionality. Where one would want to directly click and edit text, one can in fact use such direct input. (To edit rubric items, one simply clicks on them and they become text boxes. It is not indirected via an edit button or the such. And oh hey! These text boxes support LaTeX!)

Common functionality comes with an assortment of hotkeys, exactly what a grader would be seeking once they have done the same actions many times in a row, and hotkeys that take the same functionality as buttons pop up upon mouse hover over the corresponding buttons. For hotkeys for rubric items, they are simply presented next to the items themselves, without hover even necessary, since as these are numbers, one would naturally want to be able to see the associated numbers at-a-glance rather than memorizing them.

A common regret of graders when grading papers by hand is realization upon certain submissions that a certain penalty or credit on the rubric is probably too harsh or too lenient, and then realizing that one would have to go through the entire stack of papers again to find the students whose grades one should adjust to meet a new standard. Does one have to do the same, but electronically, when using Gradescope? Of course not. Gradescope allows you to filter by a rubric item to see all submissions which have already been assigned that rubric item, and immediately have all the papers that should be reconsidered. If one is only changing the point value of that particular rubric item, one doesn’t even need to go through the papers; one just edits the score associated with it.

Both students and staff benefit from an easy-to-use regrade request feature, which allows for a nice communication channel with which to deal with regrades. As staff, you could have all the submissions in front of you and compare one student’s submission with others and more quickly decide what a fair thing to do is.

Gradescope is software that actually makes grading massively more efficient; there is none of what the rest of academic software does in making you wish you were still doing things the old way.

And every so often, Gradescope rolls new updates. These updates are well tested, are actually features (more useful than shiny), and play along nicely with what has been around before. Recently Gradescope rolled out a prototype of a handwriting recognizer. I’m already really happy with how many names it successfully recognized that we don’t have to manually match anymore.

Gradescope is proper technological innovation.

Respect to Sandwich

For a couple of years, I’ve had the idea of starting a comic strip called Vi, Max, and Nona, of which one of the characters, Nona, is a cartoonist who writes comics involving talking programming languages. It became gradually clear that there’s no way I have time in my life for making this idea fully become reality, but here’s a flushing out of one of the ideas for Nona’s comic.

nona0

Phonetic Alphabets

A as in aisle
B as in bdellium
C as in cnidocyte
D as in djinn
E as in ewe
F as in faze
G as in gnarl
H as in heir
I as in iamb
J as in jicama
K as in know
L as in lech
M as in mnemonic
N as in night
O as in ouija
P as in pneumatic
Q as in quiche
R as in rite
S as in scent
T as in tsunami
U as in upend
V as in vier
W as in whole
X as in xi
Y as in yin
Z as in zhug

A as in Android
B as in big-endian
C as in Coke
D as in dogs
E as in emacs
F as in Firefox
G as in gif
H as in Haskell
I as in Iron Man
J as in Jacob
K as in Kirk
L as in left side of the road
M as in Mac
N as in 9gag
O as in Oxford comma
P as in physics
Q as in QWERTY
R as in red
S as in semicolon
T as in Taiwan
U as in under the toilet paper holder
V as in Valor
W as in Wolverines
X as in Xbox
Y as in Yankees
Z as in 0∈ℕ

A as in ayyy
B as in bee
C as in cede
D as in deed
E as in eeee
F as in fee
G as in gee
H as in he
I as in I
J as in jay
K as in kay
L as in lee
M as in me
N as in need
O as in oh
P as in pee
Q as in queue
R as in reed
S as in see
T as in tee
U as in unit
V as in veal
W as in why
X as in x-ray
Y as in you
Z as in zed