Saved one whole syllable. Astounding efficiency.

The pillow is there to dampen the resonance of the drum. If you have a drum with no pillow and hit it there will be a long ringing "boom" tail to the sound. Then if you put the pillow inside and leaned it a bit against the other side of the drum (That head is called the resonator or resonant side, the side you hit is called the batter) before hitting it again you'd remove that long ringing tail and the drum would sound like more of a short "thwack".

I looked at a lot of numbers from various watchdog groups right after the huge push in the wake of George Floyd's murder and the interesting takeaway was that encounters with the police end in murder at pretty much the same rate regardless of the races of either the officers or victims. When controlling for population demographics it was more likely for a black or hispanic person to have that encounter than others, but once the cop was targeting you it was about even odds.

The real stark contrast was when you drew the lines by income. If you were sufficiently wealthy your odds of being hurt or killed in an encounter with a police officer regardless of anyone's race dropped to effectively 0 while if you were poor (or the police thought you were) you were in serious trouble.

Not saying this is a good way to look at the data but if you don't break anything down at all and just look at all police shootings equally the least likely kind of person to be on that list is a rich asian lady while the most likely victim is actually a dog...because police kill roughly 10x more pets than people every year.

It's about class, yes, but fuck me the scared little babies popping off rounds at dog parks because wagging tails threaten them need to learn some goddamned discipline and de-escalation tactics.

The Wireless Communications and Public Safety Act of 1999 requires any cell phone be able to call 911 on any network it can find the signal of, even if it has no service available on that network so that you can use deactivated phones or make 911 calls to local emergency services in areas that might not have official 911 service.

There is a difference between a lack of signal and a lack of service. Without signal your phone can't find a network so nothing could work. Without service your phone might be able to communicate with a network but might not be activated, or it might be another carrier's network where you don't have a roaming contract, etc. If the network is there, you can call 911 even if the phone is locked or doesn't have a contract. But if there's no network you're up a creek without a paddle.

Sweet deal, glad I could help and good luck breaking in.

Actually I just scoped out some of your comment history and see you're working in CNC engineering and pop into physics and CAD subreddits a lot...I have an idea for a hand-cranked guitar pickup winder I'd like to design for 3d printing but for some reason I'm having a hell of a time getting my head around how to design the gearbox to multiply RPMs in a reasonable size. A guitar pickup involves upwards of 10,000 winds of a copper filament around the magnetic pole pieces. Motorized pickup winders tend to have speed controls from 600 to 2000 RPMs but for a hand-cranked machine 500RPM seems downright reasonable. We're talking <2oz balanced load. Is that something that might be in your wheelhouse that you could point me at some good resources or fundamentals about? Because I'd love to learn it.

Heh. I graduated in 2009 and we still had some assembly in my degree program. It wasn't even being taught in a specific CPU's assembly language at that point, they had invented some assembly-like language to teach us about registers, bitmath, and jumps but it was actually interpreted by a Java CLI tool that produced the output.

I think it was just there to teach us how good we have it working at higher levels of abstraction.

Yeah exactly, to both points. Learning how to do similar things under different paradigms is a great skill because it keeps you from getting too stuck on one way to approach a problem but learning all the available paradigms is mostly an academic exercise. You can learn the paradigms to identify their influences on languages but unless you're going into language design or academia they can be pretty esoteric. Not very many languages are purely single-paradigm. Most languages take influence from multiple paradigms and include features from those that designers like, creating fairly unique ways of expressing program instructions.

Example off the top of my head would be something like Scala. Scala adds features of the Functional paradigm to the Java language which is very Object-Oriented in its design. So if you're writing Scala you can write it like OO code, Functional code, or a mix of both. Scala idioms prefer Functional approaches so if you use those you tend to write less code and stuff runs better but you can also work with objects and gain some benefits of OO concepts like function encapsulation.

Python is another language that takes hints from Functional programming and OO programming, but implements its objects and classes very differently from how Java does it.

And we're all the better for it being that way.

Oh yeah. Totally.

Controlling flow from inside loops is done with break and continue.

Something like this:

for (i=1;i<=10;i++) {
  if (i==5) SOMETHING
  print i;
}

If you use break for SOMETHING your output is: 1 2 3 4

If you use continue your output is: 1 2 3 4 6 7 8 9 10

Some languages let you control multiple levels of looping using something like break 2 to break not only this loop, but the loop it's inside. Javascript lets you do this with labels. Not all languages give you this level of control so you either figure out how to design the process without nested loops or come up with other ways around the issue like GOTO's or flag variables that direct outer loops to break when set from inner loops but those situations have no single right answer.

Some languages also kindof have you using GOTOs and labels for exception handling...I wanna say Visual Basic? I did a project a few years ago using CrownPeak CMS which at the time I think used VB for its templating language and I vaguely recall winding up with a lot of really snotty "ON ERROR GOTO HELL" clauses. I think some legacy data applications that had a lot of functionality written in SQL procedures used that sort of error handling instead of more modern try-catch-finally or try-with-resources blocks. It's all true but I don't think I'm inaccurate in saying they're pretty niche edge cases for most programmers.

That's all true, you're absolutely right. I was just trying to keep my anecdote from getting too lengthy by leaving out details...in this case the code in question was written in Java in 2009 and running on IBM WebSphere on contemporary datacenter hardware so there were really better ways to have laid it out. Maybe the robots are stack limited which makes sense, but refactoring it is still a good thought experiment if nothing else.

Man I am not gonna throw down with an assembly programmer. They scare me a little, flying so close to the sun.

I was speaking mostly to a mindset difference in how you approach the new language.

You'll be better at Python in the long run if you start from the description of what a program is supposed to do and treating the original code itself as a black box rather than trying to translate Matlab syntax to Python syntax because knowing the language is more than just knowing the syntax, you need all those idiomatic expressions. Python has some interesting collection structures and ways of manipulating those that I don't know if Matlab has direct equivalents for, so learning how to use them is just as much of learning Python as learning the syntax.

Honestly being curious about how programming works at all is a trait I wish more developers had so that puts you above half the people I've interviewed for jobs.

GOTO would work fine in a single threaded environment, you can't use it in javascript just because javascript doesn't have a GOTO statement. If it did it would probably look the same as it does anywhere that does have it where you pair GOTO some_label with a line of code reading :some_label to give the GOTO a target line. Not sure why they didn't include it.

Yikes, I'd actually seen code kindof like that written by outsourced contractors for a financial services firm I used to work for. They created these "god" functions that ran through multi-step processes by wrapping the whole thing in a giant for loop and using If's on the iterator like if (i==1)... (i==2)... (i==3) to block each step. It really hampers extensibility.

> Question for you: if I want to improve my coding skills (because I only took one class in school, and have just picked other stuff up as I go), would it be a good exercise to re-write all their code using the structure you've outlined?

Assuming you're talking about re-writing the IF-GOTO code your robots use in more structured style, yeah absolutely. Changing the underlying implementation of some functionality while maintaining its public contract is actually the definition of "refactoring". Being able to cleanly refactor code and write code that's cleanly refactorable are actually the underlying goals of a lot of current best-practices in Object-Oriented programming so it's definitely an important skill to practice.

> And/or if I'm trying to learn another language like python specifically, see if I can re-write it in that, so I can learn that syntax & commands at the same time?

Porting code directly like that is an interesting activity but maybe something that's more of an intermediate activity once you have the fundamentals down. I thought this phrasing was kind of pompous when I first heard it but most languages have "idiomatic" ways of doing some things that is considered the correct way to write code in that language. Of course the languages are flexible enough that they would allow you port structure and style of another language's idioms to this new language, but those sorts of idiomatic patterns usually come out of some key feature of the language and have fundamental advantages in terms of code expressiveness or performance. So it's best to learn "Pythonic" ways of writing code that might be very different from how someone who'd trained as a Java or C++ developer would usually think of implementing them. Then once you feel like you can write Python, you can try re-implementing functionality that used to be written in some other language and paradigm in Python rather than trying to re-write some Java using Python. It's a slight language shift but I think it's a good way to frame it.

In a professional setting you're also unlikely to see a company trying to do a 1:1 re-write of an existing product. The switch in tech stack is usually driven by a desire to benefit from some killer feature of the new stack like NodeJS's fast async I/O or something else, and to do that you usually need to write idiomatically and respect the eccentricities of the language and the framework.

Yeah I kindof had a moment when I realized that paper was so old it predates not only C, but also C's predecessor B...and we still talk about it. I'd worked in languages without loops before and actually had to use goto's and labels to reproduce the flow control of while and for loops when I was first learning so I just assumed the concepts had always existed in programming. It's a really interesting history how we got from doing math real fast to programming a world-wide near-real-time communications network so we can look at cat videos on the toilet. ...If you're into that sort of thing, I guess.

The idea that "Goto statement considered harmful" came from an essay by Dijkstra that was published in 1968 during the dawn of computer science.

His basic case was that GOTO was too primitive to have a single easily understood function when seen in code. It tells the machine to arbitrarily move control to a different instruction at a different line of the program but says nothing about why or what's going to be there. Also since you need to physically start reading somewhere else in the code with the context of what's in memory from the previous location in mind it can make programs extremely hard to read and verify, especially in an age before IDEs and debuggers. It allowed for too wide of a gap between the mental model of a static program and a dynamic running process.

He advocated instead for what he called "structured programming" which is really just programming as anyone born after maybe 1964 understands it. Structured programming makes extensive use of this new-fangled idea from the late 50's called "blocks", because someone had to invent the idea of:

if (true thing) {
    doThings();
}
else {
    doOtherThings();
}

at some point.

With blocks that's just the way you write that code with the instructions immediately blocked inside the condition that allows their execution to proceed. With GOTO those lines could be 600 lines away. And without another GOTO to send you back to where you left off, you'll just keep going from wherever you ended up until the program exits or crashes.

GOTO also predates a lot of the looping structures we take for granted in modern programming and while it could be used to implement them, using the actual loops instead carries more meaning and makes your program easier to read, understand, and compile (compilers that translate human-readable source to machine-readable machine code can make certain optimizations in how it feeds instructions into the CPU...as long as it understands what the loop does). So at this point while a lot of the readability issues would be countered by modern tooling, the adoption of more structured ways of writing code and more nuanced looping statements makes goto...kinda pointless.