The Overprotected Kid (2014) - <AUTHOR> http://www.theatlantic.com/features/archive/2014/03/hey-parents-leave-those-kids-alone/358631/?single_page=true <comment><USER2> I think the biggest improvement we made to our outlook on the topic was to separate 'getting hurt' into subcategories of 'pain', 'damage', and 'lasting harm'. Without those subcategories being explicit, it's hard to have reasonable discussions about risk.

I have a two-year-old; she's allowed to play with a hammer and nails, but she can't use a real knife without supervision. That's because the potential for real damage or lasting harm are both high with a knife - she shouldn't use that on her own until she has been trained with techniques for doing it safely. Next year, she'll probably be allowed to use a knife on food, if not on wood (safe whittling takes a little more effort than safe cutting).

The distinction between damage and lasting harm is especially hard for many people to grasp. Going to the hospital usually means you have _damage_ \- you need stitches, a cast, crutches. Harm is only 'lasting' if it will not totally go away in the next few years - spinal injuries or major disfiguring burns.

<comment><USER3> This is exactly how I did it with my two.

For the most part, I just let "pain" happen. You knew it was going to, and it was hard not to say anything. It didn't always happen, but it usually did. This is stuff like jumping off swings, "sword fights" with sticks, snowball fights, sledding, etc. When it did happen, they always look over to see your reaction. Mostly it was a raised eyebrow or smile and a small shake of the head. Most of the time they went right back to doing what they were doing.. but generally didn't get hurt again. Progress, right?

For light "damage", I'd warn them, "uh, that's not such a good idea..." or I'd force them to add some safety equipment to try to mitigate the damage (knee pads, long pants, gloves, that sort of thing). They've got a few scars, but no broken bones - probably equal parts luck and caution on the kid's part.

Tree-climbing (and other forms of climbing) were the hardest things to deal with because the skill and the limit testing is so important, but the consequences can so variable.

Anything over that, I'd be heavily involved - supervision, stopping them, etc.

On the other hand, there were quite a number of things I tried to get them to do that were pretty dangerous, but they wouldn't do.. I tried really hard to get them into Karting, but no luck. One of the two, the older one, has taken to climbing walls, but the other hasn't.

I think they've developed pretty good self confidence and risk management.

They still sword fight like idiots, tho. That ALWAYS ends up in tears..

<comment><USER2> Foam sword fighting! Join one of the leagues :-) [http://safeswordfighting.tripod.com/](http://safeswordfighting.tripod.com/)

</comment></comment></comment><comment><USER4> My favourite words to hear as a kid were: "Go out and play"

This was in the early and mid 90's. It was amazing. I had a turf around our house that I would patrol. I knew where every plant was, which neighbourhood dogs are friendly and which aren't, where each climbable tree could be found, and I knew exactly how long it took to tumble down the nearby hill.

I was deathly scared of rollerblading down the paved hill. Natural aversion to pain, you see.

And yes, plenty of scraped knees[1]. Many bruises. Perhaps a stitch or two. But I bloody well learned my limits and could spend hours upon hours entertaining myself with everything from random hammers to pitchforks and planks that I made bike jumps out of.

It used to be so cool to be a kid.

My sister is 8 years younger. She no longer went to the playground without my mum. Not because my mum wouldn't let her, but because she didn't want to. Somewhere somehow she got the idea that she needs to be constantly supervised.

[1] Apparently there was a particular summer where both my knees and both elbows essentially had a permanent scrape. I'd always replace it with a new one before the old one healed.

<comment><USER5> _My favourite words to hear as a kid were: "Go out and play"_

Indeed. It was the mantra when I was a kid. In my neighborhood, if I said that to my kid, he'd be the only one out there. The rest of the kids are inside, playing video games or studying.

Last summer, my 13 yr old didn't see one of his friends face-to-face, but had a summer of playing with them and talking while doing so over Skype. He went to a bunch of camps, and saw kids his own age there, and spent a week with his cousins, but saw none of his school friends in person.

Yeah, it was very disturbing to me, and I tried many times to insist "wouldn't you like to have some friends over?" only to hear "no, I'm good"... several times I thought about forcing him outside, but really, the playgrounds have only young kids with parents hovering over them. He would have been alone out there.

I'm been saying to anyone that would listen that there will be unintended consequences for this shift. Dramatic ones. I hope they aren't too bad for our kids and society, and that I'm overstating it. I would love to be wrong here.

</comment></comment><comment><USER6> As the proud parent of a 3 month old, my concern is that exposing my daughter to small risks as she grows up could end in me going to jail. My wife and I joke that our kid isn't allowed to walk to the park alone until she can outrun the cops. Short of moving to Europe I am not sure how to make sure it is safe to let my child roam alone when she is an 8 year old. I am not concerned about her safety exactly, but some asshole calling the police is a very real and serious threat to our family.

[http://www.washingtonpost.com/local/education/decision-in- fr...](http://www.washingtonpost.com/local/education/decision-in-free-range- case-does-not-end-debate-about-parenting-and- safety/2015/03/02/5a919454-c04d-11e4-ad5c-3b8ce89f1b89_story.html)

<comment><USER7> Yea I'm worried about that too. I was raised in France but live in the US, as an 8 year old I used to explore lot's of things. But I'm not actually sure I want to let my kids do the same, I remember doing a lot of stupid things too and I'm not sure any of this freedom taught me anything:

\- touching dog poop to enter a "ninja" club

\- entering many private properties

\- climbing dangerously high trees

\- crossing quadruple railroad tracks with TGVs passing on them.

\- putting my head next to a passing TGV (about 2 feet away), just to see how it feels and be scared

\- jumping off high ledges to see how far I can fall without hurting myself.

\- walking near ledges with a 2 story drop.

\- playing with explosive fireworks, big enough to blow up a couple of fingers. I could just buy these as a kid in France.

This is just a small list, and I was honestly a very quiet, calm kid. I just had an active friend. And as I said, I don't remember this teaching me anything.

Whereas I remember spending time programming (visual programming) at 8 years old, and that was awesome and taught me a lot.

<comment><USER4> > \- jumping off high ledges to see how far I can fall without hurting myself.

This is actually VERY IMPORTANT knowledge. Knowing how much your body can take and knowing how to fall in a way that increases how much your body can take could mean the difference between life and death in _many_ situations.

As the Grim Reaper said when asked about giving a sword to a kid who could cut themselves: "That will be an important lesson."

<comment><USER8> Yep. I remember growing up with one of those older playgrounds - there was a platform about 6 feet off the ground that had a rope climb on one side of it. The idea was to get a kid to climb up the wall with the rope.

Six-year-old me was fascinated with jumping off of the thing. And yes, it hurt sometimes. I fell on my face, I fell on my ass, I took hard landings that jarred my bones. But I learned, and it got to the point where I was taking a running start before jumping off (Parents pulled the plug at that point).

Kids should learn that sort of stuff. Ideally, you want to protect them from "kill / maim you with no warning" stuff like electrical transformers, the third rail on the subway, dangerous chemicals, etc. You want to inculcate a healthy fear of stuff that will cause lasting harm. And, well, everything else should be free game. My parents told me I was free to go wherever on the bike as long as I stayed away from the really busy roads and wore my helmet (again, kill / maim you with no warning).

The funny thing, to me, is that many of the sports that kids play are far, far more dangerous than these childhood games. Football kills and cripples kids every single year, but it's _organized_ , so it's okay!

<comment><USER4> > Football kills and cripples kids every single year, but it's organized, so > it's okay!

Liability and blame. Parents are okay with letting their kids get injured if there is somebody to blame. Like the coach. Or some higher purpose "Oh they were training for a competition"

But parents, and people in general, balk at personal responsibility.

</comment></comment></comment></comment></comment><comment><USER9> There is a middle ground between locking your kids indoors and letting them roam feral riding on the top of trains and tagging buildings.

And that is to be an active parent and go camping, hunting, fishing with kids. Geocaching, bushwalking, kayaking, long distance bike rides etc.

These are some good starting lists: [http://www.natureplaysa.org.au/resources/2/51-things-to- do-b...](http://www.natureplaysa.org.au/resources/2/51-things-to-do-before- youre-12/) [https://www.50things.org.uk/activity- list.aspx](https://www.50things.org.uk/activity-list.aspx)

<comment><USER10> Who has the time?

When I was a kid, my over protective asian mother would let me out of the house when I got home from school, and I'd wander around the neighborhood with the neighborhood kids, and come back when it got dark.

My generation's (I'm 30) ideas of "proper parenting" are too god-damn time intensive. You should be doing stuff with your kids, sure, but beyond a pretty young age, it's their job to entertain themselves.

<comment><USER11> I don't see why in evenings, families can't spend some time in the backyard maybe grill some food or just throw a Frisbee or whatnot.

<comment><USER12> Not for nothing, but how many kids want to spend their time doing that? Sure, playing catch with a parent is fun from time to time, but when I was a kid I wanted to spend my time roaming the woods, riding bikes, or building a tree- house with my friends, not my parents.

</comment></comment></comment></comment><comment><USER13> I'm surprised there's no mention of the Berkeley, CA Adventure Playground ([http://www.ci.berkeley.ca.us/adventureplayground/](http://www.ci.berkeley.ca.us/adventureplayground/)), in continuous operation since 1979.

I have fond memories of being there as a young child. Want a hammer? Pick up 10 stray nails and trade them for a hammer. Then go smash things, attach things, whatever you like.

There's a zip line and a giant cargo net to climb. It's an incredibly empowering experience for children.

<comment><USER5> I'm seriously disappointed that I didn't know about this while my kid grew up a few miles from it. And I've been to the Berkeley Marina dozens of times and I've never seen this. Total bummer.

</comment></comment><comment><USER14> Keywords being "without making it safer".

Security theater, safety theater, everyone too afraid to point out the obvious because they don't want to make it easy for others to accuse them of callousness in a way that's hard to defend against.

[http://en.wikipedia.org/wiki/Abilene_paradox](http://en.wikipedia.org/wiki/Abilene_paradox)

<comment><USER15> I'm not sure that's really the Abilene paradox. In that, every member of the group would agree to taking the counter action if everyone else did. What we have is, I think, more like The Emperor's New Clothes. Most of the collective is in private agreement that he's naked, but would never dare speak against the misguided interest of a powerful minority.

<comment><USER16> A lot of people actually believe that kids have to be "protected from dangers". They are not just playing along to please the neighbors. However, popular opinions can also change quickly.

</comment></comment></comment><comment><USER17> The opening of this reminded me of the hours I spent in an "adventure playground" as a child in the UK. Now at least I know that I need to thank Lady Marjory Allen of Hurtwood for so much fun. I do remember thinking that the adventure playground was 'dangerous' and that was the best part.

</comment><comment><USER18> The initiatives of Gever Tulley, especially Tinkering School [1], are very in line with this article. For the interested (quoted from Wikipedia):

> Tulley delivered a talk at the TED2007 [2] conference entitled "5 Dangerous > Things You Should Let Your Kids Do". In this talk, Tulley makes the argument > that a growing trend towards over-protection of children is harming their > ability to learn and think. Thus, Tulley advocates for parents to allow > their children to do supervised activities that are considered to be > dangerous such as driving a car or playing with fire. By doing so, Tulley > believes children will learn concepts that they may not learn in more > structured and conventional activities.

Later, he published a book "50 Dangerous Things (You Should Let Your Children Do)"

[1] [http://www.tinkeringschool.com](http://www.tinkeringschool.com)

[2] [http://www.ted.com/talks/gever_tulley_on_5_dangerous_things_...](http://www.ted.com/talks/gever_tulley_on_5_dangerous_things_for_kids)

<comment><USER18> TL;DR, some of the 'dangerous' things are:

      * play with fire
      * own a pocket knife
      * throw a spear
      * deconstruct appliances
      * break the DMCA
      * drive a car

BTW, Gever mentions that Tinkering School is also about being creative, confident and in control of these things, learning to handle them safely.

<comment><USER19> Sounds like I should get my son in Boy Scouts, even though our family is becoming increasingly less religious. My experience with Cub Scouts/Boy Scouts included the following things I wouldn't have got to do otherwise:

      * Building a fire
      * Training to use a pocket knife (and being allowed to own one thereafter)
      * Shooting a rifle without my parents present

I quit early on, and they teach you way more self-sufficiency and survival skills than I learned. I recall that there's a merit badge that involves blindfolding you and dropping you off in an unknown wooded location with nothing but a tarp, and you have to "survive" for 24 hours by building a shelter, making a fire, looking for food and water, etc.

</comment></comment></comment><comment> vhost- The next generation of kids are going to be weak. I mean that.

As a kid, I was causing all sorts of trouble, broke a couple bones, created scars, pissed off a neighbor or two, played hockey, and had an outlet for figuring out who I was without my parents around. I turned out fine. I was able to make it through my problems with dyslexia and except that was part of me, I knew what pain felt like, and I learned how to treat people with respect because they didn't yell at me or call the cops; they talked to me like a little human that could learn a lesson (okay, maybe a few yelled at me).

Now I see certain family members completely sheltering their kids. No vaccines, play time inside, choosing the TV they watch, the books they read, the bikes they ride, home schooling. This is becoming a very popular way to raise kids and it's no fun.

<comment><USER20> I was walking through a suburban neighborhood with a group of friends to find a better vantage point to see the 4th of July fireworks several years ago. This woman's 8 year old daughter was riding her tasseled and glitter covered "princess" bike beside us, and had to transition from the road back to the sidewalk. The closest path was over a concrete driveway, which had about a 2 inch (~5cm) "lip" where it met the road.

The girl got "stuck" with her front wheel against the end of the driveway, and _called for her mom!_ (And yes, her mom came over and helped her roll past the "obstacle.")

<comment><USER21> See? that's what we need helicopter moms for. Surpassing 5cm obstacles with bikes.

</comment></comment></comment><comment><USER22> (Throwaway... Not sure why, yet. Something to discuss with my therapist I'm sure. ~89-94)

Before fifth grade, we would build fires to roast marshmallows and hot dogs in the disused sandbox, watched over by the honeysuckles (and, I'm sure, mom from a window). We would have pinecone wars, but only when the season was right - fresh 'cones hurt too much. We would climb trees to see how high we could get; we would head into the woods and build forts from branches and detritus. Once, during a slumber party, we snuck out late at night to ride our bikes through the witching hour. A neighbor called the police on us, thinking we were casing houses. Maybe it was our hoodies. We were, at most, 8 or 9.

By fifth grade, the neighborhood kids my age had all moved away. The one up the street - his mom a single mom, divorced from a gay ex-minister but still active in the LDS, with three younger sisters - wasn't allowed to play with us off their property once his mother caught wind of our backyard roasts and called the fire department. She was a night shift nurse. Once, when we were riding our bikes along the busy two lane (double yellow) road that ran parallel to the train and past my back yard, we saw a squirrel dead from impact. He used the front tire of his bike to crush its head, fascinated by how its eyes bulged. I threw up. A cop pulled up and gave us a stern talking to about respecting animals - even ones that were already dead. "It may be dead, but we don't know if it can still feel pain or not," he said, and went on his way.

The one down the street always had a German Shepherd that they'd give away once it got too old and untrained and relegated to a 20' length of chain. One of them had an accident in their play room once - I can't remember if it was Jupiter or Saturn (never Uranus) - and it had worms squirming in it. The stench was overwhelming. We climbed their maple trees often, we built bicycle ramps on the downslope to the coul-de-sac. Once I raced down it so fast, and the pavement was so rough, that I lost traction and slid fifteen feet on my side and knee. I was fascinated when the gravel wormed its way up through my skin; I still have the scar. We would find hollows between the lawn and the curb, or make them in the woods or in the stacked square logs that held erosion at bay and place GI Joes in battle stance, squared against Cobra in their pretend pillboxes. They had Beastmaster I and II on laserdisc, his parents smoked like a coal plant, and they moved.

The other one down the street, his dad would beat him with a belt. Once we were in their front yard and I shinnied up a tree. Misjudged. Slipped, tore the skin off my shin. I was pretty high up. Never climbed a tree after that. Never saw that one again, either. I can't remember his name. I hope he didn't continue the cycle of abuse.

I couldn't figure out, for the life of me, why we weren't allowed to cross the gentle slope that formed a lip round one side of the playground in fifth grade. I got in trouble for wandering down there several times. A boy showed me a playboy magazine there; I thought the distended breasts were gross; I tattled. He had gotten rid of the evidence in the toilet trash can, but still got in trouble. It flurried one day, and my math teacher had us stay indoors while she went outside and frolicked in it, gloating at us. She made me feel stupid for not knowing long division - when I insisted that fractions were clearly better: .3 repeating made less sense to me than 1/3.

By middle school, recess turned into "socialization time": 200 sixth graders standing for half their lunch period in sweltering heat or shivering cold, milling around bleachers and prohibited from going on the football field below by the panopticonic gym teacher with his comical shorts and puffed out chest and bulging belly and Kenny G hair, forced to interact with no context but that which came as visual, auditory, olfactory baggage.

That's when the bullying started.

<comment><USER23> Great post, that's some vivid imagery. There's many great writers here on HN, though I'd like to mention that your style of writing is fairly unique (and very good) and might point to your main account, especially if your main account is prolific (which, If I'm right, is true).

<comment><USER22> Thank you.

It might at that. My writing style on this was quite a but different than my typical comment, though -- discussion of a topic is different than telling a story.

My therapist has hinted that writing down things about my past would be beneficial, and has been trying to get me to do it for a while. I'd started this as to illustrate the unsupervised play in my childhood as a nostalgic positive, but realized there were a whole lot of other things, not so positive, that had happened too. Between the bullying in school and boy scouts and the sexual assault in the boy scouts, it's been hard to think back and remember what my childhood was like before that. Sure I remember some of the good times, but a lot of the things in the post above I haven't thought about in decades - and thought didn't remember until I began writing and it all spilled out.

</comment></comment></comment><comment><USER24> Hello. Thank you so much for this article. This is very helpful to me because I can now use skype for learning german. I have also tried some lessons by skype with a native speaker from [http://preply.com/en/german-by- skype](http://preply.com/en/german-by-skype) and it was also worth trying.

</comment><comment><USER24> This is very helpful to me because I can use skype for learning german. I have also tried some lessons by skype with a native speaker from [http://preply.com/en/german-by-skype](http://preply.com/en/german-by-skype) and it was also worth trying.

</comment><comment><USER25> When I was very young 6-8, I lived in a low-end, but rather large, apartment complex. It was built at the tail end of the brutalism architectural fad and we had oddities like fully concrete playgrounds built on top of concrete walking surface, surrounded by concrete planters with hard sharp corners.

There was a more conventional playground at an adjacent park and then a neighboring section of townhouses with an open field up at a higher elevation, and then by a strip mall on the other side. The whole area was maybe 2km x 1km.

The entire area was boxed in by 2 high-speed roads and on the other side a crazy intersection. So it formed a kind of "natural" range for us.

It was in the middle of a city so it wasn't too big of a deal for my friends and I to run around all over the complex (there were three different concrete playgrounds and a pool), go over to each other's apartments, run over to the park, play around in the parking garage. Run over to the local computer store. Nobody's parents really seemed to care too much where we went inside of this box so long as we were home by dark.

There was a 7-11 across one of the busy streets with a couple arcade games and they sold comic books and baseball cards, so the braver of us would head over there on occasion and spend our meager allowances on that stuff. It was at about here I learned that different houses had different allowances on our range. Some kids would get in trouble if they came back toting comic books or candy that could have only come from the 7-11, some kids didn't. And so by consensus us kids learned where was the furthest from home we could safely stray.

While most of my friends had a mother at home, I was fully latchkey, both of my parents worked, often till quite late. There was some strangeness in how this was managed:

\- During the school year, between getting home from school and dark, I was free to go anywhere in this box I wanted, so long as I called my parents when I got home from school.

\- If I was going to a friend's apartment, I had to let them know this. If I was just going to play outside it didn't matter where I went.

\- During the summer, my mother would hire a local mother to be my babysitter. Her sons and I were already friends, and their house rules were more or less the same as mine. So really we'd just come home for lunch and she wouldn't see us all day after that. But at least there was a "responsible adult in charge"

\- There was an apartment rule that if you wanted to use the pool, and were under 12, you needed a responsible child 12 or older to bring you.

\- If my parents decided to go out to a function by themselves at night, they'd hire in a babysitter, usually a local teen, I'd spend most of the evening outside with my friends, but within eyeshot of my house.

\- Once it got dark, I had to report back in at home, then I was free to go back outside so long as it was within eyeshot/holler distance from home.

It seemed awesome at the time and I completely enjoyed growing up there. After this, we moved to the country, and strangely it seemed my range shrunk as there simply wasn't really any place to go so it wasn't much worth getting out of the house for. I had a couple friends that were within a couple miles, and on occasion I'd walk to their houses or they would walk to mine, but that was it, for the most part my world shrunk.

I learned much later that there was a darker side to all this childhood freedom.

\- A known sex predator lived in our complex. My mother found out years later that many of my play friends had been abused by him. I believe one time he may have tried to get me to come to his apartment as I remember meeting a strange man at the neighboring strip mall who "wanted to buy my bike for $1000, but I had to come back to his apartment to get the money" The police never investigated any of the cases, and I rarely remember ever seeing police in the area.

\- The tall apartment buildings were popular spots for suicides. I think I remember at least knowing about 3 or 4 suicides while I lived there. I know that one of the bodies was found by one of my play friends. It was so traumatic that he was pulled out of school and the family moved away.

\- The brutalist design and the underground parking garage were extremely dangerous. Several of my play friends ended up in the hospital with broken bones and concussions from falling off of things or getting clipped by cars.

A couple years ago I went back to see my old stomping grounds. Of course it was much smaller as an adult than as an 8 year old.

\- All of the playgrounds had been removed.

\- A fountain feature had also been removed.

\- Many of the concrete planters had also been torn up.

\- A high fence had been put up around the pool.

\- Some of the "secret" entrances into weird structural parts of the underground garage had been fenced over.

\- The walking path to the neighboring strip mall had been removed and replaced with another high-speed road (shrinking the safe play range).

\- The path to neighboring neighborhood had been completely removed. Shrinking the range more.

There were other bits of "civilizing" that had occurred, but it seemed like a less interesting place overall.

I don't have any kids, but I'm mixed on allowing them the measure of freedom I had. There were many instances I can think of where we had gotten ourselves into real danger, and only by dumb luck did nobody get hurt. Parents who's kids did end up in the ER very quickly put restrictions on their kids. On the flip side, it was incredibly enriching to have my world be my playground. To see or know about a place I could walk or bike to, and simply go there without any interference.

However, these days, I lament that there's a bus stop outside of my house, that picks up high school kids, and takes them to a school a half-mile down the road. I would definitely let my kid walk to school instead.</comment>


Facebook Exec Says AR Glasses Will Require New Chip Designs - <AUTHOR> https://spectrum.ieee.org/view-from-the-valley/semiconductors/design/dramatic-changes-in-chip-design-will-be-necessary-to-make-ar-glasses-a-reality <comment><USER2> Everyone building AR glasses has known this for many years. I worked at one of the leading AR glasses companies in the mid 2010's. The platform was taken from a smartphone, and many of the existing ones – Google Glass have an Android backed ecosystem.</comment>


Why Perl Didn't Win - <AUTHOR> http://outspeaking.com/words-of-technology/why-perl-didnt-win.html <comment><USER3> You know what rocked? Perl 4.

I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing thousand-line C programs with hundred-line Perl programs that were more robust and worked better, and replacing shell scripts made of awkward sed/awk pipelines with neat, tight Perl. Arrays and hashes as first class data structures? Marvelous!

Then Perl 5 ruined it all. The ridiculous, bloated "object oriented" syntax rendered it basically unreadable, without adding much useful functionality. The layers of syntax options forced teamwork-driven Perl (I wrote about 10k lines of it) to pay close attention to coding standards, closer than more consistent languages, just to not step on each other or have fights.

Then along came Python and Ruby, which shared most of the benefits of Perl (scripting, mostly), but added very clean, elegant OO syntax. Everyone who actually cared about writing decent OO scripts switched. Plus Python had much better math libs, and Ruby soon had Rails.

And Perl 6? Fourteen years and nothing to show for it, and it'll have to be backwards compatible to all the things violently wrong with Perl 5. There's no use case that isn't already covered by Python and Ruby. Unless some new technology comes along and Perl jumps in firstest with mostest (like Ruby did with Rails), no one will really care.

The average age of Perl programmers has been increasing by about one year per year since 2002 or so. I don't see that changing anytime soon.

<comment><USER4> Absolutely right - Perl 4 had a clear niche (text processing, UNIX system scripting etc) and did this very well. Perl 5 added so much cruft and ugly syntax on top of this in an attempt to try to become more 'general purpose' that it lost its focus. At this point it became easier to switch to Python for 'real' programming.

There are still a lot of problems in the Perl 4 space and to be honest I wish that distributions shipped with a supported version of 4.036.

<comment><USER5> If you seriously think that Perl5 is less suitable for text processing than Perl4 was, I suspect you haven't actually used the language in a while... it's still perfectly good for that. Perhaps even better, since 5.8 added extensive support for Unicode (without requiring explicit conversions and breaking everything like Python 3 did).

<comment><USER6> From a quick skimming through the docs[0], Perl 5.8's Unicode support sounds a lot like Python 2's except that the default encoding is latin1 instead of ASCII - i.e. unlike the Python 3 way of explicitly decoding binary data into Unicode text at the point where it's read (where presumably the encoding of the data is known), it will defer the decoding until the data is used (at some completely unrelated point in the program) and decode it with some assumed globally agreed upon encoding. Since there is no globally agreed encoding (Windows even has different legacy encodings between Win32 and the command prompt!) this will appear to work as long as the data is ASCII but later, when you least expect it (and someone inputs a non-ASCII string), give UnicodeDecodeError in Python 2 or garbage data in Perl 5.8.

Ned Batchelder gave an excellent talk[1] that explains how the Python 3 approach to Unicode works. I think it makes a lot more sense once you understand it; the Python 2 way was clearly broken, and it looks like Perl 5 has the same problem but hides it better.

[0] [http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod](http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod)

[1] [http://m.youtube.com/watch?v=sgHbC6udIqc](http://m.youtube.com/watch?v=sgHbC6udIqc)

<comment><USER7> Why are you pointing to the unicode entry doc in an ancient version of Perl?

Also according to perlunifaq the minumum version you should be using is 5.8.1 which the documents for 5.8.0 would of course not mention.

Really if you want good unicode handling you should probably use 5.16.0 or later. If you want the latest version of Unicode there are ways of changing which version of Unicode Perl is compiled with, but it is easier to just use the latest version of Perl, which is 5.20.

[http://perldoc.perl.org/perluniintro.html](http://perldoc.perl.org/perluniintro.html) [http://perldoc.perl.org/perlunitut.html](http://perldoc.perl.org/perlunitut.html) [http://perldoc.perl.org/perlunifaq.html](http://perldoc.perl.org/perlunifaq.html) [http://perldoc.perl.org/perlunicode.html](http://perldoc.perl.org/perlunicode.html)

p.s. I noticed in the Python talk you linked that no one knew that the pile of poo symbol is in there because the japanese characters for luck and poo are very similar. ( I am unable to find a link to where I first read this ) The Japanese are also responsible for why we call them emoji (e means image, and moji means character. ) [http://www.fastcompany.com/3037803/the-oral-history- of-the-p...](http://www.fastcompany.com/3037803/the-oral-history-of-the-poop- emoji-or-how-google-brought-poop-to-america)

</comment></comment></comment></comment></comment><comment><USER8> Speaking as someone who lived through this period during the formative years of my programming career, the author has completely missed the most influential language of the time and, in my mind at least, the number reason why Perl lost.

Yes, I'm talking about Java. It's easy to hate now, but Java back then replaced all the server-side Perl programming that I did in the space of about 3 years, from 1994 where CGI programming was king to 1995 and the applets craze to 1999 when I was still regularly having conversations with people about the benefits of Java vs Perl to 2001 when you were actively hurting your career by not learning Java (not least because it seemed like the only people hiring were doing enterprise Java with horrible things like EJB and CMP/BMP).

Why did Java beat Perl? Well, there's a lot to that -- but at least part of it has to do with that fact that Java was simpler and didn't have nearly as many tricks up its sleeves (also known as the write-only problem). This is similar to the argument people today make when picking Go over other options like Scala. I also don't think it hurt that Java came out of Sun, which on the one hand was extremely influential because they sold the hardware everyone with money used, but on the other wasn't influential at all because they were "big iron" to the web's "why would I buy a Sparcstation when I can just put a PC under my desk?"

Fundamentally, though, Java was very successful at becoming the language you wrote code in if you wanted to be taken seriously as a software engineer building web applications and you didn't already have 5+ years of C++ experience. Perl programmers didn't get the same respect, and so Perl died.

<comment><USER9> There were two sides - PHP was eating a ton of share from Perl for people and businesses who just wanted to get some simple web thing going. Sun pulled out the "Java is Enterprise" card early and successfully marketed it as being a professional scalable web programming solution for enterprise class applications with a few targeted buzzwords for whatever market segment they were going for. Perl seemed like it was always looked at as an amateur tool (much as PHP/ASP generally were), while Java was taken seriously in "enterprise" spaces (largely due to Sun's success at marketing Java to businesses).

There's a wrinkle, too. Perl isn't just a web thing. It was (and is) still used in "enterprise" spaces for scripting on servers. It's still out there being used to create scripts rather than applications. In that space Ruby/Python are competing, but there's still plenty of sysadmins who use Perl since it works.

<comment><USER10> > In that space Ruby/Python are competing, but there's still plenty of > sysadmins who use Perl since it works.

I don't know how it looks now, but if you login into the likes of HP-UX, Aix, Solaris and so on, usually only Perl is available.

This is what made me learn Perl, back when I was mostly into Python (.com days).

</comment></comment></comment><comment><USER11> This article is pretty much spot on. I lived through this era and experienced the downfall of perl web applications first hand.

My employer produced an amazingly popular perl-based web application, using flat files for data storage because so few shared hosts had DBI and DBD::mysql installed. It's some gloriously horrible code. They did a ground-up rewrite and then hired me to maintain it, right as PHP was becoming popular.

They refused to do a PHP version until it was too late. Someone else translated our code into PHP, then rewrote it a few times before releasing it. Over just a year or two, our marketshare plummeted, and now the UBB is a distant memory. We couldn't deliver a competing product.

Even if perl hadn't lost the deployability battle, the perl 6 fiasco was what let python and company eat away at the mindshare that wasn't concerned with just web applications.

<comment><USER12> I remember the days of the UBB. Flat file databases, what memories. I also recall UBB getting hacked because the data separator was a pipe bar and the code didn't check for that on input. SQL injection before SQL. Maybe I dreamt that. Either way, I remember my time with flat file databases.

<comment><USER11> Yup, that was pretty bad. The resulting filtering ended up causing a lot of trouble for folks not using Windows-1252 or something in the ISO-8859 family, as it'd replace pipes in post bodies with the HTML numeric entity for the pipe in that charset. A similar incident is one of the things that got me hired - <USER2> was the only one to actually pick up a phone and call their office and talk to tech support about the sheer size of the possible bug.

The most fun security bug the previous major version had was a side effect of file naming. In order to prevent users from just downloading data files, every data file was given the .cgi extension and was always saved as 0777 because shared hosting sucks and nobody ever used suexec like they should.

The file format for user records is the login name on the first line, and the plaintext password on the second, email on the third. Someone figured out that #, ! and / weren't filtered in usernames. See where this is going yet? If the directory containing member records was available inside the document root, someone could perform trivial remote command execution.

The second most fun was people discovering XSS before it was called XSS. With some creative quoting, you could inject javascript into the markup.

I'm just thankful nobody figured out CSRF, I'd have hated to figure out how to deal with that way back then...

</comment></comment></comment><comment><USER13> I'm curious if anyone really expected Perl 6 to arrive like the article describes ("The problem wasn't apparent in 2000."). I was just a junior programmer, and I loved 5.6, but from the beginning 6 sounded to me like it would be a wholly different language, probably never delivered, and certainly never adopted. Maybe I'm projecting, but I felt that was a broad sentiment back then. By 2001 I was writing Python half time or more, and even though I felt a great fondness for Perl while Python left me cold, it still felt like it delivered everything Perl 6 aspired to (if you could stand the lack of regex literals, grr.....). Once Ruby became popular we got all the good things of Perl without the aridity of Python, so there was even less reason to care. In the late '00s I took a few years off programming to do a degree in Classics, and I kept telling myself half-jokingly that if Perl 6 shipped I'd know I'd been away too long. When Parrot was released I figured I'd better get back in the game.

That's not to say Perl 6 wasn't needed. Among programming languages Perl was probably my first love, especially the linguistics tie-ins with $ @ % etc, but write-only was a real problem, and people were moving to Python on the one hand and Java on the other. Maybe PHP killed Perl for low-end cheap hosting, but for larger projects, among people who would never have considered PHP, it lost because picking it seemed irresponsible.

<comment><USER14> I started calling it out as vaporware around the Holidays 2001. I would be shouted down by certain zealots who would tell me code (pre-Alpha quality) was available for use right now.

At least there are people maintaining Perl 5 at this point.

<comment><USER15> There are commits to Rakudo, a Perl 6 compiler, every day. It's also scheduled to be production ready by the end of 2015.

<comment><USER16> You might be right. But I have been reading forum posts to this effect for fifteen years, and eventually eveyone switches off. Even if you are right, would you trust your career focus to a software community who had got it this wrong for that long? I am looking forward to checking out a future perl 6 but part of that is now duke nukem forever curiosity - what on earth could be in it that kept those smart people at it for that long?

<comment><USER17> Hmmm, they've never committed to a deadline or even tried to aim for a production release before this time, so it may turn out better than you'd expect

<comment><USER18> _they 've never committed to a deadline_

Baloney.

<comment><USER17> Sorry, I didn't know was much as I thought I did

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I'd disagree with the assessment of Python3 somehow being sunset in 2020. This 2020 End of Life stuff is a marketing tactic to sell it. There are companies with 500K line codebases of Python that won't be on Python3 in 2020, if ever. It's just not feasible when new features have to be shipped. Expect pain (not for the companies in question, for Python3), in the form of a fork. The book isn't closed on this one yet.

I can't help but think that we'll eventually be seeing "Why Python3 Didn't Win". Perl and Python both foolishly abdicated the throne. While shots are fired, I think Python3 could still recover with more compromises from its 'leadership'.

<comment><USER20> While you may end up being right, Perl6 is a _much_ larger departure from Perl5 (than Python3 is from Python2). Can one even _use_ CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)?

<comment><USER19> It is a different departure, and it isn't a 1:1 comparison. That's true.

But Python3 is an obvious failure and no one is admitting it, yet. I've seen claims from the core dev team about how Python3 is doing well because it has more downloads from Python.org, which is so stupid I won't even address it. A comparison of PyPI download statistics says it all.

Python3 migration had many ridiculous ways of pushing people to migrate. The answer for Python3's adoption was always something new. It reads like the list of reasons for invading Iraq.

Originally (and today's) overly optimistic EOL for Python2, then automated code conversion utilities, then porting all the major libraries, then 'six' type libraries to allow an ugly PythonX middle ground, then adding 3.x-only new features as a carrot, now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either.

All that said, and I think this is the best-case scenario: Python3 will survive and eventually thrive. It will just be a shadow of Python's former glory.

Is that -really- worth forcing unicode handling? For Zeus' sake, I wouldn't think so. This coming from someone who agrees with the change in theory.

<comment><USER21> > Is that -really- worth forcing unicode handling?

I dunno. I'm new to Python (version 2 so far) and I easily spend 25-50% of my coding time fighting with ascii/unicode issues in Python. I wish Python 2.x just did something smarter.

Similar, but not quite as bad, is the need for me to put str() around non- string values in concatenation. Just f'ing doing it for me. I'll write a bunch of code, put together a message in a concatenation only to have it blow up at run-time because of this.

 _sigh_ I really miss Perl's implicit behaviors sometimes.

I dunno, maybe this all is making me a better programmer and person, forcing me to really deal with Unicode now, and breaking me of lots of Perl bad habits. But it's really one of the sucky parts of the language.

There's some days, after spending half the day fighting with this issue, that I almost decide to dump the whole thing and switch to Python 3.

<comment><USER19> The problem is that both support unicode and 2 vs 3 unicode handling are just two different ways to do it. Which places Python3 firmly in the 'technological churn' category, rather than true technical innovation.

I'd probably agree 3.x is more Pythonic in this regard, but I think it was an ill-advised move. Plenty of reasoning in my last response as to why.

Why not go ahead and use Python3, you may find it works for you. For me, there's a long tail of libraries that don't exist there, and frankly following the core dev teams' example- we should all act in our own best interests. I'm far more productive in 2.x.

I may eventually move to 3.x, but it will have to be based on its merits. Rather than dogma, salesmanship or propaganda. Today it isn't even close to 2.x and we're nearing 7 years since 3.0 was released.

Unlike most things in life such as updating some software package, the "latest version" of a programming language isn't always in your best interests. I think this is a hard mental barrier to break down, especially people coming into Python now.

But I would always recommend learning/using 2.x, not only is it easier to build cool things with it (the whole point), but you have to learn 2.x. You can avoid 3 entirely, without any issue whatsoever.

<comment><USER22> Are you using Python 2.X because you are maintaining existing code, or because Python 3 is just plain unsuitable for what you're trying to do?

I hear a lot of complaints about Python 3, but in my (limited) experience, 3 is better than 2.X in practically every situation I've experienced. But I've never had to maintain anybody's old code in it, either.

</comment></comment></comment></comment></comment></comment><comment><USER23> When I was younger I pushed myself to know Perl 5. I tried to learn Perl with one book. It was surprinsingly hard. I took a simpler book. I also failed grasping Perl. Those were the two recommended books for learning.

I've come to realize years after that Perl is simply difficult to learn, lots of little things to memorize. Its community took pride in language arcana. Things that are now simple in other languages are unbelievably difficult in Perl, like "hashes of arrays of hashes" and things like that.

On top of that, it's also difficult to read. No wonder Perl is losing, and to me the faster the world is cleanup from that, the better.

<comment><USER24> You're incorrect in your realization. The truth is that the older books for learning perl are simply shitty.

If you read Ovid's Beginning Perl, or chromatic's Modern Perl, you'll find they managed to explain the concepts very easily.

<comment><USER25> No, he's right. Perl is shitty. Have you ever read a random Perl script? It's impossible to interpret.

<comment><USER24> "No, he's right. Japanese is shitty. Have you ever read a random Japanese scroll? It's impossible to interpret. Even in romaji!"

</comment></comment></comment></comment><comment><USER26> Rewriting your language, like any other piece of software, is a great way to lose your market position: [http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

<comment><USER10> People forget that if one is forced to re-write the code, it might as well just use another language.

</comment></comment><comment><USER27> The "Maintenance and greenfield concerns are very different" section is relevant to my interests:

> The implications for a programming language are difficult to prove > conclusively, but simple to explain: an ecosystem focused more on > maintaining existing projects than creating new projects will be less > attractive for new projects.

Ruby/Rails provides an interesting example here. The ruby and rails community ecosystem (the author is right it's about "ecosystem" more than the language) -- has, in general, done it's best to focus as much as possible on innovation over stability. That is, has tried to choose focus on creating new projects over support for existing projects.

Much to the frustration of some in the ruby ecosystem with existing projects to support.

(Rails, of course, from one perspective _is_ an existing project; from another is a framework, which has generally over it's history cared more about new projects that will be created with Rails than existing projects built on Rails that need to be supported).

Of course, there still _are_ existing projects, and there are still developers participating in the ecosystem who need to support those existing projects. So you can only go so far.

What has this done for ruby/rails ecosystem? Hard to say. Overall it's been successful, but it still can't make the ecosystem as greenfield as a true greenfield ecosystem, which is perhaps why some are leaving ruby/rails for greener pastures -- more than any qualities of ruby as a language, it's just the opportunity to be in a greenfield ecosystem that is attractive, perhaps.

</comment><comment><USER28> I don't think Perl will ever recover from the Perl 6 fiasco, and I'm worried for Python for the same reason.

PHP, on the other hand, handled the PHP 6 "failure" relatively gracefully. There was a bit of stagnation in the days of PHP 5.2 when the devs devoted too much energy to PHP 6 and not enough on improving the current version. But soon, PHP 6 was put on hold and some of its better parts began to be ported to PHP 5. Thanks to this decision, PHP has improved by leaps and bounds since 5.3. Also thanks to the lessons learned, nobody is particularly worried about any breaking changes in PHP for the foreseeable future. Everyone knows that any script that works in PHP 5.6 will probably work just fine in 7.0, so new projects continue to be written in PHP. This peace of mind is very important for languages that carry a lot of legacy baggage.

If there's anything for other languages to learn from PHP, it would be their graceful handling of PHP 6 -> 5.3~5.6. The syntax is still terrible, and the default behavior remains borderline insane, but PHP since 2009 has been an exemplar of how a widely used scripting language should handle new versions.

<comment><USER11> > Everyone knows that any script that works in PHP 5.6 will probably work just > fine in 7.0

This is no longer strictly true. On Friday, the "let's remove all the deprecated stuff" RFC was passed. Anything that causes an E_DEPRECATED in 5.6 will now be a fatal in 7. For example, ext/ereg and ext/mysql are no longer included, and have been shipped off to PECL. Shouldn't be a problem for anyone that doesn't compile their own, really. A few php.ini settings are also now removed, which will fatal on startup.

It'll be safe to say that if your code runs fine under 5.6 with error_reporting set to -1, then you'll probably run under 7 without too much trouble.

<comment><USER29> > It'll be safe to say that if your code runs fine under 5.6 with > error_reporting set to -1, then you'll probably run under 7 without too much > trouble.

Not completely, ext/mysql does not output E_DEPRECATED. Although I guess installing a compatibility library is probably not all that much trouble.

<comment><USER11> Calling mysql_connect will cause an E_DEPRECATED. Same with mysql_pconnect.

Source: the manual page. [http://php.net/mysql_connect](http://php.net/mysql_connect)

None of the other ext/mysql functions do so.

</comment></comment></comment></comment><comment><USER30> Version number is micro, this is a macro question, to wit, the following:

When I converted a perl script to python and saved 50% LOC I didn't know which version of which I was using. Am only vaguely aware of the Python 2.x vs. 3 issues. Never was aware of Perl 5 vs. 6.

When Python and Ruby fade, I look forward to the hand wringing about how version whatever didn't get pushed out fast enough. But that won't be the reason.

<comment><USER31> But you're not a thousand companies who have built their business on Python 2 and have no interest in rewriting working code when they don't have to. Your "scripts" are pretty much irrelevant.

</comment></comment><comment><USER32> Define won.

This is the way I see it. Perl5 is still being actively developed, perl6 is coming along nicely, cpan more awesome than ever, and there's still work for a perl dev.

If everyone was using the same language, then we'd all suffer because no one would be getting the new ideas.

Competition keeps things healthy.

</comment><comment><USER33> Perl 6 didn't win because the successors to Perl were Python and Ruby, not Perl 6. Agreed, Perl 6 is a sophisticated language, but Python and Ruby have mature VMs you can use _today_. For values of "today" ranging back in time upwards of ten years.

<comment><USER34> Yep. I've heard it put "Ruby is the best of Perl, without the rest of Perl".

</comment></comment><comment><USER35> Oh man, I remember hating to program Perl. With Perl, there wasn't just one way to do things, but there were 10, and all of those involved different combinations of @{} $[] [#] '%' characters put in seemingly random order and changing completely the context on which they operated, with the logic only clear to those who somehow understood the connection between these symbols and their meaning.

Maybe it didn't win because the language syntax was just a mess, and same variables just in different contexts could mean like 3 different things depending on what way you pass them, what you you return them and what kind of random character is in front of them.

Don't take this personally, just ranting out my feelings for the Perl programming language, and glad that it isn't one of the things I have to know anymore! Good riddance!

</comment><comment><USER9> This was really good. The mix of PHP as a better solution for shared hosting (and its simplicity for beginners) and the horror story of Perl 6 were both big setbacks.

Allison Randal wrote on the death of Perl a while back and had some observations worth nothing to understand how it fell: [http://allisonrandal.com/2013/03/31/mythbusters-why-i- still-...](http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-love- perl/)

I really liked working with Modern Perl, but rarely do anymore mostly since "nobody uses Perl" kills any suggestion even when it might be the right tool for the job. Ruby has become Perl 6 for me.

</comment><comment><USER36> Perl did win, for a period of time .. expecting an interpreted language to dominate for multiple decades is unrealistic, especially with hardware advances that occur over time.

while I don't do anything with it today, I do know Perl/6 would be in contention for my 'deserted island' language of choice.

yet another dph

<comment><USER37> I have to agree; if Perl didn't "win", then who did?

Python? Very popular. Solid language. Probably at some point more adopted than Perl, but not so much so that I can say it "won", partially because of how this list goes on.

Ruby? Same.

PHP? Maybe in the web space but not in general.

Javascript? Even in light of Node, this is still a marginal language out of the browser, especially considered over the past 15 years.

Lua? No.

Perl may not have "won" but it has hardly "lost", and now IMHO the sun is just beginning to set on this entire catagory of 1990s-style dynamic scripting language and there probably will be no further "winner" in this space.

</comment></comment><comment><USER38> [probably shameless plug] I first intended to write this as an answer, but I ended up with a complete blog post:

[http://programming.tudorconstantin.com/2015/01/perl- already-...](http://programming.tudorconstantin.com/2015/01/perl-already- won.html)

<comment><USER18> _Watch out for whoever says that Perl is an ancient technology, because they 're either ignorant and completely clueless about what's really happening in the world of computer programming, or they have hidden agendas._

That's a strong statement. Are you quite sure those are the only two possibilities?

<comment><USER38> There's this Perl book called Modern Perl. It is written to help others learn about the new technologies available to Perl world. Do you know about the book? oh, you wrote it :) So yeah, if they don't have hidden agendas and they say that writing Perl apps means writing apps in an old fashion, the only possible alternative is to be ignorant :)

<comment><USER18> _I_ think Perl didn't win. I don't know the specific context of Romania, but from where I sit, it's unlikely I'll get paid to program in it in the foreseeable future, if ever.

What's my hidden agenda in agreeing with this article over yours?

<comment><USER38> The article has valid points. Hidden agenda is when people say that writing Perl is equivalent to using ancient technologies, solely because Perl had its popularity peak in the nineties - and this might also be a reason why you can't be paid for doing Perl - who would want legacy technologies in their stack?

It's just that, well, it isn't legacy. It's more up to date and much more robust than many of the hip languages.

</comment></comment></comment></comment></comment><comment><USER20> It's no wonder there are issues with Perl 5 to 6 transition they went from:

> They're going to merge Perl 5.12 and Perl 6

in "mid-2001" to:

> There's a Perl 5.8 on the way

in 2002. ^_~

That said, I think that anyone doing serious Perl 5.x work has long since abandoned the idea that Perl 6 has anything to do with Perl 5.x other than sharing the "Perl" name and Larry Wall. Maybe this is confusing to "outsiders" and the branding needs to change? It's not like the Perl 5.x line is not being maintained. Since Perl 5.10, there were some significant improvements, with consistent point releases coming out.

<comment><USER39> The branding will not change, for BDFL reasons. The best all we can do is coming to grips with Perl 6 not being a successor, but a sibling.

</comment></comment><comment><USER40> Not sure what 'winning is'... I've had a great career in Perl so far and every company I've worked at has been a startup using Perl (not old legacy code). So that's like almost 20 years and every year someone says, "Perl is dead", etc. And every year I just have a blast programming Perl. I've met a ton of great people and I enjoy contributing to open source. So I would say quite complaining about something you personally don't like and get on with doing something useful.

</comment><comment><USER41> Previous thread: [https://news.ycombinator.com/item?id=7866834](https://news.ycombinator.com/item?id=7866834)

</comment><comment><USER42> If there was no Ruby, I suspect Perl would still be popular. At one point the scripting language holy wars were "Perl vs Python". That turned into "Ruby vs Python". Similar philosophy, lots of better stuff in Ruby.

<comment><USER43> Online yes - but a hell of a lot of Tcl was being written too, by people who just couldn't be bothered posting about it.

<comment><USER44> Tcl was and still is undiscovered gold.

<comment><USER31> I'm very glad that only game writers are using Tcl for scripting their games. It's a godawful language I'd never want to maintain any real software in. Python and Ruby are bad, but Tcl is a degenerate joke. Let's please leave it undiscovered.

<comment><USER45> That said, the saving grace for Tcl were things like Expect and Tk. I don't think I ever used it for anything else....

<comment><USER44> It's being used for AI, ML and data science.

</comment></comment></comment></comment></comment></comment><comment><USER46> Anyone feeling that Python 3 is gonna do the same to Python as Perl 6 did to Perl?

<comment><USER20> As someone who has been both a Perl and a Python programmer, I don't feel like Python3 is going to kill Python. Why?

\- Python3 currently exists, and there is a large push to get the majority of the "big" packages to support it (many of which _do_ currently support Python 2.x _and_ Python3).

\- It's possible for a Python package to support both Python 2.x and Python3 at the same time or to program the Python 2.x version in such a way that converters like 2to3 can do the conversion for you. I'm aware of no such tools _or_ capabilities between Perl 5.x and Perl 6.

\- Python3 isn't as ambitious as Perl 6 is/was.

Edit: As to point #2, I recall that there may have existed (maybe it still does?) some project to use Perl 6's "reprogram the grammar" capabilities to turn Perl 6 into Perl 5. I'm not sure how I really feel about that though. There was also a time when there was some buzz around Parrot VM[1] that was associated with Perl 6 (I don't know if it was some official partnership or just some announcement of Perl 6 support in Parrot).

[1] [http://www.parrot.org/](http://www.parrot.org/)

<comment><USER47> Indeed, big libraries supporting Python 3 is rapidly growing [http://py3readiness.org](http://py3readiness.org)

Heck, apart from few - even those which are not supporting Py3k now have alternative package in PyPi. So it's positive sign.

</comment></comment></comment><comment><USER48> I think it is cool to think of one's self as the hero in the story of their life. You battle adversaries, have little victories, complete long story arcs, find a sweetheart and have romance.

I feel Perl does not deserve to be mentioned in a hero's tale. There's been too much rankling and nincompoopery out of perl's characters given the size of that community. Far, FAR too much griping. Perl is a bummer, and that is why it did not win.

My philosophy is: live the life of a champion - overcome and be a shining light for others. Your war stories should be mostly glorious victories, no matter how mundane the battles or battlefields were.

<comment><USER49> This is pretty good advice to live by. I should keep this in mind for myself.

<comment><USER50> You're both joking right? I find myself wanting to google this guy in 5 years so I can see how much real life kicks his poetic ass.

</comment></comment></comment><comment><USER40> and I want to add, I am so looking forward to having this exact conversation 5, 10 and 20 years from now...

</comment><comment><USER51> nothing to show for perl6? it's shipping in 2015.</comment>


Shanghai Hacker News meetup #2 - <AUTHOR> http://wiredcraft.github.com/hnshanghai/ The second Shanghai Hacker News meetup will be held on Wednesday 21, 2011 at Abbey Road.
If you want to chat with some likely minded folks, discuss your project or simply technology, come and join us; we'll be the table with a "招财猫" ("Lucky Cat"). As usual, we'll buy a round of drinks for the first 10 to get down there and we'll offer some snacks.
Last meetup went pretty smoothly with people from various horizons, mixing up people with a knack for node.js, RoR, Hadoop, PHP, GIS, mobile development, some backbone.js and a whole lot more... Whatever is your poison, you're welcome.
On Lanyrd.com: http://lanyrd.com/cdzmw
(Chinese version below: it's in Shanghai after all...)
---
第二次上海 Hacker News 聚会将于9月21号星期三举办,地点仍然是 Abbey Road。
无论您是探讨项目、技术,还是闲聊,都非常欢迎。同上次一样,我们将为前十位到访者免费提供一杯啤酒。
上一次的聚会非常顺利。参与者来自很多不同领域,诸如 Node.js、RoR、Hadoop、PHP、GIS、移动技术等等。这一次也非常欢迎新老朋友踊跃参加。
http://lanyrd.com/cdzmw <comment><USER2> Do you guys always have it on a wednesday? I'll be in transit in Shanghai Oct 3 night if anyone wants to meet up? feel free to shoot me an email

</comment><comment><USER3> It's so nice to have these kinds of meetups in China~

</comment><comment><USER4> Coming.</comment>


US forbids any device larger than cellphone on flights from 13 countries - <AUTHOR> https://www.theguardian.com/business/2017/mar/20/us-forbids-devices-larger-cell-phones-flights-13-countries <comment><USER2> Deliberately (?) misleading headline. The devices are not banned from flights. They are banned from being carried as hand luggage

<comment><USER3> Would you put your tablet or laptop in the checked luggage, though? When you know how they're handled...

<comment><USER2> Whether I would trust baggage handling or not isn't really the point.

Almost every news outlet is headlining this story that these devices are being 'banned' from flights, which is simply not true. They're being 'banned' from being carried on as hand luggage. You might as well say that "changes of clothes" are banned from flights, seeing as most people's suitcases are not allowed to be carried on as hand luggage either.

I know the truth doesn't make for as interesting a headline. But it's irritating to see the [allegedly] quality press increasingly adopting the tactics of the click-bait trash pedlars.</comment></comment></comment>


Why Pair Programming Is Not For the Masses - <AUTHOR> http://blog.obiefernandez.com/content/2009/09/10-reasons-pair-programming-is-not-for-the-masses.html <comment><USER2> I had fairly bad experiences with pair programming. None of the physical reasons the author brought up applied: it was in a decent, private room, with decent hardware. The social problems did not apply: it was with cool, friendly people.

It turns out that, in pair programming, while the active person hacks with all his neurons firing, the passive one sits bored out of his mind. I found that passively following someone else's programming, and possibly even fixing minor mistakes, barely uses up a fraction of the mental energy of actively coding. The passive ends up being a distraction. When the passive makes a comment ("have you considered changing this function to do XYZ?"), the active looks up, completely distracted and torn from his concentration, and stares at the passive. "What?.. What did you say?.. Oh... yes, that function... I already thought of that, and here's why it can't work." Basically, I found that being passive in a programming pair also blocks the kind of forward-thinking analysis which leads to good programs.

One more thing. The author claims that pair programming helps avoid duct- taping problems. I completely disagree, at least when it comes to my own work. When I look at my code, and I see the beginnings of something bad, I ask myself: "Could someone else understand this in two months? Will I, when it breaks?" Then I go back and fix it. Whereas in pair programming, two people will likely look at each other and say, "Oh yeah, that's an obvious workaround! Let's keep going!"

<comment><USER3> Some replies to your comment demonstrate exactly why I'm not a fan of forced pairing advocacy and the arguments they use. It borders on the religious: "I love pair programming. Try it, you will love it too"

When someone doesn't experience the unbridled joy of pair programming salvation, it is _always_ something wrong with them, their task, or their partner. Essentially, "oh you weren't pairing correctly" -> "you didn't have enough faith".

Is there any possibility pair programming advocates can cede that developers can eschew pair programming and still produce quality code?

<comment><USER4> Since I wrote one of the "here's how you could fix your pair programming" replies, I should clarify that I don't think pair programming is the only way to work. I'm not doing it in my job right now and don't particularly think I should be.

If you are pair programming either by choice or circumstance, it's useful to know some tricks to make it work better. But if you've tried it and don't think it's the right thing, then you should do something else.

</comment></comment></comment><comment><USER5> Wow, that's one arrogant piece of writing. That still doesn't provide any good, scientific reason why pair programming is that much better -- yay for anecdotes.

But I guess I'm just one of those anti-social programmers. Excuse me while I try to see which of my unwashed heavy metal shirts to wear today.

<comment><USER6> I too certainly got this holier-than-thou sense from reading the article, and I also felt that it missed the point.

Pair programming doesn't work for everyone not because of those pretty dumb reasons. Pair programming doesn't work for everyone because not everyone is the same in their thought processes. Personally, I'm a very outgoing guy and when working with a team on a problem I love to throw ideas around and, if I'm the more knowledgeable one of the group, teach. But I know for sure that some people would rather work alone on a problem, and if that's what gets a problem done quicker and more efficiently, power to that person!

I was hoping this article would dive into the more social aspects of pair programming, but nope. Instead it was "your hardware sucks" or "your company sucks".

<comment><USER5> Apart from the fact that we're still missing a serious study of pair programming (isolated from other Agile hooplah), it's also a false dichotomy. Isolated damsel programmer in the ivory cubicle vs. paired mind meld.

I would say "Pair programming? Yo, Obie, I already gotta pair!" in my best Andrew Dice Clay manner -- but with a German accent, my best Andrew Dice Clay manner is rather abysmal...

<comment><USER7> "but with a German accent, my best Andrew Dice Clay manner is rather abysmal..."

Hmm. Andrew "Würfel" Klay could sound interesting ...

</comment></comment></comment></comment><comment><USER8> "I find it best when I put a guard with a whip near each programmer. They work faster , more eager to stay long hours, produce on average x2 more lines of code. They should not forget that only 100 years ago their forefathers were working 18 hours in Manchester assembly lines factories. They should know that although it's a 21 century, the system has not changed"

</comment><comment><USER9> I, for one, get higher quality work done when I'm allowed to take breaks. This shop might be heaven for workaholics, but there's a lot of really excellent folks who just wouldn't enjoy their jobs if there was someone in the room constantly pushing them to keep working. It's great their culture works for some, but if this were the norm - I'd quit my job and go back to school in something that didn't involve computers, very quickly.

Or go into management. Do they practice Pair Leadership? Didn't think so.

<comment><USER10> Actually, if you read the NYT article, they use a pomodoro time management technique–25 mins on, then a 5 min break.

<http://www.nytimes.com/2009/09/20/jobs/20pre.html>

working hard != being over-worked ... at least that's how I understood it

<comment><USER11> The Pomodoro technique is phenomenal. I actually end up doing ~50 and 10 rather than ~25 and 5. The trick is, when the buzzer goes off, I hit save, mash make && make test and go grab a cigarette. Chat about the weather, video games, anything really with other folks (non-smokers are encouraged to take "smoke breaks" outside, get some much needed sunlight and just relax out of the cubicles). Come back in, look at compiler output or test results and there's a list of things to start working on. If it all ran fine, continue working.

Amazing how something so simple as "get up and away from your desk" does more than any "agile", "extreme" or "You're kicked from a plane, you must write a driver that interfaces the rip cord to the parachute release mechanism in order to deploy your chute" methodology.

</comment></comment></comment><comment><USER12> I'm completely and utterly unconvinced that two brilliant programmers can produce _more than twice_ their usual individual output together, versus just consulting when they have an interesting question or a stumbling block.

If you got Linus Torvalds and Richard Stallman sharing one computer for their working lives, would they really have produced _more_ than on two computers? I seriously, seriously, doubt it.

<comment><USER13> i'll bet you measure output in [LoC / hour], don't you?

pairing means sharing thoughts, means thorough examination of thoughts, means validated thoughts, means code based on good reasoning.

<comment><USER12> Have you got much besides straw-manning what I'm saying and proof by personal assertion?

</comment></comment></comment><comment><USER14> > Hashrocket is a boutique shop, so we can be very picky about who we hire. > [snip] We've hired qualified interns, but we don't hire apprentice or > junior-level folks.

What ever happened to hiring good people and training them?

<comment><USER15> It's hard to do that on a client's dime, at least for me. (I know other consultancies do it all the time and it disgusts me.)

<comment><USER16> Part of running a business is paying the associated costs. Training new employees is an expected cost of running a business, so take it out of your end. Doesn't seem like a particularly outrageous idea...

</comment></comment></comment><comment><USER17> It seems like pair programming is quite popular with consulting companies (Hashrocket, Pivotal). You get to charge for the time of two developers instead of just one.

I haven't heard of any startups that pair program.

As a humorous addendum, my wife was part of a conversation where Pivotal was mentioned. She interjected, "Isn't that the company where they do couples programming?"

<comment><USER18> You have spotted it. The whole Agile movement and its practices, like pair programming, are driven and promoted by consultants who make money out of it.

EDIT Moreover, I am not sure whether the companies you mentioned really practice pair programming or they use it as a marketing ploy to impress they customers.

</comment></comment><comment><USER19> Ugh. What a horrible article. I've done mandated pair programming in the past and I've had good and bad experiences during that time - it depends a lot on who your partner is and what the project is - there's no way it can be "the one true answer" with so many variables. My opinion is that pair programming is something that good developers do naturally when and for as long as is required. Mandating it for all development sends the signal that you think your programmers are too incompetent/stupid to trust on their own.

While I'm a big believer in object oriented programming, even I can admit it isn't always a good fit for every job. Pair programming is no different. Believing otherwise is just your religion showing.

<comment><USER20> I fail to see in that article where it advocates mandated pair programming... In fact I think it does a pretty good job of pointing out when/where pair programming does NOT work (i.e. many environments for the reasons listed). If you happen to work in an environment not conducive to pair programming and they force you to do it... well then...

</comment></comment><comment><USER21> Pair programming to me is a managerial gimmick to keep trench people in check, like those timesheets with specifics down to five minutes. To make them look over each others shoulder, and not surf the web. To address the near-universal management suspicion that your employees slack on the company time. (Disclaimer: yes I did read _that_ book about the (failed) Chrysler project experience generalization to whole industry, so am familiar with the official hype part).

Many people just like the way people normally work better. To do the job you assigned as you see fit, to possess quiet minutes for thinking at will, and to have full control and sole responsibility for what you do. There is time and place for interactions, that's why people have code reviews, meetings, brainstorming sessions, et cetera. If sitting on the degenerate case of meeting of two throughout all your worktime is your thing, fine, do pair programming. But as the author clearly says it is not for masses, although I beg to differ about the actual reasons.

</comment><comment><USER22> Perhaps programming isn't really for the masses, many of these points just describe traits in people that cause bad software to be written period.

The best teams are those who are passionate about getting software right: they'll do whatever is needed to make their software work well. Whether that is pair programming or not. Whether to pair depends on how work is organized, it really requires episodes <http://c2.com/ppr/episodes.html> (or usually called stories). Pairing is, for me at least, one tool in the toolbox. It is particularly good on green-field projects I've found where there are a lot of decisions to be made.

</comment><comment><USER23> > "When doctors screw up (massively) they get sued. When (permanently > employed) programmers screw up they get let-go, and they go find a new job, > usually with more responsibility and a pay raise. There are no ramifications > for software malpractice."

Seems like a mindless rant to me. We can always keep modify software as we like. The same can't be said for a bridge or a human being on a operating theater. What an absurd comparison to make.

</comment><comment><USER24> The rigidity of this approach surprises me. I certainly think pair programming has value. But I don't understand why this company would be so rigid in enforcing it as the _only_ way to develop software.

<comment><USER25> "The rigidity of this approach surprises me"

That is because you don't know Obie. HashRocket is Obie's vision about how sw dev should be done made manifest. I would go crazy working at HR, but hey the man has a right to his vision.

The interesting thing is how "agilists" who pride themselves on their , err, agility are very rigid about "the right way to develop software".

</comment></comment><comment><USER26> I've only ever had exceptional experiences when pair programming. Maybe it's for reasons similar to Obie's; the people that I paired with were excellent programmers.

If I tried to tell you why it was great, I'd basically be re-iterating what he said. More focus, better code, less time, less bugs, better design...

</comment><comment><USER27> _To the average programmer, having to pair full-time means they won't get to waste time during the day on [..] Hacker News._

If my employer wouldn't allow me to read HN during the day, then I'd go find another one. Constantly learning and improving myself is what keeps me going and HN helps me in that. I consider it my study time, which I otherwise don't get (one of the major disadvantages of this employer).

</comment><comment><USER28> _Full-time pair programming keeps developers focused and coding, all day, every day, week-in, week-out._

Sounds like a recipe for burn-out to me. Maybe if you switch to 6 hour days, or 4 day weeks, it could be more sustainable.

I did like one thing he said though, which has nothing to do with pairing... he said they require developers to purchase their own laptops. Like a mechanic or carpenter provides his own tools. That makes some sense to me. Let people chose the tools that they are most familiar with and most productive using.

<comment><USER29> I think critics tend to compare pair programming to those moments when they are most productive. One programmer in flow may be able to really crank something cool out in a day or so. He might even work 25 hours straight to do it, and really get it out there. If he spends the next week polishing, tweaking, and adding very little functionality, he doesn't include that in his comparison to pair programming. He did it in 25 hours, it took a pair of programmers three days, the pairs are slower, even though the pairs are done and have moved on to other, important stuff.

Pair programmers who work 6 hour days can finish a lot of useful functionality in a week or two. They also have social lives, get to take long lunches, go hiking on the weekends, etc., even though they are very productive. This is why I prefer it. Plus, it's totally sustainable, and it comes with a built-in training methodology.

I used to think that everyone really should start pairing. But I'm more in the camp now that people should form little organizations that pair and basically put everyone else out of business. If it's more productive, places like hashrocket are going to become the leading shops for software. Their employees are going to make twice the market rate, have social lives, good friends at work, interesting problems to work on, and relativley low stress. If it's not more productive, they'll probably eventually have trouble competing.

<comment><USER15> Bravo!

The burnout objection is laughable. Our consultants are required to bill 35 hours per week, which translates to an average of 7 hours of coding or less every day (there is billable work like meetings that is not writing production code).

We don't work weekends and we don't do overtime. Like, ever.

<comment><USER30> Only one form of burnout comes from long hours though. It can also come from repetitive tasks that require little thought, or in your particular case, being forced to approach problems in a rigid manner that isn't in your natural style.

That being said, you've made it clear that your entire team already fits your style, right down to having the same preferences in breath odour. I wonder though how much productivity is lost managing that aspect of things. :-)

</comment></comment></comment></comment><comment><USER31> Pair programming is an attempt to take two good programmers and turn them into one great programmer. If you hire great programmers in the first place, it is unnecessary and wasteful.

<comment><USER32> That depends on the difficult of what they're developing.

Boilerplate code? Two great programmers are a waste.

Moderate difficulty? Maybe less efficient than working separately, but they'll still work a bit faster, produce fewer defects, transfer knowledge well, etc.

Really complex problem? Not a waste at all.

</comment></comment><comment><USER30> _Being honestly hard-working is still one of the best ways to earn accolades and raises. Accolades and raises usually bring some measure of added happiness._

You know what I think produces better measures of added happiness? Not working in a sweatshop.

My major problem with pair programming is that it has the effect of treating programmers like children that need to be controlled. This is no different than the corporate drone being assigned a single task to do over and over again. It's more productive sure, but it's similarly a death march.

Sorry, but people aren't cogs in a machine. They goof off, they're unmotivated, and sometimes - believe it or not - they do other things besides work.

I'd much rather employ programmers in a traditional sense who are happy, goofy, disagree a lot and are somewhat productive than have a super productive team of like thinking robots, because essentially that's what you need to make pair programming work.

Productivity is not the be all and end all.

</comment><comment><USER33> Depressing but accurate reading.

Even the standard "pairing sucks" advocates in the comments agree that these things are what is stopping the average IT shop from being productive and professional.

And, while as I say it's depressing, it also kind of makes me feel better to know that most everybody else is in the same boat.

<comment><USER28> I think pairing sucks. Based on my personal experience with it. I'm just not cut out for it, mostly. I'm more comfortable and productive in the the "private office with a door" environment that DeMarco and Spolsky advocate. I don't dispute that pairing works for some people, in some situations.

Despite the overall "we're so smart and so much better than everyone else" attitude in this piece, the still-relevant conclusion is that pairing is not easy, requires large investments in both physical assets and people who want to work that way. He even admits that once your team is larger than a dozen or so, the feasibility of pairing starts to break down because of personality conflicts.

<comment><USER33> You've apparently been thrown off course by the love-it-or-loathe it reaction to pairing, but you're actually _agreeing_ with the article. He's listing why it _isn't_ feasible for most situations. (Though most people seem to interpret this as reverse psychology, though I would suggest any appraisal of the general practice of software development that doesn't portray it as almost totally broken is far from accurate).

But really I could write a long (sometimes contradictory) list of things that would help people program better that would get similar levels of reaction:

      * use vi
      * use emacs
      * use an IDE
      * TDD
      * unit testing
      * any kind of testing
      * writing documentation
      * using the highest level language possible
      * using C++
      * using anything but C++
      * source control
      * distributed source control
      * avoiding gotos

Judging by the _slightly over-emotional_ responses in this thread to pairing you only need to find one good bit of software written without these tools/ideas and you can ignore them totally. Apparently, in your case, an individual not liking something, or it being hard, or requiring investment or not being suitable for all sizes of teams rules it out, which covers most of this list.

I would suggest doing hard things you don't like, which require investment and need to be applied appropriately to your context is a pretty good definition of "profesionalism", something sorely lacking in most software development shops but on the other hand just because it fits that definition doesn't mean it's the right thing to do.

I think that pairing, like many things in this list, can be appropriate and useful but I'm not about to burn anyone as a witch if they don't like it or practice it.

<comment><USER28> Oh your reply just crystalized one of the main problems I had with pairing. See, I use emacs and a bunch of command line tools. Almost everyone else in the shop used visual studio. I think one other guy used some editor he liked. So to pair with someone I had to use visual studio, which is like asking a master carpenter to use a hammer and saw that were picked up at Wal-Mart instead of the tools he had spent a decade mastering.

So in order to pair effectively, everyone has to use the same tools. And that's going to be a big problem for people who don't like those tools. I don't think the article really hit that point.

EDIT: Oh and your little aside: _I would suggest any appraisal of the general practice of software development that doesn't portray it as almost totally broken is far from accurate_ is fabulous. Love it.

</comment></comment></comment></comment><comment><USER34> Pair programming works. However, I don't see the point in using it all the time - in some situations, it's only as effective as working solo. It really rocks for crisis situations (pair debugging) or new feature implementation quickly (all-night coding).

Flow is a very important part of pair programming.

</comment><comment><USER35> I've tried pair programming a few times at several companies, and while it's occasionally been great to work through a specific problem, in general I wasn't a fan, it was awkward and boring. But recently, at my startup, I've been sitting on the couch coding on the TV (because I switched over to iPhone development and the only spare mac was the TV mac mini, and it can't drive my 30 inch monitor.) Pair programming has actually been happening fluidly with this set up, and it's been great. It's comfortable to sit side by side and both have a head-on view of the large monitor.

</comment><comment><USER36> Let me get this straight. Did he just claim that managers need to be willing to fire someone for having bad breath? And he has the nerve to accuse others of tolerating anti-social behavior?

</comment><comment><USER37> pair programming went out of fashion for the same reason foosball tables in the office did: it was a dumb idea somebody concocted in the haze of the dotcom boom. reality eventually reasserted itself, we grew up, and learned to work like professionals.

if the only way to keep your developers busy and not goofing off is to have someone looking over their shoulder, then you, my misguided friend, fail as a leader.

</comment><comment><USER20> I just want to point out that saying "You're doing it wrong" (as the article does) does not necessarily imply that you could be doing it right. It doesn't have to be taken as a condemnation of your skills/ability. It simply won't work in all situations and the article does a pretty good job of pointing out blockers to pairing working.

</comment><comment><USER38> Pair programming seems like one of those necessary evils. I don't find working with a partner any fun in terms of the joy of hacking stuff out and figuring stuff out on your own, but I see the value in having multiple eyes on code, and I'm sure it could have found lots of bugs in my past.

</comment><comment><USER39> Yes, arrogant and absurd. It does prove one thing (yet again). Beware of Methodology Cults. That's what Agile and 'XP' are (who'd want to name a methodology after a failed operating system, by the way).

Kent Beck = Jim Jones. Beware.

</comment><comment><USER40> Never really done pair programming, but I'm struck by how much it's culture- dependent, and how easily it can be undone by initial assumptions. "We'll save money on furniture." "That guy's good, but too expensive."

</comment><comment><USER41> From my experience on pair programming: \- it occurs naturally if you give two programmers one computer and one problem. \- one programmer becomes tactician/executor, other one becomes strategist/supervisor \- tactician thinks how to make loop to iterate properly, strategists thinks why to make loop and what to do next. \- it helps immensely to have someone who has different ideas than you on your side, if you are willing to submit to this ideas if you don't have other than idealistic arguments against them.

</comment><comment><USER42> In my experience pair programming works best when used on hard problems. If you're doing the sort of coding where there is no complex problem solving involved and you're basically limited by your typing speed then pair programming is probably just hindrance.

However for the sort of hard complex problem that is pushing you to your limit and requires hours of thought, testing and prototyping to produce a dozen lines of production code I find it can be enormously effective if paired with the right sort of person.

</comment><comment><USER13> that one guy at work, he either doesn't shower often enough for his type or he never heard of deodorant.

as long as the wind blows away from him (windows open), that's not a bother though.

edit: i thought i should share some of my pair programming experiences and insights...

one time a friend and I programmed some ATmega embedded assignment for a course. what happened was that we sat down on a couch in the library (our faculty cares!), laptops on our laps.

and then the mind meld began...

i mostly talked about what i was writing at the moment, what considerations i put into each call and conditional. reasoning out loud about various conditions that could or could not happen. i did that so we were on the same page and he would not hesitate to ask if anything was looking suspicious. the resulting code felt very pure, i must say.

he had our plans, schematics and pinouts handy and kept track of the coding progress (this done, that left). he knew how the parts would fit together and steered the process.

i should pick his brain some more on that experience sometime.

the other time was at work, where a coworker got me to sit with him for my experience with the python language. he went through that rushed job of spaghetti while my eyes glazed over because i hadn't seen the code before. occasionally i pulled on this and that dangling thread to see what was attached, which gave me some insight and him some more things to fix (logic bugs mostly).

that code still is buggy as hell (also because it interfaces with/works around another buggy pile of shit), which is why i asked for a real code review. code reviews are done rarely enough that i'm afraid it's gonna end without much gain.

</comment><comment><USER43> Why hasn't Pair Programming extended itself beyond just programming? What about something like "Pair Accounting"? "Pair Book Writing"? I don't see anyone arguing that the cubicle office is fundamentally flawed, except for in cases where people are anti-social and don't like each other.

<comment><USER44> Then you haven't been reading much. I've seen tons of objections to cubicles, some anecdotal and some based on scientific evidence such as noise levels and interruptions from people walking by and chatting disrupting flow.

Even the guy that invented the cubicle hates it. His original idea was for a workstation where you could do some work standing, some sitting, use 3d space and not just 2d. I think we can all see how far from the original concept we have come.

My objection to cubicles comes down to 2 things: Can't control lighting (and offices always have those wretched overhead fluorescents) and there's always that disconcerting feeling someone is standing there staring at you when you essentially have your back to the whole room.

</comment></comment><comment><USER45> Pair programming is good for UI/HCIish code and so so for other types of code. Studies have shown that human are not good at multitasking even though it makes them _feel_ productive.

Personally I think pair programming is overrated while code review is still underrated.

</comment><comment><USER46> Pair programming bad. Pair debugging good.

</comment><comment><USER47> From a quick, unscientific survey of the discussion around pair programming it looks like most of the people who have tried pair programming like it, and most of the people who haven't think it would suck. Is anyone else noticing this pattern?

<comment><USER18> The article provides 10 reasons why pair programming might not work. Moreover, it says that these reasons are very common:

      10. Most software managers...
      9. Most software shops...
      8. Most software shops...
      7. Most software shops...
      6. Most software people...
      5. Most software shops...
      4. Most software shops...
      3. Most software developers...
      2. Most software developers...
      1. Most software shops...

Do you see the pattern: most pair programming attempts, if they happen, fail, because of "Most of the...".

You write: "most of the people who have tried pair programming like it". Your conclusion is contrary to one of the the article.

</comment></comment><comment><USER48> Personally the idea of pair programming would suck out the joy of programming for me. I just can't stand the thought of not thinking through what I am doing and talking about it, is way slower than doing it in my head.

<comment><USER49> I think the point is to think-and-talk instead of think-and-rewrite.

<comment><USER50> Someone who is able to think and talk at the same speed is either an impractically fast talker or an impractically slow thinker.

<comment><USER13> sacrifice "speed" for validated thought.

pair programming intends to _prevent_ rushed spaghetti code and replaces it with deliberate code that was born from the shared thought of several people.

<comment><USER50> Spaghetti code is not necessarily the result of fast thinking... shallow is enough... fast or slow.

However, fast thinking is necessary for playing out different versions of a solution inside one's head and generally for analyzing the suitability and elegance of one. That process is fast, internal and generally not conductive of talking. Just concentration and discipline. Also, verbalizing a thinking process is always a lossy compression. At least for me. And it's not because I don't know how to express myself, although I might not be very good at that either. It's because verbalizing a thinking process always feels like serialization of an inherently parallel and _real time_ process. The mouth is a shared resource here.

<comment><USER49> While you can evaluate elegance and simplicity in your head that doesn't work for edge cases and side effects. That's were talking and writing and sketching are helpful. I don't encounter much code where i can hack with the flow. Mostly the task is either utterly boring or too complex for my little head.

</comment></comment></comment></comment></comment></comment><comment><USER51> Pair programing is not for everyone. Like any other method. Pair programing is for motivated, enthusiastic and even addicted people. It is a different approach to the problem, which people must have curiousness, motivation and courage to try. Try together.

It cannot be forced or set up by the managers. It cannot be motivated by money. It is for passionate people, who have a desire to solve some problem or get things better together.

btw, Kent Beck's "Extreme Programming Explained" stats clear that it isn't a silver bullet and it didn't work alone. Only together with testing, planing, small changes and continuous integration. It is a part of collective effort.

And of course, passionate and enthusiastic people don't give a damn to things like halitosis when they're doing together that they really love to do.</comment>