I once did something similar. There is this strace-like program for Windows that captures things like memory allocations or mouse movement as part of the Win32 API. I modified the source so it emitted an OSC message on every trace and sent it to PureData which would output MIDI. The result was, well, pure cacophony. But it was amusing to, for example, belt out a dissonant piano piece by typing in VIM or use calc.exe as a (really shitty) drumpad.
It had stationary "microphone" particles whose x-position controlled the left/right stereo pan of the sound, and whose y-position controlled the speed (pitch) of the sound, and you could draw "bumpers" or "barriers" out of microphones to deflect and bottle up the gas particles in high or low pressure chambers.
Both the microphones and gas particles had 4 bits of "payload" that would combine to select one of 16 voices (particle payload) and one of 16 samples of that voice (microphone payload). By the pitch and stereo pan, you could tell where the particles were hitting the microphones, and by the voice and sample, you could tell the value of the microphone and gas particle payloads.
So of course I made "laughing gas" with a set of laugh samples, a "stinky gas" with a set of fart samples (to give the laughing gas something to laugh at), and a "scatting gas" (with samples like Cab Calloway singing), plus several other voices too (like Yes and No gasses for representing boolean values), so you could release just a few or any number or ratio of laughing/farting/scatting gas particles (finely tuning the fart:laugh:scat ratios to your mood). Just a few particles, and you'd only hear the occasional sound, but you could spray in a whole lot of any kind of particle to make a high pressure gas that sounded like a huge crowd of people laughing, farting, or scatting at once.
Another thing that would work well with musical gas is diffusion limited aggregation, where instead of gas particle making a sound and bouncing when they hit a microphone, they make a sound and freeze into "ice" (another microphone). That way you have to keep adding more gas and growing the crystal bigger to make more sound (but you can use an "ice eraser" (hair dryer) drawing tool to melt frozen crystal back into sublimated gas.
Modular synths like Max and Reaktor are great. You can open up the source of random components and combine them in weird ways to make new instruments. I do wish PD was more useable like Reaktor is. NI had a massive assortment of user-created instruments dating back to 2001 to spend hours poring through.
Just as electric vehicles can have skeuomorphic “engine” sounds for safety [1] or aesthetics [2], I’d love to see a service that emits “fan” noise to track CPU usage.
I have my motherboard set to run the CPU radiator fans a low-moderate speed at ~50 degrees C and below, but ramp up rapidly approaching 55+, with no hysteresis or gradual ease-in. I can absolutely gauge CPU usage on a second-by-second basis by fan noise. Any transient spikes cause an easily perceptible (but not overwhelming) wooshing.
I used to have something like that with an old machine with poor, spluttering cooling. You could really tell every time something processor intensive was running.
It was actually quite useful at times. For example, if some webpage was constantly running some heavy javascript, the fans would soon alert me that something was up.
A blind programmer named Karl Dahlke does something similar: he pipes linux console output directly to a speaker to get a quick overview. (then he uses text-to-speech to delve into the details.) I think this hack is less discordant than Dahlke's hack.
>In 1995, as an artist-in-residence at Xerox PARC in Palo Alto, California under the guidance of Mark Weiser, she created an art installation made up of LED cables that lit up relative to the amount of internet traffic. The work is now seen as one of the first examples of ambient or "calm" technology.
>Designing Calm Technology:
Mark Weiser and John Seely Brown,
Xerox PARC,
December 21, 1995.
>Introduction: Bits flowing through the wires of a computer network are ordinarily invisible. But a radically new tool shows those bits through motion, sound, and even touch. It communicates both light and heavy network traffic. Its output is so beautifully integrated with human information processing that one does not even need to be looking at it or near it to take advantage of its peripheral clues. It takes no space on your existing computer screen, and in fact does not use or contain a computer at all. It uses no software, only a few dollars in hardware, and can be shared by many people at the same time. It is called the "Dangling String".
>Created by artist Natalie Jeremijenko, the "Dangling String" is an 8 foot piece of plastic spaghetti that hangs from a small electric motor mounted in the ceiling. The motor is electrically connected to a nearby Ethernet cable, so that each bit of information that goes past causes a tiny twitch of the motor. A very busy network causes a madly whirling string with a characteristic noise; a quiet network causes only a small twitch every few seconds. Placed in an unused corner of a hallway, the long string is visible and audible from many offices without being obtrusive. It is fun and useful. The Dangling String meets a key challenge in technology design for the next decade: how to create calm technology.
>We have struggled for some time to understand the design of calm technology, and our thoughts are still incomplete and perhaps even a bit confused. Nonetheless, we believe that calm technology may be the most important design problem of the twenty-first century, and it is time to begin the dialogue.
[...] (read the whole paper, it's great!)
>Dangling String: Let's return to the dangling string. At first it creates a new center of attention just by being unique. But this center soon becomes peripheral as the gentle waving of the string moves easily to the background. That the string can be both seen and heard helps by increasing the clues for peripheral attunement.
>The dangling string increases our peripheral reach to the formerly inaccessible network traffic. While screen displays of traffic are common, their symbols require interpretation and attention, and do not peripheralize well. The string, in part because it is actually in the physical world, has a better impedance match with our brain's peripheral nerve centers.
>In Conclusion: It seems contradictory to say, in the face of frequent complaints about information overload, that more information could be encalming. It seems almost nonsensical to say that the way to become attuned to more information is to attend to it less. It is these apparently bizarre features that may account for why so few designs properly take into account center and periphery to achieve an increased sense of locatedness. But such designs are crucial. Once we are located in a world, the door is opened to social interactions among shared things in that world. As we learn to design calm technology, we will enrich not only our space of artifacts, but also our opportunities for being with other people. Thus may design of calm technology come to play a central role in a more humanly empowered twenty-first century.
>Mark Weiser in 1988 articulated the idea of ubiquitous computing for the first time at the Computer Science Lab at Xerox Palo Alto Research Center (PARC). He coined the phrase “ubiquitous computing” and wrote several papers on it. The initial forms of ubiquitous computing include tabs, pads, and boards. The first ever known ubiquitous system was the artist Natalie Jeremijenko’s Live Wire or Dangling String situated at Xerox PARC, under the technical leadership of Mark Weiser.
>Mark Weiser suggested the idea of enormous number of ubiquitous computers embedding into everything in our everyday life so that we use them anytime, anywhere without the knowledge of them. Today, ubiquitous computing is still at an early phase as it requires revolutionary software and hardware technologies.
Semicolons in JS is how you differentiate between someone who understands that code ambiguity leads to pain, vs someone who shouldn't be allowed near multi-line statements.
Honest question: how often does the code ambiguity due to lack of semicolons lead to non-obvious bugs?
I'm nowhere close to being a JS expert, but I've done some JavaScript-heavy pet projects and I've got an ambiguous statement interpreted wrong exactly once, and the cause was pretty obvious within a minute of looking at the error.
Good linters correctly highlight all missing semicolons as a symptom of sloppy, negligent, careless programming (or pointless syntactic showboating). It's also technically syntactically valid to omit braces around single statements after if, else, for, and while statements, but idiotic and dangerous to do that, too.
Please give a concrete example of this pain that you have actually experienced. I understand that ASI (automatic semi-colon insertion) is in theory ambiguous because you are relying on the compiler, or in some cases many different compilers, to execute the statement correctly. In practice, for over a decade, I have never run into such an issue. I suspect it's due to engineers trying to get too cute with their implementations.
;;;;;;;;;;;; // protective wall of semicolons
;;var a = 10, b = 20;;
;;
;;function add(a,b)
;;{;;
;;return a + b;;;;;;;; // this function MUST work
;;};;
;;;;;;;;;;;; // protective wall of semicolons
;[]... is one of two rules you memorize when you omit semis. It's not even that common of a case, though your own example doesn't even make sense.
I don't really understand the drama, just like people who use semis in place you don't need them. In real code, you should be using a linter anyways. At which point semis or no semis becomes purely an aesthetic concern. Like whether you use single or double quotes.
I haven't used semicolons in over 8 years and never had an issue. And with tools like eslint and prettier, you have no excuse to be making such trivial mistakes, like adding superfluous semicolons like function(){};
I have other more important rules I need to memorize with those brain cells, that I don't need to voluntarily choose to give myself more problems that require me to memorize ridiculous rules and obscure special edge cases to look out for all the time, that inexplicably screw me if I happen to slip up and forget to apply them. I stopped playing "step on a crack, break your mother's back" years ago, when I was old enough to actually have somewhere I needed to be.
Note though, that this ambiguity doesn't really affect the whole "whether to use semicolons" debate either way. If anything, it's more likely to occur in code that does use semicolons than in code that doesn't.
Intuitively, as a someone who uses C style languages, this becomes:
if(foo) doX(); doY();
Can someone confirm which intuition is correct?
I ask because, to me: it not being intuitive is a problem--even if it is not classified as ambiguous.
It being only contextually intuitive, also seems somewhat problematic--but maybe excusable if it is assumed you know some similar language going into it and it behaves similarly to that other language.
No idea what GP was trying to say, but the C style intuition is correct. The bug in that code is due to omitted brackets, it has nothing to do with semicolons/ASI.
I think I see what you're saying, but the context here was asking for cases where omitting semicolons causes non-obvious bugs. I mean:
if(x)
return
"foo"
clearly there's a bug there, but adding in semicolons wouldn't change the code's behavior. So it doesn't affect the "is it bad to omit semicolons?" debate either way.
Bookmarklets are situationally pretty useful; they’re the easy entry to custom cross-site userscripting, a test drive before going full extension. They’re as legit a use of JS as anything else is.
(That said: if you use someone else’s code, putting up with their style is part of the bargain, even if I think leaving out semicolons is pointless aesthetic bikeshedding.)
> even if I think leaving out semicolons is pointless aesthetic bikeshedding
Bikeshedding isn't when you paint the bikeshed your favorite color, it's the bickering over the shade it should be painted which is actually what you did, especially since the damage has already been done. ;)
A bash one-liner solves this problem for you. If you think it's "cool" to execute JS as a bookmarklet you are free to distribute your own version of the library. The original commenter was the one "putting people down" by demanding the author do it "the right way".
