A rocker's guide to management - <AUTHOR> https://www.1843magazine.com/features/a-rockers-guide-to-management <comment><USER3> > One of the most striking differences between the Stones and the Beatles is > that the Beatles split up after a mere seven years at the top, whereas the > Stones are still going. One startup flashed brightly and burned out; the > other established itself as a long-running corporation.

When it comes to fame the Beatles' model is the clear winner. In 56 years the Rolling Stones performed more than two thousand concerts around the world[1]. They did so many concert tours that there exits a Wikipedia category[2] just for the tours. Sure, the Rolling Stones are world famous, but what effort was required to become and stay that way. Compare that with the Beatles. They put in ten years of work to reach universal long lasting popularity - <USER2> efficient is that.

When it comes to fortune I'm not so sure. Comparing net worth of McCartney ($1.2 billion [3]) and Mick Jagger ($360 million [4]) it looks pretty clear too. But when we compare the overall wealth generated by the Beatles vs that of the Rolling Stones I'm not sure if that would be as clear cut. I don't have any number though and I think it's difficult to compare.

[1] [https://en.wikipedia.org/wiki/The_Rolling_Stones_concerts](https://en.wikipedia.org/wiki/The_Rolling_Stones_concerts)

[2] [https://en.wikipedia.org/wiki/Category:The_Rolling_Stones_co...](https://en.wikipedia.org/wiki/Category:The_Rolling_Stones_concert_tours)

[3] [https://en.wikipedia.org/wiki/Paul_McCartney](https://en.wikipedia.org/wiki/Paul_McCartney)

[4] [https://en.wikipedia.org/wiki/Mick_Jagger](https://en.wikipedia.org/wiki/Mick_Jagger)

<comment><USER4> The question is, would the Stones be as popular today if they also split up after 7 years at the top? I'd argue they would since all of their best work (with the exception of Exile on Main St. - which was released in their 8th year) was released in this time.

Of course I'm not going to argue that anyone is as popular as the Beatles, but I'm pretty sure the Stones would also have had universal long lasting popularty if they had only been around for the same amount of time.

You also can't compare the wealth of McCartney to Jagger. Firstly, McCartney had a very successful solo career after the Beatles, during which time he released way more albums than the Stones in the same time period and did his own share of touring. Secondly, McCartney owns a significant music publishing catalogue and has other business ventures.

<comment><USER5> I had the impression most of their fame came from the fact that they are the oldest rock band alive.

<comment><USER6> You take that back!

<comment><USER5> Oh, is there an older rock band?

<comment><USER7> GP is arguing that their fame is derived from attributes other than their age, not the fact that they are indeed the oldest rockers around

</comment></comment></comment></comment></comment></comment><comment><USER8> For those who are not into rock music or music in general necessarily, this article is still worth reading and thinking about. A couple of lines stand out for me, especially: "...every group has a threshold for tension that represents its optimal level of conflict. Uncontrolled conflict can destroy the group, but without conflict, boredom and apathy set in."

This is consistent with my own experience, both in bands and in companies, and perhaps in personal relationships also. A certain amount of friction is actually optimal in terms of output of the band / company / couple.

<comment><USER9> I'm not sure, there's definitely people (I mean, there must be others than myself ;)), mostly introverted, that shine best when they know that the relationship is based on pure facts and no unforeseeable tension may arise from hurt egos.

That being said, maybe we're such a minority that virtually no human group would be comprised of only that kind of mind (even in couples).

<comment><USER10> > pure facts and no unforeseeable tension

I cannot imagine a non-trivial environment where everything is deterministic and there's no room for argumentation. For example, when deciding on the color of a new logo, or what to do for a company trip, there's no obvious canonically true solution. Therefore, opinions and personal preferences come into play, which is a source of conflict.

<comment><USER9> > For example, when deciding on the color of a new logo, or what to do for a > company trip, there's no obvious canonically true solution. Therefore, > opinions and personal preferences come into play, which is a source of > conflict.

Ha, those are great examples where I will absolutely refuse to give my opinion :)

"What's your idea on the new logo color?", "I don't care, I'll be ok with whatever you choose", "No really, tell me", "No really, I don't want to think about it", "I don't get it", "I know you don't". Quit harsh, I conceed :)

Related: bikeshedding and [https://en.wikipedia.org/wiki/Law_of_triviality](https://en.wikipedia.org/wiki/Law_of_triviality)

<comment><USER11> Quite an annoying approach in itself. The worst is people doing that when deciding where to eat.

</comment></comment></comment></comment></comment><comment><USER12> >The notion that bands should make music for the love of it was always romantic and now seems positively quaint. Rock groups are mini-corporations

The top 0.1% of rock groups maybe. The vast majority don't make significant money and probably do it mostly for the love of it and maybe a bit in the hope they'll make it one day.

<comment><USER13> I don't entirely agree. If you want to have a chance to make it, you _have_ to be more than just a group of guys playing music. You need to be professional, manage your booking, do networking, manage your music production...

<comment><USER14> That's right, but start by writing some good songs first (whatever the genre)...otherwise, business wise, it' probably better just to focus on being a tribute band.

<comment><USER15> If I understand you correctly, you're advocating for creating an MVP before moving on to the questions of how to manage the business around it.

<comment><USER14> Ok: play something people want to hear.

<comment><USER16> So what you're saying is, you need to have an idea of the market fit for your product.

<comment><USER14> I'll go along: you're pitching your music and receiving feedbacks since the early stages of your startup band, so no need to study how to fit the market. Go fast, break strings.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> > If rock groups are businesses, businesses are getting more like rock bands. > Workplaces are far more informal than they used to be, with less emphasis on > protocol, rank and authority. Many firms try to cultivate the creativity > that can come from close collaboration. Employers attempt to engineer > personal chemistry, hiring coaches to fine-tune team dynamics and sending > staff on team-building exercises. Employees are encouraged to share lunch, > play table tennis and generally hang out. As the founder of Hubble, a London > office-space company, put it, "We hope that our team will become friends > first, and colleagues second."

The problem is, most of these companies are closer to formula driven Justin Bieber than the less pop-focused (say) Radiohead.

Both have their merits. However, talking the latter while walking the former (or vice versa) creates disconnect - for employees, as well as customers.

Ultimately, culture matters. It's a process. It must be cultivated and curated. It is __not__ a speech or memo from the top that intends to magically everyone with the snap of their fingers.

There's far more to "We're going to innovate..." and "We're going to be creative..." and "We're going to be customer focused..." than simple saying such things.

p.s. Heart and commitment matters. When you think of any great band you can hear their all-in-ness. Those who fake it, are far less likely to make it, and last.

</comment><comment><USER18> > One notable exception to this rule was The Smiths. When Morrissey and Johnny > Marr founded the band in 1982, they insisted on taking a bigger cut of > income, from all sources, than the bassist, Andy Rourke, and the drummer, > Mike Joyce

Has anyone ever found any redeeming personal qualities to Morrissey?

<comment><USER19> He's a unique blend of funny and annoying, a master troll.

His lyrics are one of the few I actually listen to and enjoy. Not to mention the song titles. So I guess he's a decent writer?

<comment><USER20> What a fantastic description or Morrissey. He's exactly a "master troll". His social "role" is like the chorus from Greek tragedies.

I don't often listen to his music anymore. But, when the mood hits, nothing else satisfies.

</comment></comment></comment><comment><USER21> The Stones are like Apple, arguably Brian Jones was their Steve Jobs, after Jones passed they became this tried and true formula, they may have added in a disco beat in the late 70s but it was basically an iconic sound with iconic songs, but their creative genius had passed long before. I don't expect Apple to die off any time soon but Jobs was definitely their Brian Jones. But like the Stones I expect them to continue long into the future playing out the same formula over and over.

<comment><USER22> I wanted to argue against this, and I don't necessarily agree, but I guess the Stones did their best work after Jones died, but not too long after he died and I guess one could argue the same about Apple after Jobs (so far)

</comment></comment><comment><USER23> I worked with REM for the past 20 years. This article is dead on. Learned more from that band about management than from any business mentors.

<comment><USER20> What an incredible experience it must have been to be around such a creative group of guys. Even today, I can listen to Stipe's lyrics and find different meaning with my changing life experiences.

I know they didn't like it, but Fables of the Reconstruction is one of the most moody, creative works in modern music IMO.

<comment><USER23> They came around to liking it at around the 20 year mark :)

</comment></comment></comment><comment><USER24> >John Lennon's and Paul McCartney's artistic partnership enabled them to vertically integrate the hitherto separate functions of songwriting and performing.

Ugh, really? We're going to bring corporate buzzwords to the Beatles now?

Lennon and McCartney had perfectly complementary qualities.

When Paul would write "I've got to admit it's getting better", John would add "It can't get no worse".

Paul is a great multi instrumentalist and has a great ear for melody, while John had lees musicianship but was a subtler and sometimes wickedly funny lyricist.

Did you every see a video of an octopus capturing prey, the way they wrap themselves around it and smother it?

That is what capitalism is attempting to do with everything.

<comment> 52-6F-62 > Did you every see a video of an octopus capturing prey, the way they wrap > themselves around it and smother it?

That is distinctly reminiscent of Matt Taibbi's take on Goldman Sachs:

> _The first thing you need to know about Goldman Sachs is that it's > everywhere. The world's most powerful investment bank is a great vampire > squid wrapped around the face of humanity, relentlessly jamming its blood > funnel into anything that smells like money._

\---

[https://www.rollingstone.com/politics/politics-news/the- grea...](https://www.rollingstone.com/politics/politics-news/the-great- american-bubble-machine-195229/)

</comment></comment><comment><USER20> The book "Beyond Category" is a fantastic book that profiles Duke Ellington as a band leader. He kept a large number of high-level musicians, often with challenging personalities, employed and working together for decades. He managed to accomplish it in the face of a "pivoting market": around the late 40's/early 50's listeners turned more toward bebop with its small-group sound.

It's a worthwhile read for anyone with both music and leadership interest.

</comment><comment><USER25> >Underpinning R.E.M.'s flat governance structure was an egalitarian economic one. As Tony Fletcher explains in "Perfect Circle", his biography of the band, each member received an equal share of publishing royalties, regardless of who contributed what to each song. The same was true of their recording and performing royalties – although here equal splits are normal. One notable exception to this rule was The Smiths. When Morrissey and Johnny Marr founded the band in 1982, they insisted on taking a bigger cut of income, from all sources, than the bassist, Andy Rourke, and the drummer, Mike Joyce. This introduced an instability into the group, hastening its demise after five years.

My understanding is that truly equal shares across the board are pretty rare, and probably even rarer if you filter for success. I think Van Halen was run that way, at least in its glory years (ie until DLR left).

Marr & Morrissey insisting on a larger share of performing royalties and gig fees is just mean, considering they dominated songwriting. That's actually a minefield for some acts, because the songwriting money is WAY BIGGER (at least traditionally) than performance royalties.

This came up in some of the more amusing sequences in the old VH-1 "Behind the Music" about the Go-Go's, who like many bands split songwriting royalties by actual authorship. The overwhelming majority of their songs (and all their hits) were written by Jane Weidlin and/or Charlotte Caffey, so after _Beauty and the Beat_ blew up they started getting checks that were much, much bigger than the other band members, who took exception.

Weidlin's response to their ire was "well, write some fucking songs!"

</comment><comment><USER26> This seems a remarkably wholesome article given how vicious showbiz can be around song writing rights, recording deals etc. There's no discussion of the actual management of these acts - people like Peter Grant/Led Zeppelin or Mike Jeffery/Jimi Hendrix Experience, who both had very questionable business practices. Those are the people who control and exploit the talent, it seems very few acts have management who are looking out for them...

</comment><comment><USER20> The owner of a music school in my neighborhood graduated from Berklee Music College in the mid-90's. Even then Berklee had its students taking classes in business. A lot of being a successful musician is promotion and understanding how contracts work.

</comment><comment><USER27> So, are we going to have "rockstar-managers" and "ninja-bosses", too? Awesome.

</comment><comment><USER28> _Friends who once gathered in garages to thrash out songs on guitars and drums are now as likely to get together to brainstorm ideas for apps_

Kind of a case in point: Smashing Pumpkins' drummer Jimmy Chamberlin, who is the CEO of a tech company focused on live events ([https://www.modeproject.com/liveone-crowdsurfing/#liveone- fi...](https://www.modeproject.com/liveone-crowdsurfing/#liveone-film)). He got the gig through a connection with Groupon's Andrew Mason.

I think the study of bands' management styles really does give useful insights into creativity and venture creation. Bands (more than most startups) represent an almost ideal opportunity to have a balance of complementary job responsibilities; it's then up to the members (or leader[s]) to creatively optimize the output, including song creation, live performances, recording, fan outreach, marketing, etc.

One area where things get interesting is when professional management gets involved. I was intrigued by that part in the article about the grizzled manager telling Tom Petty to put his foot down, and the repercussions that followed. This manager cut his teeth working with Joni Mitchell and Neil Young, perhaps the two most mercurial and insistent creative forces of the late 60s rock scene. It's interesting to think what would have happened had Petty hired someone else who had a different perspective.

Another area that fascinates me is when things go wrong, and how these entities adjust. The scene in _Bohemian Rhapsody_ where Freddie Mercury splits with the record exec who doesn't like opera is fictional, but a true story that is even more bitter is the split with Queen's early manager Norman Sheffield, a former drummer and later founder of the UK's first Apple dealership. Listen to the first track off the album Bohemian Rhapsody, written by Mercury, "Death on Two Legs," probably the ultimate rock diss track. It's so powerful and bitter. It amazes me they didn't try to work it into the movie, although that may relate to the fact that it is unfamiliar to most audiences, probably because radio was reluctant to play it back in the day.

A third topic is scaling the business. I've written about Led Zeppelin in the past (see [http://leanmedia.org/lean-media-example-led- zeppelin-i/](http://leanmedia.org/lean-media-example-led-zeppelin-i/)) and believe the band was the ultimate rock startup: A talented creative team that clicked, an experienced pro (former Yardbirds guitarist Jimmy Page) leading the way, using audience feedback cycles to help shape the first songs _before_ they entered the studio, and management that didn't try to mess with the creative core.

Manager Peter Grant was a fearsome character ([https://www.loudersound.com/features/the-last-days-of-led- ze...](https://www.loudersound.com/features/the-last-days-of-led-zeppelin-g- force)), but only focused on the business end (especially touring) and let Page lead the way in the studio and on stage. Because Led Zep was bootstrapped and didn't have a record deal when they started, they didn't have some record executive trying to call the shots in the studio and they worked quickly. Inception was in August 1968 and the release of the first album took place in January of the following year. _Led Zeppelin II_ was similarly lean, recorded while they toured. Four of their first five albums were certified RIAA "Diamond" albums, each selling more than 10 million copies (see [http://leanmedia.org/chart-shows-rise-fall-music- album/](http://leanmedia.org/chart-shows-rise-fall-music-album/)) which I think may be a record.

Yet by the mid-70s Led Zeppelin really bogged down. They started living the rock star life, and were doing massive tours that sucked the energy out of the band. _Physical Graffiti_ took something like 18 months to produce (yes, it was a double album, but still). By the late 70s, Page and Bonham had serious substance abuse problems and the creative mantle passed to Jones and Plant. The band folded after Bonham died in 1980.

</comment><comment><USER29> I'll say American, or Western business culture has a lot of "non-problems." To even imagine what makes a "problem" to a rich Western multinational, one has to put up some effort.

I'm not a fan of S. Jobs, but generally approve of ways how he reanimated Apple Computers. A lot of commons sense based decision making in corporate structure, and HR policy. For one, he fired a lot of business degree holders from running actual engineering units — an issue of "inversion," I think is what the prime majority of big tech companies suffer from, and can't do a thing about.

Remembering that, I can only continue to laud and appraise what it is the mainstream Chinese way of running a tech company. I was dealing with Chinese electronics since my first job in a trade company in Singapore 12 years ago. Just how freaking efficient they are. This baffled me 12 years ago, and it still does today.

Nowhere but in China, you can have "signed contract in the morning, widgets in the evening." Rather sizeable collectives of up to 100 men are running here without a single "business" degree holder except of a single accountant/tax filler. Such companies run almost like as if they were a computer program, except they exist in real world.

If I am asked to summarise what that malaise is that ails Western business in a single sentence it is "Western business culture is not about doing business."

Too artsy, too talkshopy, too much "empty thinking," some people don't even know what they are supposed to do — if I take upon Jiang Zemin's style of a maxim statement.

<comment><USER30> Having grown up and worked in the US and lived in China for the past 10 years, I think you're overreaching with your characterization of corporate culture.

China, like the USA, has a wide range of companies that span the spectrum of efficiency. Try to get some customer service at China Telecom and you'll see the bottom-tier of efficiency that resembles, or is even worse, than trying to get your cable fixed with Comcast.

<comment><USER29> > China, like the USA, has a wide range of companies that span the spectrum of > efficiency. Try to get some customer service at China Telecom and you'll see > the bottom-tier of efficiency that resembles, or is even worse, than trying > to get your cable fixed with Comcast.

True. There are horrifically bureaucratised private companies with SOE roots, or ones ran by the "old boss" class. But in China, nobody will place them as an example to emulate, but in America, the amount of people hellbent on "running the company like a F500 multinational" is just scary, and these people __don 't even realise__ that they are doing, and wanting something that is wrong.

<comment><USER31> Are you telling me there are startups that _want_ to run like F500 multinationals?

No company has SOX compliance departments, mandatory HR trainings or audited travel expense policies because they want to, they're just there because beyond a certain point you'll find out the hard way that they're there for a reason.

<comment><USER29> > Are you telling me there are startups that want to run like F500 > multinationals?

Yes.

And their polar opposites are not better either.

Many of those guys are claiming that they know a thing about tech industry. Some have actual tech education, maybe some low effort projects, but I meet a lot cadres that put forward statements like "Our CTO has 20 years engineering experience, we have zero reservations about our execution ability," but then it finds out that the guy ran RnD offices for 20 years, but every time he actually had to make anything he ran from one agent to another "to deal with those Chinese factories." In other words, a dude on a CTO job with zero actual manufacturing experience. In such cases I almost feel obliged to whisper to the CEO or the founder "if he can't make you anything, why do you even hire him?"

I'm not speaking about our clients, but, say, "the feel of industry in general" :)

When I see people coming to SZ with an aspiration of making the next Ihpone, some of them come with a crew the size of our our entire engineering consulting company (around 50 people,) but they already have a baggage of "product managers," "corporate strategist," "experience managers," and some 10 other managers with titles I never ever heard of.

That way you can have startups with 10th of megabucks in funding, huge teams, and no products to sell...</comment></comment></comment></comment></comment>


Secure C coding standards by SEI - <AUTHOR> https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard <comment><USER2> Direct PDF download:

[http://www.sei.cmu.edu/downloads/sei-cert-c-coding- standard-...](http://www.sei.cmu.edu/downloads/sei-cert-c-coding- standard-2016-v01.pdf)

<comment><USER3> Miserable fail to cert for requiring a https-less registration for a document on security.

<comment><USER4> CMU doesn't require, but it does allow:

[https://www.sei.cmu.edu/downloads/sei-cert-c-coding- standard...](https://www.sei.cmu.edu/downloads/sei-cert-c-coding- standard-2016-v01.pdf)

</comment></comment></comment><comment><USER5> Is anyone else finding some of these rules to be bizzarely tone deaf?

Recurring pattern:

 _" Don't do such and such that is obviously wrong."_

Well, no kidding! I would never do such a thing ... _on purpose_! It's the not-on-purpose occurrences that I need help with.

Without a concrete plan on how to _prevent_ or _detect_ that situation, this advice isn't helpful. I know I shouldn't rely on uninitialized memory, and, believe me, I do not want to. Give me a coding _strategy_ which minimizes the occurrence of uses of uninitialized memory. Recommend a compiler and its particular compiler options, or some lint or other static checking tool or run-time detection.

"Don't read uninitialized memory" isn't something I can turn into a concrete action to somehow improve software quality.

It's like a driver's manual which says "stay on the road and don't run over people".

<comment><USER6> Like the ISO C standard I do not think that Cert is meant to be a training document in and of itself like a book. The user of the standard is going to have to draw on other sources, experience and technology to put together a an implementation strategy.

The purpose of the standard is to allows a piece of software to get CERT certified. You have to actually submit your code to CERT and they analyze it and give you a certificate and add the software to the list of conforming systems.

This can intern help to gain other certifications. For instance if you are working on software for the Department Of Defense they have there own sets of certification standards. Some of which may be satisfied by conformance to CERT.

I would start to investigate static analyzers and compilers and see what you can find. Specifically look for claim that diagnose standards violations and which ones.

Also take a look at section 1.7. There is a difference between the 99 coding 'rules' and the 185 'recommendations'. Recommendations provide guidance but do not necessarily indicate a defect. So a recommendation is not necessarily exact.

<comment><USER5> In that case, why is it repeating material out of ISO C instead of just referring to ISO C as a base document for all those points.

You can summarize it all in one item:

"A program fails to conform to the CERT standard for secure coding if it violates any of the following 'undefined behavior' situations explicitly described in ISO C, or implicitly by omission: [give a summary list with brief descriptions and section references]"

<comment><USER6> I can't answer for the the people who wrote it. What you could do is put together a few questions and send them an email. Or look around the wiki.

Just for future reference when you quote put the page number or section so people can look it up and see the context.

From my experience expert arguments about C end with a reference to the C standard. The C standard is authoritative. If you can quote the standard to back up your argument you win. Arguing C/C++ is different from most other languages in that respect because we have an official ISO standard and expert C/C++ programmers take the standard very seriously.

The language of the C standard is very terse and hard to read for most people. (myself included) And a lot of the issues are very subtle. As a result anyone quoting the C standard starts to adopt the C standard style of language and idiom. So you get some arguments and documents like CERT that end up being kind of hard to read and terse also. I have read some arguments where I have to open the standard to read the argument because its essentially two people quoting the standard arguing about the correct meaning of a particular passage.

If they give a section reference to the C standard the purpose is to be authoritative. So that people reading it can look those up in the C standard and know that they are official undefined behaviors. There are lots of arguments about specific undefined behavior. And the only way to settle the dispute is to refer to the standard to see if the behavior is actually an official undefined behavior or someone who is making there own judgment which is usually wrong if its not backed up by the standard.

<comment><USER5> I don't mean that they are repeating material _verbatim_ out of ISO C as a quote; they are wastefully _reinventing_ it in their own words.

A secure coding standard form CERT should focus entirely on describing conventions and program properties that do not already follow from the standard as a matter of correctness.

For instance, it's a security problem if, say, we manipulate sensitive data and then don't wipe the memory. That does not violate ISO C in any way.

A perfectly ISO C and POSIX conforming application could have a race condition with regard to a symbolic link. Or some time-of-check-to-time-of-use (TOCtoTOU) race.

A perfectly ISO C and POSIX application could do something stupid with permissions.

Creating a listening socket for local use and not restricting it to the loopback address (like 127.0.0.1 on IPv4) should fail a security review.

There are all kinds of things that either follow from the language and API documents in very non-obvious ways, or not at all.

Not initializing an object and then using it falls into a catch-all bucket of "language violation" that can be covered in a paragraph or two.

<comment><USER6> Its a bit tricky I think.

> A secure coding standard form CERT should focus entirely on describing > conventions and program properties that do not already follow from the > standard as a matter of correctness.

from CERT 1.7 "The wiki also contains two platform-specific annexes at the time of this writing; one annex for POSIX and one for Windows. These annexes have been omitted from this standard because they are not part of the core standard."

So while the CERT does use some examples from system interfaces its not a standard for programming the system interfaces for POSIX or Windows. It looks like there trying to limit the standard to ISO C. The examples you gave fall into the system interface category. POSIX is huge and the same for Windows, much bigger then ISO C.

I think in order to explain conventions for a system interface you really need a longer form publication like a book. So you can take 50 pages to describe an interface and how to use it and show examples etc.

The best way that I have found to figure this stuff out is the standard way. You get a copy of all the relevant standards as a foundation, ISO, POSIX, Window and stuff like CERT. Then you you get some of the system programming books (listed below). Then you find get some good reference code that show best practice. usually code from the operating system or utilities. Lastly read all the compiler docs and tool docs to set up the best code analysis framework you can.

These are a few system programming books that I use.

(best intro book) GNU/Linux Application Programming [https://www.amazon.com/GNU-Linux-Application- Programming/dp/...](https://www.amazon.com/GNU-Linux-Application- Programming/dp/1584505680/ref=sr_1_3?ie=UTF8&qid=1491440469&sr=8-3&keywords=linux+application+programming)

UNIX Systems Programming [https://www.amazon.com/UNIX-Systems-Programming- Communicatio...](https://www.amazon.com/UNIX-Systems-Programming- Communication- Concurrency/dp/0130424110/ref=sr_1_1?ie=UTF8&qid=1491440175&sr=8-1&keywords=unix+system+programming)

Advanced Programming in the UNIX Environment [https://www.amazon.com/Advanced- Programming-UNIX-Environment...](https://www.amazon.com/Advanced-Programming- UNIX- Environment-3rd/dp/0321637739/ref=sr_1_3?ie=UTF8&qid=1491440175&sr=8-3&keywords=unix+system+programming)

Windows System Programming [https://www.amazon.com/Programming-Paperback- Addison-Wesley-...](https://www.amazon.com/Programming-Paperback-Addison- Wesley-Microsoft- Technology/dp/0134382250/ref=sr_1_1?ie=UTF8&qid=1491440172&sr=8-1&keywords=windows+system+programming)

The Linux Programming Interface [http://www.man7.org/tlpi/](http://www.man7.org/tlpi/)

edit: I'm not sure your skill level, you may have seen all of those but I posted them regardless. There is a lot of security and convention in those books.

</comment></comment></comment></comment></comment></comment><comment><USER7> Is there a code analysis tool that will flag code that violates these rules?

<comment><USER8> Elsewhere on the SEI site there are some checkers [1] [2]. They also advocate using clang's "-Wthread-safety" among others. It doesn't sound to me like there exists a tool that will measure this coding standard as conformance criteria.

[1] [https://github.com/SEI-CERT/scvs](https://github.com/SEI-CERT/scvs)

[2] [https://sourceforge.net/projects/rosecheckers/](https://sourceforge.net/projects/rosecheckers/)

</comment></comment><comment><USER9> The "compliant solution" example for setlocale() is thread-unsafe, AFAICT.

(I'm not aware of a safe solution other than "don't use the text processing part of the C standard library, because its design is too wrong".)

<comment><USER10> There is a thread-specific uselocale() in POSIX.1-2008.</comment></comment>


"These idiots are paying me to learn new skills" - <AUTHOR> http://berzniz.com/post/112910477641/a-bunch-of-idiots-are-paying-me-to-learn-new

<comment><USER2> Are you saying.. "* I'm just kidding of course. They're not idiots, but it makes it sound much better."

so that you can trick the "idiots" into thinking they aren't idiots, and thus continue to pay you?

<comment><AUTHOR> I actually work for people who I consider to be good friends. It's just something I tell people of how this industry works and why it's an awesome job.

<comment><USER2> I figured as much, most of us do. Nothing like a portable skill set in high demand.</comment></comment></comment>


Ask HN: Which YC startups have launched in 2009? - <AUTHOR>

Is there a list? <comment><USER2> <http://en.wikipedia.org/wiki/Y_Combinator></comment>


Ask HN: What are your daily must-read sites? - <AUTHOR> As Hacker/Developer or designer interest, beside HN of course ;) <comment><USER2> I don't have particular must-read sites so much as collection of sites with potentially interesting material set up in Pulse which I scan through twice a day or so.

I end up reading stuff from HN [1], The Verge [2], Wired[3], A VC[4], VentureBeat[5], AllThingsD[6], Technology Review [7] and Ars Technica [8] most often.

They aren't strictly digital related, but I get a lot out of Archinect [9] and core77 [10] for design interest.

1: <http://news.ycombinator.com/newest>, 2: <http://www.theverge.com/>, 3: <http://www.wired.com/>, 4: <http://www.avc.com/>, 5: <http://venturebeat.com/>, 6: <http://allthingsd.com/>, 7: <http://www.technologyreview.com/>, 8: <http://arstechnica.com/>, 9: <http://archinect.com/>, 10: <http://core77.com/>

</comment><comment><USER3> <http://hckrnews.com> (my preferred interface to Hacker News)

</comment><comment><USER4> I got tired of visiting each site individually so I built <http://skimfeed.com>

</comment><comment><USER5> <http://www.contemporist.com> Daily routine because of my obsession with architecture, home design and styles.

<http://www.reddit.com/r/ArtisanVideos/> Hours and Hours of video on how things are built, by hand. I'm utterly fascinated by the craft of building tangible objects with your hands.

<http://wireframes.linowski.ca> A legend in the Interaction Design field

<http://sidebar.io/> ..and most recently, I enjoy getting my design related digest from Sacha Greif & Co.

<comment><USER6> Thanks for mentioning Sidebar!

By the way, the HN crowd might be interested to know Sidebar is built with Meteor (on top of Telescope actually: <http://telesc.pe>).

<comment><USER7> Sidebar loads very slow and the ajax spinner doesnt stop spinning. Mind sharing how it was build and where it is hosted?

<comment><USER6> Yeah, sorry about that, that happens sometimes. It's built with Meteor and hosted on EC2.

</comment></comment></comment></comment><comment><USER8> Reddit, for starters. There are a lot of great sub-Reddits you can subscribe to and you can remove a lot of the pointless default ones (/r/atheism, /r/politics, /r/aww, etc.) so you end up with a feed that really suits you.

<http://inbound.org/> is basically HN for people also interested in online marketing, SEO, etc - lots of great practical stuff ends up on there that never makes HN.

<comment><USER9> Thanks for mentioning inbound -- hadn't seen that one before and looks good for SEO/marketing/etc.

Are there other similar HN-type sites that are business-oriented?

</comment></comment><comment><USER10> James Gurney's blog Gurney Journey <http://gurneyjourney.blogspot.co.uk/>.

StackOverflow newest C++/Python questions

Reddit

Seth Godin

Google Reader

xkcd

<comment><USER11> +1 for xkcd I often end up re-reading old comics when there aren't any new ones.

</comment></comment><comment><USER12> In no particular order

<http://www.news.ycombinator.com>

<http://www.economist.com>

<http://thedailywtf.com/>

Reddit - todayilearned, science, politics, askreddit

<http://www.foreignpolicy.com/>

</comment><comment><USER13> I come to Hacker News just for the opinion articles that people post. I also love to read The Verge.

</comment><comment><USER14> Prismatic for personalized articles [1] and the amazing HackerWeb for iOS [2] for a fix on the go.

1: <http://getprismatic.com/> 2: <http://hackerwebapp.com/>

</comment><comment><USER15> <http://andrewsullivan.thedailybeast.com/> Andrew Sullivan: balanced political commentary from a British conservative living in America and who voted for Obama.

</comment><comment><USER16> The Economist

</comment><comment><USER17> _If i'm researching something:_

HNsearch.com, Topsy.com, pinboard.com, stackoverflow.com, getprismatic.com, subreddits for specific topics.

Sometimes, delicious.com, which i used to go every day.

subject matter specialists on twitter,

______________

 _If i'm not researching something:_

I open chrome and firefox pages to manage extensiosn/addons and those are the only pages i let myself open (my version of no-procrast)

</comment><comment><USER18> I use Flipboard to aggregate the best stories from several sources. They have a heap of design feeds already listed as well as business, tech and HN in there too. Best part is its easy to flick quickly through headlines, share what you want and also save to instapaper for later.

</comment><comment><USER19> 1\. Quora - To participate in discussions and learn new things 2\. <http://zenhabits.net> \- Minimalism and Better habits 3\. Reddit/r/Science 4\. Techcrunch, GigaOm, Engadget - Tech Trends 5\. Fubiz.net - For daily dose of inspirations

</comment><comment><USER20> I used to keep up with tens of blogs and sites via RSS, as I got busier it became obvious I couldn't possibly keep up with all of them. Now HN & NYTimes is the only place I visit and occasionally Lifehacker. HN filters out most of what I don't care about.

</comment><comment><USER21> O'reilly radar - 4 daily links is what I read when I don't even have time for HN. If it's one of the things I really care about, it usually ends up on there. <http://radar.oreilly.com/>

</comment><comment><USER22> I use Prismatic (<http://getprismatic.com>) which gives me more than enough to read on a daily basis. I also use Zite on my iPad (because Prismatic doesn't have an iPad app -- yet?).

</comment><comment><USER23> TMZ

</comment><comment><USER24> <http://news.ycombinator.com/newest> <http://www.wired.com/>

</comment><comment><USER25> Too many websites to visit each time, I read from this small toy feed reader : <http://bit.ly/10SNaFJ>

</comment><comment><USER26> HN, Pinboard popular and recent, New York Times, Reddit

<comment><USER27> I went over to Pinterest and took a look at the popular and found nothing worth looking EVERY DAY. That's when I realized you said PinBOARD and not PinTEREST.

</comment></comment><comment><USER28> Hacker news, GitHub (new and trending projects), AngelList, Twitter, Dribbble, and sometimes Facebook.

</comment><comment><USER29> <http://highscalability.com/>

</comment><comment><USER30> HN, Techmeme, Twitter. My Twitter feed is mostly pointers to tech/design articles.

</comment><comment><USER31> Dzone <http://www.dzone.com>

<comment><USER32> I stopped using Dzone ages ago. It has become a mixture of spam and dangerously stupid disinformation. It's being heavily gamed and the owners don't care.

<comment><USER31> Honestly, I'm also at the edge of my patience.

I mentioned it for completeness.

</comment></comment></comment><comment><USER33> HN and various tech sites I follow on Twitter. Also reddit.

</comment><comment><USER34> For me: NYTimes, Techmeme and Hacker News

</comment><comment><USER35> I like Microsoft's Channel9 website

</comment><comment><USER36> HN, TC, GigaOm and theRegister

</comment><comment><USER37> Mostly, BBC

</comment><comment><USER38> news.yc

Drudge Report

Reddit

</comment><comment><USER39> Reddit, HN, /. and if I am still unsatisfied I check Pocket or my myriad of RSS feeds in Google Reader from which blogs like Jeff Atwood et al</comment>


Stop writing classes... - <AUTHOR> http://pyvideo.org/video/880/stop-writing-classes <comment><USER3> I almost never write classes in Python. That may be a result of the fact that I never use Python for anything other than system automation and data post processing; I don't use Python to build complicated systems. What I have made use of are named tuples:

      3DPoint = collections.namedtuple('3DPoint', ['x', 'y', 'z'])
      p1 = 3DPoint(3, 2, 4)
      p2 = 3DPoint(10, 1, 10)

      dist = math.sqrt((p2.x - p1.x)**2 +
                       (p2.y - p1.y)**2 +
                       (p2.z - p1.z)**2)

I don't mean to say that classes aren't useful in Python, just that I've gotten a lot done in the language just depending on hashes, lists, tuples, named tuples, functions, comprehensions and generators. I've never felt the need to define a a class - the closest I came, I realized I wanted a named tuple. It certainly would make sense in the above example to define "dist" as a member function of a 3DPoint class, but it's just not how I write code in Python.

Contrast this with C++, where I define classes all the time. I think the reason for this discrepancy is that if you want to do anything interesting in C++, you almost have to define a struct or a class; that's where most of the abstractions happen. In fact, if I want functional style code in C++, I have to define my functions as classes. I think that Python's native tuple types, first-class functions and comprehensions make the difference.

<comment><USER4> A few years ago, I quit organizing my code in terms of classes altogether. Everything got so much simpler that for me that whole way of looking at programming is now a gigantic mistake. It's true that you have to have a powerful enough language to get away with writing only functions, or at least one that doesn't impose classes on you, but that's true of lots of languages nowadays.

Freud said sometimes a cigar is only a cigar. I say sometimes a function is only a function.

Classes get in the way between the programmer and the problem. They force you to reify your thinking into "things" (classes) that demand names and citizenship rights, so to speak, in the system. These "things" don't really exist, but we act like they do, and so increasingly see the problem in terms of the classes we've defined. This is a distorting filter that we can ill afford when the problem is complex (if it's not complex, who cares - <USER2> will work ok). The solution is not to define such pseudo-things in the first place, but rather to focus at all times on the problem at hand. Functions, for me, are the right level of abstraction to do this. They don't get in the way.

Once a bunch of classes have taken residence in your system and your brain, it's hard to remember that they aren't real, and thus the pain threshold is quite high before you realize that they're causing problems. At that point they're hard to change: you have to replace the old class hierarchy with a new class hierarchy. The difference between that and reworking a few functions is the difference between working in concrete and clay.

There's also the cognitive tax of having to think about what classes to create and what to name them. This too is overhead we can ill afford given our limited mental resources. If you've ever found yourself putting some code in a new class (perhaps because the old one got too big, or because you need to use it from two places) and gotten stopped in your tracks by the question, "What should I name it? What _is_ this thing?" you are experiencing the overhead I'm talking about. It's the programming equivalent of Mr. Heavyfoot: <http://www.youtube.com/watch?v=R9d2Y1We-d0>. There _is_ no such _thing_ ; you're just working in a way that forces you to pretend that there is and fulfill a bunch of duties towards it.

These two issues together are a double-whammy: you pay up front for what you pay for later.

It is shocking to see how much simpler systems become when we stop doing the things that make them complicated.

<comment><USER5> I couldn't disagree more.

Classes are nothing but:

      1. a group of data attributes, and
      2. a defined set of operations that can happen on instances
         of those data attributes.

If you are opposed to classes, which of these characteristics are you opposed to? Since I think it would be pretty much impossible to be a programmer and be opposed to structs or tuples, it must be the latter that you don't like: giving structs an associated set of methods that operate on them.

But having a set of methods that define the state transitions that are possible on an object is incredibly useful, for so many reasons. It helps organize your code. It provides nicer, more intuitive syntax. But most importantly, it reduces program complexity by narrowing down the set of code that can directly modify the attributes of an object.

Without this encapsulation, any piece of code anywhere in the program could be modifying data attributes in any way, and it is extremely difficult to reason about the state transitions that any particular struct could be taking.

There is no rule that says classes have to be in any kind of hierarchy at all, and in fact "prefer composition over inheritance" has been common wisdom for years now.

I recently rewrote a very useful but hard to follow JavaScript library in a more object-oriented style. The old code has a bunch of maps everywhere that can be read or written by any part of the code, and it's very difficult to follow. In a more object-oriented style the structure of the code is far more obvious, and the state transitions that each object can take are far more clear.

<comment><USER6> To follow up on gruseom's comment that YMMV, I would point you to Joe Armstrong's (Erlang creator) "Why OO Sucks"[1]. The title isn't great, and you may hate the content, but the interesting thing (to me) is that he makes a lot of the same basic points as you and then he draws all the opposite conclusions.

Maybe a reasonable conclusion is that there is no silver bullet for managing complexity and making things easier to reason about.

[1]: <http://www.sics.se/~joe/bluetail/vol1/v1_oo.html>

<comment> loup-vaillant No silver bullet? Check this out: <http://vpri.org/html/work/ifnct.htm>

They already have some results: <http://www.vpri.org/pdf/tr2011004_steps11.pdf>

To sum it up, they do "personal computing" in about 4 orders of magnitude less code than current mainstream systems (from more than 200 millions lines to about 20,000). That includes the self-implementing compilers. The only thing they left out was the device drivers (which by the way takes less than 0.5% the size of current systems).

Now the Complexity Werewolf just went from "Unspeakably Awful Indescribable Horror" to "Cute puppy".

</comment></comment></comment></comment></comment><comment><USER7> Are java programmers the most egregious abusers of the Gang of Four?

Twice now, I've been faced with a metric crap-ton of Java source files for reading / writing to a device.

Anything you could possibly imagine, gets defined as a class. There's dozens of classes, and more SLOC than I can count.. Meanwhile, an equivalent C program comes in at 2k SLOC, and 4 files.

You().Can('not').Do(any(thing)).Concise().In(java())!

When I was primarily doing C++, I gradually switched to generic programming once visual studio supported STL... And then when I started using Perl I found I didn't need to write classes at all.

Reminds me of this Paul Graham quote: "This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write."

<http://www.paulgraham.com/icad.html>

<comment><USER8> You might enjoy Steve Yegge making fun of this aspect of Java culture, if you haven't this particular post before: [http://steve- yegge.blogspot.com/2006/03/execution-in-kingdom...](http://steve- yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html)

<comment><USER7> I had not seen that! Explains so much...

 _In the neighboring programming-language kingdoms, taking out the trash is a straightforward affair, very similar to the way we described it in English up above. As is the case in Java, data objects are nouns, and functions are verbs. But unlike in Javaland, citizens of other kingdoms may mix and match nouns and verbs however they please, in whatever way makes sense for conducting their business.

For instance, in the neighboring realms of C-land, JavaScript-land, Perl-land and Ruby-land, someone might model taking out the garbage as a series of actions — that is to say, verbs, or functions. Then if they apply the actions to the appropriate objects, in the appropriate order (get the trash, carry it outside, dump it in the can, etc.), the garbage-disposal task will complete successfully, with no superfluous escorts or chaperones required for any of the steps.

There's rarely any need in these kingdoms to create wrapper nouns to swaddle the verbs. They don't have GarbageDisposalStrategy nouns, nor GarbageDisposalDestinationLocator nouns for finding your way to the garage, nor PostGarbageActionCallback nouns for putting you back on your couch. They just write the verbs to operate on the nouns lying around, and then have a master verb, take_out_garbage(), that springs the subtasks to action in just the right order._

</comment></comment></comment><comment><USER7> "I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work." - Alexander Stepanov.

<comment><USER9> The part about proofs and axioms is completely non-logical. for the past several centuries, proofs have relied on axioms. Euclid introduced axioms (postulates) in order to provide proofs (and precise formulations) for informal statements. So the math part is really more an argument in favor of classes as a sort of axiomitization of computing.

<comment><USER10> The majority of the proofs Euclid produced existed, both as theorem and proof, before his time. Similarly, few recent mathematical advances have started with formalizations and axioms. Calculus wasn't put on a rigorous basis until Lebesgue's time, hundreds of years after Newton and Leibniz. Category theory needed quite some work before it was formalizable. Differential geometry wasn't that rigorous until the twenties or so. Complex analysis was developed using many, many unnecessary assumptions because the formalities weren't there. I'm not picking-and-choosing math fields here; these are just the ones I'm familiar ones. It turns out, axiomatization and theory-building are two separate jobs rarely performed by the same mathematician. Usually, the theory- building makes the mathematician famous, and the axiomatization does not, but this is in many ways a tragedy. In any case, to the outsider of mathematics, it seems that axioms come first. This is false -- axioms come much later, because the work of axiomatizing isn't worth it before the theory proves itself useful. Axioms come first in a formal way, in the same way classes come first in a formal way. But the interesting thing isn't the class -- it's the instance. And in the same way, the axioms aren't interesting -- it's the resulting theories. I found the analogy very insightful.

</comment></comment></comment><comment><USER11> I notice no mentions of Ruby yet, and I wonder if this discussion is pretty much impossible to have in the Ruby world, given Ruby is _solely_ an object oriented language, even if you try to use it procedurally. Not writing classes would be against so many Ruby conventions and accepted style that it's a non- topic?

Or is it that classes in Python _specifically_ aren't that much of a win over the language's implementation of other paradigms? I sure haven't hit into any problems using classes or objects in Ruby, even when sometimes the use feels a little contrived to begin with, but.. I also have no choice :-) (maybe Rubyists have a Stockholm Syndrome with OO ;-))

<comment><USER12> I think part of the reason this doesn't come up in Ruby is that Ruby doesn't have Python's powerful namespacing system.

In Python, it's reasonable to have a package with just functions in it, whereas in Ruby, writing a top-level method means polluting every object in the system. You can write modules that have singleton methods on them, but you still don't have anything as flexible as Python's "from pkg import foo, bar"—the caller needs to either write "ModuleName.my_function" at every call site, or use "include" and end up with the module's methods as part of the consuming class's interface.

<comment><USER13> Implicit self and late binding in Ruby makes it hard to implement a proper namespacing system without breaking other semantics :(

After working with Perl (which has a similar namespacing), I must it's something I really miss when I come back to Ruby.

</comment></comment></comment><comment><USER14> One concern I have with Jack Diederich's video is that he never addressed one benefit of classes: better testability. In his Muffin example, he took out the instance variable that stored the API URL and created a constant out of it. If I had an URL for my staging environment, and another for my production environment, I'd like to programatically set that instead of going back into the code, modifying the constant value, run the test, and then change the value back to the original. That's just a bug waiting to happen.

This isn't to say his underlying message is wrong (I 100% agree with Jack's message, too much classes create unnecessary complexity in your library/app), but I don't want people destroying their classes without fully understanding the consequences.

<comment><USER15> You can create a variable, set that, and pass that variable as the first parameter to greeting. I don't see why having a class makes testing any easier.

<comment><USER16> Decoupling. For example if your code requires access to an outside resource (database, message queue, email service) you can mock said resource in order to test the code in isolation.

<comment><USER15> Down that road lies the hell of dependency injection frameworks. A simpler approach is to use something like detours[1] to mock bare functions directly.

[1] <https://research.microsoft.com/en-us/projects/detours/>

<comment><USER9> Google Guice is not hell.

</comment></comment></comment></comment></comment><comment><USER17> Disagree with "Decoupling" never used or "if used, they are pulling a fast one on you". It not only will help make his point of decreasing line-count, but more importantly, it is one of the main principles in achieving DRY-ness (both code-level and more importantly, architectural level DRY-ness). I'll even go further and say that if you're not thinking about it all the time, you're most likely doing it wrong.

<comment><USER18> I think he didn't mean that it's never used, just that it's never actually said in the real world.

My experience confirms this.

<comment><USER17> Yup, my bad, he actually said "people never say". But the way he presented it, seemed like he's opposed of it. But I still think it should be mentioned more in the industry so more developers are aware of it and think about it more often than not.

EDIT: Can't reply to Tommabeeng's comment (probably too deep). Yup, and I agree with the presenter's main point - that classes are not necessary in many situations, even for decoupling.

<comment><USER19> He does say about coupling & cohesion that "if used, they are pulling a fast one on you".

That's wrong. I like the key to his talk but the plague of large complicated systems is exactly coupling and incoherence. Classes are NOT necessarily the way to achieve these.

<comment><USER20> As others have implied already, he could just as easily have been referring to the words.

I think his intention was to explain that these are the same words (mostly from academia and taken up with reckless abandon via language architectures like Java) that may be thrown around by some to create the code mess (anti- pythonic) in the first place.

</comment></comment></comment></comment></comment><comment><USER21> Over-engineered code is frustrating to read and work with. If your project doesn't require classes then it's fine to not create a bunch of complexity with OO style and design patterns. But if you just dismiss the techniques because they're difficult or you don't want to spend time learning, then you're likely to re-invent the wheel over and over.

<comment><USER22> That's not what the video was about at all. The speaker never implied to use an approach that would lead to reinvent the wheel over and over ... quite the contrary in fact.

<comment><USER21> Well, his message I think is easily translated into "classes suck - never use them" by those who may choose read into it that way. He also dismisses a few rather basic design patters as basically jokes (literally with laughs from the audience as if these ideas are idiotic rather than foundations of software design) without making the distinction that these concepts are actually really important.

It's easy for people who are very smart and experienced to dismiss the rules - that applies for all things, not just programming. But if you never learn the basics then you'll stumble over silly things that have be solved by much smarter people.

<comment><USER22> Standard design patterns are important ... if you program in Java and similar languages. But many of these are completely unnecessary when using a dynamic language like Python - and many others.

<comment><USER21> To me it's just simply a way to organize code, there's nothing inherently good or bad about classes. You can use or abuse them like anything else. It never hurts to know the basic GoF patterns and when to use them to simplify your code or solve a common problem. You can use them with or without classes. Most Javascript libraries that I look at today use closures, prototypes and anonymous objects that might as well be classes. Patterns seem to be making a huge appearance in client-side code in the last year. I'll admit that I don't know anything about Python, though.

</comment></comment></comment></comment></comment><comment><USER23> I dislike classes but I like bundling data along with methods which operate on that data. I often find that JavaScript's classless objects are a great solution. It's just so natural to be able to create an object with object literal syntax without first creating an ad hoc class and then instantiating it:

      var o = {
          name: 'David',
          greet: function () {
              console.log('Hi, I am ' + this.name);
          }
      };

<comment><USER24> > bundling data along with methods which operate on that data

What can you possibly believe a class is other than exactly that?

<comment><USER23> I realize that is one thing that classes offer. My point is that you can achieve exactly the same thing with objects rather than classes.

Very often when writing Python (or whatever) you'll create a class which is only ever instantiated once and the instantiation is done simply for the benefit of calling one method.

In such cases I find classes to be overkill. What I really want is the object. I don't need to factor the object's behavior out into a class.

Many of my sympathies are expressed much more thoroughly and eloquently in the many papers you can find online by Walter Smith outlining the motivations behind NewtonScript.

</comment></comment></comment><comment><USER4> It may interest people to know that Alan Kay has said that they got granularity wrong with classes. Functions are a good granularity, and so are systems, but classes don't work. To get true encapsulation as he originally envisioned it, you need to think in terms of interoperating systems. The example he gave of getting it right is the internet (but not the web). This was all from Kay's talk last year in Germany.

<comment><USER25> Do you have a source (video, transcript) to that talk of Alan Kay in Germany?

<comment><USER26> I believe he is referring to this talk: <http://tele- task.de/archive/video/flash/14029/>

<comment><USER4> Yes thanks - and if anyone watches it, be sure also to check out the stuff on Bob Barton. I learned about a magnificent part of computing history thanks to that talk.

Edit: here you go:

<http://news.ycombinator.com/item?id=2855500>

<http://news.ycombinator.com/item?id=2928672>

<http://news.ycombinator.com/item?id=2856567>

<http://news.ycombinator.com/item?id=2855508>

The first two are teaser comments. The second two are the important pieces. Also the paper Kay praises at the start of the talk is short and very worth reading.

</comment></comment></comment></comment><comment><USER27> I think he missed one of my favorite uses of classes: a collection of implementations of defined methods, especially if you can't pass around function pointers. For example, you're working with a Reader and the Reader is something that needs to be able to read( _) and flush(_ ) and open( _) and close(_ ). You use that Reader everywhere with those abilities. You don't care how they work, you just need for it to be able to do those four things. If you're expecting different Readers, it's useful to have a Reader interface and then classes that implement it.

Unfortunately, this is the only way to perform this activity in Java. Also, I adore Go's style of pseudo-OO programming.

.. or, from reading the HN threads, is that decoupling?

If so, I'm using decoupling right now!

<comment><USER28> I think he addressed that (or a very similar circumstance) while talking about the stdlib heap, and again in response to the question on "bag of related functions." I don't think he'd take issue with your position.

Alternatively, if you are working with things that you expect to follow a certain interface, Python does not really require a formal definition. Duck typing should suffice.

</comment></comment><comment><USER29> I'm not much of a python programmer, but in Java I use classes all the time. The main reason is that small classes make writing unit tests easy. I can use a mocking library like <http://www.easymock.org/> to mock out whatever dependencies the code I'm trying to test depends on.

I agree on some of the presenters philosophical ideas, mainly that adding complexities into the codebase before they're needed is almost always a terrible idea, but saying that classes lead to complex code is simply not true, at least in my experience.

<comment><USER22> Of course you use classes all the time in Java: it forces you to do so by design. I have significantly more experience with Python than with Java and I find that writing unit tests on functions is as easy if not easier than writing tests for (small) classes. And Diederich's point about small classes being a code smell (my words - not his) is hard to refute.

</comment></comment><comment><USER30> As an 'end-user' of Python, I rarely find myself writing my own classes, but I am really pleased that the authors of many of the libraries that I use decided to write classes.

I think the distinction between 'end-users' and people who make libraries is an important one and one that Jack seemed to overlook.

</comment><comment><USER31> What surprises me is that no-one mentioned inheritance when speaking about classes. I am not a fan of classes and I prefer the functional approach, whenever possible. In my experience, I found that classes make sense as part of a hierarchy, that is, when subclassed to override/specialize methods or to describe interfaces, like type-classes in Haskell.

</comment><comment><USER32> Look, there is nothing _wrong_ with classes and OO in general. What is _wrong_ is using OO when it is unnecessary and only adds layers of complexity.

<comment><USER4> _What is wrong is using OO when it is unnecessary_

That's a platitude which everybody can and does say about everything.

But I think one can make a case that there _is_ something wrong with OO in general. The original arguments for OO were: it's better for managing complexity, and it creates programs that are easier to change. Both of these turned out not to be true in general. So we need to ask, when _is_ OO a win? But for simpler problems it doesn't matter, because anything would work. So we need to ask: what are the hard problems that OO makes significantly easier? I don't think anyone has answered that.

I suspect it's that OO is good when the problem involves some well-defined system that exists objectively outside the program - for example, a physical system. One can look at that outside thing and ask, "what are its components?" and represent each with a class. The objective reality takes care of the hardest part of OO, which is knowing what the classes should be. (Whereas most of the time that just takes our first hard problem - what should the system do? - and makes it even harder.) As you make mistakes and have to change your classes, you can interrogate the outside system to find out what the mistakes are, and the new classes are likely to be refinements of the old ones rather than wholly incompatible.

This answer boils down to saying that OO's sweet spot is right where it originated: simulation. But that's something of a niche, not the general- purpose complexity-tackling paradigm it was sold as. (There's an interview on Youtube of Steve Jobs in 1995 or so saying that OO means programmers can build software out of pre-existing components and that this makes for _at least one_ order of magnitude more productivity - that "at least" being a marvelous Jobsian touch.)

The reason OO endures as a general-purpose paradigm is inertia. Several generations of programmers have been taught it as _the_ way to program -- which it is not, except that thinking makes it so. How did it get to become so standard? Story of the software industry to date: software is hard, so we come up with a theory of how we would like it to work, do that, and filter out the conflicting evidence.

<comment><USER33> > The original arguments for OO were: it's better for managing complexity, and > it creates programs that are easier to change. Both of these turned out not > to be true in general.

Wrong. Even the worst Enterprisey mess of Java classes and interfaces that you can find today, is probably better than most of the spaghetti, global state ridden, wild west that existed in the golden days of "procedural" programming.

If you consider that software is composed of Code and Data, then OOP was the first programming model that offered a solid, practical and efficient approach to the organization of data, code and the relationship between the two. That resulted in programs that, given their size and amount of features, were generally easier to understand and change.

That doesn't mean OOP was perfect, or that it couldn't be misused; it was never a silver bullet. With the last generation of software developers trained from the ground up with at least some idea that code and data and need to be organized and structured properly, it's time to leave many of the practices and patterns of "pure" OOP and evolve into something better. In particular, Functional has finally become practical in the mainstream, with most languages offering efficient methods for developing with functional patterns.

<comment><USER4> You believe this, but you've given no reason to believe it other than the dogma you favor. The old-fashioned procedural systems I've seen with global state and the like were actually easier to understand than the convoluted object systems with which they were often replaced. Your comment is exactly the kind of thing that people who are enthralled with a paradigm say. But the "worst Enterprisey mess of Java" that you blithely invoke is... really bad, actually, as bad as anything out there. You're assuming that paradigm shifts constitute progress. I offer an alternate explanation for why paradigms may shift: because the new generation wants to feel smarter than the old one.

<comment><USER34> OO enterprisey mess is strictly better than global state ridden spaghetti code. The hard part with enterprisey code is that the code performing the action is hidden under layers of abstraction. The bootstrapping cost is much higher here because you have to put more abstractions in your head before you can understand a particular bit of functionality. This is a different sort of complexity than the global state spaghetti.

With the global state code you have to understand the entire codebase to be sure who exactly is modifying a particular bit of state. This is far more fragile because the "interaction space" of a bit of code is much greater. The dangerous part is that while you must understand the whole codebase, the code itself doesn't enforce this. You're free to cowboy-edit a particular function and feel smug that this was much easier than the enterprisey code. But you can't be sure you didn't introduce a subtle bug in doing so.

The enterprisey code is better because it forces you to understand exactly what you need to before you can modify the program. Plus the layered abstractions provide strong type safety to help against introducing bugs. Enterprisey code has its flaws, but I think its a flaw of organization of the code rather than the abstractions themselves. It should be clear how to get to the code that is actually performing the action. The language itself or the IDE should provide a mechanism for this. Barring that you need strong conventions in your project to make implementations clear from the naming scheme.

<comment><USER4> This sounds like ideology to me. You can _never_ be sure you didn't introduce a subtle bug, you can never _force_ someone to understand what they need to, and interactions between objects can be _just_ as hard to understand as any other interactions.

I agree that a project needs strong conventions, consistently practiced. See Eric Evans on ubiquitous language for the logical extension of that thinking. But this is as true of OO as anywhere else.

<comment><USER34> First off, apologies for seemingly badgering you in various threads in this post. I don't usually look at usernames when replying so it was completely by accident.

>interactions between objects can be just as hard to understand as any other interactions.

While this is true, there are strictly fewer possible interactions compared to the same functionality written only using primitives. To put it simply, one must understand all code that has a bit of data in its scope to fully understand how that bit of data changes. The smaller the scopes your program operates in, the smaller the "interaction space", and the easier it is to reason about. Class hierarchies do add complexity, but its usually well contained. It adds to the startup cost of comprehending a codebase which is why people tend to hate it.

<comment><USER4> That's hilarious. Well, you're welcome to "badger" (i.e., discuss) anytime. It's I who should apologize for producing every other damn comment in this thread.

In my experience, classes don't give the kind of scope protection you're talking about. They pretend to, but then you end up having to understand them anyway. True scope protection exists as (1) local variables inside functions, and (2) API calls between truly independent systems. (If the systems aren't truly independent, but just pretending to be, then you need to understand them anyway.)

<comment><USER34> You're right that the scope protection I'm talking about isn't as clear cut when it comes to classes. Design by contract is an attempt to address this. Client code can _only_ refer to another object through a well-defined interface. Thus your limited scope is enforced by the type system itself. Furthermore, much of this discussion is about _perception_ of complexity rather than actual complexity.

In python you can access any classes internals if you're persistent enough. However, the difficulty in doing so and the convention that says that's bad practice gives the perception of a separation, thus one does not need to be concerned about its implementation. It lowers the cognitive burden in using a piece of functionality.

Haven't you noticed this yourself? A simpler interface is much easier to use than a more complicated one. If you're familiar with python, perhaps you've used the library called requests, its a pythonic API for http reqeusts. Compare this to the core library API using urllib2. The mental load to perform the same action is about an order of magnitude smaller with requests than urllib2, and its because there are far more moving parts with the latter.

My contention is that if bits of data and code are exposed to you, it is essentially a part of the API, even if you never actually use it. You still must comprehend it on some level to ensure you're using data it can access correctly, aka interaction space (I feel like I'm selling a book here).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> Defining abstract datatypes and legal operations on those datatypes is useful whether you do it with objects or Haskell type classes or C++ generics. It's easy to go overboard with objects but explicit interface definitions are a lot easier to reason about then big grab bags of functions.

</comment><comment><USER36> Wish someone asked his opinion on "singletons". I've been fan of them in the past, and now I totally despise them... But then it came to me, that I don't despise the semantics of he singleton - I just write that as a bunch of functions, rather than class with methods that is "singleton-ized".

There were also some revelations - like printer().getSingleton() (or instead of printer, put keyboard, mouse, memory, etc.) - at some point some of these "singletons" might be become "multi-tons" - for example gamepad().getSingleton() already is a trouble...

<comment><USER37> The best "singleton" for me is python module. Import is the constructor of singleton. Python itself controls single initialization of object.

</comment></comment><comment><USER38> Some arguments from this guy are:

1) Do not use a class if it doesnt have state

Agreed

2) Keep it simple and do not think about the future, fix it later if needed

He probably never wrote API code in libraries needed for other people. Once you choose something you are bound to it. In this case classes and interfaces are very helpfull. For example the API class example in the beginning (no state) is a good example. In the future the api might be extended with more functionality. The last thing you want is have 3rd parties rewrite their code cause you changed the API. So a class is good to provide a Facade (yes Facade Pattern).

3) package names are not for taxonomy but for preventing nameclashes

True. However in Java the editor is so powerfull that you never ever have to lookup package names. This goes automatically (IDE parses the code on the fly). Java package names also use URI patterns like: com.google.android.hardware.vibrator. Which can only be used by somebody who has the google.com domain name. This prevents name clashes ALL the time. In python you sometimes have to rename a whole project. And the taxonomy gives you an indication what the code actually does.

4) Dont overuse exceptions and keep shorts names.

Agreed. However i am not sure what the best granularity is. In a public Library API, i would be very carefull about this.

Otherwise I agree with him.

</comment><comment><USER39> This discussion would be much more constructive if we have an actual problem to code a solution for... then we could see the merits of each approach...

</comment><comment><USER24> Stop writing class __hierarchies __.

Classes are fine. Over-engineering classes, like over-engineering anything is bad, m'kay?

</comment><comment><USER40> For awhile I did not really know how to take this whole thing. Upon reflecting, I realise I probably do lean away from Classes in general... it was strange to come upon that realisation, as I come from a strong Java/OOP background.

The benefits of Classes are still related to data abstraction. But it is pointless if you are still accessing the data directly anyway (getters and setters be damned). So, I would only legitimately prescribe a class only when you are building a data structure.

Nowadays, my classes are either \- composition of primitive data (as I don't have tuples(python)/structs or dynamic objects (javascript)) \- or function groups (like a business logic layer of some sort, which could have just as easily have been just bags of functions in modules).

I'm going to be teaching my students Classes in a couple of weeks... food for thought before then.

</comment><comment><USER41> I don't understand. I started to program computers when I was 12. I used BASIC. And now they have conferences because they don't know how to write data structures and subroutines? No wonder software gets bloated...

<comment><USER41> And just last week I read about a post where some guys were amazed that one coud write loops without for {;;} while {} or do { } while

Facepalm.

</comment></comment><comment><USER42> One thing that I still wonder about is, in cases where I need for some object to hold some state, whether it is better to use a class or a closure. Both approaches are similar in many ways but still subtly different. Is there a good rule of thumb, kind of like the one for classes vs tagged unions? (classes let you add new classes but don't like if you add a new method, tagged unions let you add new methods but make it hard to add a new type).

</comment><comment><USER43> I think most of the comments here are taking it too far. Not using classes in some cases is not equivalent to stopping using classes altogether. Classes are yet another tool in the programmer's toolbox. Sometimes the tool makes sense, sometimes it doesn't. The trick is to know when. But jumping to absolutes is surely not the right way to go about it.

</comment><comment><USER44> I agree with most of this issues, but it sounds like his editor doesn't have auto import and jump to definition like Eclipse.

eg complaint about nested packages. (not that I agree that this is a necessary class): instead of MuffinMail.MuffinHash.MuffinHash, type MuffinHash and have your editor add: from MuffinMail.MuffinHash import MuffinHash.

<comment><USER45> Tools to reduce the burden of tautology are workarounds. You can rely on tools to make the worst design/language less painful, but it's not an argument against avoiding tautology.

</comment></comment><comment><USER46> "Stop writing classes... "

No

Ooooh, you wanted to make a case for not using classes in certain situations? Then enough with the linkbait title.

</comment><comment><USER47> The best use of Python Classes is as a stand-in for Javascript-style object syntax, ala:

      class foo:
        pass

      f = foo()
        f.bar = "yes"

which is easier to type and more readable than:

      f = {}
        f['bar'] = "yes"

(credit where due: learned this trick from TB)

<comment><USER48> You can simplify it a bit by building the container class on the fly, if desired.

      >>> x = type('Foo', (object,), {})
      >>> x.bar = 1
      >>> x.bar
      1

</comment></comment><comment><USER49> OOP obfuscate our programs by blurring the frontier between data and treatment. I can't agree more, since I made the mistake quite a few times myself.

</comment><comment><USER50> I wish they told me that when I took inline lessons on class-class.org</comment>


Max Headroom broadcast signal intrusion - <AUTHOR> https://en.wikipedia.org/wiki/Max_Headroom_broadcast_signal_intrusion <comment><USER3> If you have never seen the original 1985 British film that introduced "Max Headroom: 20 minutes into the future", you are in for a serious treat. It is so much better than I ever expected -- and it's only 55 min long. More relevant than ever:

[https://youtu.be/aZY-yQYVf38](https://youtu.be/aZY-yQYVf38)

<comment><USER4> Could you summarize the way in which it is "relevant" (and to what)?

<comment><USER5> Dystopian media influenced oppressive states, a nation placated with purile entertainment, an underground of those who 'really know' what is going on fighting to restore humanity, watched over by a slightly crazed AI ...

</comment></comment></comment><comment><USER6> Always a favorite whenever it shows up here. It's like you know this person was breaking the law but no one was really hurt and it goes unsolved still. It's a great mystery story of someone messing with a system no one really messes with.

<comment><USER7> It's a great go-to in the unsolved mystery community when people look for a fun light-hearted mystery.

</comment></comment><comment><USER8> It's amazing that the identity of the signal pirate has never been leaked. Doubly so since there were at least two people involved. Surely the statute of limitations has passed. Perhaps everyone involved passed away before they ever felt comfortable going public with their story.

<comment><USER9> Long ago I read a (4chan I think?) post from someone claiming that it was very possible he knew the people who did this hack.

He said he wasn't 100% sure, but that there were strong reasons to believe so.

He explained that he used to hang out with 2 brothers, one of which had some mental issues, perhaps autism or something similar, that acted strange at times, and that seemed to have skills with radios and other tech. He also remembers that a girl which is very briefly shown in the hacked video stream looked like the girlfriend of the other brother.

Also recalled that the voices in the stream sounded familiar and I think he even mentions remembering that they had a sheet of metal similar to the one in the video, and that his theory was that the brother with autism was the one with the mask, while the other one rotated the sheet of corrugated metal, while the girlfriend was recording them.

Anyway, I don't remember the exact details and of course I'm not saying the story is true or anything...

But it did have some interesting air of mistery even if it were false. The poster didn't seem like he was trying to lie to anyone, just that he genuinely thought he kew the people responsible for the hack.

And then the story he was telling suddenly portrayed a very cool and odd piece of tech "history", if it were true.

To me, this always sounded a little bit like real-life cyberpunk stuff and every time I remember about Max Headroom I'm reminded of the hack and the story I read by random chance, on a random forum like 4chan, thinking, what if it was real and I was just reading there a post written by someone that knew the Max Headroom hacker...? I wish very hard for that to be real.

Well... I'm rambling here, but I guess that's the magical internet a lot of us feel drawn too?

<comment><USER10> Maybe Reddit?

[https://www.reddit.com/r/IAmA/comments/eeb6e/i_believe_i_kno...](https://www.reddit.com/r/IAmA/comments/eeb6e/i_believe_i_know_who_was_behind_the_max_headroom/)

[https://www.reddit.com/r/UnsolvedMysteries/comments/3oaxi5/n...](https://www.reddit.com/r/UnsolvedMysteries/comments/3oaxi5/new_developments_in_the_max_headroom_incident/)

</comment></comment></comment><comment><USER11> To give a context to the younger readers, first, what of who Max Headroom was:

[https://en.wikipedia.org/wiki/Max_Headroom_(character)](https://en.wikipedia.org/wiki/Max_Headroom_\(character\))

The original was _not_ done with computers:

"the computer-generated appearance was achieved with prosthetic make-up and hand-drawn backgrounds. Preparing the look for filming involved a four-and-a- half-hour session in make-up, which Frewer described as "gruelling" and "not fun""

But it looked like magic at that time.

Also:

[https://www.vice.com/en_us/article/pgay3n/headroom- hacker](https://www.vice.com/en_us/article/pgay3n/headroom-hacker)

<comment><USER12> One of my favourite shows growing up. Hard to believe it was all done 'analog' and no CGI. Adds rawness and charm to the whole thing - Kind of like 'Thunderbirds'.

</comment></comment><comment><USER13> Related from 2018: [https://news.ycombinator.com/item?id=16816663](https://news.ycombinator.com/item?id=16816663)

2015: [https://news.ycombinator.com/item?id=9845038](https://news.ycombinator.com/item?id=9845038)

</comment><comment><USER14> Is there any knowledge of the mechanism used to hijack the signal, or what WGN/WTTW did to protect against it afterwards?

The Wikipedia article seems to indicate even the engineers never figured it out.

<comment><USER15> I lot of broadcast operations have a frequency that isn't in the broadcast band that they use to send their signal to a remote tower. Presumably if you point a stronger transmission at the receiver you can become the dominant signal. Or at least that's what I always thought. I would think you would have needed some inside information or otherwise have worked in the industry at the time to really pull this off? Maybe not, though.

<comment><USER16> Every microwave uplink frequency is listed on the the FCC's ULS site:

[https://www.fcc.gov/wireless/systems-utilities/universal- lic...](https://www.fcc.gov/wireless/systems-utilities/universal-licensing- system)

Usually the uplinks are in the 10+ GHz band, and the antenna (usually looks like a big bass drum on the tower, [http://www.steeltowerchn.com/wp- content/uploads/2018/06/Micr...](http://www.steeltowerchn.com/wp- content/uploads/2018/06/Microwave-Antenna-Radio-Tower-GSM-Tower-800x480.jpg)) is pointed towards the station's studios.

So hijacking it would not be trivial. You need to be in the line of site and be able to produce enough power to overwhelm the real signal, which isn't trivial at those frequencies. There's also probably something similar to ATIS to stop unauthorized transmissions.

Here's KIRO uplink from their studio to a tower atop Queen Anne Hill in Seattle. The exact location of the transmitter and receiver are in the locations tab.

[https://wireless2.fcc.gov/UlsApp/UlsSearch/license.jsp?licKe...](https://wireless2.fcc.gov/UlsApp/UlsSearch/license.jsp?licKey=959133)

<comment><USER17> What about 10GHz+ is important to uplink transmission? Better directionality? Harder to spoof?

<comment><USER18> Smaller antennaes needed for the same gain as lower frequencies.

Terrible ability to go through, say, a concrete wall, but that's an issue for broadcast, not point-to-point. Possibly an advantage by reducing noise from other 10ghz signals (maybe harmonics from a bad microwave oven?).

They also have narrower fresnel zones than lower frequencies, so it's easier to hit your target without having to be too high at both sides.

And the usual tradeoffs: Spectrum is available and you want equipment that's cheap and reliable, but not too cheap either.

<comment><USER17> Thanks for the info.

</comment></comment></comment></comment></comment></comment><comment><USER19> Max Headroom is now more relevant than ever. If you haven't watched the TV series, stop what you're doing and get the binge over with.

The dystopian future predicted in this series is well and truly upon us - <USER2> case of fiction predicting future truths.

We need Max Headroom to guide us out of the disaster of the modern Internet. Alas, we have Zuckerberg instead ..

<comment><USER20> I too keep telling people to watch it.

We are close to accidentally creating an attention-democracy where whoever is able to keep the attention of the masses has the most influence over politics. It could be argued that whoever is able to get the most attention is also the most in tune with what people want. Since centralized filtering of news is an important part of the political meta-game of building opinion, perhaps it is not wrong to formalize this process. Enter Max Headroom.

<comment><USER21> I don't think that this new and it arguably predates democracy. Being able to keep the attention of the masses influencing policy has generally been called 'leadership' \- even if they are frankly idiots who lead them straight off cliffs. It is another one of those annoyingly conflated words like 'empathy' assuming that understanding people and caring about them are the same - leadership has connotations of actually being effective and getting others to follow.

<comment><USER20> True. Follow-the-leader is easy and democracy isn't. Especially when idiots are all too willing to jump off cliffs instead of acting with the responsibility that democracy places upon us. Perhaps there exists forms of democracy which steer us away from the obvious precipice.

</comment></comment></comment></comment><comment><USER22> I've always been surprised some inspired performance artist hasn't done this to the live sound feed at a big music festival like Bonnaroo or Coachella yet. Audio runs from the stage/band to a sound guy in the middle of the field who controls the mix then from there it goes back across the field to the PA system mounted on stage. The audio cables are literally just big snakes that run right through the crowd where anyone could access them. Highjack a post mixer cable and bob's your uncle.

The only hitch would be that afaik at festivals the pa arrays are passive so you'd need to steal power too so you can power an amplifier and send a powered signal, but if you managed that it'd be even worse than the tv broadcast intrusion because there's no easy way to shut it off, the sound guy has no control because you're after him in the signal chain and nobody onstage is set up to handle something like that. It's not like beyonce is gonna climb the scaffolding and start unplugging speakers when the crab rave starts playing inexplicably.

<comment><USER23> I'm actually surprised this doesn't happen with wireless microphones more often. While the industry is slowly moving towards digital transmitters, many broadway shows still use old body pack analog transmitters on their actors. Since these shows are stationary they are likely using the same frequencies for each transmitter every night.

I can't imagine it would be too hard to figure out some of these frequencies and transmit over them into the PA. There is a pilot tone but I don't think it'd be difficult to spoof.

I used to work in a shop that rented out audio equipment to broadway shows.

<comment><USER24> Not quite the same thing, but James Randi famously debunked a "faith healer" by listening into to their analogue earpiece: [https://www.youtube.com/watch?v=q7BQKu0YP8Y](https://www.youtube.com/watch?v=q7BQKu0YP8Y)

Maybe more on-topic, an early demonstration of long-distance radio was hijacked: [https://www.youtube.com/watch?v=sP2qqMegNKA](https://www.youtube.com/watch?v=sP2qqMegNKA)

</comment></comment></comment><comment><USER25> I have always felt a personal annoyance about this, as it interrupted an episode of "Horror of Fang Rock" \- one of my favorite Doctor Who stories.

</comment><comment><USER26> It was the KLF

</comment><comment><USER27> Maybe one day people will stop posting about this inane nonsense.</comment>


How Usain Bolt compares to runners from other countries - <AUTHOR> http://www.hindustantimes.com/static/olympics/every-country-fastest-man-in-one-race-100m/ <comment> et-al At least it's more visually engaging than the _Tages-Anzeiger_ 's visualization discussed here: [https://news.ycombinator.com/item?id=12310032](https://news.ycombinator.com/item?id=12310032)

However, I do wish they could've shown actual acceleration and speeds as opposed to the easily calculated average speed. Wake me up when someone makes the effort to find all the historic footage and overlays it on top of one another.</comment>