There are these type of posts on HN that I prefer to tag #HNGold.
Plink-plonk.js – hear webpages render with DOM observer and audio API
51–60 of 61 posts
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#52I cannot help but refer to this old, old joke: https://en.wikipedia.org/wiki/Blinkenlights#Etymology (I used to discern between program stages on 286/386 because sound of power supply was different for different loops)
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.
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#53Earlier quoted context omitted.
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.
It's not so much how often it happens, but how freaking hard it is to find the problem by inspection when it does happen.
Linters correctly highlight all the ASI-related that realistically happen. (Or eslint does anyway, can't speak for others.)
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#54Earlier quoted context omitted.
A typical response is return false Where the program returns undefined. I can only think of these examples as straw men. Not once did I run in to an ASI bug.
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.
Quite right. As do other examples.
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#55Earlier quoted context omitted.
Intuitively this becomes: 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 lan…
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.
My point was that its hard to tell where the semicolon will be inserted. As well as the intention of the programmer. Here is another example:
if(x)
return
"foo"
return callback
(1,2,3,4)Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#56You can do something similar with an AM radio on a minimalist Linux install with nothing in the background.
Install NetBSD on the radio for extra effect.
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#57Earlier quoted context omitted.
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.
My point was that its hard to tell where the semicolon will be inserted. As well as the intention of the programmer. Here is another example: if(x) return "foo" return callback (1,2,3,4)
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"
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#58Earlier quoted context omitted.
My point was that its hard to tell where the semicolon will be inserted. As well as the intention of the programmer. Here is another example: if(x) return "foo" return callback (1,2,3,4)
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.
if(y) return
"bar"
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#59I 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…
Granular synthesis is great for this kind of stuff. Max/MSP, PD, and CSound have support for that. 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 ga…
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.
Re: Plink-plonk.js – hear webpages render with DOM observer and audio API
#60Earlier quoted context omitted.
It's not so much how often it happens, but how freaking hard it is to find the problem by inspection when it does happen.
Linters correctly highlight all the ASI-related that realistically happen. (Or eslint does anyway, can't speak for others.)
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.
https://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...