I have a similar tendency. I doesn't really work for me to write code and listen to lyrics so EDM and grindcore, like carcass, works for me. Either there are few words or you can understand them.
I think this fits well with Phish's isolated monoculture. I also started listening to Phish in the early 90s and have only seen 30 shows or so. Every time I go to a run it is very comfortable. There have been times I havn't seen them for a a good chunk of a decade and the shows feel the same. Eventhough jams have been part of their much of their history variation in musical style hasn't been. That leads to homoginization that makes for great vibe music.
We have standards, called laws, for how we use shared resources. The fine is about $60/day. Feels low to me to be honest. The actions described could have easily contributed to death via disruption of emergency services.
Kind of interesting. You can google map yourself to within a few 100 meters of the thing. I suspect the people who "found it" were really just pimping it? If there isn't already there will be trash around it soon. https://www.google.com/maps/dir/Green+River,+UT/38.3431111,-...
I came at this the other way. KnR was my first real book about programming. Next were Bentley. Most O'Reilly and like books are overly wordy and don't get to the meat of the issue for me.
I don't think KnR will make you a much better engineer. But it will give you a really strong boost into being a reasonable c programmer. And it does that well because it focuses on that.
You have this backwards. Being mean doesn't scale. A small number of mean people can poison a large part of the community. That drives off future contributors at a high rate. Being reasonable does scale. When somebody isn't following reasonable guidelines it takes one person to point them at the FAQ, help them understand what they did wrong and why it could be done better next time, etc. One response[1] to point back in the right direction. Low investment for a good outcome. If more people decide to add like reasoning for why the question/comment/answer was off then more energy was spent to convince the original person that this is a hostile forum to use. Now you end up with more energy being spent to achieve a lesser effect. That is a lower ROI.
There is a difference between being concise (cut to the chase) and being rude. And yea, language differences can blur that line. But it is a spectrum. Just 'cuz not everybody will think you are being NICE doesn't mean it is fine to be a jerk.
[1] Due to the distributed nature of these platforms you can end up with a small multiple of simultaneous responses. Fine, most people get this is a possibility. One good way some people deal with this is to not knee jerk response to everything. Sadly that has a the effect of having the jerks do more of the responding.
I have goats and like them. "sweet fermenting odor": This person has never been around a billy goat. They stink and it sticks around. I like goats as farm pets. They can be a bit, well, goatly in butting and biting. Goat TV though rocks.
I think while this article doesn't really prove its thesis very well there is a kernel of an idea here which is useful to investigate. That is the idea that line by line stepping is a crutch that weakens the programmer.
Out of the 5 beliefs he quotes from celebrities we only have reasons for 3. Of those 3 the common thread I see is that we should be able to reason about our code and debuggers act to derail that. Furthermore, it appears that the aspect of debugging most being maligned here is stepping through code line by line. I'm fairly certain that is specific to a certain type of mindset. If I was writing a title for a talk in this area it might be more like "single stepping bad for students" and then talk about how to build code that is easy to model and think about and then use that to work through most problems. If you've got yourself past that student part (and yes, you'll dip back into this with new tech / languages) then being able to single step when it makes sense (don't have docs, processor isn't doing the right thing, etc.) makes you more powerful. Not less.
The focus on printing is a bit annoying. The writer seems to have never worked in embedded systems, distributed systems, or systems where reproducing the bug isn't an option. In the last case a debugger is your tool for grunging around in a core dump. In the embedded case some type of debugger or forcing a core dump (and thus using a debugger) might be your only choices.
I also question if he has ever worked on web systems. Reasoning "harder" about how some new CSS or javascript "feature" behaves across different browsers is useless. Writing little ad hoc uses (maybe in a debugger) and carefully tracking how they act in a debugger is powerful.
A lesson from my history is that of systems that take a long time to build and upload. The one I worked on early took 60 minutes to build and 30 minutes to upload to test hardware. You didn't fix bugs one by one. You fixed them by discovery, fixing on the platform (inserting nops, etc.) in assembly while replicating that in source (probably kicking of a build in case that was the last bug of this run), and then continuing to test / debug and get every little bit you could out of the session. And if you had to single step then that was worth it. Is this entirely a historical artifact? I havn't worked with anything that bad in decades but I still work with embedded (and some web) systems where the time to build and upload can be a minute to minutes. Getting more out of the session is useful and debuggers are part of that.
Refactoring as a response to a bug seems like a mistake worse than line by line stepping to me. Not understanding a cause but making a change propagates incorrect thinking about the system.
But I think the real missing part of this article is a discussion of what are other useful tools. The last comment in the article mentions "Types and tools and tests". It is easy to say tests are table stakes but a similar article about testing would create a flamefest so it is a bit hard to tell what kind of table (or is it stakes)? So what are those tools beyond testing? I'd love to have DTrace everywhere I worked. The number one best tool I've ever seen for working with a live system. The ideas in Solaris mdb about being able to build little composable tools around data structures is awesome. Immutable methods of managing databases are wonderful. It would have been nice if this author talked about design and refactoring "tools" (could be methodologies) he liked or thinks should exist.
The title of this needs to be changed go "A brief history of why artists are no longer making a living recording music". Live music is still huge and there are great musicians who make the majority of their income making something unique every night. Much like how people have made money off music has changed from selling sheet music to live performances to recordings we are back at creating music. Not selling its reproduction.
Interesting this article never said "poorly architected". The conclusion that the issue is peanut buttered points at that. Instead of looking into the system for things to optimize is there any proposal or initiative to rework it at a higher level?
My Barlow story starts with reading the first issue of the EFFector. Being a Deadhead I was also aware of John as Bob Weir's song writing partner. Reading a CACM column by Bob during a set break prompted an email exchange of no real note but fond memories. Rip a hole in the sky John. And may the rest of us learn just a little from your life.
This is not about comparing values. "is" compares address (memory location) and == compares value. While the same address implies the same value (for integers; see Naan for fun counterexample otherwise) the same value doesn't imply the same address.