Ding!

The last time I used a typewriter was when I was a freshman in college.  I found an old typewriter in the library and used it to write letters to my cousin.  A fair amount of letters on the thing didn't work and I never remembered to send those letters - both fitting symbols for the place of the typewriter in modern society.  But, like that typewriter that probably still hangs out in a dingy corner of the library, the mechanico-social conventions surrounding typewriters also limp on: enter the bell alert.

Try copy and pasting either of these bits of code into a new program file and running it in your console:

ring-a-ding.rb

puts `clear`
puts "Press enter to ring the bell!"

x = ""

while x != "bye"
x = gets.chomp
puts "\a"
end

bellz.js

let i = 0
while (i<5){
console.log('\u0007')
i++
}

Music! (...well, sound at least)

The Ruby escape character "\a" and the Unicode character \u0007 are both "bell alert characters" which do nothing more or less than what the programs above make them do - they make a little ding.  The bell alert hails back when typewriters needed to alert their typists (who were probably too busy drinking martinis during their lunches to pay attention to their work) that they had typed to the end of a line and needed to press return and start a new one.

When people transitioned from typing on typewriters to typing on computers, in order to provide continuity for users many typewriter conventions followed - like the QWERTY layout, the caps lock key, and...the bell alert, even though there wasn't really any technical reason why these things had to persist.  And in the interest of backward compatibility, many programming languages still include the bell alert as an escape character.  And even languages like javascript which do not have a bell alert have the ability to generate one by printing the unicode bell alert character to the terminal.

So...is this just a historical oddity?  What is the point of a program that does nothing but makes an annoying noise every time you hit enter?  It doesn't seem like there is one at first until you really listen to that noise a lot and then...it starts to hit you how many times you've heard that sound before, despite probably never really paying attention to it and especially never knowing what it was.

The bell alert is used in all sorts of programs to give the user a non-visual clue that something has happened when the screen shouldn't be updating, generally when the user is trying to do something that can't be done.  It's a frustrating noise, but it's far less frustrating than if the user keeps trying to do an action and it just...isn't....doing.  We often forget in an era of silenced phones and quiet office spaces that there are ways that our computers can communicate with us beyond pixels on a screen.  Try throwing a bell alert in your own code sometime and watch your users' experience improve marginally without them even knowing it.


"And therefore never send to know for whom the bell tolls; It tolls for thee." - John Donne

Comments

Post a Comment

Popular posts from this blog

The Sorting Hat

Image
Here's a lesson about the difference between theory and practical applications. Everyone knows about  bubble Sort  and  merge Sort  - they're probably the first two sorting algorithms you learned.  Everyone also knows that (1) bubble sort sucks and (2) this is due to the fact that its average time complexity is O(n^2), aka the worst time complexity.  It even generally performs worse than things like insertion sort and  selection sort , the "a D- is still a passing grade" of sorting algorithms. While all these things are true, there's a more important truth: always test your code. While reading  The Imposter's Handbook by Rob Conery  the other day and flipping through the comparison sort algorithms he provides, I decided, Why not actually test out this code?   And, the  speed test demon  that I am, my test involved sorting out his [23,4,42,15,16,8] array one million times with bubble sort and with merge sort, and I got this res...
Read more

Kadane's Algorithm

Imagine it is 1977.  You do not have a degree in computer science.  You have not spent months grinding leetcode.  You are given a algorithm problem that a decorated mathematician has already created what looks like an optimal solution. And then in less than a minute you come up with a better answer. You are  Jay Kadane , and the problem that you have solved is the maximum subarray problem. The maximum subarray problem gives you an array of numbers and asks you to pick out the subarray with the largest sum.  The problem is trivial if all the numbers are positive: [ 1 , 5 , 1 , 3 , 2 ] <- the largest subarray is obviously the entire array But what if you've got some negative numbers thrown in there? [ 1 , 5 , -1, 3 , - 2 ] <- sure, you don't want the negatives. But isn't taking the -1 worth the +3? A brute-force solution materializes pretty easily: just create every subarray and find the biggest sum: [ 1 ] = 1 [ 1 , 5 ] = 6 [ 1 , 5 , - 1 ] = 5 ...
Read more

Loose Equality, the Null Operator, and Other Oddities

 Here's a fun bit of code to run: console . log ( '0.5' == 0.5 ) //evaluates to true console . log ( '0.5' === 0.5 ) //evaluates to false The first equality statement is what's known in JavaScript as "abstract equality comparison", which people usually refer to as "loose equality."  Loose equality compares objects only after doing a type conversion - so even though '0.5' is a string and 0.5 is a number, JavaScript sort of jams them together and says "sure, good enough."  It's weird, but convenient sometimes when dealing with data that's really (in an abstract sense) numbers but could come through the pipes as either a number or a string. People have written surprisingly long algorithms to precisely define what  abstract equality  and  strict equality (aka, normal equality)  mean in JavaScript and other languages that adhere to the ECMAScript standards.  But for our regular usage, things that are to people the same ...
Read more