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.
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.
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.
;[]... 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.
;;;;;;;;;;;; // protective wall of semicolons
;;var a = 10, b = 20;;
;;
;;function add(a,b)
;;{;;
;;return a + b;;;;;;;; // this function MUST work
;;};;
;;;;;;;;;;;; // protective wall of semicolons
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".
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. ;)
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 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.
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 had something like that with my previous desktop (~ years ago, so not ancient) because the onboard audio was really crap or badly shielded, and amplifying the line-out and listening to that with headphones, every single application had it's own signature pattern of high-frequency chirping when starting up or doing certain operations, websites sounded different from each other when scrolling them. It was kind of neat.
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.
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, ...
60 comments
[ 4.4 ms ] story [ 186 ms ] threadhttps://wiki.c2.com/?FixBrokenWindows
https://www.rtuin.nl/2012/08/software-development-and-the-br...
https://blog.codinghorror.com/the-broken-window-theory/
https://medium.com/@matryer/broken-windows-theory-why-code-q...
if(foo) doX() doY();
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.
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(){};
https://news.ycombinator.com/item?id=3842713
https://github.com/twbs/bootstrap/issues/3057
And don't forget to semicolon-harden your most important mission-critical code:
https://www.bluejava.com/4PN/Semicolons-in-JavaScript---The-...
(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.)
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. ;)
This whole thread is insufferable bikeshedding.
but also, violentmonkey
(I used to discern between program stages on 286/386 because sound of power supply was different for different loops)
[1]: https://en.wikipedia.org/wiki/Electric_vehicle_warning_sound...
[2]: https://electrek.co/2018/03/07/jaguar-i-pace-artificial-moto...
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.
I had AV software running but the virus was new and undetected.
https://en.wikipedia.org/wiki/Granular_synthesis
http://www.csounds.com/manual/html/SiggenGranular.html
I made a "musical gas" cellular automata the worked that way, which could have LOTS of audio events happening each frame. Kind of like aerosol MIDI.
It was based on a "Billiard Ball Automata" random brownian motion gas simulation, using the Margolus neighborhood.
https://en.wikipedia.org/wiki/Billiard-ball_computer
https://en.wikipedia.org/wiki/Block_cellular_automaton#Neigh...
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.
https://www.youtube.com/watch?v=6ZTuYLj5dbk
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.
https://en.wikipedia.org/wiki/Diffusion-limited_aggregation
>Live Wire (Dangling String), 1995
>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.
https://web.archive.org/web/19970619144534/http://www.ubiq.c...
>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, ...