Ping Pong Is Killing Your Company Culture - <AUTHOR> https://medium.com/huma-stories/ping-pong-is-killing-your-company-culture-d3b46bdbf702 <comment><USER2> "Many companies, especially rapidly growing startups, make the somewhat false assumption that cultural wins come from superficial perks. Games rooms, zen gardens and branded loot (from skateboards to iPads) are all dangled enticingly at candidates, subconsciously suggesting 'We're a fun place to work'."

This isn't really a false assumption. For potential employees just coming out of college, it's a great perk.

For people that have been in the industry for 10 years, not so much.

I generally just want more vacation time or better pay.

</comment><comment><USER3> Clickbait title. Have you even bothered playing ping-pong casually? It has multiple benefits:

1) Physical activity. Sure standing desks are the rage right now, but actual movement is better.

2) People actually hold conversations while playing ping-pong. One of our VPs would be talking to another one about investment strategies while they played each other.

3) It's a good way to meet new people in your office. You see someone from another department play, ask to join, then meet someone new and bond over a shared interest.

So in HR vernacular, ping-pong has the potential to form organic relationships. Instead of company volunteer days on weekends where half the people would rather be at home with their friends or families.

</comment><comment><USER4> This article isn't even about ping pong. Furthermore, I love ping pong and think it's a great addition to any office. I look forward to playing my daily game of ping pong at the office and it makes the day way better!

</comment><comment><USER5> The entire article seems to suggest that 'Millennials' are different and their needs require a different culture...

... ageism is obviously strong.

<comment><USER3> This author's other articles are also about the every mysterious millennials. Pandering to the clueless.</comment></comment>


AI that makes Angular/React/Bootstrap Apps? - <AUTHOR> http://www.dhi.io/

<comment><USER2> Well that seems so futuristic to me.

BTW, what happened to grid? [1] They were claiming the similar idea but not js side I suppose.

[1] [https://thegrid.io/](https://thegrid.io/)

<comment><USER3> Glad to hear that you think its futuristic :). There are probably two main differences between thegrid and dhi. Dhi can help with JS also - along with HTML and CSS. Thegrid atleast appears to be mostly focused on design (HTML & CSS ) from their copy. Second important difference is that - with thegrid - the AI does the design or layout. With Dhi - you do the design.

Giving YOU, the developer - full control is extremely important to us.

</comment></comment><comment><USER4> It sounds promising, we are always impressed with some of the startups who have a vision of disrupting the software world. Definitely something to watch out for.

</comment><comment><USER3> The AI does not automatically make these apps. Its an assistant - that helps you make. You are still the driver/puppeteer.

</comment><comment><USER5> greaaaat

</comment><comment><USER6> Followed up with an AI that fixes (some of the time) Angular/React/Bootstrap apps made by the first AI.</comment>


Show HN: Tabli – A Tab Manager for Google Chrome - <AUTHOR> http://antonycourtney.github.io/tabli/ <comment><USER2> Very cool... I've been using TabsOutliner which has been a joy for me, but I like some of the UI refinements it looks like you have.

I've always wanted to do this same thing but include other applications / files and be able to easily pop in or out of a session or project.

<comment><USER3> I'm currently working on something like what you mention on your second line (something like a project manager for the OS), after creating a terminal project manager [0] (shameless plug).

I'll probably have a prototype/alpha-relase (OS X only, for now) within a few weeks.

As for Tabli, it looks pretty useful!

[0]: [https://github.com/eivind88/prm](https://github.com/eivind88/prm)

</comment></comment><comment><USER4> I haven't used an extension itself, but the code is very pleasant to look at, clean and functional (which is not surprising given your Haskell background). Is this your first attempt at using React? How hard would it be to port it to Safari?

<comment><AUTHOR> Thanks! This was not my first project with React, but it was a playground for me to experiment with some novel React ideas (like css-in-js) and different ways of structuring the application. After some frustrating attempts to organize Tabli using Flux I ended up abandoning Flux and creating my own alternative micro-framework called OneRef, a sort of Redux-lite for use with the wonderful Immutable.js library for maintaining application state. I have a draft Medium post about this that I hope to publish one of these days...

</comment></comment><comment><USER5> This is amazing, thank you. For those of you who didn't read the Usage guide: "Use the keyboard shortcut (Ctrl-. by default). It's worth memorizing this."

btw, I'm not sure why but Tabli isn't searchable on the Chrome store for me.

<comment><AUTHOR> Thanks, glad you like it. Tabli wasn't searchable in the Chrome store for the rather silly reason that I hadn't gotten around to making promotional tiles. I just made some mediocre ones for now and made it public / searchable; I can improve the tiles later :-)

</comment></comment><comment><USER6> I really like this after playing with it for a short bit here.

Question though, the "Other Windows", that's on my current machine right? Can I not see windows open on another machine like in the History tab?

<comment><AUTHOR> Glad you like it. You're correct, Tabli is only intended to help you manage windows and tabs within the current browser session on your current machine. Saved Windows ([http://antonycourtney.github.io/tabli/tabli- usage.html#save-...](http://antonycourtney.github.io/tabli/tabli- usage.html#save-windows)) are stored as bookmark folders so will sync as normal bookmarks and show up when you start Chrome on a different machine. (Currently saved windows are only loaded when Tabli initializes, but that's fixable.) I don't use Chrome on multiple machines _simultaneously_ so hadn't really considered this use case. Thanks for bringing to my attention, will give it some thought.

<comment><USER3> As someone that almost never closes applications or powers down his computers, I'd also like to see this!

EDIT: Great job, nevertheless!

</comment></comment></comment><comment><USER7> Long time user of TooManyTabs. This is better. I figured there'd be a keyboard shortcut, since this was posted on HN after all, and thank goodness.

Cheers.

</comment><comment><USER8> This is great!

I often end up with close to 100 tabs open, so I'm super happy about this!

However, I spent a second thinking about: how do I get to this point? And the answer is I click on a pile of links and plan to get to them later. It might actually be better if I had a way to easily just turn the links into some form of bookmarks without holding open a tab for them.

<comment><AUTHOR> There's another extension that does something like what you propose called one-tab: [http://www.one-tab.com/](http://www.one-tab.com/) Those that use One Tab seem to love it, and if it fits the way you want to work...great! One concern with what you propose is: Doesn't this just end up moving the problem from having a disorganized pile of tabs to having a disorganized pile of bookmarks? For my style of working, I find I have certain anchor pages for a topic or project that I refer to regularly. Although I also open many tabs, I wanted an easy way to discard these ephemeral tabs but get back to my base state of anchor tabs. The "Revert" functionality in saved windows helps with this: [http://antonycourtney.github.io/tabli/tabli- usage.html#rever...](http://antonycourtney.github.io/tabli/tabli- usage.html#revert-windows)

<comment><USER8> It does convert the problem from a giant mess of tabs to a giant mess of bookmarks, but at least bookmarks don't use much CPU/RAM.

I was thinking of installing The Great Suspender, but not all my tabs are ephemeral, but I guess it has a way to configure domains it shouldn't suspend, so I might try that together with your extension.

</comment></comment></comment><comment><USER9> I really really like this too.

I was thinking of building something similar because I regularly have >200 tabs open.

This looks like it does everything I wanted, and then some. Nice!

</comment><comment><USER10> Very nice.

Shameless plug on a lightweight (~50 lines of code) Chrome extension I wrote called Tab Extract to attack the too-many-tabs-open problem from another angle:

[https://chrome.google.com/webstore/detail/tab- extract/iphchn...](https://chrome.google.com/webstore/detail/tab- extract/iphchnegaodmijmkdlbhbanjhfphhikp)

<comment><USER11> Hey, this is brilliant!

The ability to reorganize/move tabs between windows helps a lot. I use SessionBuddy and VerticalTabs, plus Alfred's "tabs" search command, but none allow moving tabs to other/new windows.

Tabli has a very nice UI, works well and the code is top notch but no reordering/moving tabs unfortunately.

Another useful extension that doesn't work in recent Chrome versions is TabSplit and so far I haven't found an alternative.([https://chrome.google.com/webstore/detail/tab- split/imjbfepo...](https://chrome.google.com/webstore/detail/tab- split/imjbfeponcaggdpmoiadjbafihlojbco))

</comment></comment><comment><USER12> I _LOVE_ this. As a developper, I have thousands of tabs open at all time and Chrome manage them very poorly.

Thanks a lot for this chrome app.

</comment><comment><USER13> If, like me, you suffer from hypertabitis this may just be a solution for you!

</comment><comment><USER14> Was looking for something like this for quite some time. Great software

</comment><comment><USER15> if your Chrome tabs look like this: [http://imgur.com/3Z5GimX](http://imgur.com/3Z5GimX) then you need to use Tabli!

</comment><comment><USER16> OneTab is still the best. It's fun to just push a whole days worth of tabs into a list that you can cherry pick from at will. Not to mention freeing up resources..</comment>


Show HN: Csvlint.go, command line tool for validating CSV files against RFC 4180 - <AUTHOR> https://github.com/Clever/csvlint

<comment><USER2> Cool that you can download this as a standalone binary for OSX/linux/windows! Nice work

</comment><comment><USER3> Sometimes we work with really large CSV, anyway to make it bail on first error?

<comment><AUTHOR> I haven't done any performance testing on large data sets yet, but in general I've been super happy with the Go's CSV library, both in terms of performance and ease-of-use.

If the speed ends up being a problem, it should be pretty easy to add a "\--bail" flag or something.

<comment><USER3> In your experience is it CPU bound or disk? Maybe you can split files and use go routines etc?</comment></comment></comment>


Windows Phone, Latin America's second most widely used mobile platform - <AUTHOR> http://www.microsoft.com/en-us/news/Press/2013/Aug13/08-21WPLATAMPR.aspx

<comment><AUTHOR> I think the most interesting thing about this development is that in Latin America app developers have a much stronger motivation to build apps for Windows Phone. As a Windows Phone owner I think that the lack of apps is the most annoying thing by far. The rest of the OS is actually quite OK.

</comment><comment><USER2> I'd be completely happy with my windows phone if only it allowed me to set custom SMS tones. I was very surprised that I like it so much. It has caused me the most frustration I have ever experienced in a phone, but I still like it.

The cheap Nokia Lumia models seem to be making it more popular. My brother and I both independently bought one, despite both being self-proclaimed apple fanboys.

</comment><comment><USER3> The little devil in me would like to see Microsoft burn. The little angel in me knows that a third big mobile OS will be good for competition. I guess I hope Windows Phone does well, but not too well :)

<comment><USER4> Despite being a UNIX die-hard, I rather like Windows Phone. I'm on my second handset (Nokia 710, now 720) and will buy another without hesitation.

If someone can suggest a handset that has better navigation with zero cost, has a battery life like the 720 (2 days EASILY), is silky smooth, has an IMAP client that isn't a piece of shit, is available SIM free for under £200, has perfect Exchange integration, never crashes and can withstand being dropped hundreds of times then I'll switch.

Oh and Nokia build quality: these things are like Nokia 3310s - you can throw them across the room, drop them from full head height and they still work flawlessly with no breaks (I've tried it).

Not one single Android, BB, Firefox or iOS device can actually do all that, which is my problem.

<comment><USER5> >Despite being a UNIX die-hard, I rather like Windows Phone.

I love the UX of Windows Phone but what has kept me from getting a WP8 device for myself is the lack of an SSH client as configurable as JuiceSSH for Android or PuTTY for Symbian (as far as I'm aware). Is there one fit for a UNIX die-hard? The killer feature of JuiceSSH for me (which was a major reason why I decided to stay on Android) is transparent SSH hopping.

Another, lesser, concern is the lack text reflow in IE but I think we can expect that to be addressed soon. It's one of the top feature requests.

<comment><USER4> I gave up on SSH on "glass" devices so this is fine for me. Too easy to FUBAR something from miskeying.

I switch on the WiFi hotspot on the device and use PuTTY on my ThinkPad instead.

<comment><USER5> >I gave up on SSH on "glass" devices so this is fine for me. Too easy to FUBAR something from miskeying.

As I've said in a previous HN thread on WP8 (edit: [1]), now that Android devices with QWERTY keyboards are being phased out it could be a real opportunity for Windows Phone if Microsoft encouraged vendors to ship devices with physical keyboards. How viable a market this is, I wonder? I imagine past Nokia Eseries users (like myself) would appreciate it, as should at least some of the enterprise Blackberry users Microsoft seems after.

[1] [https://news.ycombinator.com/item?id=6200051](https://news.ycombinator.com/item?id=6200051)

</comment></comment></comment></comment></comment><comment><USER6> Buying an iPhone in Argentina is really complicated. First, because the many complications to import, second because you can't buy dollars making it more complicated and third because even if you use your credit card the government charges an extra huge percentage of the spent price in taxes. All these things are done to stop argentinians to buy foreign money.

<comment><USER7> Argentina has some strange things going on, but why is it different with a windows phone?

</comment></comment><comment><USER8> Sadly (I'm a Windows developer), it's almost all Android here in Paraguay.

I spoke with a couple local companies that do mobile development and the biggest problem is still the cost of hardware. That's even though Paraguay doesn't have anywhere near as large a problem with importing as other nearby countries do (for example, Uruguay's 60% import duty and 22% IVA, Argentina's restrictions on imports and spending money outside the country). I occasionally pop into cell phones stores and I haven't yet found a Nokia Lumia to replace my old X6. I'm sure they're available, but they certainly aren't common.

</comment><comment><USER9> Wow, I love how with all this PR text they manage to not mention Android even once.

<comment><USER10> Because that would, like, make so much sense for them.

</comment></comment><comment><USER11> Interesting, what is the reason for the growth in Latin America compared to elsewhere? Does Nokia have a strong brand there?

<comment><USER12> Maybe with the lower price point Lumia phones? I don't know. Maybe they are pushing it really hard like here (Germany). Buy Lumia here ad, buy Lumia there blabla marketing.

<comment><USER13> Yeah, at least in the south of Brazil, you can't enter a city without seeing a huge ad saying something like "welcome to cityname, here you can buy windows phones in the storename" That and a lot of pictures of windows phone interface everywhere

</comment></comment></comment><comment><USER14> Hard to know what to make of this without any numbers, but I doubt the iPhone (or any similarly priced top-end phone) was flying off the shelves in many of these countries.

<comment><USER10> People are buying things they can't afford in every country. That might be a defining characteristic of our age.

</comment></comment><comment><USER15> I wonder if Windows Phone will soon have TPM 2.0, too:

[http://investmentwatchblog.com/leaked-german-government- warn...](http://investmentwatchblog.com/leaked-german-government-warns-key- entities-not-to-use-windows-8-links-the-nsa/)</comment>


Photos from Bell Labs Datacenter in 1960s (2019) - <AUTHOR> https://rarehistoricalphotos.com/inside-bell-labs-datacenter-1960s/ <comment><USER2> These are all fantastic photos. One thing that stood out to me is how prevalent the AT&T/Western Electric blue is everywhere.

Much of my career has been spent inside telephone company central offices, where I've seen equipment from dozens of different vendors. The 5ess is still the sharpest and cleanest looking hardware I've ever seen. Bright white with that distinctive blue accent trim.¹

It's really a timeless look, and shows just how much effort they put into "irrelevant" details like that. A lot of vendors aim for a unified style, but it's usually boring and hard to distinguish from their peers. But AT&T stuff was distinctive, and I don't think it suffered from the passage of time. In other words, it doesn't look retro-futuristic. It just looks nice.

Look at the the 8th photo². You see the cabinets in the background, the keys on the console, the keys on the terminal, the platen knob, and the drawers on the desk. All matching and designed.

[1] (I give Nortel some "anarchy" credit for their courageous use of brown and green. It's fugly in an endearing sort of way :)

[2] [https://2.bp.blogspot.com/-vaO- bHVmCQ4/XciOziQqrqI/AAAAAAAAS...](https://2.bp.blogspot.com/-vaO- bHVmCQ4/XciOziQqrqI/AAAAAAAASjw/hyw68qKbSIUrUlXmRudkLZl4WkI80BV0QCLcBGAsYHQ/s1600/Bell_Labs_1960s%2B%25289%2529.jpg)

<comment><USER3> There's no switching hardware in these photos. It's an IBM System/360 installation, and everything is IBM System/360 Blue [1], not AT&T/WE. The same branding is still used today.

[https://www.ibm.com/design/language/color/](https://www.ibm.com/design/language/color/)

DEC used similar colours in their mainframes

[https://upload.wikimedia.org/wikipedia/commons/3/35/PDP-10_1...](https://upload.wikimedia.org/wikipedia/commons/3/35/PDP-10_1090.jpg)

But varied the colours for minis

[http://www.pdp-11.nl/museum-center-group.jpg](http://www.pdp-11.nl/museum- center-group.jpg)

Interestingly, it has become traditional to use blue (and teal) to indicated advanced technology:

[https://vignette.wikia.nocookie.net/expanse/images/c/c6/Prot...](https://vignette.wikia.nocookie.net/expanse/images/c/c6/Protomolecule_structure_on_Venus.jpg)

[1] Also available in rust/red, not shown here.

<comment><USER2> Thanks. I'm realizing this as well with sibling comment's photo and my reply. AT&T's blue is not as vivid as shown in these photos and the ones you linked. It's more muted/desaturated.

I know there's no telco switching stuff here, but I had (wrongly) assumed that, since it was Bell Labs, that it was their own hardware using the same scheme.

I stand by my admiration of that 5e, even though it appears the photos here aren't representative of it. :)

<comment><USER4> Bell Labs was not just about telco stuff, it was quite a revolutionary R&D unit in many ways. Seems to me a lot of people who worked there either did - or could have - worked at MIT, Stanford, Berkley, etc.

A read of the Wikipedia page [1] shows just how varied the research there was, but I'm not sure it's up there today so perhaps it's slipped from our minds.

One interesting thing I found out about the place is that I believe some university faculties have tried to model their research buildings on the physical layout of Bell Labs: everybody gets an office, but common areas are lengthy corridors away, meaning there is a good chance of serendipity and meeting colleagues when you're not heads-down. I have a hazy recollection this is how MIT built one of their newer buildings, but can't find a source for it now.

And yes, you're right, the kit looks beautiful.

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

</comment></comment></comment></comment><comment><USER5> My father used to be a programmer back in the 1960's for the IBM 700 series mainframes, writing programmes and simulations in FORTRAN 4 (and I think some assembler, too) for our now-defunct shipbuilding industry (Sweden). The stories he told me about how debugging back then included manually going through series upon series of punchcards (often by laying them out on the floor in his house and crawling while reading) humbles me somewhat to how far we've come in the industry where debugging something is as easy as pressing a button and getting instant feedback. Back then results from a compute had to be processed overnight even for relatively simple programmes.

One thing we've seemed to regressed on though is the professional stature of our industry - back then private offices were the norm and the Orwellian open- office hellscape of today was no where to be found.

<comment><USER6> In the old days, the first step was think through the logic very carefully, because every mistake took a long time for the cards to get collected and run through the machine. Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. Only then were cards punched. And those cards were certainly checked for typos before submitting the job.

This was all because the turnaround was so slow.

Another fun card fact was that most people drew diagonal lines on their card decks, so you could more easily put them in order if they got scrambled.

The consequence of all of this is that debugging cards was actually not all that common, because you were doing checks at all the preliminary steps.

This was all quite fun, actually. Think of driving a standard-shift car, compared with an automatic.

<comment><USER7> > Most people started by scratching their head and looking into space for a > long time. Then they started drawing some sketches of flow (maybe with > flowcharts, but often not doing that formally). Then they wrote out the code > on coding sheets that had columns matching the columns on cards. Then they > spent time reading the code and thinking like the machine.

This sounds a lot like how I work when writing new code that's not just a quick throw-away script, but built to last. If implementing a new feature takes me one week, then the first one is usually spent just reading the existing code and thinking about the other parts of the application and environment are going to interact with the new feature.

It takes more time initially, but it saves me a ton of pain down the line, and luckily my managers appreciate that trade-off as much as I do.

</comment></comment></comment><comment><USER8> I'm terribly curious what all these jobs are:

* Computer Operator

* Computer Operations Supervisor

* Tape Librarian

* Data Control Supervisor

From the article text, presumably these do not involve programming? I'm old by HN standards but this predates me by a couple eras. I guess "Tape Librarian" is obvious enough, but what does the day-to-day life of a Computer Operator look like?

<comment><USER9> I worked with mainframes and superminis back in the 70s. My first job was night computer operator.

Computer operator: scheduling and monitoring jobs, managing the print spool (queue) printing reports, stripping (removing carbon paper) and collating, sometimes swapping disk packs, loading/unloading tapes, running backups. And making sure the computer didn't crash or halt. The minis and mainframes I worked on generally ran one job at a time, and the jobs might have a sequence, reading from and writing to disk or tape.

We kept transistor radios on top of the computer cabinets. Each job made a distinctive sound, as did runaway programs (infinite loops, for example). A halted computer did not make a sound so the radio was an early warning that something wasn't right.

Tape librarian: magnetic tapes degrade over time from use, stretching, humidity. The tape librarian cataloged the contents and sequence of tapes, how many times they were used, their age. When a tape had too many errors or got to end of life the tape librarian would schedule a duplicate job.

<comment><USER7> > We kept transistor radios on top of the computer cabinets. Each job made a > distinctive sound, as did runaway programs (infinite loops, for example). A > halted computer did not make a sound so the radio was an early warning that > something wasn't right.

You mean you used the radio like a baby monitor?

<comment><USER10> The different components would make different electromagnetic interference patterns. You could tell what the computer was doing (or not doing) from the static.

This is also how some of the first computer generated music was produced.

<comment><USER11> I remember listening to my TRS-80 that way -- easy to monitor outer/inner loops, different sounds for Basic vs. asm code, etc. The downside was that often people had no choice -- the TRS-80 was so noisy, that nobody in the house could watch (OTA broadcast) TV if I had the computer on.

<comment><USER9> Can confirm. I did some work on a TRS-80 in a Radio Shack store (inventory on cassette tapes!). The "trash 80" as it was called would interfere with the stereo equipment in the store, the manager would have to turn the little computer on the counter off to demo a receiver.

<comment><USER11> > "trash 80" Boo! :)

Still much love for it...

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> The picture with the tape library makes me wonder why we only have the option of the small tape cartridges of today. It would be super cool to have a horizontal arrangement of say 20 such "tape wheels" each with their own R/W head. Imagine the capacity such a unit would achieve with today's tape medium! Our LTO-8 tape cartridge holds 12 TB of incompressible data. Imagine a wheel that big could hold somewhere like 100 TB or so. If you put 10 of them in a horizontal row, with 10 heads, you get a PB archival machine..

I'd feel badly of our tape robot now.

<comment><USER13> Just for fun:

An LTO-8 tape is 960 m long and 5.6 µm thick.

A standard-length ANSI-standard 9-track is 2,400 ft long and 0.0015 in thick.

So naïvely assuming you could spool about 2,400 ft * (0.0015 in / 5.6 µm) worth of LTO-8 tape on a reel, we have

145161/28000 = (0.0015 in / 5.6 µm) * (2400 ft / 960 m)

so your imaginary LTO-8 reel could store around five times as much data as an ordinary LTO-8 cartridge, or about 60 TB.

Sounds promising until you realize that, even assuming impossibly efficient cylinder-packing and no additional overhead for automation, a single 9-track reel takes about as much space to store as five LTO cartridges…

</comment></comment><comment><USER14> [http://www.larryluckham.com/1969%20&%2070%20-%20Bell%20Labs/...](http://www.larryluckham.com/1969%20&%2070%20-%20Bell%20Labs/album/index.html)

Here is the original images.

Also that thring they call a computer terminal, I'm pretty sure is either an TSPS, OSPS or TOPS console, basically used for telephone operators.

<comment><USER15> This has come up before here and on Twitter and nobody has ever known, but I intend to keep asking: does anyone know where this Bell Labs facility was in Oakland, CA? The only mention of it anywhere on the web lead back to this page. I can find no other contemporaneous documentation of it, and I even searched the Oakland Public Library periodicals archive.

<comment><USER16> According to this article it was in the basement of the Bermuda Building ([https://www.sfgate.com/tech/article/bell-labs-larry- luckham-...](https://www.sfgate.com/tech/article/bell-labs-larry-luckham- techie-women-photos-13578683.php)) which was demolished after Loma Prieta damaged it ([https://localwiki.org/oakland/Bermuda_Building](https://localwiki.org/oakland/Bermuda_Building)).

</comment></comment></comment><comment><USER17> This is fascinating not only because of the datacenter

I wish we had the 60s fashion back

<comment><USER18> Looks like that office can't possible be as cold as modern offices. I would freeze in dresses like that in a modern workplace.

<comment><USER19> I remember raised-floor machine rooms being distinctly colder than office space. But more importantly, none of those shoes are barnyard acid resistant.

</comment></comment></comment><comment><USER20> The monopoly Bell had made so much innovation possible - did society as a whole really benefit when Bell was broken up?

<comment><USER14> It's a very mixed bag.

We lost lots of good paying jobs, we lost the rollout of ISDN, which would have spend up offering high speed network access, we lost hundreds of millions spent on basic research.

We gained, a bunch of openness, mobility, and access to a wider breadth of services. It's still a mixed bag.

<comment><USER21> We had an ISDN at an office I worked at in 96, but we had cable internet (@Home) at the house. IIRC it was 6Mbps/1Mbps.

</comment></comment></comment><comment><USER22> I can almost smell the formaldehyde smell coming from the 60's paints, wallpapers and furniture.

</comment><comment><USER23> The first thing that struck me in the images: so many women of all colors working in tech!

</comment><comment><USER24> I enjoyed these photos. I often wish I had been born earlier so I could've been around for this part of the history of computing.

</comment><comment><USER25> > The Charge-Coupled Device or CCD, now universally used in digital cameras,

Not any more:

[https://en.wikipedia.org/wiki/Image_sensor#CCD_vs._CMOS_sens...](https://en.wikipedia.org/wiki/Image_sensor#CCD_vs._CMOS_sensors)

</comment><comment><USER26> cool to think diversity could exist in a tech company...

<comment><USER27> Well, sort of.

 _" One day I took a camera to work and shot the pictures below. I had a great staff, mostly women except for the programmers who were all men. For some reason only one of them was around for the pictures that day."_

<comment><USER26> haha yes, but computer programming was mostly women in the 40s and for a while. i stand by my sarcasm.

</comment></comment></comment><comment><USER28> Two things stand out to me, other than the clothing/fashion...

So much raised floor

So many tapes.

<comment><USER29> And the hairstyles. :)

</comment></comment><comment><USER30> Lots of women in IT (or 'DP' for 'data processing') back then.

I started in 1990 on IBM mainframes, a lot of what is depicted looks like my first data centers. I saw the last of the punch cards, round tapes go to square tapes, and more greenbar paper than I'd care to admit.

Good times.

</comment><comment><USER31> The Mountain View Computer History Museum is near by and I love making a visit. The era that interests me the most is from the 60's where they started to scale up from the tube era. It's just amazing considering the time and effort compared to today.

</comment><comment><USER32> If the same kind of pictures would be taken today in the US (and most other western countries) obesity would be the rule with a few exceptions. Seems like the 60s didn't have this problem yet.

</comment><comment><USER33> 2nd "artist & work" photo. pencil sharpener attached to the wall. in a data center? shavings debris danger.

</comment><comment><USER25> I like the way people used to dress for work.

</comment><comment><USER34> Very nice story and photos. It's truly incredible how things have developed since then!

<comment><USER35> > how things have developed since then

and vice versa, how many things looks similar

</comment></comment><comment><USER36> Was expecting more pictures of 60s tech rather than ladies in tight dresses.

<comment><USER37> Me too, but if you put yourself in the photographer's shoes, I guess you wouldn't just walk around taking pictures of random stuff in your office (it's just the equipment you work on, after all, who would ever care about that?), but rather the people you interact with every day. Reading the article's text, the photographer was clearly fond of the people he worked with. I'm also glad it turned out to be this, instead of that. I've seen plenty of photos of old equipment; it's cool to see candid shots of people actually performing the work that was done on the equipment.

</comment></comment><comment> d--b Geez, there certainly were more women in tech at that time.

<comment><USER38> Because computer programmers played guitar at the time.

</comment></comment><comment><USER39> This website is gold</comment>


The social side of science seen in the research on programming language quality - <AUTHOR> https://www.hillelwayne.com/post/this-is-how-science-happens/ <comment><USER2> Programming and programming languages are in a big portion subject of social sciences anyway. Made for the needs of humans used by humans in groups with practices and methods addressing the particularities of humans and human groups. Not ordinary humans but humans indeed. Probably it is more of social science than mathematics or other human independent matters. Social science that is using other disciplines, similar to economics, but at least an interdisciplinary subject.

<comment><USER3> I just can not agree with this concept. Using the standard you propose, architecture for instance is a social science, and I'd argue most non-computer engineering fields would be classified as social sciences as well. Computer Science is by traditional applied mathematics, at least the theoretical courses of study treat it so. But there is a reason Computer Engineering is the predominantly understood title of the overarching software field. Programming languages do not exist in some philosophical vacuum, they are created to be implemented in the real world, on real hardware, and deal with the very real physical capabilities and drawbacks of that real world hardware. While programming, and software design as it is generally practiceD, is not as rigorous as other engineering fields, it is the application of the sciences to create or implement technology. So I just can not agree that programming languages and programming are in any way a social science.

Also, just to be clear, there can be social science fields which inquire into aspects of the engineering field of Computer Science, but that doesn't effect the underlying character of the field.

Also, also, I would strenuously argue against the proposition that mathematics is in any way 'human independent.' But that argument is not entirely relevant.

<comment><USER4> Architecture is very much about culture. I'm not sure I'd call it a social science, but the science part of architecture - making sure that buildings don't fall down - is left to structural engineers.

If you read how architects justify their designs, they're full of references to culture, philosophy, and occasionally - too rarely - practical research into how people move through and live/work in spaces.

It's a social activity in that architects design for other architects. Clients are secondary.

CS is actually no different, it's just far less culturally self-aware. There's nothing objective about CS. It grew out of a specific philosophical current, and it could easily have gone in other directions, emphasising other kinds of entity relationships - e.g. less atomised and sequential, more contextual and associative. That in turn would have influenced the design of the hardware.

<comment><USER5> You can say the exact same thing about mathematics.

</comment></comment></comment></comment><comment><USER6> Wow, what a bad idea. Do Haskell and PHP get used for the same sort of projects? Or Erlang and Ruby? No, they get used for very different sorts of projects. You would need to only compare similar kinds of projects (e.g. web frameworks, or statistical analysis, or device drivers) to get anything useful out of this data source. But, that's probably not possible, because in most cases there aren't enough projects in very many languages. This also assumes that bugs are all equally likely to get FOUND in all languages. What if bugs are easier to find in language X than in language Y? Then you will get MORE, not fewer, commits that mention fixing them in language X, which is the opposite of what you would want the signal to indicate. I could go on, but there's no need, as even these points are enough to totally invalidate the premise of this research. Getting into the weeds of the analysis of the original study or the rebuttal, is not going to give you anything useful, if the original premise that you are measuring how language compares to bugs is wrong, and it almost certainly is.

<comment><USER7> Confounding variables don't invalidate research, they merely inform us on how to weigh the evidence, and shape future research.

Studies can have interesting conclusions even in the presence of confounding variables. Sometimes the state of the art in a certain hypothesis space hasn't progressed past of of these yet, but that's still better than gut feeling.

In some areas like public policy research you will never completely eliminate all of these factors, but that's no reason not to attempt to create knowledge.

<comment><USER8> I don't think GitHub mining is state of the art, and there are opportunities, as the article says, to separate the signal from the noise. I agree in the general sense, but there should be some lines drawn at which point we can say research is invalid so people don't run away with the results.

<comment><USER9> Yeah, the original study is clearly so methodological unsound that it's conclusions shouldn't be repeated.

But fankly most of the posts here are people almost calling the original authors _heretical_ for even trying to data mine commit messages.

</comment></comment></comment></comment><comment><USER10> At the very end of this grand tour:

> Science has its problems, but it's still the best we got.

I would agree _if_ you're doing particle physics and looking for p < 0.0000003 then absolutely. Science is a great tool for the kinds of investigations of the natural world which can be understood by science. If you're doing social science by scraping some data from the internet and looking for p < 0.05, that's a very different story.

I'm not actually sure what aspect of this qualifies as "science", besides using p-values to analyze the data. Even if all the categorization and sampling and analyses were perfect, it's using commit messages and known bugs with known fixes, all of which are essentially self-reported.

<comment><USER11> From my POV the real problem is that there are phenomenon that apparently cannot be studied scientifically. Like _Reiki_. Now I'm not a scientist but I am a huge proponent of science. Carl Sagan is among my personal heroes, okay? I am in favor of science over superstition and irrationality.

One day I encountered a phenomenon that is as real and physically dramatic as, say, the electric field of a Van de Graff generator. Being a fan of science I went looking for the math/science/engineering for this phenomenon. Long story short, after a few years of research, I discovered that: 1) this phenomenon has been known since antiquity in a pre-scientific way; 2) several researchers had independently (re-)discovered it multiple times going back about 2.5 centuries; 3) each time it had achieved a certain notoriety but then been debunked and subsequently ignored or forgotten. The first was Mesmer & "animal magnetism", but there are several others including Baron Von Reichenbach & the "Odic force", and Wilhelm Reich & "Orgone". This is repeating today with several kinds of "energy healing" including Reiki (which is distinguished by being Japanese and unabashedly theistic (Rei means Divine)) where practice is widespread, but lacking scientific validation. As I say, I've _felt_ Reiki, so I know it's real, but so far I've personally never been able to interest any scientists in studying it, despite offering to demonstrate it. And the studies that have been done haven't helped. The Wikipedia article for Reiki just straight up calls it pseudoscience.

<comment><USER12> To the extent that Reiki or any other alternative medicine technique actually does anything, it's easily explainable by the placebo effect.

You know what we call alternative medicine that works? Medicine.

<comment><USER13> The placebo effect itself is fairly spooky.

<comment><USER14> Not really.

It's all Descartes fault, essentially, by postulating the "mind" as distinct from matter.

More specifically, placebo pain-relief has been associated with endogenously produced opioids for approximately 40 years now (1978, I believe).

More recent research suggests that much of the variance in the effects of pain-killers can be associated with these endogenously produced opioids (when the patient was not aware of the pain-relief, responses were similar).

So essentially, the placebo effect is just a normal part of your body responding to medical treatment, regardless of the efficacy of said treatment.

I'm talking about pain because most of the research is on pain, but the principles are similar where placebos tend to be effective (not against infections, sadly but pain and depression seem to be extremely placebo- responsive).

</comment></comment></comment></comment></comment><comment><USER15> I'm confused. So the original paper was shown to be flawed, but then the rebuttal was also shown to be flawed. But this article argues the flaws in the rebuttal was not as glaring as the flaws in the original paper?

But the approach of counting commits on github just seems fundamentally flawed. The first step should be to show that the github dataset _can_ be used to say anything about quality and productivity of things like language choice. Arguing about how to classify commit messages seem pointless without this foundation.

<comment><USER16> He talks about that in the end. Here's the relevant section:

 _Is this even a good idea?_

We've just spent several thousand words on methodology to show how the original FSE paper was flawed. But was that all really necessary? Most people point to a much bigger issue: the entire idea of measuring a language's defect rate via GitHub commits just doesn't make any sense. How the heck do you go from "these people have more DFCs" to "this language is more buggy"? I saw this complaint raised a lot, and if we just stop there I could have skipped rereading all the papers a dozen times over.

Jan Vitek emphasizes this in his talk: if they just said "the premise is nonsense", nobody would have listened to them. It's only by showing that the FSE authors messed up methodologically that TOPLAS could establish "sufficient cred" to attack the premise itself. The FSE authors put in a lot of effort into their paper. Responding to that all is "nuh-uh your premise is nonsense" is bad form, even if the premise is nonsense. Who is more trustworthy: the people who spent years getting their paper through peer review, or a random internet commenter who probably stopped at the abstract?

It all comes back to science as a social enterprise. We use markers of trust and integrity as heuristics on whether or not to devote time to understanding the claim itself. This is the same reason people are more likely to listen to a claim coming from a respected scientist than from a crackpot.12 Pointing out a potential threat to validity isn't nearly as powerful as showing how that threat actually undermines the paper, and that's what FSE had to do to be taken seriously.

<comment><USER15> Interesting, but as a layman this seems totally backwards. If the underlying premise is flawed, who cares if the methodology is correct? If the original study _hadn 't_ made errors like misclassifying some projects or commit messages, the result would still be based on an unfounded premise.

<comment><USER9> To put it simply: if the methodology is sound then the premise _can 't_ be unfounded, because the premise is the source of the methodology.

<comment><USER17> I think you may misunderstand what others mean when they say "premise".

For this paper, the premise is that GitHub commit history indicates language quality.

The methodology is then the implementation of the study: how do we classify each commit? How do we identify the base language in a repository? What would lead us to discard a repository as a data source?

The methodology may be perfect, but you may still end up with nonsense because GitHub is not a comprehensive or representative source of data for studying programming.

<comment><USER9> No, pretty obviously the claim is that language properties will _affect_ the type of commits being made, _this_ is the premise they start from.

The CACM paper then did a bad job of testing if this is true by not being vary careful with the labelling and cleaning of their data, a point on which they were then attacked.

Please notice that they were critiqued on their _methodology_ , not for thinking that commits are casually influenced by the design of the language they modify.

<comment><USER18> Their premise is even more deeply flawed than that. AFAICT, they didn't consider selection bias seriously enough.

I'm not sure if it's politically correct to say this, but, e.g., it's entirely possible that particularly meticulous coders are both more likely to select a strong, statically typed functional language _and_ generate bugs at a lower rate. And that the effect turns out to be almost entirely due to the person and not the programming language.

There are also some fundamentally unanswerable questions. Like, would dynamic typing come off looking better if the selection of dynamic languages weren't dominated by warty messes like php and ecmascript?

<comment><USER19> > I'm not sure if it's politically correct to say this, but, e.g., it's > entirely possible that particularly meticulous coders are both more likely > to select a strong, statically typed functional language

I don't think you need to worry; this isn't "politically incorrect". It's just wrong.

Agree with what you said afterwards, though: Meticulous coders probably _are_ less likely to write bugs. But that will be true regardless of the languages they choose or prefer.

<comment><USER18> > It's just wrong.

It's something everyone has a strong opinion on, but nobody's ever really figured out how to measure. Leaving it a subject that's still firmly in the province of conjecture. Typically self-affirming conjecture.

Me, I like dynamic languages, but, given that this subject is pretty much a complete knowledge vacuum, populated only by occasional iffy, easily criticized studies like the one in question, I'm inclined to say that the only position that offers any decent chance of not being informed primarily by confirmation bias is to assume that, for the most part, none of us has any firm idea what they're talking about. Least of all oneself.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Number of commits as a metric is a poor idea, because it will immediately be gamed. I constantly advocate with D that people break up larger PRs into smaller self-contained ones, for several reasons. Undermining this with a metric that draws unfounded conclusions isn't helpful.

<comment><USER15> Just make sure you don't use the word "fix" in the commit messages, then the reliability of D will be through the roof!

<comment><USER21> That _was_ funny, but in fairness can you imagine how expensive and long drawn a real study into this question would be?

<comment><USER22> All it takes to avoid that is looking into commit histories of projects in each language and figuring out how they mark bugfixes. If it's suspiciously reliable you would know you made a mistake classifying bugfixes somewhere or your sample is too small or the programming practice in the language is unusual and needs closer look.

</comment></comment></comment></comment><comment><USER23> Interesting rundown, thanks!

I'm a bit puzzled with the "not a dox" tweet, what is going on here? I know that this is probably the least interesting part of the article, but I'm confused and curious.

<comment><AUTHOR> Ooops, didn't quite explain that properly! The tinyurl links to Berger's Facebook page.

</comment></comment><comment><USER24> It's amazing the paper got published in the first place – the idea that comparing open source codebases could tell you all that much about the underlying language is sort of bizarre when comparing such different projects to begin with.

<comment><USER25> It is not the role of peer-review to do this kind of gatekeeping (although it would be nice if it could filter out bad methodology and data errors). This is the role of exchanges just like the one discussed here.

<comment><USER24> Journals can reject a paper on editorial grounds – for example, Nature doesn't publish every valid paper submitted to it.

<comment><USER25> True, but it is not the role of peer-review as a whole to prevent papers with whose premise you can argue from being published anywhere. The goal of peer- review is to filter out papers that use bad methodology. Debates over premises is carried out in other papers.

</comment></comment></comment></comment><comment><USER26> Related from a few months ago: [https://news.ycombinator.com/item?id=21637411](https://news.ycombinator.com/item?id=21637411)

</comment><comment><USER27> Every project grows until it becomes too complex and hence unmanageably buggy. Some languages/static analyzers/linters/architectures/frameworks let a project become bigger and more complex before becoming unmanageably buggy.

So if you look at two projects, and both have a bunch of bugs, that doesn't tell you much. You have to know bugs-per-unit-complexity, which is pretty damn close to unmeasurable.

It's telling, though, that the companies managing the world's most complex systems run them in C++, Java, and TypeScript. And more recently, Go and Rust.

With much finance research, if the results were real, the researchers would be making billions on Wall Street rather than be academics. So, too, with software research. If the results were real, the researchers could become gazillionaires advising FAANG instead of being academics.

<comment><USER28> This is something I come back to repeatedly when attempting to evaluate claims about certain technologies (e.g. programming languages) being extravagantly effective: people's sentiments about how great some technology is often seems out of proportion to what their gains were through using it.

Of course that's difficult to evaluate. But if their gains _were_ in proportion, I think you'd see these crazy spikes like what you're saying about these researchers becoming gazillionaires. And it just doesn't seem to happen.

Which is not to say there's _no_ difference—but 1) the improvements seem to be by smaller factors than what engineers believe 2) they don't seem to generalize as much as is often claimed: afaict, a significant aspect of the gains has to do with reducing impedance mismatch between problem domain and language (but advocates will typically adopt a stance that the language is just intrinsically superior).

I would be very interested to hear counter-examples if people have them (I know the PG/Viaweb/Lisp story).

<comment><USER27> I think the folks really fascinated with which language is intrinsically superior are missing out on the fact that the language itself is <10% of the software development process. There's tooling, architecture, libraries, monitoring, etc. The language's feature set or verbosity is rarely the bottleneck.

I'm skeptical that the PG/Viaweb/Lisp story generalizes at all to non- geniuses. Like, sure, if you gave Paul Graham raw assembly he could probably do some pretty impressive stuff even so. Doesn't mean anyone else can. He's a genius. So is Robert Morris.

</comment></comment></comment><comment><USER19> It's astounding how discussing programming languages can devolve into flamewars, even when the discussion starts as actual academic research and the participants are dedicated scientific researchers.

</comment><comment><USER25> This is a truly terrific post, but it says:

> They're underselling the effect here. While the dominant factor is number of > commits, language still matters a lot, too. If you choose C++ over > TypeScript, you're going to have twice as many DFCs! That doesn't > necessarily mean twice as many bugs, but it is suggestive. Further, while > they say the effect is "overwhelmingly dominated by […] project size, team > size, and commit size", that doesn't actually bear out. Only the number of > commits is a bigger factor in language choice.

This is inaccurate. "Effect" is not the expected difference (i.e. difference between the means) but, roughly, the expected difference divided by variance. Just looking at the expected difference is insufficient to determine if the effect is large (and undersold) or small.

Expected difference is not an interesting statistical property, just as the mean isn't (by itself). If you're looking at ten Clojure projects and ten C++ projects, and all ten Clojure projects have 10 DFCs, while eight C++ projects have 8 DFCs and two have 500, then the expected difference is huge, but the effect is small. Indeed, when looking at the variance, Clojure, the "best"-performing language in this dataset, and C++, the "worst"-performing language in this dataset, the two were not very distinguishable, supporting everyone's finding of a very small effect.

<comment><USER29> > Expected difference is not an interesting statistical property, just as the > mean isn't (by itself).

Difference in means can meet the definition of effect size, and are listed as an example right away in the wikipedia article on it [0]! The key is that it capture the phenomena of interest (and generally, the magnitude shouldn't be a function of number of observations). In psychology, where scales often have arbitrarily defined ranges (eg IQ scales), means usually are not useful effect sizes.

The case you list is a separate issue from effect size (probably the violation of distributional assumptions in some implicit or explicit model). Even using difference in means / variance (say, cohen's d), two observations that extreme would make the interpretation of both mean and variance calculations pretty dubious (a problem not solved by dividing them).

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

<comment><USER25> Which example? The six examples that talk about "difference in means" really show the difference in means divided by some measure of variance. Who would consider the same expected difference to mean the same effect size when the population distributions are narrow and when they're wide?

> two observations that extreme would make the interpretation of both mean and > variance calculations pretty dubious

Yeah, it's a bad example, but I think it at least gives an intuition for why expected difference is not a good measure of effect. This shows two data sets with the same expected difference but one shows a large effect and one shows a small one: [https://imgur.com/a/hg2NNl2](https://imgur.com/a/hg2NNl2) (the rebuttal paper also draws the expected value _with variance_ and shows a similar situation).

<comment><USER29> > Which example?

First paragraph: "Examples of effect sizes include the correlation between two variables,[2] the regression coefficient in a regression, the mean difference, or the ..."

> Who would consider the same expected difference to mean the same effect size > when the population distributions are narrow and when they're wide?

For the case where the unit of measurement has a sensible, relevant interpretation (e.g. if a study measured dollar value of two interventions), and attempts to capture uncertainty via CI or another means, I would consider it _one_ meausure of effect size.

The key to understanding effect size is that its most common focus is around making measures over arbitrary scales become scale invariant. But scales are not always arbitrary.

Daniel Lakens has a great article on ES and puts the motivation for calculating them well..

> First, they allow researchers to present the magnitude of the reported > effects in a standardized metric which can be understood regardless of the > scale that was used to measure the dependent variable. Such standardized > effect sizes allow researchers to communicate the practical significance of > their results (what are the practical consequences of the findings for daily > life), instead of only reporting the statistical significance (how likely is > the pattern of results observed in an experiment, given the assumption that > there is no effect in the population).

[https://www.frontiersin.org/articles/10.3389/fpsyg.2013.0086...](https://www.frontiersin.org/articles/10.3389/fpsyg.2013.00863/full)

To the degree that the thing measured has an inherently meaningful scale to the researchers (eg sometimes dollars, time), then it is already an effect size measure.

There is some nuance here, since the level on which you might want to interpret something (eg the spread could be part of the value, especially to an individual who will have 1 and not many codebases).

You might also want to render it comparable to other studies that measure something else, and it's unclear how to convert it to your scale, so you use standardized ES measures (eg many meta analyses).

But an important point is that whether something qualifies is really a question of the scale. (What the best ES is for your specific question is another important issue!)

<comment><USER25> > the mean difference

Yes, but later the article shows that "mean difference" is really mean difference divided by variance.

> an important point is that whether something qualifies is really a question > of the scale

It's one of the concerns, but I would say it's the main one. An effect size needs to distinguish between the two cases here, both having the same expected difference: [https://imgur.com/a/hg2NNl2](https://imgur.com/a/hg2NNl2)

If you care about units, you can talk about the expected value/difference, but that doesn't make that a meaningful effect size. What you need to do in those cases is to, at least, mention both the expected difference and the variance.

<comment><USER29> > Yes, but later the article shows that "mean difference" is really mean > difference divided by variance.

I would say later the article shows examples of standardized effect size, so divides by variance. Whether that means effect size can't be a difference in means (and explains the wiki intro comment) I disagree with--see my Lakens comment for why.

> If you care about units, you can talk about the expected value/difference, > but that doesn't make that a meaningful effect size. What you need to do in > those cases is to, at least, mention both the expected difference and the > variance.

This seems like it is begging the question. If you look at the definition and rationale for effect size, both in the wikipedia and in Lakens, a claim this strong is not there. For example, a CI over difference in means is one way to capture what a standardized effect size that uses a specific variance term might be doing (what Lakens describes as the second ES viewpoint: statistical significance, distinguishing between effect and power).

In any event, thanks for discussing--it's been really helpful to think about and revisit this topic!

</comment></comment></comment></comment></comment></comment><comment><USER30> > the entire idea of measuring a language's defect rate via GitHub commits > just doesn't make any sense. How the heck do you go from "these people have > more DFCs" to "this language is more buggy"?

If Github is used by ordinary programmers (what are the reasons to assume otherwise?) i.e., if the sample is unbiased then what is the issue with going from "these [random] people" to "this language"?

</comment><comment><USER31> I'm surprised someone takes my github saved games seriously. It certainly wasn't me.

I think this science project would be more fun if assumptions were discarded. Just gather the data, do it without a hypothesis. Something interesting might come up worthy of one.

I liked the bit of crankology in the article. If you sound like a crank no one will take you seriously? I had one day pondered what if the cranks are right? How would we know? It follows that we can't know sounding crank equals being wrong and that our idea of "sounding serious" is based on a flawed data set, if it isn't noise entirely. The topic of the study here certainly doesn't inspire my confidence.

<comment><USER32> Such post hoc hypothesis trawling essentially is p hacking. Try a large enough set of explanations and your data will show something significant. Might be hard to replicate.

<comment><AUTHOR> One of my favorite examples is this tour de force on "proving" that chocolate helps with weight loss: [https://io9.gizmodo.com/i-fooled-millions-into- thinking-choc...](https://io9.gizmodo.com/i-fooled-millions-into-thinking- chocolate-helps-weight-1707251800)

<comment><USER32> or the forever classic: [https://www.xkcd.com/882/](https://www.xkcd.com/882/)

</comment></comment></comment></comment><comment><USER33> > But it still seems intuitive that language should matter.

Am I the only one that thinks this is a naive assumption? They aren't really languages like English is a language--so much for intuition. Don't definitions matter to science? Does science carry a selfie stick? I'm suddenly keen on the antithesis of science or a less social science.

</comment><comment><USER34> If _all_ you cared about was fibonacci, or some other "quality", then fine, use that as benchmark. But others might care more about productivity, cost, etc. Then it's also a matter of taste and what is currently fashionable.

</comment><comment><USER35> There's talk and comments about the measure ("DFCs"). What would be better? And is it possible to use this one to eke out a signal even though the measurement has some known problems?

</comment><comment><USER36> Two comments:

" _FSE was a preprint: a paper that hadn't necessarily gone through peer- review, editing, and publication in a journal. Academics share preprints because 1) the process of getting a paper journal-ready can take years, so this gets it out faster, and 2) academics can share their research with people who aren't able to afford the ludicrous journal fees._ "

To my knowledge, all ACM conferences including the "ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering" are peer-reviewed. In CS, in my experience, peer-review for conferences is more thorough than journal review. Conferences are more important. The idea that they are preprints is something from linguistics or some other field.

" _How did FSE take the rebuttal rebuttal? Not well._

" _So that's technically not a dox, because he didn't publish Berger's private information, but still. That's a really asshole thing to do!_ "

I'm not sure I would call linking to someone's Facebook page from Twitter to be "doxxing" in any sense. Calling a fellow researcher a "donkey" _is_ a bit of an asshole thing, too. (I have no link to said comment, but I know Emery Berger. He's very positive he's right, the smartest in the room, and very abrasive.)

Tl;dr: Software engineering research is a garbage fire. But we knew that.</comment>


Ask HN: What personal projects for learning web scalability? - <AUTHOR>

I'm gradually becoming more and more fascinated by the big and/or just interesting web apps/sites that rely on massive amounts of trafic, data, queries, etc. To scratch the itch, I've decided to start some personal project exercising some of the technologies and approaches to scalability ... BUT as you probably have guessed - it's hard to come up with ideas that are of the development scale of a single developer AND at the same time have some of the real-world challenges of scalability and/or high availability and/or performance.
I'm quite open to new technologies/stacks. Currently work as fairly standard webdev (LAMP stack).
What ideas would you propose? It can be fun!
Thanks in advance <comment><USER2> This is really hard to do. The problem is the scalability is that personal project's just don't get to being say.. 500gigabytes big. And they don't have some 1000 programs asking questions, nor do they have junior engineers working the db.

This problem is akin to stress testing a fully functional system.

Personally, when I've had this itch, I work on learning map-reduce in mongodb/riak.</comment>